Hello, Giovanni Biscuolo <g...@xelera.eu> writes:
> Hi Maxim, > > I learned about this issue today > > Maxim Cournoyer <maxim.courno...@gmail.com> writes: > > [...] > >>> After tracing the process, I noticed that the last thing it did was >>> loading its mesa shader cache, stored under: >>> >>> ~/.cache/mesa_shader_cache >>> >>> Deleting that directory resolved the issue. >>> >>> It seems that'd be a bug in Mesa (for failing to determine that it >>> should have invalidated its cache going from version 21 to 22 post >>> core-updates merge). > > AFAIU this issue is still present using mesa 23 since Guillaume Le > Vaillant had to use this workaround yesterday [1] and reported his > backtrace upstream [2] > > If I'm not wrong (i.e. vlc et al are now using mesa 23) this should also > be reported upstream (I can do it if needed). Which upstream are you thinking about? My understanding is that this problem is a Mesa problem, and it's already reported there (the issue linked in [2]). > AFAIU the only thing we can do to fix this bug is to disable the shader > cache (MESA_SHADER_CACHE_DISABLE=true) until a proper fix is found > upstream. Disabling the shader cache sounds like a decent workaround or even definitive solution. One less stale cache to worry about... If it's like the Qt shader cache, the performance hit is probably too small to be noticeable (maybe just slower startup times of complicated opengl applications such as games?). > ...or apply a patch to rename "~/.cache/mesa_shader_cache" to > "~/.cache/mesa<version>_shader_cache" That's another good idea. > Alternatively, we should find a way to make Guix users aware of this > kind of problems and possible workarounds they can apply (it's not > related to this specific bug) I would rather pursue the other above options you suggest, so that it doesn't happen in the first place! Thank you for sharing these ideas. -- Maxim
