[Mesa-dev] [RFC] NIR serialization

Tue Sep 12 04:25:00 UTC 2017

On 09/07/2017 04:26 PM, 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 think it's basically a requirement if we want to adequately test
SPIR-V in OpenGL.  The volume of tests for SPIR-V in the CTS is going to
be small compared to the number of tests for GLSL in the CTS and piglit.

> 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
> 
>> - now, the question is if this is worth the additional effort
>>
>> Kind regards,
>> Daniel
>>
>> -------- Forwarded Message --------
>> Subject:        Re: NIR serialization
>> Date:   Tue, 5 Sep 2017 11:00:31 -0700
>> From:   Ian Romanick <idr at freedesktop.org>
>> To:     Daniel Schürmann <daniel.schuermann at campus.tu-berlin.de>, Nicolai 
>> Hähnle <nhaehnle at gmail.com>, Timothy Arceri <tarceri at itsqueeze.com>
>>
>>
>>
>> Sorry for taking so long to reply.  It was a long holiday weekend in the
>> US, and I was away.
>>
>> On 09/01/2017 05:03 AM, Daniel Schürmann wrote:
>>> A direct NIR binary serialization would also do the job (vc4/freedreno
>>> was mentioned as well).
>>> I only thought that SPIRV is preferable because
>>> - deserialization for free
>>> - cached shader size
>>> - spirv-opt and glslang alternative
>>>
>>> The term lossy doesn't make much sense to me with regard to
>>> optimizations: aren't all optimizations lossy?
>>
>> By lossy I mean there is a significant  semantic change.  As soon as
>> GLSL IR is converted to NIR, Boolean types completely cease to exist.
>> They are replaced with integers that are either 0 or -1.  Similarly, all
>> matrix types cease to exist.  They are replaced by a set of vectors.
>>
>> For the purpose of the on-disk cache, this probably doesn't matter.  It
>> does mean that additional information about, for example, types of
>> uniforms has to be tracked.  In a direct GLSL IR to SPIR-V translation,
>> type information is maintained, so the SPIR-V has all the necessary
>> information.
>>
>> As a glslang replacement, maintaining type information is an absolute
>> requirement.  Users will use other tools to introspect the SPIR-V shader
>> to find locations of uniforms, shader inputs, offsets of values in UBOs,
>> etc.  If the types are changed in the SPIR-V shader that we emit, none
>> of that will work.  I plan to enable retrieval of portable SPIR-V both
>> from a Mesa driver and the standalone GLSL compiler.
>>
>> Right now SPIR-V binaries will be quite large.  I have several ideas
>> that I plan to implement once we have OpenGL 4.6 done that should
>> dramatically reduce the size of SPIR-V... I'm actually hoping to present
>> that at FOSDEM.
>>
>>> The primary goal would be the lossless NIR-SPIRV-NIR round-trip.
>>> Secondary, it would be desirable if we achieve valid SPIRV binaries
>>> which preserve the semantics of the original shader.
>>> And here is the question if this is possible with the type information
>>> that are available...
>>>
>>> Ian: can you hint me to your repository? I couldn't find it.
>>
>> https://cgit.freedesktop.org/~idr/mesa/log/?h=emit-spirv
>>
>>> Kind regards,
>>>
>>> Daniel
>>>
>>>
>>> On 09/01/2017 12:16 PM, Nicolai Hähnle wrote:
>>>> In addition to using NIR-based optimizations, I believe Timothy
>>>> mentioned that a method for serializing NIR would help the shader disk
>>>> cache of i965. It would certainly help radeonsi if/when we switch to
>>>> the NIR backend, because we could compile new shader variants without
>>>> falling back all the way to GLSL. For that, a lossless NIR-SPIRV-NIR
>>>> path would do the job.
>>>>
>>>> Not that falling back all the way to GLSL from radeonsi is impossible,
>>>> but it would also require a whole bunch of new groundwork to be done
>>>> -- basically, we would need multi-threaded GLSL compilation and linking.
>>>>
>>>> Cheers,
>>>> Nicolai
>>>>
>>>>
>>>> On 01.09.2017 02:41, Ian Romanick wrote:
>>>>> I have been working on GLSL IR to SPIR-V. I have a bunch of stuff in
>>>>> the emit-spirv branch of my freedesktop.org tree.  Once that is done, it
>>>>> should be pretty trivial to adapt it to NIR to SPIR-V, but I don't know
>>>>> how useful that would be for Mesa.  Part of the problem is NIR loses a
>>>>> lot of information about types (bool and matrix types), so a
>>>>> SPIRV-NIR-SPIRV path would necessarily be lossy.
>>>>>
>>>>> On the flip side, GLSL IR lacks a huge number of optimizations that
>>>>> exist in NIR, so it's probably not a huge improvement over spirv-opt.
>>>>>
>>>>> On 08/26/2017 02:33 PM, Nicolai Hähnle wrote:
>>>>>> Hey Ian,
>>>>>>
>>>>>> Have you done any more concrete work on NIR serialization? See below...
>>>>>>
>>>>>> Cheers,
>>>>>> Nicolai
>>>>>>
>>>>>> On 26.08.2017 23:17, Daniel Schürmann wrote:
>>>>>>> Hello Nicolai,
>>>>>>>
>>>>>>> I'm a Master student (CS) from TU Berlin and currently writing an
>>>>>>> OpenMP backend for clang using SPIR-V/OpenCL for my thesis. As I'm
>>>>>>> interested in mesa and graphics driver development since long time, I
>>>>>>> would like to get involved a little bit.
>>>>>>>
>>>>>>> Recently, I read your [RFC] ARB_gl_spirv and NIR backend for radeonsi.
>>>>>>> You propose a serialization of NIR either directly or by using SPIR-V
>>>>>>> as binary format.
>>>>>>> I wanted to ask if you (or someone else) already started implementing
>>>>>>> this because it seems to be a nice task for me to get into mesa and
>>>>>>> NIR.
>>>>>>> I would rather try to use SPIR-V as binary format for two (not yet
>>>>>>> mentioned) reasons:
>>>>>>> - it could be used as a replacement for spirv-opt and draw some
>>>>>>> attention
>>>>>>> - I expect SPIR-V to be smaller than a raw (unoptimized) serialization
>>>>>>> of NIR.
>>>>>>>
>>>>>>> The round-trip NIR -> SPIRV -> NIR should preserve all information
>>>>>>> while SPIRV -> NIR -> SPIRV must preserve the semantic meaning. Please
>>>>>>> tell me, if your know about some hindering obstacles or if someone is
>>>>>>> already working on this.
>>>>>>>
>> [snip]
>>>>>>>
>>>>>>> Thank you for your time,
>>>>>>> kind regards,
>>>>>>>
>>>>>>> Daniel
>>
>>
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 