cafkafk/nixpkgs
cafkafk/nixpkgs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2
nixpkgs/pkgs/development/libraries/mesa/disk_cache-include-dri-driver-path-in-cache-key.patch

75 lines
2.5 KiB
Diff
Raw Normal View History

Recover the complicated situation after my bad merge I made a mistake merge. Reverting it in c778945806b undid the state on master, but now I realize it crippled the git merge mechanism. As the merge contained a mix of commits from `master..staging-next` and other commits from `staging-next..staging`, it got the `staging-next` branch into a state that was difficult to recover. I reconstructed the "desired" state of staging-next tree by: - checking out the last commit of the problematic range: 4effe769e2b - `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken merge commit and its revert from that range (while keeping reapplication from 4effe769e2) - merging the last unaffected staging-next commit (803ca85c209) - fortunately no other commits have been pushed to staging-next yet - applying a diff on staging-next to get it into that state
2020-10-25 22:17:24 +01:00
From 980164fd92f5c2302624cd046d30ff21e6e4ba8a Mon Sep 17 00:00:00 2001
mesa: add patch to include driver path in cache key Mesa usually uses the timestamps of the llvm and driver shared libraries as a cache key. In /nix/store these are all zero, so we'll include $(drivers) in the cache key, which should be unique for all combinations of mesa and llvm versions.
2018-08-06 21:23:02 +02:00
From: David McFarland <corngood@gmail.com>
Date: Mon, 6 Aug 2018 15:52:11 -0300
Subject: [PATCH] disk_cache: include dri driver path in cache key
This fixes invalid cache hits on NixOS where all shared library
timestamps in /nix/store are zero.
---
mesa: build with meson
2019-03-27 00:41:50 +01:00
meson_options.txt | 6 ++++++
mesa: add patch to include driver path in cache key Mesa usually uses the timestamps of the llvm and driver shared libraries as a cache key. In /nix/store these are all zero, so we'll include $(drivers) in the cache key, which should be unique for all combinations of mesa and llvm versions.
2018-08-06 21:23:02 +02:00
src/util/disk_cache.c | 3 +++
mesa: build with meson
2019-03-27 00:41:50 +01:00
src/util/meson.build | 7 ++++++-
3 files changed, 15 insertions(+), 1 deletion(-)
mesa: add patch to include driver path in cache key Mesa usually uses the timestamps of the llvm and driver shared libraries as a cache key. In /nix/store these are all zero, so we'll include $(drivers) in the cache key, which should be unique for all combinations of mesa and llvm versions.
2018-08-06 21:23:02 +02:00
mesa: build with meson
2019-03-27 00:41:50 +01:00
diff --git a/meson_options.txt b/meson_options.txt
Recover the complicated situation after my bad merge I made a mistake merge. Reverting it in c778945806b undid the state on master, but now I realize it crippled the git merge mechanism. As the merge contained a mix of commits from `master..staging-next` and other commits from `staging-next..staging`, it got the `staging-next` branch into a state that was difficult to recover. I reconstructed the "desired" state of staging-next tree by: - checking out the last commit of the problematic range: 4effe769e2b - `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken merge commit and its revert from that range (while keeping reapplication from 4effe769e2) - merging the last unaffected staging-next commit (803ca85c209) - fortunately no other commits have been pushed to staging-next yet - applying a diff on staging-next to get it into that state
2020-10-25 22:17:24 +01:00
index 2d39d13b6ad..daf06480a60 100644
mesa: build with meson
2019-03-27 00:41:50 +01:00
--- a/meson_options.txt
+++ b/meson_options.txt
Recover the complicated situation after my bad merge I made a mistake merge. Reverting it in c778945806b undid the state on master, but now I realize it crippled the git merge mechanism. As the merge contained a mix of commits from `master..staging-next` and other commits from `staging-next..staging`, it got the `staging-next` branch into a state that was difficult to recover. I reconstructed the "desired" state of staging-next tree by: - checking out the last commit of the problematic range: 4effe769e2b - `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken merge commit and its revert from that range (while keeping reapplication from 4effe769e2) - merging the last unaffected staging-next commit (803ca85c209) - fortunately no other commits have been pushed to staging-next yet - applying a diff on staging-next to get it into that state
2020-10-25 22:17:24 +01:00
@@ -368,6 +368,12 @@ option(
mesa: build with meson
2019-03-27 00:41:50 +01:00
value : true,
description : 'Enable direct rendering in GLX and EGL for DRI',
)
+option(
+ 'disk-cache-key',
+ type : 'string',
+ value : '',
+ description : 'Mesa cache key.'
+)
mesa: 19.2.7 -> 19.3.1
2020-01-03 17:57:49 +01:00
option(
Recover the complicated situation after my bad merge I made a mistake merge. Reverting it in c778945806b undid the state on master, but now I realize it crippled the git merge mechanism. As the merge contained a mix of commits from `master..staging-next` and other commits from `staging-next..staging`, it got the `staging-next` branch into a state that was difficult to recover. I reconstructed the "desired" state of staging-next tree by: - checking out the last commit of the problematic range: 4effe769e2b - `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken merge commit and its revert from that range (while keeping reapplication from 4effe769e2) - merging the last unaffected staging-next commit (803ca85c209) - fortunately no other commits have been pushed to staging-next yet - applying a diff on staging-next to get it into that state
2020-10-25 22:17:24 +01:00
'prefer-iris',
mesa: 19.2.7 -> 19.3.1
2020-01-03 17:57:49 +01:00
type : 'boolean',
mesa: add patch to include driver path in cache key Mesa usually uses the timestamps of the llvm and driver shared libraries as a cache key. In /nix/store these are all zero, so we'll include $(drivers) in the cache key, which should be unique for all combinations of mesa and llvm versions.
2018-08-06 21:23:02 +02:00
diff --git a/src/util/disk_cache.c b/src/util/disk_cache.c
Recover the complicated situation after my bad merge I made a mistake merge. Reverting it in c778945806b undid the state on master, but now I realize it crippled the git merge mechanism. As the merge contained a mix of commits from `master..staging-next` and other commits from `staging-next..staging`, it got the `staging-next` branch into a state that was difficult to recover. I reconstructed the "desired" state of staging-next tree by: - checking out the last commit of the problematic range: 4effe769e2b - `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken merge commit and its revert from that range (while keeping reapplication from 4effe769e2) - merging the last unaffected staging-next commit (803ca85c209) - fortunately no other commits have been pushed to staging-next yet - applying a diff on staging-next to get it into that state
2020-10-25 22:17:24 +01:00
index a92d621927a..3bd65c6890c 100644
mesa: add patch to include driver path in cache key Mesa usually uses the timestamps of the llvm and driver shared libraries as a cache key. In /nix/store these are all zero, so we'll include $(drivers) in the cache key, which should be unique for all combinations of mesa and llvm versions.
2018-08-06 21:23:02 +02:00
--- a/src/util/disk_cache.c
+++ b/src/util/disk_cache.c
Recover the complicated situation after my bad merge I made a mistake merge. Reverting it in c778945806b undid the state on master, but now I realize it crippled the git merge mechanism. As the merge contained a mix of commits from `master..staging-next` and other commits from `staging-next..staging`, it got the `staging-next` branch into a state that was difficult to recover. I reconstructed the "desired" state of staging-next tree by: - checking out the last commit of the problematic range: 4effe769e2b - `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken merge commit and its revert from that range (while keeping reapplication from 4effe769e2) - merging the last unaffected staging-next commit (803ca85c209) - fortunately no other commits have been pushed to staging-next yet - applying a diff on staging-next to get it into that state
2020-10-25 22:17:24 +01:00
@@ -401,8 +401,10 @@ disk_cache_create(const char *gpu_name, const char *driver_id,
mesa: add patch to include driver path in cache key Mesa usually uses the timestamps of the llvm and driver shared libraries as a cache key. In /nix/store these are all zero, so we'll include $(drivers) in the cache key, which should be unique for all combinations of mesa and llvm versions.
2018-08-06 21:23:02 +02:00
/* Create driver id keys */
mesa: 18.2.2 -> 18.2.3 https://lists.freedesktop.org/archives/mesa-dev/2018-October/207343.html Optimistically drop disk cache patch, changelog mentions related changes to cache behavior. Not sure if those changes address our problem (can we count on build-id?) so someone more familiar with this should probably take a look before merging :).
2018-10-20 03:42:21 +02:00
size_t id_size = strlen(driver_id) + 1;
mesa: add patch to include driver path in cache key Mesa usually uses the timestamps of the llvm and driver shared libraries as a cache key. In /nix/store these are all zero, so we'll include $(drivers) in the cache key, which should be unique for all combinations of mesa and llvm versions.
2018-08-06 21:23:02 +02:00
+ size_t key_size = strlen(DISK_CACHE_KEY) + 1;
size_t gpu_name_size = strlen(gpu_name) + 1;
mesa: 18.2.2 -> 18.2.3 https://lists.freedesktop.org/archives/mesa-dev/2018-October/207343.html Optimistically drop disk cache patch, changelog mentions related changes to cache behavior. Not sure if those changes address our problem (can we count on build-id?) so someone more familiar with this should probably take a look before merging :).
2018-10-20 03:42:21 +02:00
cache->driver_keys_blob_size += id_size;
mesa: add patch to include driver path in cache key Mesa usually uses the timestamps of the llvm and driver shared libraries as a cache key. In /nix/store these are all zero, so we'll include $(drivers) in the cache key, which should be unique for all combinations of mesa and llvm versions.
2018-08-06 21:23:02 +02:00
+ cache->driver_keys_blob_size += key_size;
cache->driver_keys_blob_size += gpu_name_size;
/* We sometimes store entire structs that contains a pointers in the cache,
Recover the complicated situation after my bad merge I made a mistake merge. Reverting it in c778945806b undid the state on master, but now I realize it crippled the git merge mechanism. As the merge contained a mix of commits from `master..staging-next` and other commits from `staging-next..staging`, it got the `staging-next` branch into a state that was difficult to recover. I reconstructed the "desired" state of staging-next tree by: - checking out the last commit of the problematic range: 4effe769e2b - `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken merge commit and its revert from that range (while keeping reapplication from 4effe769e2) - merging the last unaffected staging-next commit (803ca85c209) - fortunately no other commits have been pushed to staging-next yet - applying a diff on staging-next to get it into that state
2020-10-25 22:17:24 +01:00
@@ -423,6 +425,7 @@ disk_cache_create(const char *gpu_name, const char *driver_id,
mesa: add patch to include driver path in cache key Mesa usually uses the timestamps of the llvm and driver shared libraries as a cache key. In /nix/store these are all zero, so we'll include $(drivers) in the cache key, which should be unique for all combinations of mesa and llvm versions.
2018-08-06 21:23:02 +02:00
uint8_t *drv_key_blob = cache->driver_keys_blob;
DRV_KEY_CPY(drv_key_blob, &cache_version, cv_size)
mesa: 18.2.2 -> 18.2.3 https://lists.freedesktop.org/archives/mesa-dev/2018-October/207343.html Optimistically drop disk cache patch, changelog mentions related changes to cache behavior. Not sure if those changes address our problem (can we count on build-id?) so someone more familiar with this should probably take a look before merging :).
2018-10-20 03:42:21 +02:00
DRV_KEY_CPY(drv_key_blob, driver_id, id_size)
mesa: add patch to include driver path in cache key Mesa usually uses the timestamps of the llvm and driver shared libraries as a cache key. In /nix/store these are all zero, so we'll include $(drivers) in the cache key, which should be unique for all combinations of mesa and llvm versions.
2018-08-06 21:23:02 +02:00
+ DRV_KEY_CPY(drv_key_blob, DISK_CACHE_KEY, key_size)
DRV_KEY_CPY(drv_key_blob, gpu_name, gpu_name_size)
DRV_KEY_CPY(drv_key_blob, &ptr_size, ptr_size_size)
DRV_KEY_CPY(drv_key_blob, &driver_flags, driver_flags_size)
mesa: build with meson
2019-03-27 00:41:50 +01:00
diff --git a/src/util/meson.build b/src/util/meson.build
Recover the complicated situation after my bad merge I made a mistake merge. Reverting it in c778945806b undid the state on master, but now I realize it crippled the git merge mechanism. As the merge contained a mix of commits from `master..staging-next` and other commits from `staging-next..staging`, it got the `staging-next` branch into a state that was difficult to recover. I reconstructed the "desired" state of staging-next tree by: - checking out the last commit of the problematic range: 4effe769e2b - `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken merge commit and its revert from that range (while keeping reapplication from 4effe769e2) - merging the last unaffected staging-next commit (803ca85c209) - fortunately no other commits have been pushed to staging-next yet - applying a diff on staging-next to get it into that state
2020-10-25 22:17:24 +01:00
index 0893f64793b..d46ce85a85f 100644
mesa: build with meson
2019-03-27 00:41:50 +01:00
--- a/src/util/meson.build
+++ b/src/util/meson.build
Recover the complicated situation after my bad merge I made a mistake merge. Reverting it in c778945806b undid the state on master, but now I realize it crippled the git merge mechanism. As the merge contained a mix of commits from `master..staging-next` and other commits from `staging-next..staging`, it got the `staging-next` branch into a state that was difficult to recover. I reconstructed the "desired" state of staging-next tree by: - checking out the last commit of the problematic range: 4effe769e2b - `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken merge commit and its revert from that range (while keeping reapplication from 4effe769e2) - merging the last unaffected staging-next commit (803ca85c209) - fortunately no other commits have been pushed to staging-next yet - applying a diff on staging-next to get it into that state
2020-10-25 22:17:24 +01:00
@@ -179,7 +179,12 @@ _libmesa_util = static_library(
include_directories : [inc_include, inc_src, inc_mapi, inc_mesa, inc_gallium, inc_gallium_aux],
mesa: 19.2.7 -> 19.3.1
2020-01-03 17:57:49 +01:00
dependencies : deps_for_libmesa_util,
mesa: 19.3.3 -> 20.0.1 New APIs implemented: OpenGL 4.6 and Vulkan 1.2
2020-03-11 14:39:20 +01:00
link_with: libmesa_format,
Recover the complicated situation after my bad merge I made a mistake merge. Reverting it in c778945806b undid the state on master, but now I realize it crippled the git merge mechanism. As the merge contained a mix of commits from `master..staging-next` and other commits from `staging-next..staging`, it got the `staging-next` branch into a state that was difficult to recover. I reconstructed the "desired" state of staging-next tree by: - checking out the last commit of the problematic range: 4effe769e2b - `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken merge commit and its revert from that range (while keeping reapplication from 4effe769e2) - merging the last unaffected staging-next commit (803ca85c209) - fortunately no other commits have been pushed to staging-next yet - applying a diff on staging-next to get it into that state
2020-10-25 22:17:24 +01:00
- c_args : [c_msvc_compat_args],
mesa: build with meson
2019-03-27 00:41:50 +01:00
+ c_args : [
Recover the complicated situation after my bad merge I made a mistake merge. Reverting it in c778945806b undid the state on master, but now I realize it crippled the git merge mechanism. As the merge contained a mix of commits from `master..staging-next` and other commits from `staging-next..staging`, it got the `staging-next` branch into a state that was difficult to recover. I reconstructed the "desired" state of staging-next tree by: - checking out the last commit of the problematic range: 4effe769e2b - `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken merge commit and its revert from that range (while keeping reapplication from 4effe769e2) - merging the last unaffected staging-next commit (803ca85c209) - fortunately no other commits have been pushed to staging-next yet - applying a diff on staging-next to get it into that state
2020-10-25 22:17:24 +01:00
+ c_msvc_compat_args,
mesa: build with meson
2019-03-27 00:41:50 +01:00
+ '-DDISK_CACHE_KEY="@0@"'.format(
+ get_option('disk-cache-key')
+ ),
+ ],
Recover the complicated situation after my bad merge I made a mistake merge. Reverting it in c778945806b undid the state on master, but now I realize it crippled the git merge mechanism. As the merge contained a mix of commits from `master..staging-next` and other commits from `staging-next..staging`, it got the `staging-next` branch into a state that was difficult to recover. I reconstructed the "desired" state of staging-next tree by: - checking out the last commit of the problematic range: 4effe769e2b - `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken merge commit and its revert from that range (while keeping reapplication from 4effe769e2) - merging the last unaffected staging-next commit (803ca85c209) - fortunately no other commits have been pushed to staging-next yet - applying a diff on staging-next to get it into that state
2020-10-25 22:17:24 +01:00
gnu_symbol_visibility : 'hidden',
mesa: build with meson
2019-03-27 00:41:50 +01:00
build_by_default : false
)
mesa: add patch to include driver path in cache key Mesa usually uses the timestamps of the llvm and driver shared libraries as a cache key. In /nix/store these are all zero, so we'll include $(drivers) in the cache key, which should be unique for all combinations of mesa and llvm versions.
2018-08-06 21:23:02 +02:00
--
Recover the complicated situation after my bad merge I made a mistake merge. Reverting it in c778945806b undid the state on master, but now I realize it crippled the git merge mechanism. As the merge contained a mix of commits from `master..staging-next` and other commits from `staging-next..staging`, it got the `staging-next` branch into a state that was difficult to recover. I reconstructed the "desired" state of staging-next tree by: - checking out the last commit of the problematic range: 4effe769e2b - `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken merge commit and its revert from that range (while keeping reapplication from 4effe769e2) - merging the last unaffected staging-next commit (803ca85c209) - fortunately no other commits have been pushed to staging-next yet - applying a diff on staging-next to get it into that state
2020-10-25 22:17:24 +01:00
2.28.0
Reference in a new issue Copy permalink