GNU bug report logs - #35575
Some graphical programs borked with Guix on Arch

Previous Next

Full log

View this message in rfc822 format

From: Marius Bakke <mbakke <at> fastmail.com>
To: Brendan Tildesley <mail <at> brendan.scot>, 35575 <at> debbugs.gnu.org
Subject: bug#35575: logo,Some graphical programs borked with Guix on Arch
Date: Tue, 31 Mar 2020 16:53:34 +0200

[Message part 1 (text/plain, inline)]

Brendan Tildesley <mail <at> brendan.scot> 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 (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.