On Thursday, September 7, 2017 4:26:04 PM PDT 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'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
We shouldn't use SPIR-V for the shader cache. The compilation process for GLSL is: GLSL -> GLSL IR -> NIR -> i965 IRs. Storing the content at one of those points, and later loading it and resuming the normal compilation process from that point...that's totally reasonable. Having a fallback for "some things in the cache but not all the variants we needed" suddenly take a different compilation pipeline, i.e. SPIR-V -> NIR -> ... seems risky. It's a different compilation path that we don't normally use. And one you'd only hit in limited circumstances. There's a lot of potential for really obscure bugs. Serializing NIR, and possibly a few auxiliary structures that we need, seems reasonable. Although, just using the GLSL seemed reasonable to me as well, but I guess that's proven to be painful? --Ken
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
