[Mesa-dev] [RFC] NIR serialization

Fri Sep 8 00:12:44 UTC 2017

On Thu, Sep 7, 2017 at 5:09 PM, Rob Clark <robdclark at gmail.com> wrote:

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

That's my thought as well.  We're already caching TGSI and it's way more
lossy than NIR.

Looking at Connor's rather old shader-db flame graph[1], it appears that
caching the NIR shortly after brw_preprocess_nir could give us significant
gains all by itself.  We'd still have to throw it all away whenever the
mesa version changed, but not having to fall all the way back to GLSL every
time we need a variant would be good.

 [1]: https://people.freedesktop.org/~cwabbott0/perf-shader-db-nir.svg

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

Yup.  Should be fairly simple.  The biggest difference between that and
nir_clone would be that you would have to map pointers to/from integers
instead of mapping pointers to pointers.

--Jason

> 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
> _______________________________________________
> 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/20170907/61d43b19/attachment-0001.html>