Daily news, dev blogs, and stories from Game Developer straight to your inbox
Sponsored By
A story about shaders, Part II
When we left off yesterday, artists were at last able to create shaders without having to learn any programming. It seemed like a new age of enlightenment, but was everything really happy in the mushroom kingdom? The story continues...
3 Min Read
From my experience, the big thing that gets in the way of the fairly tale ending (wherein artists can blissfully create production quality shaders with a friendly GUI) is performance management. Why is performance management such a big deal? Here are some thoughts:
GPU optimization is hard.
Different team-members have different priorities.
Time.
In this post, let's look at #1 - GPU optimization is hard.
A modern GPU consists of a hardware graphics pipeline with several programmable stages, access to various kinds of memory with different performance properties and caching schemes, and the whole thing runs massively parallelized. Getting the best performance out of such a complicated system is hard, much harder than "normal" programming. This isn't a big revelation, the software engineering community has been studying ways to make it easier to work with memory caching and parallel programming for ages.
What's hard about this kind of optimization is that the solutions are all about balance. You need to balance the load on the various parts of the pipeline so that rendering doesn't get backed up behind one super-slow stage. You need to balance quality against speed, and balance memory vs compute time. It's a lot like 
Spinning plates
spinning plates, which is why graphics programmers never give you straight answers when you ask them why the game is running too slow. They usually come back with something like, "we could precompute this in a texture, or do that math in the vertex shader, or cut this unrelated effect over here, or...", usually trailing off to run another battery of tests. The kind of optimization we're doing here is hard because a lot of the time you'll speed something up, and the game doesn't go any faster. You can't just go looking for anything that is slow, you need to find the right thing. Even after you find the bottleneck, you need a wide range of strategies for clearing them because the right trade offs for one situation may not be the right ones for the next situation. This all comes from hard won experience. It takes time and patience to learn.How you deal with this challenge of optimizing the complex GPU beast once you switch to artist-driven shader creation depends on how ambitious your performance targets are. If your project doesn't need the hottest graphics running at 60fps, a graphics programmer may be able to come up with some hard limits on things like size and number of textures, the number of ALU instructions to allow per shader, and vertex counts and sizes. These are things that are fairly easy to measure, and correspond to many typical performance problems. Remember that this is still an oversimplified view of your performance, and to hit your frame rate target guided only by these numbers, the limits will have to be conservative. This means under-utilizing the GPU in most cases. The alternative is keep the graphics programmers involved in shader creation, in partnership with the artists.
So we've established that GPU optimization is hard, so to get the best results we'd like to keep a graphics programmer in the loop. The story doesn't end here. Next post, I'll elaborate on some issues that arise from getting the code and art teams to work together smoothly.
About the Author(s)
You May Also Like
