[Mesa-dev] [RFC] NIR serialization

Thu Sep 7 23:26:04 UTC 2017

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

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