My products need to run on a wide variety of hardware and drivers, both current and future. Consequently, I always run away as fast as I can from any behavior that is explicitly undefined – even if nVidia and ATI both assure me that the behavior works with their current cards.
As you may have noticed, confidence in the correctness of my code is very, very important to me 
Originally posted by MZ:
I do realize what are consequences of relying on undefined results. However, in threads in the past both Matt from Nvidia and Evan from Ati recommended particular usage scheme of WGL RTT, which is explicitly specified as undefined. Both guys ensured it does work on their HW. It was about RTT into double-buffered pbuffer. In practice, this technique is very closely related to the technique described in this thread. I think unsafety of relying on undefined result in this particular case is not as big problem as you see it.
MZ,
You’re getting into deeper waters with this kind of thing though. The way our hardware works (both NV and ATI apparently) we can promise defined results for what the spec leaves undefined in the case of double-buffering.
Texturing from the active render target is another thing entirely. Still, if you can live with “at your own risk”, you may be able to do some nifty stuff. (Not that I’m advocating it. 
)
Thanks -
Cass
[This message has been edited by cass (edited 01-24-2003).]
Originally posted by jwatte:
[b]Someone up the thread was talking about accessing the frame buffer as a general texture. And, as far as I know, current blend hardware is very specialized to do the read-modify-write cycle very fast. They can’t even (currently) fit a floating point unit in that path, so I could only imagine that putting an entire fragment program in the way would make it that much worse.
If all you have accessible is the frame buffer fragment corresponding to the current fragment, then I agree things would become a little easier, although probably not as “easy” as the current blend hardware. But I’d have to ask an ASIC designer to get any kind of certainty about that :-)[/b]
The reason there’s no blending on floating point render targets is just that blending assumes certain operations are cheap, such as 1 - x, which is true for integers but not for floats. For the very same reason you no longer have pre-scale/pre-bias/post-scale etc in a ARB_fragment_program as you had in ATI_fragment_shader and NV_register_combiners. So to implement blending with normal glBlendFunc() calls would be expensive in hardware. But if you can access the backbuffer in the shader you can use the same hardware for blending. The only real difference is at which time we access the framebuffer, and if we only access it the last thing we do in the shader there shouldn’t be a whole lot of difference compared to a normal blend.