[Mesa-dev] [RFC] NIR serialization

[Kenneth Graunke]

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.

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/20170908/d81421f3/attachment.sig>