Why is programmable pipeline( GLSL ) faster than fixed pipeline?

Question

So I'm teaching myself GLSL and am trying to figure out why it's suppose to be faster than the fixed function pipeline.

The reason I am having a problem is that from my understanding , the shaders you create are replacing sections of the pipeline that were there before. So, how's simply providing your own version speeding things up?

The only thing I can think is if you tried to supply say your own lighting equation before, you would have to do the calculation on the CPU, but now you can do the calculations on the GPU which will be faster.

Am I understanding this correctly?

Answer 1

Shaders you create aren't going to be your own version of fixed-function pipeline(FFP), but a custom vertex- and pixel-manipulating operations to achieve something cool and complex.

Many things you do via programmable pipeline(PP) will work faster than their possible FFP implementations, because PP reduces the number of passes or amount of combiner and cubemap magic required to render these hypothetical things in FFP.

Imagine implementing such a common thing as per-pixel lighting in FFP with only interpolated vertex data and sample texture in your hands. It's not even possible to do it "honestly", only hacks for special cases depending on faithful precalculated cubemaps and some serious blending. With PP it becomes a matter of colorizing a dot product between light direction and vertex normal.

All in all, PP turns slow and impossible into fast and possible. But if you decide to write a shader to implement the same algorithms used in FFP, you would find out that FFP will be slightly faster because it's very hardware-optimised.

Answer 2

In theoretical terms the programmable pipeline is slower than the fixed function pipeline. No general purpose processor can compete with a special case processor. The original fixed function pipeline was little more than a bunch of logic gates in a line which is as fast as theoretically possible.

However, these days the programmable pipeline is the norm. So the hardware is instead geared towards the programmable pipeline. Having lost the initial efficiencies of having a circuit specifically created for one certain data flow, it must accommodate the most common case, which is the shader-based approach. However for backwards compatibility options, the fixed function pipeline is still made available - but the cost is that the old fixed functions have to be transated into shaders, which may well incur a cost. This would explain the performance difference.

Answer 3

The main reason I could think of is a phase in fixed pipeline, that your program doesn't need it. for example image a game where all lights are static, you can easily implement a shader that doesn't even try calculating for dynamic light. in this case you shader runs faster than a precompiled shader that is checking some equations for dynamic light (a general purpose shader). there are other examples too, you can easily think of many aspect that should be considered for a fixed pipeline but you can ignore implementing in your own GLSL codes.

Answer 4

That's it exactly, your shaders are replacing parts of the pipeline. But often your shaders are specialized towards a specific effect you want to achieve and don't handle every possible special feature that might be activated, therefore being simpler than a shader that emulates the complete fixed-function pipeline. Whereas the fixed-function path has to take into acount many things and OpenGL features you might just not want to use (or haven't even heard about).

And the days where you had the fixed-function done in special hardware (opposite to a fully programmable hardware) are over, what probably happens when you use the fixed-function pipeline is, that your driver just loads its own special shaders that implement the fixed-function paths. But these might be very complex, to provide each and every feature the fixed-function pipeline offers.