<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 13, 2017 at 8:42 AM, Nicolai Hähnle <span dir="ltr"><<a href="mailto:nhaehnle@gmail.com" target="_blank">nhaehnle@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">On 13.09.2017 11:54, Eero Tamminen wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hi,<br>
<br>
On 12.09.2017 09:55, Jordan Justen 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 2017-09-11 21:44:32, Timothy Arceri 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 12/09/17 14:23, Ian Romanick 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 09/08/2017 01:59 AM, Kenneth Graunke 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>
We shouldn't use SPIR-V for the shader cache.<br>
<br>
The compilation process for GLSL is: GLSL -> GLSL IR -> NIR -> i965 IRs.<br>
Storing the content at one of those points, and later loading it and<br>
resuming the normal compilation process from that point...that's totally<br>
reasonable.<br>
<br>
Having a fallback for "some things in the cache but not all the variants<br>
we needed" suddenly take a different compilation pipeline, i.e. SPIR-V<br>
-> NIR -> ... seems risky.  It's a different compilation path that we<br>
don't normally use.  And one you'd only hit in limited circumstances.<br>
There's a lot of potential for really obscure bugs.<br>
</blockquote>
<br>
Since we're going to expose exactly that path for GL_ARB_spirv / OpenGL<br>
4.6, we'd better make sure it works always.  Right?<br>
<br>
One nice thing about SPIR-V is that all of the handling of uniform<br>
layouts, initial uniform values, attribute locations, etc. is already<br>
serialized.  If I'm not mistaken, that was one of the big pain points<br>
for all of the existing on-disk storage methods.  All of that has been<br>
sorted out for SPIR-V, and we have to make it work anyway.<br>
</blockquote>
<br>
Correct these are the main issues for the fallback path, however this is<br>
only used by i965 (exactly because an intermediate cache is missing).<br>
Using SPIR-V as the intermediate cache means we still need to convert to<br>
NIR and run all the opts, so I don't really see the advantage of caching<br>
to SPIR-V over NIR.<br>
</blockquote>
<br>
For shader cache, hopefully we'll normally have the final program in<br>
the cache, which means the 're-run opt passes' is probably not a big<br>
factor. But, it still seems a fair point.<br>
<br>
I think the biggest advantage of having either nir or spir-v would be<br>
not having to fallback to running the glsl compiler, right?<br>
</blockquote>
<br>
Shader cache is performance optimization aimed at reducing compile times.<br>
<br>
When I earlier profiled it, 2/3 of the shader compilation work is done at linking stage.<br>
</blockquote>
<br></div></div>
Caching NIR would completely eliminate the linking stage for shader variant compiles, since the NIR is already linked.<br></blockquote><div><br></div><div>Yes, so there goes 2/3 of our compile time.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Cheers,<br>
Nicolai<span class="gmail-im gmail-HOEnZb"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Caching done at higher level than the linked binary shaders, may be of questionable performance value, because the caching itself has also some cost (extra code, disk access cache lookups etc).<br>
<br>
Some profiling showing that doing caching at NIR/SPIRV level could measurable help performance (compared to caching overhead), would be appreciated.<br>
<br>
However, if the main purpose of caching NIR/SPIRV is something else than performance[1], then that's a different matter.  It just should be clear what is the aim of this change.<br></blockquote></span></blockquote><div><br></div><div>There are a couple of reasons:</div><div><br></div><div> 1) Caching the linked NIR should git rid of 2/3 to 3/4 of your shader compile time.  That's very significant. Sure, we can do better, but 70% is a big perf boost. :-)  I highly doubt that nir deserialization will be a significant cost.</div><div><br></div><div> 2) Provide a better fall-back when we don't have an Intel GEN binary.  Falling back all the way to GLSL is very expensive and potentially unreliable due to the way OpenGL lets you change bindings post-linking and the changes don't apply until you re-link.  Falling back to linked NIR should have similar reliability to the TGSI cache which seems to be working very well.</div><div><br></div><div>--Jason<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im gmail-HOEnZb"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Maybe we'll see which becomes available first? :)<br>
</blockquote>
<br>
<br>
     - Eero<br>
<br>
[1] Such as:<br>
* better code validation, or<br>
* ability to replace / tweak the cached files to manually test impact of compiler optimizations before implementing them<br>
______________________________<wbr>_________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/mesa-dev</a><br>
</blockquote>
<br>
<br></span><span class="gmail-im gmail-HOEnZb">
-- <br>
Lerne, wie die Welt wirklich ist,<br>
Aber vergiss niemals, wie sie sein sollte.<br></span><div class="gmail-HOEnZb"><div class="gmail-h5">
______________________________<wbr>_________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank">mesa-dev@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/mesa-dev</a><br>
</div></div></blockquote></div><br></div></div>