[Mesa-dev] [RFC] NIR serialization

Wed Sep 13 04:25:30 UTC 2017

I think the arguments for doing NIR serialization and deseriallization are
pretty persuasive. I've started a skeleton of a NIR serialization
implementation at
https://cgit.freedesktop.org/~cwabbott0/mesa/log/?h=nir-serialize. Note
that filling this in by following nir_clone should be mostly mechanical and
straightforward, and easy to test too: we already have the NIR_TEST_CLONE
environment variable that clones the NIR before each pass, so we can just
extend that to optionally serialize and then immediately deserialize
instead, and then test i965 piglit for regressions. Of course, this will
also have to be hooked into mesa/st and i965 to be useful. Not sure how
much time I'll have to work on it, but it should be relatively easy for
someone else to pick up, even as a first project with Mesa/NIR.

On Wed, Sep 6, 2017 at 5:12 PM, Daniel Schürmann <
daniel.schuermann at campus.tu-berlin.de> 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)
> - 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> <idr at freedesktop.org>
> To: Daniel Schürmann <daniel.schuermann at campus.tu-berlin.de>
> <daniel.schuermann at campus.tu-berlin.de>, Nicolai Hähnle
> <nhaehnle at gmail.com> <nhaehnle at gmail.com>, Timothy Arceri
> <tarceri at itsqueeze.com> <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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170913/3dbfe109/attachment-0001.html>