RadeonSI Quietly Landed A Shader Cache As A Last Feature For Mesa 11.2

[stqn]

Hopefully the next step is to save the compiled shaders on disk. I’m not a radeonsi gamer but with nvidia some games take several minutes to load when shaders need to be compiled (new game or driver version), even with a fast CPU.

[jrch2k8]

Not really, for example when I used to play TF2 with the weapons skins I always had stalling when switching weapons, since switching weapons in tf2 happens often, this reduces the average fps.

well you are right but you asked benchmarks and in that case it won't affect the average much since benchmarks normally don't constantly re compute shaders that much often but even then it won't give more fps(your min and max will stay the same) just stabilize your average fps since it avoid frame tankings and stutters, so this is about smoothness not speed ups.

Sure this can be benchmarked but it can require some creative thinking to make it visible in a graph and im not sure if PTS can measure it properly but michael should knot that better so i won't touch the benchmarks side of things here

[smitty3268]

Couple points.

This is only enabled if you have LLVM 3.8+.

This is not the same as a full-blown shader cache a la the proprietary drivers. It's more meant to be a way of working around the fact that the driver has to change shaders when various state changes are made in OpenGL, which is a consequence of the way radeon hardware works and interacts with OpenGL. Though it is a good first step towards a full shader cache, as there is now just 1 binary program compiled per shader rather than potentially multiple versions depending on different GL states.

It would be simple to just start saving these drivers to the hard drive, but it probably makes more sense to come up with a solution that happens before the GLSL parser gets involved, as that is still pretty slow and wouldn't get bypassed.

Some numbers and a far better explanation from Marek are available here: https://lists.freedesktop.org/archiv...ry/107737.html

5) Performance of the shader cache
The test is a short apitrace of Borderlands 2.
Without the cache: GLSL link time = 18361 ms Driver compile time = 14510 ms
With the cache: GLSL link time = 12576 ms Driver compile time = 8552 ms

This leaves a lot to be desired, but it was expected. The TGSI compilation takes 41% less time, which means 41% of all TGSI shaders are duplicates. On average, linking GLSL shader programs (including the TGSI compilation) takes 31.5% less time.

The compile times are still unacceptable and caching shaders on the disk appears to be a necessity. A radeonsi-only cache on the disk should be relatively easy with the current cache in memory, but 33% of the compilation time is not spent in radeonsi.

So it should speed up load times in a lot of cases, in addition to hopefully keeping in-game stutters reduced.

[haplo602]

Couple points.

This is only enabled if you have LLVM 3.8+.

This is not the same as a full-blown shader cache a la the proprietary drivers. It's more meant to be a way of working around the fact that the driver has to change shaders when various state changes are made in OpenGL, which is a consequence of the way radeon hardware works and interacts with OpenGL. Though it is a good first step towards a full shader cache.

It would be simple to just start saving these drivers to the hard drive, but it probably makes more sense to come up with a solution that happens before the GLSL parser gets involved, as that is still pretty slow and wouldn't get bypassed.

Some numbers and a far better explanation from Marek are available here: https://lists.freedesktop.org/archiv...ry/107737.html



So it should speed up load times in a lot of cases, in addition to hopefully keeping in-game stutters reduced.

Pretty much this. also it does NOT remove the performance hit when each shader is used for the first time. only reuses are cheaper. however it's a nice step forward.

[marek]

I'm guessing this won't have much of a measurable performance difference in benchmark averages, but it should definitely be noticeable to users during gameplay, which is great.

I think that the whole work (not just the shader cache, but also the commits that remove shader compilation from draw calls) will help game benchmarks too.

If a benchmark loads shaders before it starts benchmarking, the result will be that the shader compilation time will not affect the final result no matter how long the compile times are. If a benchmark needs 10 seconds to compile shaders, it means the benchmark will finish 10 seconds sooner from the start of the benchmarking.

Unreal Engine (Borderlands 2, etc.) loads shaders before draw calls and drivers can't change that, but I noticed 40% of those shaders are duplicates. The shader cache in memory eliminates them, making even the first compilation look faster, and subsequent shader reloads almost instant.

[duby229]

Couple points.

This is only enabled if you have LLVM 3.8+.

This is not the same as a full-blown shader cache a la the proprietary drivers. It's more meant to be a way of working around the fact that the driver has to change shaders when various state changes are made in OpenGL, which is a consequence of the way radeon hardware works and interacts with OpenGL. Though it is a good first step towards a full shader cache, as there is now just 1 binary program compiled per shader rather than potentially multiple versions depending on different GL states.

It would be simple to just start saving these drivers to the hard drive, but it probably makes more sense to come up with a solution that happens before the GLSL parser gets involved, as that is still pretty slow and wouldn't get bypassed.

Some numbers and a far better explanation from Marek are available here: [URL="https://lists.freedesktop.org/archives/mesa-dev/2016-February/107737.html"]https://lists.freedesktop.org/archiv...ry/107737.html[/U

So it should speed up load times in a lot of cases, in addition to hopefully keeping in-game stutters reduced.

Ah! That make a lot of sense. So in this particular case the cache reduce latency by making certain a shader is already available when it gets re-used. And eventually once the disk cache gets implemented properly, once the shader is compiled the first time, even restarting the computer that shader will still be available. As long as the disk cache is being used as storage for the sake of storage it'll probably be fine.

But I present The Old Republic Online as an example of how using a disk cache can seriously hurt performance. It's not a matter of bandwidth that hurts, it's latency.

[pal666]

This is only enabled if you have LLVM 3.8+.

mesa in fedora 24 is built with llvm 3.8, so this one is covered

[theriddick]

XCOM2 is a good example of shader stutter, it has it in spades.

[duby229]

Do you mean latency on a rotational disk, not SSD? I have my home directory (and consequently the shader caches, such as ~/.AMD/GLCache) on an SSD.

Since the moment I bought an SSD, latency isn't an issue in any application I am running - the CPU speed is now the limiting factor.

Or can latency of the shader cache be an issue even on an SSD?

I think it depends on how it's implemented. From what I read here and elsewhere it sounds like it would only be read from disk in case it isn't already in RAM. It'll only have that one time hit on reading the shader from disk. It that case it would certainly have much less latency than recompiling the shader.

For SSD, yeah, they have much less latency than any HDD, but still are the slowest component in a computer. Compared to RAM SSD's are slow as dirt.

[LeJimster]

Ever since I've switched to Linux I've wondered why things weren't as smooth, with noticeable fps drops. Something I notice especially in The Talos Principle on loading a new level. This shader caching feature seems like the way forward and I appreciate all the work being put into it as it's this kind of thing that makes a big difference to immersion.