Hi all,

I was thinking too myself this afternoon (dangerous I know!) You only ever hear or see of one graphical rendering architecture being utilised on projects; either fixed function or more recently shaders. I am wondering if there is an overhead that prevents the mixing of fixed function and shader architectures being utilised by the same renderer, surely doing the simple lighting/bump map calculation using the fixed function stuff and utilising the shader architecture for the heavier stuff would provide some nice returns? The only downside I can see is the potential throttling of the gpu bandwidth or possible contention issues. Has anyone looked into this and have any interesting links to throw back?

Thanks in advance,

Hinchy.

As far as I know, modern GPUs don't have any fixed-pipeline any longer (at least the parts which could be replaced by shader code). The driver use shaders to simulate them. So, no benefit from using the fixed pipeline over shaders.

It's also much much cleaner to just use shaders for everything. The fixed pipeline is not actually simpler - by the time you set all your GL_COMBINE/SetTextureStageState modes you end up with a lot of code that doesn't actually clearly express the operation you're doing. Add in texture matrix ops or texcoord generation and you'll find that the fixed pipeline code starts going into pages (and with a lot of tricksy state change management) that could be expressed by a few simple lines of shader code.

Doom 3 mixed fixed pipeline with shaders and it needed to use an invariant position option in it's shaders because the calculations between the two modes didn't match. That removed it's ability to do interesting things like custom position transforms, or performance optimizations like GPU model animation.

There's also the small matter of the fixed pipeline not being exposed by modern APIs. D3D11 doesn't have it at all, and modern OpenGL won't (or at least shouldn't, unless you're using NVIDIA, in which case you're reducing the chances of your finished product working on other hardware) expose it in a core context.

Yes I heard on the grapevine that the fixed function pipeline was effectively deprecated. It's interesting to hear id tried it with doom3. I'm looking into migrating away from fixed function for these very reasons. Had I found some more resources about the intermingling of fixed function and shaders I may have taken that approach but it looks fraught with dangers so it's more likely that i'll just rewrite the fixed function stuff as shaders.

Forget it.
Move on, you are already 10 years behind.

The rigs we use are roughly the equivalent to your average desktop pc about 4/5 years ago. So we aren't doing anything bleeding edge lol. That being said the minute stuff starts getting deprecated it's time to pack up and "Move on" as you say. So I think my mind is made up on how I'll move the graphics engine forward. Thanks for the input and advice folks.

Hinchy.

Even with 4/5 year old kit you're going to get fairly solid SM3 support (unless you're talking Intel graphics, where it'll be SM2 on the earlier 9xx series, SM3 otherwise) so you can confidently move on.

I've ported codebases from fixed to shaders a few times and it's not too hard; just a one-step-at-a-time job.

It's also much much cleaner to just use shaders for everything. The fixed pipeline is not actually simpler - by the time you set all your GL_COMBINE/SetTextureStageState modes you end up with a lot of code that doesn't actually clearly express the operation you're doing. Add in texture matrix ops or texcoord generation and you'll find that the fixed pipeline code starts going into pages (and with a lot of tricksy state change management) that could be expressed by a few simple lines of shader code.

I have to disagree on that, fixed function is actually way simpler, you can set the states of the FF pipeline the way you want, without any worry bout the rest of the states. with shaders, everyone tries to minimize the amount of states, often you pay with slower shaders that do redundant work, to avoid having a state, as you otherwise suffer from the well know shader-combination-explosion.
It's for sure easier to use shader, if you want to implement one specific effect e.g. SSAO, quite a straight forward c code, but if you implement the whole renderer for a game, you end up having "states", which are triggered by artist, game-code, assets,... and you translate those into some bitmasks to index a shaderDB. It's also in no way easier to maintain/debug, there can be tons of visual and technical bugs, that just become visible after an unexpected combination of your feature set. With FF, you have your states and you can easily imagin what happens in a specific setup, with shader flags, you need to make a capture and debug into the shader, and sometimes you figure out, it's a shader compiler bug, or a bug in the internal compiler in some driver... that wasn't really happening with hardware (except of prototype samples)

it makes of course no sense to use FF anymore, but it was simpler, my 2cents.