On Thu, Sep 7, 2017 at 7:26 PM, Jordan Justen <jordan.l.jus...@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 <i...@freedesktop.org> >> To: Daniel Schürmann <daniel.schuerm...@campus.tu-berlin.de>, Nicolai >> Hähnle <nhaeh...@gmail.com>, Timothy Arceri <tarc...@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@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
