On 09/07/2017 04:26 PM, Jordan Justen 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 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 think it's basically a requirement if we want to adequately test SPIR-V in OpenGL. The volume of tests for SPIR-V in the CTS is going to be small compared to the number of tests for GLSL in the CTS and piglit. > 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
