[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#35575: logo,Some graphical programs borked with Guix on Arch

From: Marius Bakke
Subject: bug#35575: logo,Some graphical programs borked with Guix on Arch
Date: Tue, 31 Mar 2020 16:53:34 +0200
User-agent: Notmuch/0.29.3 (https://notmuchmail.org) Emacs/26.3 (x86_64-pc-linux-gnu)

Brendan Tildesley <address@hidden> 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?

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]