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

[phoronix]

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

An in-memory shader cache landed for the RadeonSI Gallium3D driver on Sunday and made it in time for the Mesa 11.2 branching...

http://www.phoronix.com/scan.php?page=news_item&px=RadeonSI-Shader-Cache-Lands

[duby229]

Cool. That it avoids touching storage is awesome. I understand that it isn't a "content" cache so it would be unlikely to thrash the disk anyway, but still very cool. Good thinking ahead. Much appreciated.

[FireBurn]

It wasn't any quieter than any other changes to Mesa - I'm guessing you just didn't spot it

[jrch2k8]

As far as I know, RadeonSI was already caching shaders in memory before this.

What is the actual improvement of the binary shader cache?

Ovbiously marek could explain better but basically every time a new effect or asset in games needed to be rendered you usually get a huge FPS drop while LLVM compiles the shaders to binary and in some games that could get really annoying really fast, since this patch many (not all yet) games just stutter the first time the shader is used and never again.

So far for me X Rebirth, Civ 5 and Metro Redux(es) are way more FPS stable now(Pending Cities Skylines since a mod is crashing it after the update beside traffic++)

[boffo]

hmhmmh what about the benchmarks (on/off)?

[duby229]

I don't understand.

How would you suggest to implement a content cache for OpenGL? I presume by "content" you mean textures.

HD textures of Shadow of Mordor consume about 10 GB on disk. How are you suggesting to create a cache for that?

I didn't suggest that at all. In fact I recognize that since the amount of physical data is small the risk of disk thrashing is minimal. However bandwidth isn't the only metric. Latency can be and often is more important. That's why I think it's a good idea. Avoid storage even if bandwidth isn't a concern.

[jrch2k8]

hmhmmh what about the benchmarks (on/off)?

this patch should not speed up any games, is not an optimization(normally at least), this avoid stalling the render thread while compile shaders over and over again during game play by just compiling shaders once and reuse from memory from that point onwards.

So Before patch

60fps -> 10fps(compiling) -> 60 fps -> 8 fps(compiling) -> 60fps ......

After patch

60 fps -> 10fps(compiling)-> 60fps -> 60fps(reusing) -> 60fpsfps -> 60 fps(reusing) .......

note this patch don't cache GS shaders yet, so tessalation can still trash up your fps for compilation but should be a lot less than before

[plonoma]

this patch should not speed up any games, is not an optimization(normally at least), this avoid stalling the render thread while compile shaders over and over again during game play by just compiling shaders once and reuse from memory from that point onwards.

So Before patch

60fps -> 10fps(compiling) -> 60 fps -> 8 fps(compiling) -> 60fps ......

After patch

60 fps -> 10fps(compiling)-> 60fps -> 60fps(reusing) -> 60fpsfps -> 60 fps(reusing) .......

note this patch don't cache GS shaders yet, so tessalation can still trash up your fps for compilation but should be a lot less than before

Very good explanation.
Really illustrates clearly what the effect of the shader cache is.

This patch is a fantastic improvement for the radeonsi driver.
Eliminating stuttering will have a very good impact on fluency / stuttering and thus gameplay.
Want to see the reusing extended to GS and CS as well.

Still leaves us with the stalling from initial compilation.
OpenGL could benefit greatly from async shader compilation and async GPU VRAM loading + shader cache by default.
It sounds like decoupling shader compilation and caching/loading from the rendering pipeline/loop could do wonders for stable, fluent framerates with less stuttering.

[schmidtbag]

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.

[boffo]

this patch should not speed up any games, is not an optimization(normally at least), this avoid stalling the render thread while compile shaders over and over again during game play by just compiling shaders once and reuse from memory from that point onwards.

So Before patch

60fps -> 10fps(compiling) -> 60 fps -> 8 fps(compiling) -> 60fps ......

After patch

60 fps -> 10fps(compiling)-> 60fps -> 60fps(reusing) -> 60fpsfps -> 60 fps(reusing) .......

note this patch don't cache GS shaders yet, so tessalation can still trash up your fps for compilation but should be a lot less than before

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.