VC4 Gallium3D Thread Switching Work, Reviewing On-Disk Shader Cache

[phoronix]

Phoronix: VC4 Gallium3D Thread Switching Work, Reviewing On-Disk Shader Cache

Broadcom developer Eric Anholt has issued his first weekly progress report of the new year for the VC4 open-source graphics driver supported by the Raspberry Pi...

http://www.phoronix.com/scan.php?page=news_item&px=VC4-Thread-Switch-Shader-Cache

[darkbasic]

Shader cache <3

[FireBurn]

Hasn't Marek been working on the shadercache stuff for radeonsi too?

[Azpegath]

Hasn't Marek been working on the shadercache stuff for radeonsi too?

IIRC, he's been working on the memory shader cache, not the on-disk. Previously, he said that the on-disk shader cache wasn't a priority, and that many other things would be prioritized before it.

[Veerappan]

IIRC, he's been working on the memory shader cache, not the on-disk. Previously, he said that the on-disk shader cache wasn't a priority, and that many other things would be prioritized before it.

That.

Timothy Arceri has been working on the on-disk shader cache for a while now (and sadly having to beg for reviewers), which stores compiled shaders to disk (using some hashing of the shader source, host cpu, gpu target, and mesa version [or something along those lines] to generate a unique key). Marek Olsak has been working on an in-memory shader cache for radeons which caches compiled shaders in memory for the life of the process (within some max memory limits, I'm assuming).

The radeon in-memory cache currently just stores compiled shaders for the life of the process, which means that the first time you load a given level/asset, the shader will always need to be compiled, but then the next time you load that level/asset/whatever, the cached shader can be used. The on-disk shader cache stores copies of compiled shaders to disk, so that the cached shader binaries can be used across program executions. When Michael does PTS benchmarks, the on-disk shader cache will probably appear to give a much larger benefit than the in-memory radeon cache due to how PTS does a separate launch of each game between its 3+ benchmark runs. I suspect that PTS will start actually having to do more than 3 runs fairly often because the standard deviation between the first run and runs 2/3 will exceed its acceptable threshold.

Along with that, I believe that the threaded background optimizations for radeon also come into play. I.e. when you first compile a shader, it is compiled with a minimum amount of optimization applied (just the cheap/fast optimizations); After the shader is compiled and the compiler goes idle, a more aggressively optimized version of the shader is created to replace the slower-but-quick-to-compile version that was created at first.

I suspect that eventually we'll probably get the best of both worlds. Once the on-disk shader cache for mesa lands, someone will probably go through the effort to hook it up to the radeon drivers, and if we're lucky, the background threaded optimization/replacement jobs will also apply to the disk-cached shaders as well.

I can't say whether it will be Marek Olsak who does the work, or someone else, but I strongly suspect it'll happen at some point.

[pal666]

I suspect that PTS will start actually having to do more than 3 runs fairly often because the standard deviation between the first run and runs 2/3 will exceed its acceptable threshold.

it would be easier to just throw away results from warmup run

[geearf]

it would be easier to just throw away results from warmup run

Or to disable the on disk cache for the tests.

[starshipeleven]

Or to disable the on disk cache for the tests.

disabling a feature that most people leave enabled, in a test where you want to see its performance too?

[geearf]

disabling a feature that most people leave enabled, in a test where you want to see its performance too?

If the first run that creates the shader is too slow, people won't spend the time to do a full run, so to me that's the most interesting test.
Hence I do not care about the cache's performance.
Of course, I'll be very happy to have it for games that build shaders on loading.


As for the "disabling a feature that most people leave enabled" well the in memory cache is left enabled by user too, but I believe PTS will close the game and restart it between benchmarks, so that's more like what I suggest no?

[starshipeleven]

If the first run that creates the shader is too slow, people won't spend the time to do a full run, so to me that's the most interesting test.

This is your own assumption. If you know that the first time is slower but then it is much faster, you can accept a slower-than-normal start.

Hence I do not care about the cache's performance.
Of course, I'll be very happy to have it for games that build shaders on loading.

Sorry but you are missing the point of a benchmark.
In a benchmark, you would want to know both. First the cold-start situation then the warm-start situations. SO you can see how better it is before and after, or if the feature makes sense in game X or in game Y or if it makes things worse.

As for the "disabling a feature that most people leave enabled" well the in memory cache is left enabled by user too, but I believe PTS will close the game and restart it between benchmarks, so that's more like what I suggest no?

No, that's just a realistic usecase, as you don't usually leave the game running 24/7 on your PC.
Flushing disk caches for shaders isn't something people would do in a realistic situation, as it is against the whole point of disk caching. The caches get rebuilt on driver or game updates, not on game restart.