Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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?

share|improve this question
    
Are you asking if it's faster to create your own versions of the existing functions or if it's faster to offload functions you were calculating on the CPU? –  Byte56 Aug 25 '11 at 17:09
    
I've found a post on gamedev.net that answers my questions. –  Joey Green Aug 25 '11 at 17:18
2  
I see. You should post an answer about it here, so that others can benefit. Perhaps clarifying your question in the process. –  Byte56 Aug 25 '11 at 17:25
    
@joey-green would you please link the gamedev.net here. I would be helpful for people who will stumble upon this question. –  iamcreasy Aug 25 '11 at 19:31
1  
To confuse matters more, in my tests the fixed pipeline may actually be faster than shaders, at least in simple cases; see sol.gfxile.net/instancing.html –  Jari Komppa Aug 25 '11 at 20:25
show 2 more comments

4 Answers 4

up vote 23 down vote accepted

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.

share|improve this answer
1  
Nice answer ... +1. –  Green Code Sep 1 '11 at 10:48
    
@Green Not sure about that. Misses the point somehow. Kylotan's answer is much more appropriate for the actual question. –  Christian Rau Sep 3 '11 at 20:07
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
    
"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." ..are you sure about this? Can you please provide any reliable resource? Thanks. –  iamcreasy Aug 25 '11 at 21:03
    
@iamcreasy I don't have a reliable source (therefore the probably), I have to admit. But I strongly doubt, that nowaday's graphics cards (which are just a bunch of many small processors), still have dedicated hardware for computing lighting or fog computations. Instead it is more likely they just load pre-compiled programs for this into the specific shader stages (whether these come from the driver or some ROM storage, I don't know). –  Christian Rau Aug 25 '11 at 21:09
    
@iamcreasy according to nouveau wiki nouveau.freedesktop.org/wiki/CodeNames, fixed pipeline was removed in GeForce 6xxx. –  DirtY iCE Jul 3 '13 at 22:54
    
"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." True. "But these might be very complex, to provide each and every feature the fixed-function pipeline offers." A good driver will generate shaders for just the functionality you have enabled. –  Chris Aug 21 '13 at 19:24
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.