Can compiling and linking a shader on a worker thread increase the parallelism in our applications? On the surface, the answer sounds like yes, of course, it moves the CPU intensive compiling off our rendering thread. Although NVIDIA’s Release Notes for NVIDIA OpenGL Shading Language Support from November 2006 state that the driver holds a coarse lock.
I’m curious if this lock is around all GL commands or just compiling/linking shaders. Perhaps it is worth just having a single worker thread for compiling/linking but not multiple threads. Or perhaps the lock is gone in newer drivers.
If there’s any information on ATI or Intel available, I’d also like to know about that.
NVIDIA’s OpenGL drivers have quite a bit of locking in them that has prevented me from seeing any gains from a multithreaded renderer (using the GPU affinity extension). I’ve had a bug open with them for about a year now, and while they are supposedly working on it, it hasn’t gotten much better. I’ve had better luck with ATI, so it may be worth trying your idea on their hardware.
one recommendation when you try to optimize link/compile time, is that the best practice is to compile and link all the shaders without querying the result of the compilation right away:
compile (shader0)
…
compile (shader100)
getresult (shader0)
…
getresult (shader100)
otherwise, the driver attempt to use another core for this time consuming task will not work because the “get result” will cause a synchronization. (this is what we have seen on most applications)
Thanks for the info guys. I know the driver is free to compile on another core but I didn’t know if any drivers actually did it in practice - good to know that ATI does.
There are still times when I’d like to explicitly create a thread for compiling and other GL resource preparation. It’s not the end of the world if some drivers lock, I just wanted to know what I am getting into.