[Mesa-dev] [RFC] NIR serialization

Jordan Justen jordan.l.justen at intel.com
Tue Sep 12 06:55:18 UTC 2017


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.

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


More information about the mesa-dev mailing list