A story about shaders, Part IV

With a graphics programmer in the mix for the technical bits and the responsibilities sorted out, what's left? The last major obstacle to good shader performance within this new paradigm is the game developer's old nemesis, time.

Most of the non-trivial performance problems in a game don't show up until the majority of the content and code is in the game, i.e. toward the end of the project. After all, just about any shader will run fine if the GPU doesn't have anything else to do. So when you start making shaders, and there is no post effect or UI rendering, few high-poly objects, not much game code running, and so on, progress seems easy. With a nice shader authoring GUI, shaders can be quickly hacked together and checked off the todo list.  In this way, you can easily lose sight of your true progress, overlooking the large body of testing and refinement work those shaders have generated that comes after their initial creation. This scheduling problem applies to quality issues as well as performance, once you get all of the shaders in game and the final assets assembled, you may find consistency problems or other quality concerns. By streamlining the early stages of shader development, we may be lulled into thinking that the later stages (testing, debugging, generalizing, optimizing) will be faster.  Nothing about the GUI makes these stages faster and easier, arguably some (like debugging tool-generated shader code) may actually be harder.

Much of this is unavoidable, so to minimize the impact this has on your project you can do things such as early prototyping using benchmark content (i.e. representative of what you want in the final game), iterative development cycles that include hard performance assessments, and of course allocating and protecting a healthy chunk of time at the end of the project for polish and optimization. As long as you remember to manage the time risks that go with your performance goals, this obstacle does haven't to hold you back.

Getting artists directly involved in creating shaders is a leap that needs to be made to realize the full potential of the latest platforms. While it makes content creation more technical for the art team, it also frees up time for graphics programmers to forge ahead on new and cool techniques that have yet to be seen in real-time rendering. By recognizing that optimization is hard, making shader building a collaborative activity, and ensuring that testing and optimization is a priority in the schedule, the game industry at large can successfully and relatively painlessly make the leap to artist-driven shader creation workflows. 

Flickr photo by serhio