GL_EXT_discard_framebuffer

[skynet]

Yes, I've just read the same today. However, that API is no different than the already existing orphaning possibility provided by using glTexImage(..., NULL) or glBufferData(..., NULL).

Orphaning and marking objects as "purgable" are different concepts.

Orphaning says "I do not need this data anymore, I will never need it again."

Purgable objects are marked as "I don't mind if the driver throws this data away. I will regenerate the data if needed. But if the data can be kept around, fine."

[aqnuep]

Okay, you're right. There is difference between orphaning and purgeability. However, I meant that both glTexImage(..., NULL) and D3D11.1 are post-actions, while purgeability has the advantage that it tells the information to the driver up-front.

[Xmas]

(though I wonder at how common this would actually be)

In the vast majority of FBO usage cases you don't need to keep depth/stencil or multisample data around. Discarding the contents of these attachments should become a matter of course.

What you absolutely don't want is to put EXT_discard_framebuffer in, then come along in a year's time and add a texture invalidate function. Because they do the same thing.

If someone were to come up with such a function, you could keep DiscardFramebuffer as a convenience function and define it in terms of the new invalidate functions. No big deal.

By the way, you'd also need invalidate functions for renderbuffers and the default framebuffer.

[aqnuep]

By the way, you'd also need invalidate functions for renderbuffers and the default framebuffer.

Yes, and we arrived to another thing that I still really miss from OpenGL: having the possibility to use the default framebuffer attachments as textures (btw that's possible in D3D).

[Alfonse Reinheart]

By the way, you'd also need invalidate functions for renderbuffers and the default framebuffer.

Why would you need one for the default framebuffer? The act of swapping the buffer with a non-copy swap tell the driver that it can be discarded. That's what the non-copy swaps are for.

[aqnuep]

Why would you need one for the default framebuffer? The act of swapping the buffer with a non-copy swap tell the driver that it can be discarded. That's what the non-copy swaps are for.

But what if you would like to discard only certain attachments? Actually I think it is pretty unlucky that we can handle the default framebuffer only with window system specific functions. It would be great if the default framebuffer would be no different than any other framebuffer object so that we can play around with its attachments.

[Alfonse Reinheart]

But what if you would like to discard only certain attachments?

There's no such thing as "certain attachments," on the default framebuffer. If you mean "certain images", what does it matter? If you can invalidate textures/renderbuffers, then you don't really care about other default framebuffer parts like GL_AUXi and so forth.

I just don't see the need for having a special API for something so special case, when you can have a general API that covers that special case as well as others.