unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Brendan Tildesley <mail@brendan.scot>
To: 35575@debbugs.gnu.org
Subject: bug#35575: logo,Some graphical programs borked with Guix on Arch
Date: Sun, 29 Mar 2020 15:00:57 +1100	[thread overview]
Message-ID: <adaf110a-cf9a-4df5-b27a-f119a73f9b95@brendan.scot> (raw)
In-Reply-To: <c276ed96-e5a0-975d-7954-77b8831487c0@brendan.scot>

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);

  parent reply	other threads:[~2020-03-30  2:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-05  7:58 bug#35575: Some graphical programs borked with Guix on Arch Brendan Tildesley
2019-05-05 10:33 ` Boris A. Dekshteyn
2019-05-07 11:09 ` Brendan Tildesley
2019-05-08  9:42   ` Boris A. Dekshteyn
2020-03-29  4:00 ` Brendan Tildesley [this message]
2020-03-31 14:53   ` bug#35575: logo,Some " Marius Bakke
2021-02-22  8:31     ` bug#35575: closing. bug has not reoccurred since Brendan Tildesley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=adaf110a-cf9a-4df5-b27a-f119a73f9b95@brendan.scot \
    --to=mail@brendan.scot \
    --cc=35575@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).