Jump to content

  • Log In with Google      Sign In   
  • Create Account


Fixed function and Shaders


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 fanaticlatic   Members   -  Reputation: 459

Like
0Likes
Like

Posted 02 February 2012 - 05:52 AM

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.
"I have more fingers in more pies than a leper at a bakery!"

Sponsor:

#2 Ashaman73   Crossbones+   -  Reputation: 6982

Like
2Likes
Like

Posted 02 February 2012 - 08:00 AM

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.

#3 mhagain   Crossbones+   -  Reputation: 7649

Like
1Likes
Like

Posted 02 February 2012 - 09:07 AM

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.

It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#4 fanaticlatic   Members   -  Reputation: 459

Like
0Likes
Like

Posted 02 February 2012 - 10:05 AM

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.
"I have more fingers in more pies than a leper at a bakery!"

#5 phantom   Moderators   -  Reputation: 6917

Like
1Likes
Like

Posted 02 February 2012 - 10:20 AM

The last hardware to have the Fixed Function Pipeline (FFP), as replaced by shaders, was the GeForce FX (aka GeForce Fail) which had a hybrid FFP/Shader setup internal. The ATI card of the same time, the R300 aka 9700, was totally shader driven and wiped the floor with the GFFX.

The R300 was released in 2002.
The FFP has been dead in hardware for nearly 10 years now.

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

#6 fanaticlatic   Members   -  Reputation: 459

Like
0Likes
Like

Posted 02 February 2012 - 10:28 AM

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.
"I have more fingers in more pies than a leper at a bakery!"

#7 mhagain   Crossbones+   -  Reputation: 7649

Like
0Likes
Like

Posted 02 February 2012 - 10:39 AM

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 appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.


#8 Krypt0n   Crossbones+   -  Reputation: 2360

Like
0Likes
Like

Posted 03 February 2012 - 01:50 AM

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.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS