architecture - 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!

question from:https://stackoverflow.com/questions/6539774/glsl-multiple-shaderprogram-vs-uniforms-switches

Answer 1

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.