<div dir="ltr">On 1 November 2013 05:08, Tapani Pälli <span dir="ltr"><<a href="mailto:tapani.palli@intel.com" target="_blank">tapani.palli@intel.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On 11/01/2013 12:38 PM, Erik Faye-Lund wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Fri, Nov 1, 2013 at 11:35 AM, Tapani Pälli <<a href="mailto:tapani.palli@intel.com" target="_blank">tapani.palli@intel.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 11/01/2013 12:21 PM, Erik Faye-Lund wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Won't using the git-sha1 as a compatibility-criteria cause issues for<br>
developers with local changes? I'm not so worried about this for<br>
OES_get_program_binary itself, but once the shader-cache is in place<br>
it sounds like a potential source of difficult to track down<br>
misbehavior...<br>
</blockquote>
<br>
I agree it might be too aggressive criteria but it is hard to come up with<br>
better and as simple.<br>
</blockquote>
That's not my objection. My objection is that this might give<br>
headaches for people with local modifications to the glsl-compiler.<br>
Local modifications does not affect the git-sha1.<br>
</blockquote>
<br></div></div>
For the automatic shader cache this headache could be helped a bit with a environment variable or drirc setting that can be used during development. On the other hand an automatic cache must work in a transparent way so it should be always able to recover when it fails, so one should only see it as 'slower than usual' (since recompilation/relink required) sort of behaviour. The WIP of the automatic cache I sent some time earlier also marked (renamed) these 'problematic' cached shaders so that they can be detected on further runs and cache can ignore those.<br>

<br>
I agree that it might become problematic, on the other hand it is also easy to just wipe ~/.cache/mesa and disable cache. Not sure if Nvidia or Imagination try to handles these cases with their cache implementations.<span class=""><font color="#888888"><br>
</font></span></blockquote><div><br></div><div>I'm also concerned about this, especially for the automatic shader cache.  During development, we frequently make small changes to the front end, recompile, and then run a small test program, expecting our changes to take effect.  I'm very worried about requiring developers to remember to set an environment variable, change a drirc setting, or wipe out a cache when making changes that haven't been committed yet.  Especially when the consequence of forgetting to do so is that the change you were trying to make won't have any observed effect.  That's the sort of thing that leads people to spend hours chasing phantom bugs.<br>
<br>How about if we have the cache mechanism include the modification time of the mesa .so in the shader binary (in addition to the sha), and reject shader binaries that don't have a matching modification time?  That way if mesa is recompiled, any previously-cached shaders will automatically become invalid without the developer having to do any work.<br>
<br><br></div><div>A related concern I have is: what happens if someone changes their video card, or transplants their hard drive into a different machine that has different graphics hardware?  Different back-ends have different settings of ctx->ShaderCompilerOptions (some back-ends have different values from one chipset to another), so even if the version of Mesa is the same and there are no local developer changes, the linked IR is not going to necessarily be the same if the graphics hardware changes.<br>
<br></div><div>To address this, I'd recommend that we also include the device's PCI ID in the shader binary, and reject mismatched binaries.<br></div></div></div></div>