Stupid question: Is it possible to have both programmable and fixed function shaders?

[DeadlyNinja]

I don't mean programmable vertex shader + fixed function pixel shader like the 3DS. I mean both programmable and fix function pixel shaders together. So like developers with smaller budget or smaller companies can readily make of the fix function stuff, while the big budget games can program their own shaders benefiting both sides.

 

[Xenus]

In theory yes but it would be redundant so I'm not sure why anyone would.

 

[3dcgi]

It doesn't seem necessary since that's what software libraries are for.

 

[MJP]

You would be much better off by having a series of shaders that implemented the traditional fixed-function pipeline. This is how the IHV's have implemented the fixed-function parts of GL/DX ever since they supported programmable shaders.

 

[wsippel]

It's possible, and DMP is expected to reveal such a GPU this year. PICA Extreme, the bigger brother of the 3DS GPU, will feature both, programmable pixel shaders and fixed function/ parametric Maestro units. Wouldn't be surprised if the Wii successor used this GPU.

 

[Shifty Geezer]

Surely PICA has t do that for BC with other PICA developments? It's pointless in a clean architecture as shaders can do what the fixed-function pipes can. Unless fixed-function units are an order of magnitude more efficient, the space they take up would be better served going towards more programmable shaders. eg. Let's say a GPU is divided 50/50 programmable DX cores and PICA fixed-function cores - unless those fixed-function units are twice as fast at what they do than the DX units, using them in isolation won't be any faster than if replaced with programmable cores.

All developers need is a set of shaders that replicate the fixed-functions you'd have, that they'd use out of the box without caring to write their own. That saves the development cost and keeps the GPU simple and flexible for other devs.

 

[wsippel]

They most definitely are far more efficient. Maestro also contains hardwired functions for rendering stuff like gaseous objects or hair, or generating procedural textures on the fly. I think it's a great idea to hardwire very common and very complex and costly functions, while also supporting programmable shaders for anything else.

 

[DeadlyNinja]

Yeah, I recall reading about fix function being more efficient (but of course lacks flexibility), and that games can run at steadier frame rate.

 

[Shifty Geezer]

But how much more efficient? I can understand design a GPU around it, like PICA, but a combination of programmable and fixed-function seems a rather forced compromise. The whole reason we have unified shaders is because tasks were made more efficient, and more could be done for the same silicon, by moving away from discrete units for discrete jobs. Complex shaders could be hardwired, but I'd need to see a huge benefit to have my programmability given over to a fixed set of asset limits - if you want more fur but exceed the fixed function units capacity, you are stuck, whereas with programmable hardware you can reduce shader use elsewhere.

 

[Silent_Buddha]

But how much more efficient? I can understand design a GPU around it, like PICA, but a combination of programmable and fixed-function seems a rather forced compromise. The whole reason we have unified shaders is because tasks were made more efficient, and more could be done for the same silicon, by moving away from discrete units for discrete jobs. Complex shaders could be hardwired, but I'd need to see a huge benefit to have my programmability given over to a fixed set of asset limits - if you want more fur but exceed the fixed function units capacity, you are stuck, whereas with programmable hardware you can reduce shader use elsewhere.

The fixed function won't do much to help from the programmability side of things. You'd still be able to do the same things with the universal shaders. But if it's targetted at very specific but also very common high cost of execution functions it would be a large win in a console where you can't afford to put in a power hungry GPU like a GF110 or Cayman.

So for a, hopefully, small cost in silicon it could potentially have a large overall impact on speed of execution which theoretically could free up more rendering time for other things that would previously have been taken up by the high cost shader.

Or to put it another way. That small cost in silicon for a fixed function unit might result in a larger overall increase in performance when it is being used versus using that same space for more universal shader execution units. Of course, this assumes that fixed function unit is used more often than not. Hence, why it only makes sense for things that are commonly used.

Hair and gaseous units as mentioned previously by wsippel seem like good candidates as hair is fairly common. Perhaps it'll result in less bald hulking space marines. Now we can have space marines with glorious flowing Fabio locks of hair.

Regards,
SB

 

[Rangers]

Now we can have space marines with glorious flowing Fabio locks of hair.

Next gen will truly have arrived!

 

[AlNom]

The fixed function won't do much to help from the programmability side of things. You'd still be able to do the same things with the universal shaders. But if it's targetted at very specific but also very common high cost of execution functions it would be a large win in a console where you can't afford to put in a power hungry GPU like a GF110 or Cayman.
...

