GLSL multiple shaderprogram VS uniforms switches

Question

I'm working on a shader manager architecture and I have several questions for more advanced people. My current choice oppose two designs which are:

1. Per material shader program

=> Create one shader program per material used in the program.

Potential cons:

• Considering every object might have its own material, it involves a lot of glUseProgram calls.
• Implies the creation of a lot of shaderprogram objects.
• More complex architecture that #2.

Pros:

• Shader code can be generated specifically for each "options" used in the material.
• If i'm not wrong, uniforms have to be set only one time (when the shaderprogram is created).

2. Global shader programs

=> Create one shader program per shader functionality (lightning, reflection, parallax mapping...) and use configuration variables to enable or discard options depending on the material to render.

Potential cons:

• Uniforms have to be changed many times per frame.

Pros:

• Lower shader programs count.
• Less SP swich (glUseProgram).

You might notice that my current tendency is #1, but I wanted to know your opinion about it.

• Does initial uniforms setting offset the glUseProgram call overhead (I'm not especially speed freak) ?
• In the case #1, for any memory or performance consideration, should I call glLinkProgram only once when I create the SP, or I must unlink/link each time I call glUseProgram?
• Are there better solutions ?

Thanks!

Answer 1

On mobile devices, branching in a shader greatly increases time to render. You should do some measuring on the time to switch programs vs the reduced draw rate associated with branching in a per vertex / per texel repeating operation. I'd recommend method #1 and take a look at how GPUImage is set up for a good oop friendly shader architecture.

https://github.com/BradLarson/GPUImage

Answer 2

Let's look at #1:

Considering every object might have its own material, it involves a lot of glUseProgram calls.

This isn't that big of a deal, really. Swapping programs is hard, but you'd be swapping textures too, so it's not like you're not already changing important state.

Implies the creation of a lot of shaderprogram objects.

This is going to hurt. Indeed, the main problem with #1 is the explosive combination of shaders. While ARB_separate_program_objects will help, it still means you have to write a lot of shaders, or come up with a way to not write a lot of shaders.

Or you can use deferred rendering, which helps to mitigate this. Among its many advantages is that it separates the generation of the material data from the computations that transform this material data into light reflectance (colors). Because of that, you have far fewer shaders to work with. You have a set of shaders that produces material data, and a set that uses the material data to do lighting computations.

So I would say to use #1 with deferred rendering.

Answer 3

It really depends on your hardware and the specific demands of your app.

Another con of #2 is that your shader usually ends up not being as efficient because it has to do some conditional branching based on the uniforms you pass in. So you're basically trading off between less time switching state versus decreased throughput in your shader. It depends on which one is worse.

You should definitely only call glLinkProgram once per shader. Compiling a shader takes much longer than switching out already-compiled shaders.

There aren't really any better solutions. Pretty much everyone writing a rendering engine has to make the decision you're faced with.