[Mesa-dev] [RFC] NIR serialization

[Kenneth Graunke]

On Monday, September 11, 2017 9:23:05 PM PDT Ian Romanick wrote:
> On 09/08/2017 01:59 AM, Kenneth Graunke wrote:
> > On Thursday, September 7, 2017 4:26:04 PM PDT Jordan Justen wrote:
> >> On 2017-09-06 14:12:41, Daniel Schürmann wrote:
> >>> Hello together!
> >>> Recently, we had a small discussion (off the list) about the NIR 
> >>> serialization, which was previously discussed in [RFC] ARB_gl_spirv and 
> >>> NIR backend for radeonsi.
> >>>
> >>> As this topic could be interesting to more people, I would like to 
> >>> share, what was talked about so far (You might want to read from bottom up).
> >>>
> >>> TL;DR:
> >>> - NIR serialization is in demand for shader cache
> >>> - could be done either directly (NIR binary form) or via SPIR-V
> >>> - Ian et al. are working on GLSL IR -> SPIR-V transformation, which 
> >>> could be adapted for a NIR -> SPIR-V pass
> >>> - in NIR representation, some type information is lost
> >>> - thus, a serialization via SPIR-V could NOT be a glslang alternative 
> >>> (otoh, the GLSL IR->SPIR-V pass could), but only for spirv-opt (if the 
> >>> output is valid SPIR-V)
> >>
> >> Ian,
> >>
> >> Tim was suggesting that we might look at serializing nir for the i965
> >> shader cache. Based on this email, it sounds like serialized nir would
> >> not be enough for the shader cache as some GLSL type info would be
> >> lost. It sounds like GLSL IR => SPIR-V would be good enough. Is that
> >> right?
> >>
> >> I don't think we have a strict requirement for the GLSL IR => SPIR-V
> >> path for GL 4.6, right? So, this is more of a 'nice-to-have'?
> >>
> >> I'm not sure we'd want to make i965 shader cache depend on a
> >> nice-to-have feature. (Unless we're pretty sure it'll be available
> >> soon.)
> >>
> >> But, it would be nice to not have to fallback to compiling the GLSL
> >> for i965 shader cache, so it would be worth waiting a little bit to be
> >> able to rely on a SPIR-V serialization of the GLSL IR.
> >>
> >> What do you suggest?
> >>
> >> -Jordan
> > 
> > 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?

In addition to the old pipeline:

- GLSL from the app -> GLSL IR -> NIR -> i965 IR

GL_ARB_spirv and OpenGL 4.6 add a second pipeline:

- SPIR-V from the app -> NIR -> i965 IR

Both of those absolutely have to work.  But these:

- GLSL -> GLSL IR -> NIR -> SPIR-V -> NIR -> i965 IRs
- GLSL -> GLSL IR -> SPIR-V -> NIR -> i965 IRs

aren't required to work, or even be supported.  It makes a lot of sense
to support them - both for testing purposes, and as an alternative to
glslang, for a broader tooling ecosystem.

The thing that concerns me is that if you use SPIR-V for the cache, you
need these paths to not just work, but be _indistinguishable_ from one
another:

- GLSL -> GLSL IR -> NIR -> ...
- GLSL -> GLSL IR -> NIR -> SPIR-V, then SPIR-V -> NIR -> ...

Otherwise the original compile and partially-cached recompile might have
different properties.  For example, if the the SPIR-V step messes with
variables or instruction ordering a little, it could trip up the loop
unroller so the original compiler gets unrolled, and the recompile from
partial cache doesn't get unrolled.  I don't want to have to debug that.

One could avoid this by making the original compile always go through
SPIR-V, and just drop glsl_to_nir altogether, so both take the same
paths.  But...it's kind of an unnecessary step in the common case...

Just serializing/reading back the NIR and resuming the compile from the
exact same IR would also solve that problem.

Or, just being -really- careful with the translator, I guess...

> 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.

That is pretty nice.  I don't recall it being that painful, but, not
reinventing things is kind of nice too...

> > Serializing NIR, and possibly a few auxiliary structures that we need,
> > seems reasonable.  Although, just using the GLSL seemed reasonable to
> > me as well, but I guess that's proven to be painful?
> > 
> > --Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170911/55e10a94/attachment.sig>