[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