GL_EXT_discard_framebuffer

[aqnuep]

What about adding the following ES extension to desktop GL?

GL_EXT_discard_framebuffer

It actually trivially adds the possibility to invalidate the content of framebuffer attachments. This can provide room for some optimizations.
Of course, this feature is more relevant for GPUs on embedded devices that's why it is an OpenGL ES extension, however I think it may provide possibility for optimizations on desktop as well.

What do you think? Is it pointless for desktop GL?

[arekkusu]

Desktop implementations typically already implement something like this, by saying "the contents of the back buffer become undefined after swap" in their window system-specific layer.

This extension is most relevant to systems like iOS, where the only way to create a drawable is to create an FBO. In typical desktop use cases, if you create an FBO you certainly don't want to discard the contents immediately after rendering, because you will use the results as a texture in the future. It's only in the "use an FBO as the main system drawable" case that this extension is a big performance win.

Some desktop systems (i.e. Apple) also already have other mechanisms (i.e. APPLE_object_purgeable) to allow fine-grained discarding of object contents, which helps performance in memory-pressure situations.

[kRogue]

Also in the EGL world, there is a bit/property that one sets when getting context (or was it surface) where the contents of the buffer can safely be discarded by the GL implementation at the start of each frame. Generally speaking, in the embedded world, even if the you are NOT doubled buffered this bit should be true (because it saves a read back into the GPU for all tile based renderers such as PowerVR SGX and ARM Mali).

[aqnuep]

Thanks for the info, I know the main reason was to not have to read back the content of the framebuffer from the GPU's fast memory to the main memory, however was not thinking about double buffering actually makes this extension unnecessary (at least in most cases).

Actually the idea came into my mind after reading one of Eric Lengyel's posts on twitter:

It'd be really nice if OpenGL gave you a way (better than clearing) to indicate that FBO contents can be discarded on buffer swap.

... and actually this is what GL_EXT_discard_framebuffer is for, just maybe only Eric knows what he needed it for.

[Alfonse Reinheart]

It'd be really nice if OpenGL gave you a way (better than clearing) to indicate that FBO contents can be discarded on buffer swap.

That makes no sense, as FBOs cannot be buffer swapped.

And really, I don't see the point of having an explicit invalidate method for FBOs only. If you're talking about invalidating images, then there should be methods for invaliding images, whether they happen to be part of an FBO or not. Associating it with FBOs makes no sense.

It should just be glTexInvalidate, which can invalidate either the whole image or just a mipmap (note: the latter would not be allowed for immutable textures).

[aqnuep]

I think he just meant framebuffers when he used the term FBO, even though that's not really correct.

Actually your proposal about image invalidation is even better, however, unfortunately OpenGL does not expose yet the possibility to access the attachments of the default framebuffer (which may be the very last thing that is not supported by OpenGL compared to D3D).

Also, if we are talking about the details of a possible image invalidation command I think invalidating a single level of a texture wouldn't break immutable textures as it invalidates just the content, not the mip level (okay, I know you meant here the very same invalidation mechanism that allows in case of buffer object the reallocation of the buffer, or at least swapping between two or three buffers, as discussed at the buffer_storage topic, however, image invalidation may not necessarily go that far).

[Xmas]

And really, I don't see the point of having an explicit invalidate method for FBOs only. If you're talking about invalidating images, then there should be methods for invaliding images, whether they happen to be part of an FBO or not. Associating it with FBOs makes no sense.

The main purpose of the EXT_discard_framebuffer extension is to avoid unnecessary data copies on tile based renderers, especially writing out depth, stencil, or multisample data to external memory when these buffers will be cleared at the beginning of the next frame anyway.

Invalidating FBO attachments perfectly fits that use case. If you want to discard the contents of a texture you can already do so.