<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/06/2013 12:14 AM, Paul Berry
wrote:<br>
</div>
<blockquote
cite="mid:CA+yLL66vwOw6Dp9uf1_T7uNxmrk=Z_i1NYtsRPaAPxCTDbaryQ@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div dir="ltr">On 1 November 2013 05:08, Tapani Pälli <span
dir="ltr"><<a moz-do-not-send="true"
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
moz-do-not-send="true"
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>
</div>
</div>
</div>
</div>
</blockquote>
<br>
My next plan for adding more validation was to add ir instruction
sizes and a couple important struct sizes as part of the dump, this
would allow some amount of sanity checking but mesa modification
time addition sounds like better idea and would not add so much
additional data.<br>
<br>
<blockquote
cite="mid:CA+yLL66vwOw6Dp9uf1_T7uNxmrk=Z_i1NYtsRPaAPxCTDbaryQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><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>
</blockquote>
<br>
Thanks, this is is a nice idea, currently there's also the vendor
and renderer strings in the dump but so far these have been used
only for debug purposes.<br>
<br>
// Tapani<br>
<br>
</body>
</html>