Brendan Tildesley <[email protected]> writes: > To follow up on this old bug, I believe the issue may come from here: > https://gitlab.freedesktop.org/mesa/mesa/-/blob/master/src/compiler/glsl/shader_cache.cpp#L144 > > Mesa calculates a sha1 based on some things they reason affect the > output, but likely it is not truely a function of every parameter than > can make a difference to the shader output. When we updated from llvm6 > to lvm7 I'm guessing it changed the shaders somehow, and the llvm > version is not included in the hash. Since I have zero understanding > mesa, I'm not capable of determining the best solution. One thought is > that if we included the mesa /gnu/store path in the calculation, this > would make the hash's truely unique for a given mesa version, but also > cached shaders that /would/ work would be routinely discarded after an > update (i assume?). Would this be sensible or completely break something > else? Should we just add the llvm version, or just start a mesa bug > report asking for input?
Is this still relevant? I haven't heard reports about this in a long time, nor experienced it (anymore) on my super-experimental systems that switch LLVM and Mesa versions all the time. So I think the issue might have been fixed upstream?
signature.asc
Description: PGP signature