Hardware MLAA/other edge post-process settings just prior to scaling and output? XD (I keed) Might as well have depth as an input ala depth + 2D for 3D modes.

not srs...

 

[3dcgi]

In a way what DeadlyNinja is asking about already exists. If an operation is useful enough it gets a dedicated instruction while other operations might need macros that are really multiple instructions.

 

[Megadrive1988]

It's possible, and DMP is expected to reveal such a GPU this year. PICA Extreme, the bigger brother of the 3DS GPU, will feature both, programmable pixel shaders and fixed function/ parametric Maestro units. Wouldn't be surprised if the Wii successor used this GPU.

I hope not, and it's looking very likely that AMD is supplying the GPU for Wii's successor. Either an Rx7xx (Radeon HD 4xxx family) GPU or a Fusion APU. I'm now hoping for the Trinity APU. That would provide shader model 5.0 support, including tessellation (sp?). However it's possible that an Rx7xx GPU is being used, as per the current rumors ignorantly say "R700" which would specifically mean the 4870x2 which was the dual RV770 card released late 2008. Thus, I use "Rx7xx" to be non-specific. The only detail about the GPU is that it supports shader model 4.1. The current thinking (via GAF) is that AMD would not licence any of the more current shader 5.0 (Evergreen, Northern Islands) GPUs to Nintendo, but would licence the older Rx7xx to Nintendo.

If true, Nintendo would be getting a somewhat dated GPU, but one that's still ahead of Xenos and RSX in both features and power. By how much though, is a good question. Another theory is that the Rx7xx GPU in dev-kits is not the final GPU and that Nintendo is waiting on AMD to supply the final Fusion APU. It's very hard to keep track of the explosion of rumors. I'm still reading that massive thread on GAF.

 

[sebbbi]

Fixed function units + programmable units can be a good choice as long as the architecture is designed so that most of the hardware can be utilized most of the time.

If the developer has to choose between a separate fully fixed function pipe or a separate fully programmable pipe, and cannot mix them, half of the chip transistors idle all the time (assuming the fixed function and programmable hardware is split 50/50). To make things more efficient, the chip must utilize both fixed function and programmable hardware simultaneously (in some kind of pipelined fashion).

The current graphics chips already have lots of both fixed function and programmable hardware. For example the fixed function texture sampling units in current hardware are a good use of transistors, since most algorithms can be implemented so that the sampling units are properly utilized all the time. There are of course some cases where the fixed function sampling units are idling (for example during shadow map rendering), but in a properly balanced graphics engine, the sampling units are almost 100% balanced most of the time. A good way to use excess texture sampling units when you are ALU bound is to formalize your math in a way that allows you to store math results in a texture and use it as a lookup. This way you can utilize the fixed function sampling unit even if you are not actually needing it for the task it was originally intended for. Otherwise it would stay idle and do nothing.

I don't know how their fixed function gaseous object and hair stuff works, but it would be bad if those transistors are idling most of the frame, since most games do not have that much gaseous stuff or hair visible in the scene at once (it they have at all). But it all depends of course how big part of the gaseous object pipe is actually running on fixed function hardware. It only the triangle setup / rasterization stage is running on a separate fixed function hardware, and the gaseous object pixel rendering uses same shader pipes as all the other rendering, then it might be a good way to spend some transistors.

 

[Shifty Geezer]

I don't know how their fixed function gaseous object and hair stuff works, but it would be bad if those transistors are idling most of the frame, since most games do not have that much gaseous stuff or hair visible in the scene at once (it they have at all).

That's precisely my thinking, although I agree with what you said and suppose I was generalising "fixed function" as fixed shader operations that can be performed in shaders. The problem I have with the Maestro philosophy is what if your game hasn't got hair and gas? Any specific jobs given over to hardware like that are going to force design choices onto devs, or sit idle. At this point I can't see any fixed-function FX/shader units worth sacrificing programmable shaders for. Except GI lighting, which is something that'd be almost universally used no matter the game style, but I don't see how and GI methods around at the moment can be streamlined into fixed-function units.

 

[Fafalada]

The problem I have with the Maestro philosophy is what if your game hasn't got hair and gas?

Practicality aside - the most fun with "maximizing" HW is perverting fixed-function elements to do things they were not designed to do.

 

[MJP]

Except GI lighting, which is something that'd be almost universally used no matter the game style, but I don't see how and GI methods around at the moment can be streamlined into fixed-function units.

Fixed-function Gauss–Seidel solver?