There is very little information in that article. Do you have other links to similar information?
Nope. Unfortunately, the ARB isn’t as communicative as they used to be or ought to be. So SIGGRAPH it is… if then.
The blend unit solves these issues simply by being fixed function, it’s easy to make a single read-modify-write sequence atomic. If you make this programmable you get a lot of problems. They are not unsolvable, but solving them costs a lot performance.
Not necessarily. I could see blend shaders looking something like the old register combiners (or, at the really high end, ATI_fragment_shader). A limitted set of comparison, color, and discard operations that is somewhat configurable. You could call it programmable, if only for the complexity of operations that become possible.
Originally posted by Overmind: The blend unit solves these issues simply by being fixed function, it’s easy to make a single read-modify-write sequence atomic. If you make this programmable you get a lot of problems. They are not unsolvable, but solving them costs a lot performance.
Does this consideration lend weight to this idea of a second (or multiple) depth buffers over programmable shaders later in the pipeline?
It seems that multiple depth buffers with a selection of basic built-in functions (eg. GL_LESS) and operations (eg. GL_REPLACE) may be much more amenable to hardware implementation than general programmable framebuffer access.
That said, the point is fairly moot if these sort of shaders have already been decided upon by the ARB… why did the meeting minutes suddenly end in 2004?
Does this consideration lend weight to this idea of a second (or multiple) depth buffers over programmable shaders later in the pipeline?
I don’t imagine a blend unit (particularly in the first version) would offer the power to grab any texture out there and do stuff with it. So if there were to be some kind of second depth buffer, it would definately need to be a real thing: a buffer object bound to another depth target in the FBO.
The more I think about it, the more I think that RC’s are the right way to go about both implementing and exposing (conceptually. Obviously the real interface would be glslang with function calls) a blend shader.
That said, the point is fairly moot if these sort of shaders have already been decided upon by the ARB… why did the meeting minutes suddenly end in 2004?
Something about some IP problems with publically posting minutes.