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

Previous Next

Package: guix;

Reported by: Brendan Tildesley <mail <at> brendan.scot>

Date: Sun, 5 May 2019 08:00:02 UTC

Severity: normal

Done: Brendan Tildesley <mail <at> brendan.scot>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Brendan Tildesley <mail <at> brendan.scot>
To: 35575 <at> debbugs.gnu.org
Subject: bug#35575: logo,Some graphical programs borked with Guix on Arch
Date: Sun, 29 Mar 2020 15:00:57 +1100
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?

The code:



ralloc_asprintf_append(&buf, "tf: %d ", prog->TransformFeedback.BufferMode);
   for (unsigned int i = 0; i < prog->TransformFeedback.NumVarying; i++) {
      ralloc_asprintf_append(&buf, "%s ",
prog->TransformFeedback.VaryingNames[i]);
   }

   /* SSO has an effect on the linked program so include this when 
generating
    * the sha also.
    */
   ralloc_asprintf_append(&buf, "sso: %s\n",
                          prog->SeparateShader ? "T" : "F");

   /* A shader might end up producing different output depending on the 
glsl
    * version supported by the compiler. For example a different path 
might be
    * taken by the preprocessor, so add the version to the hash input.
    */
   ralloc_asprintf_append(&buf, "api: %d glsl: %d fglsl: %d\n",
                          ctx->API, ctx->Const.GLSLVersion,
                          ctx->Const.ForceGLSLVersion);

   /* We run the preprocessor on shaders after hashing them, so we need to
    * add any extension override vars to the hash. If we don't do this the
    * preprocessor could result in different output and we could load the
    * wrong shader.
    */
   char *ext_override = getenv("MESA_EXTENSION_OVERRIDE");
   if (ext_override) {
      ralloc_asprintf_append(&buf, "ext:%s", ext_override);
   }

   /* DRI config options may also change the output from the compiler so
    * include them as an input to sha1 creation.
    */
   char sha1buf[41];
   _mesa_sha1_format(sha1buf, ctx->Const.dri_config_options_sha1);
   ralloc_strcat(&buf, sha1buf);

   for (unsigned i = 0; i < prog->NumShaders; i++) {
      struct gl_shader *sh = prog->Shaders[i];
      _mesa_sha1_format(sha1buf, sh->sha1);
      ralloc_asprintf_append(&buf, "%s: %s\n",
_mesa_shader_stage_to_abbrev(sh->Stage), sha1buf);







This bug report was last modified 4 years and 91 days ago.

Previous Next


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