[Mesa-dev] [RFC] NIR serialization

Tue Sep 12 19:08:30 UTC 2017

On 12.09.2017 06:25, Ian Romanick wrote:
> 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.

The idea being a stand-alone linker & compiler that supports everything 
Mesa does, but also writes out cross-stage valid locations for uniforms 
and I/O?

The latter is really the biggest pain when working with glslang...

Cheers,
Nicolai

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

-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.