[Mesa-dev] [RFC] NIR serialization

Timothy Arceri tarceri at itsqueeze.com
Tue Sep 12 07:15:37 UTC 2017


On 12/09/17 16:55, Jordan Justen wrote:
> On 2017-09-11 21:44:32, Timothy Arceri wrote:
>> On 12/09/17 14:23, Ian Romanick wrote:
>>> On 09/08/2017 01:59 AM, Kenneth Graunke wrote:
>>>>
>>>> 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.
>>>
>>> Since we're going to expose exactly that path for GL_ARB_spirv / OpenGL
>>> 4.6, we'd better make sure it works always.  Right?
>>>
>>> One nice thing about SPIR-V is that all of the handling of uniform
>>> layouts, initial uniform values, attribute locations, etc. is already
>>> serialized.  If I'm not mistaken, that was one of the big pain points
>>> for all of the existing on-disk storage methods.  All of that has been
>>> sorted out for SPIR-V, and we have to make it work anyway.
>>
>> Correct these are the main issues for the fallback path, however this is
>> only used by i965 (exactly because an intermediate cache is missing).
>> Using SPIR-V as the intermediate cache means we still need to convert to
>> NIR and run all the opts, so I don't really see the advantage of caching
>> to SPIR-V over NIR.
> 
> For shader cache, hopefully we'll normally have the final program in
> the cache, which means the 're-run opt passes' is probably not a big
> factor. But, it still seems a fair point.

Using SPIR-V would also require a special path and extra code to do 
this, with nir you should just need to load from disk if its not in the 
buffer and continue on your way.

> 
> I think the biggest advantage of having either nir or spir-v would be
> not having to fallback to running the glsl compiler, right?
> 
> Maybe we'll see which becomes available first? :) >
> -Jordan
> 


More information about the mesa-dev mailing list