Read from read/write texture should be valid until pass writes

OpenGL
1

The following functionality already works on the GeForce 8800, Go 6800, and probably many others. This is just a request for a change in the spec to ensure it keeps working in the future.

The spec change:

Reading a value from the framebuffer or a texture that is bound for both reading and writing, such as in an FBO, should be guaranteed to return the correct value (the value of that pixel prior to beginning the current rendering pass) if a write to that location has not yet been done in the current pass, for any primitive. After a write has been done in the current pass, for any primitive, a subsequent read from the same location is undefined.

This would allow multipass techniques without the two-texture ping-pong requirement in many cases.

Comments?

-Raystonn

2

Comments?
I’d post something, but Evan said it best:

Well, the whole problem with the assertion that this is OK within a single pass, is that a ‘pass’ is not defined anywhere in OpenGL. Is it everytime you call begin? Establishig such a semantic would require that implementations flush their caches at that point, which could have a negative impact on performance. Also there have been lots of graphics cards in the past that would require a surface transfer between rendering and texturing. These would break under that scenario. An SLI config where each card rendered 1/2 of the FBO would be another example where this is not something that could be fully guaranteed without sacrificing performance.
It wasn’t a good idea in the other forum, and it doesn’t suddenly get to be a good idea here.

3

It wasn’t a good idea in the other forum, and it doesn’t suddenly get to be a good idea here.
It’s a good idea that may be difficult to implement.

4

I think the “difficult to implement” is the part that makes it a bad idea, as much as I love it as a software guy.

5

Yeah, totally. I just don’t think it’s fair to call something a bad idea, just because it’s difficult to implement.

6

A future “blend”/“framebuffer” shader could be used for this I suppose.