I code in OpenGL and I've been reading some posts about this uber-shader approach.

It first sounded neat but on second thought having lots of shader programs will require lots of glUseProgram() calls in runtime, which is afaik the most expensive gl function to call in runtime. (said by L.Spiro as I recall)

Is this thing noted? Am I missing something? Are there better approaches for managing shaders in big engines?

Also, what about using uniforms to do dynamic branch selection? This may slow things a little, but avoids having the switch many programs in every frame.

For example, opaque and translucent objects should always be permutated and without a branch indicating "alpha or not".

Why is that? Rendering translucent object only differs from opaque objects by the order of draw calls, no? The shader can stay the same.

Edit: Maybe my English slows me down here but by "permutated" you mean having different shaders for translucent and opaque objects, right?

A side question: What could be a legit number of shader switches in each frame, in AAA games?

For real? I thought something like 100 would be expensive as hell.

Well then precompiling all possible shader routines shouldn't be too wasteful I guess.

Can you answer my first question?

Another question:

How in-depth do you go with uber-shaders? Do you also condition the vertex attributes, like so:

layout(location=0) in vec3 vertex;
#ifdef VERTEX_COLOR
layout(location=1) in vec3 color;
#endif
#ifdef VERTEX_NORMAL
layout(location=2) in vec3 normal;
#endif
//and so on

For real? I thought something like 100 would be expensive as hell.

Mitigate the cost of glUseProgram() by sorting objects with the same shaders such that they can be drawn without calling glUseProgram() (render queues).
Branches inside shaders are almost free as long as all pixels in a block take the same branch. Still there is a small cost for branching, and it never makes sense to keep a branch if you have to swap shaders anyway (such that the branch is always taken in one and never in the other). For example, opaque and translucent objects should always be permutated and without a branch indicating "alpha or not".
A branch is costly if in a block some pixels will take one path and others the other. In that case each branch waits for the other, meaning all pixels ran both branches.
When to permutate is decided based on the balance between these costs.
L. Spiro