On Sun, May 21, 2017 at 11:17 AM, Timothy Arceri <tarc...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
