[Mesa-dev] [RFC] NIR serialization

[Ian Romanick]

On 09/11/2017 09:23 PM, 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?
> 
> 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.

And... we wouldn't necessarily have to throw away cached SPIR-V when the
Mesa version changes... though we may want to anyway.

>> 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
> 
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170911/b0b74cfb/attachment.sig>