[Mesa-dev] [RFC] NIR serialization

Fri Sep 8 00:09:22 UTC 2017

On Thu, Sep 7, 2017 at 7:26 PM, Jordan Justen <jordan.l.justen at intel.com> 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 haven't given it a great deal of thought, but it seems to me if
glsl->tgsi is not too lossy for shader cache, then glsl->nir would not
be either.. certainly glsl->nir is less lossy than glsl->tgsi.

And nir_serialize doesn't seem super complicated, certainly less so
than glsl->spirv.  It should be about on par w/ nir_clone.  I'd have
written it myself for freedreno (and vc4/vc5) shader-cache by now if
it weren't for enough other things that are higher on the TODO list
(and lately being busy with stuff lower in the stack)..

BR,
-R

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