1

I was looking aground trying to understand why we are still using fixed function blending modes in newer 3D API's (like D3D11). In D3D10 fixed function Alpha Clipping was removed in favor of using the shaders. Why because its a much more powerful approach to almost any situation.

So why then can we not calculate or own blending operations (aka texture sample from the RenderTarget we are currently rendering into)?? Is there some hardware design issue in the video card pipelines that make this difficult to accomplish?

The reason this would be useful, is because you could do things like make refraction shaders run way faster as you wouldn't have to swap back and forth between two renderTargets for each refractive object overlay. Such as a refractive windowing system for an OS or game UI.

Where might be the best place to suggest an idea like this as this is not a discussion forum as I would love to see this in D3D12? Or is this already possible in D3D11?

genpfault
  • 51,148
  • 11
  • 85
  • 139
zezba9000
  • 3,247
  • 1
  • 29
  • 51
  • "Where might be the best place to suggest an idea like this" *Everyone* wants this. Everyone wants a *lot* of things. You don't need to suggest these sorts of things to hardware makers; they know that people want them. Wanting things does not mean that they're going to happen. Nor will suggesting them mean getting them faster. – Nicol Bolas May 21 '12 at 22:24
  • "they know that people want them... Nor will suggesting them mean getting them faster" -And how is that? Because of some random unsupported guess? Or maybe because ppl like me(even if im not up to speed about this issue) asks and talks about it actually indicates to 'others' that 'others' have come to similar thoughts and/or needs?? Im sorry I hit a nerve in your that big ego of yours... but communication is the first step in materializing any valid idea. – zezba9000 May 21 '12 at 23:16
  • Hardware makers do not listen to "guys on a forum." They listen to John Carmack. They listen to Tim Sweeney. They listen to the guys at Blizzard, EA, Activision, and so forth. They don't listen to random voices out of the blue. Why? Because the guys who actually do this stuff professionally are already making the valid suggestions. And if you want evidence for it, there's the fact that we *have this functionality already* (to a non-trivial degree) in "arbitrary" read/write access to images. Hardware makers added this functionality because the big guys wanted it, not because of guys on a forum. – Nicol Bolas May 22 '12 at 05:39
  • Dude rly? Why do you even comment on here if all your going to do is ridicule others because you 'feel' they should contain knowledge you hold so dear?? Time to see past the ego through psychological association, there are plenty of valid idea's and questions out there that don't come directly from the 'big' guys wether or not the hardware ppl hear or listen to them is irrelevant to there validity. And thats not even relevant to the question anyway, so get over it we've all got stuff to learn, even John Carmack. – zezba9000 May 24 '12 at 03:51

2 Answers2

3

So why then can we not calculate or own blending operations

Who says you can't? With shader_image_load_store (and the D3D11 equivalent), you can do pretty much anything you want with images. Provided that you follow the rules. That last part is generally what trips people up. Doing a full read/modify/write in a shader, such that later fragment shader invocations don't read the wrong value is almost impossible in the most general case. You have to restrict it by saying that each rendered object will not overlap with itself, and you have to insert a memory barrier between rendered objects (which can overlap with other rendered objects). Or you use the linked list approach.

But the point is this: with these mechanisms, not only have people implemented blending in shaders, but they've implemented order-independent transparency (via linked lists). Nothing is stopping you from doing what you want right now.

Well, nothing except performance of course. The fixed-function blender will always be faster because it can run in parallel with the fragment shader operations. The blending units are separate hardware from the fragment shaders, so you can be doing blending operations while simultaneously doing fragment shader ops (obviously from later fragments, not the ones being blended).

The read/modify/write mechanism in the blend hardware is designed specifically for blending, while the image_load_store is a more generic mechanism. And while generic may beat specific in the long-term of hardware evolution, for the immediate and near-future, you can expect fixed-function blending to beat image_load_store blending performance-wise every time.

You should use it only when you must. And even the, decide if you really, really need it.

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
1

Is there some hardware design issue in the video card pipelines that make this difficult to accomplish?

Yes, this is actually the case. If one could do blending in the fragment shader, this would introduce possible feedback loops, and this really complicates things. Blending is done in a separate hardwired stage for performance and parallelization reasons.

datenwolf
  • 159,371
  • 13
  • 185
  • 298
  • Yes after writing this I did realize refraction could not be done as I suggested, aka you would have to buffer the last frame to sample from. – zezba9000 May 21 '12 at 23:50