Shader cache

Started by
13 comments, last by Prune 13 years, 9 months ago
Quote:Original post by Danny02
just one question why?
Loading times is a big reason - and not just in the final/shipping version of the game --

Some companies go further than a local shader cache during development, and use a networked shader cache. Whenever a shader is compiled, the binary version is uploaded to a central server so other people on the team don't also have to compile it.

On some games, with hundreds of shader permutations, changing a shader source file can add a few minutes to your next loading screen - multiply the number of shader changes by the number of people on the team and it can be a non-trivial amount of wasted development time ;)
Advertisement
I can see that u don't want your App to freez for a short amount of time when it needs to recompile shaders, but why don't u compiel all shaders at programm start?

What questions me is, I felt that the compile time of a shader was always quite quick and when having a lot shaders this shouldn't matter that much when all are compiled at startup rigth?
Quote:Original post by Danny02
why don't u compiel all shaders at programm start?
Being able to reload shaders while the game is running is very useful for fast iteration, but that's another topic ;)
Quote:What questions me is, I felt that the compile time of a shader was always quite quick and when having a lot shaders this shouldn't matter that much when all are compiled at startup rigth?
I've got one shader at work that has about 70 permutations (different versions of the same shader with #ifdefs). Some of the individual permutations take ~10 seconds to compile :( In total, the whole shader takes a few minutes.
The only reason why I was thinking about shader cache is to avoid run-time stalls.

And no, I can't compile all shaders at a start up of my app, because as Hodgman said, that would take too much time. I have around 5 "super shaders" and every one of them uses around 10-30 #ifdefs.

[Edited by - Volgut on July 13, 2010 9:22:24 AM]
Is not an additional motivation on the vendors' side optimizations that come with new drivers? I bet non-trivial shaders compiled under an old and a new driver on the same hardware have a good chance of producing nonidentical binary.

By the way, is it possible to transfer an OpenGL context from one process to another? If so, it would be possible to use a Windows service or Linux daemon to hold your context with its compiled shaders until your application needs it, thus providing a semi-persistent OpenGL context (within a system restart). Catching a fatal exception in your application, or a quit message etc., would then trigger the transferring back to the service.

I might actually try something like this since I'm already using a system service as a watchdog.
"But who prays for Satan? Who, in eighteen centuries, has had the common humanity to pray for the one sinner that needed it most?" --Mark Twain

~~~~~~~~~~~~~~~Looking for a high-performance, easy to use, and lightweight math library? http://www.cmldev.net/ (note: I'm not associated with that project; just a user)

This topic is closed to new replies.

Advertisement