GL_EXT_discard_framebuffer

[Alfonse Reinheart]

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.

I don't care what the purpose of EXT_discard_framebuffer was; my point is that you can achieve the same functionality a better way. A way that allows you to do more than just avoiding unnecessary copies on tile-based renderers, while doing squat on non-TBRs.

Images you frequently upload to can be invalidated, for example. You shouldn't have to stick them in an FBO just to do that.

Tile based renderers are not limited to OpenGL ES.

Really? How much product does PowerVR sell on desktops these days?

[Eric Lengyel]

My motivation for tweeting about this is related to SLI on desktop systems. I want to be able to tell the driver that I'm never going to use the contents of an FBO rendered during one frame as a texture in any subsequent frame, so don't ever waste time copying it to the other GPUs.

I know that the IHVs tell us to clear the FBOs every frame so the driver can infer that the contents will be replaced and avoid these copies, but I've had problems getting that to work reliably. Also, what if some FBOs aren't rendered to every frame (shadow maps, for example)? It wouldn't be optimal to keep clearing those anyway just so the driver knows not to copy them.

[aqnuep]

Thanks for the explanation!

Now I would also say that it would be easier for the driver to determine when the contents of the framebuffer should be preserved if we would have something like GL_EXT_discard_framebuffer as I don't see that from driver implementation point of view invalidating the texture would be the most easy way to detect such situations.

Btw, isn't it bothering you that SLI for OpenGL is only available on Quadro cards due to NVIDIA's limitation of exposing the WGL_NV_gpu_affinity extension only on Quadro cards? At least we have GLX/WGL_AMD_gpu_association for linux and Windows for all ATI cards.

... and that goes back to the topic of cross-vendor multi-GPU support in OpenGL core

[arekkusu]

I think APPLE_object_purgeable addresses both Alfonse's and Eric's examples.

Objects dirtied in VRAM (i.e. rendered to) can be marked purgeable. Then, if some event (like a page-out due to memory pressure, or a switch to another renderer aka SLI) occurs, the contents are simply discarded-- don't spend any time shuffling data around that the app will just re-generate next frame anyway.

Same API applies to textures/buffers/renderbuffers.

[Eric Lengyel]

Now if only either EXT_discard_framebuffer or APPLE_object_purgeable was actually available on NV and AMD desktop hardware for PCs.

[Xmas]

I don't care what the purpose of EXT_discard_framebuffer was; my point is that you can achieve the same functionality a better way. A way that allows you to do more than just avoiding unnecessary copies on tile-based renderers, while doing squat on non-TBRs.

Images you frequently upload to can be invalidated, for example. You shouldn't have to stick them in an FBO just to do that.

And why is using a NULL pointer for texture image data not enough?

I'd disagree that your suggestion is a better way for the common use case of discarding render targets.

[Alfonse Reinheart]

And why is using a NULL pointer for texture image data not enough?

glTexStorage. Once you have immutable storage, you may need a way to "reallocate" it without it truly being mutable again.

I'd disagree that your suggestion is a better way for the common use case of discarding render targets.

It's not a "better way" for that use case. It is a better way overall, because you don't clutter the API with these things that are only useful in corner cases. You get the same effect by just invalidating all of the images bound to the buffer. It's slightly less convenient than the "common use case" (though I wonder at how common this would actually be), but it allows it to be much more useful in general.

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.

[aqnuep]

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.

While after all I agree, I think GL_APPLE_object_purgeable could be a good thing to adopt as you can tell the driver up-front that it can discard the content of the object, but invalidation is done later thus the driver must let's just say "look-ahead" in order to be able to always make the right decision in the right time.

Let's just think about the following use case:

• glBindFramebuffer (framebuffer with discardable attachments)
• draw something here
• glBindFramebuffer (another framebuffer)
• glTexImage (invalidate attachment textures)

In such a case most probably the image will be already saved back to the texture storage at the point the new framebuffer is bound (just think about the Z-decompression phase of Hi-Z as an example, but color buffer compression is not uncommon either) unless the driver looks ahead and figures out that there is no need for it.

However, with purgeable objects you can do it in the following way:

• glObjectPurgeable (mark attachment textures as purgeable)
• glBindFramebuffer (framebuffer with discardable attachments)
• draw something here
• glBindFramebuffer (another framebuffer)

Here the driver will know up-front that the textures could be discarded so there will be no case when the decompression/store operations will take place.

Unfortunately GL_APPLE_object_purgeable is not enough either as far as I remember it defines object purgeability only for buffer objects but it should be extended to handle textures as well.

[ScottManDeath]

D3D11.1 supports similar functionality:

http://msdn.microsoft.com/en-us/libr...resource_views

[aqnuep]

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).

Anyway, it seems that this topic is definitely one that has to be addressed.