On Fri, Sep 8, 2017 at 2:09 AM, Rob Clark <robdcl...@gmail.com> wrote: > 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.
I don't consider TGSI lossy at all. We cache TGSI binaries and it's been working for us spectacularly. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
