[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?
signature.asc
Description: PGP signature