Make uniform variables const in shaders

[c42f]

Making the uniform variables const really helps to speed up the default vertex shader since it's a bit of a monster and the shader compiler can optimize out big chunks.

This would mean mapping the user tweakable parameters to const rather than uniform variables, and recompiling each time the user fiddles with the controls. If we also want stuff like the file index to be baked in as a constant, it would also mean having a unique compiled shader for each geometry.

[nigels-com]

So-called "uber shaders" are a fairly common approach, with various #if ... #end style conditionalisation. Another approach I've seen is generating the shaders algorithmically, which is flexible but tends to result in hard-to-maintain shader-generation logic.

[c42f]

Keep in mind that the user is supposed to be able to edit these shader on the fly, so algorithmic generation isn't really an option. The #if... #else style would work, but is messy for the same reason.

In practice I found that simply declaring variables const rather than uniform made the nvidia shader compiler do the same thing as a lot of #if... #else and is much cleaner for the user. Obviously there's no guaranteed portability here, but even the most basic optimizing shader compiler should do dead code elimination. Right? Or am I being naive?

[nigels-com]

Indeed. This kind of plumbing is what a lot of the CgFX runtime was concerned with. But alas, the FX abstraction seems to have gone by the wayside, and vendors seem to be mostly rolling their own material library schemes these days. Perhaps there is an abstraction here that there is a user-definable kernel that gets parsed, inspected and wrapped with appropriate "plumbing". I'll take a look when I wade into the codebase.

As for optimisations, you can't rely on much beyond what's specified in general, but certainly in the case of the Nvidia GLSL implementation - dead code elimination and loop unrolling can be assumed. There isn't an alternative to testing on various GPU/OS/driver combos, in practice. (Boring, but important! :-)

[c42f]

Unfortunately, rolling my own material handling is basically what I'm doing: You'll see that I've put the vertex and fragment shaders into a single text file (nice since it puts everything in one place, but leads to code duplication). User defined GUI controls for uniform variables are defined on specially formatted comment lines. There's currently no scheme for the parts of the material handling which should happen on the CPU side.

Materials definitely feels like a thing which should have a standard system, I'd rather not be inventing this wheel myself.

As for testing, I don't have access to the hardware to do a good job. I just try fixing bugs when they're reported.