[Mesa-dev] [RFC] NIR serialization

Marek Olšák maraeo at gmail.com
Sat Sep 9 00:03:51 UTC 2017


On Fri, Sep 8, 2017 at 2:09 AM, 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.

I don't consider TGSI lossy at all. We cache TGSI binaries and it's
been working for us spectacularly.

Marek


More information about the mesa-dev mailing list