On 12/09/17 16:55, Jordan Justen wrote:
On 2017-09-11 21:44:32, Timothy Arceri wrote:
On 12/09/17 14:23, Ian Romanick wrote:
On 09/08/2017 01:59 AM, Kenneth Graunke wrote:
We shouldn't use SPIR-V for the shader cache.
The compilation process for GLSL is: GLSL -> GLSL IR -> NIR -> i965 IRs.
Storing the content at one of those points, and later loading it and
resuming the normal compilation process from that point...that's totally
reasonable.
Having a fallback for "some things in the cache but not all the variants
we needed" suddenly take a different compilation pipeline, i.e. SPIR-V
-> NIR -> ... seems risky. It's a different compilation path that we
don't normally use. And one you'd only hit in limited circumstances.
There's a lot of potential for really obscure bugs.
Since we're going to expose exactly that path for GL_ARB_spirv / OpenGL
4.6, we'd better make sure it works always. Right?
One nice thing about SPIR-V is that all of the handling of uniform
layouts, initial uniform values, attribute locations, etc. is already
serialized. If I'm not mistaken, that was one of the big pain points
for all of the existing on-disk storage methods. All of that has been
sorted out for SPIR-V, and we have to make it work anyway.
Correct these are the main issues for the fallback path, however this is
only used by i965 (exactly because an intermediate cache is missing).
Using SPIR-V as the intermediate cache means we still need to convert to
NIR and run all the opts, so I don't really see the advantage of caching
to SPIR-V over NIR.
For shader cache, hopefully we'll normally have the final program in
the cache, which means the 're-run opt passes' is probably not a big
factor. But, it still seems a fair point.
Using SPIR-V would also require a special path and extra code to do
this, with nir you should just need to load from disk if its not in the
buffer and continue on your way.
I think the biggest advantage of having either nir or spir-v would be
not having to fallback to running the glsl compiler, right?
Maybe we'll see which becomes available first? :) >
-Jordan
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
