[Mesa-dev] [RFC] ARB_gl_spirv and NIR backend for radeonsi

Rob Clark robdclark at gmail.com
Sun May 21 17:54:29 UTC 2017


On Sun, May 21, 2017 at 11:17 AM, Timothy Arceri <tarceri at itsqueeze.com> wrote:
> <snip>
>
>>
>> 3. NIR vs. TGSI
>> ---------------
>> It is *not* a goal for this project to use NIR for normal GLSL shaders.
>> We'll keep the TGSI backend at least for now. But it makes sense to think
>> ahead.
>>
>> A minor disadvantage of NIR is that the GLSL-to-NIR path is not as solid
>> as the GLSL-to-TGSI path yet, but this shouldn't be too difficult to
>> overcome.
>>
>> The major disadvantage of NIR is that it doesn't have serialization.
>> radeonsi uses the fact that TGSI *is* a serialization format for two things:
>>
>> - The internal shader cache, which avoids re-compiling the same shader
>> over and over again when it's linked into different programs. (This part
>> only needs a strong hash.)
>>
>> - The (disk) shader cache stores the TGSI so that it's available in case
>> additional shader variants need to be compiled on the fly.
>>
>> Some ideas:
>>
>> 1. Add a serialization format for NIR. This is the most straight-forward
>> solution, but it's a lot of work for a comparatively small feature.
>
>
> This would simplify the i965 cache fallback path a lot. I *think* it also
> solves the blocking issue (or at least the major one) with a vc4 (and a
> guess freedreno) on-disk shader cache.
>

I haven't had a chance to dig into on-disk shader cache.. but if we
don't have a way to fail and go back to glsl on variant mis-match,
then I guess serializing nir probably would be the blocking issue for
vc4 and freedreno..

BR,
-R


More information about the mesa-dev mailing list