Re-create FBO (frame buffer object) each frame

Hi
I would like to create FBO that will be “shared” between all contexts. Because an FBO is container and can not be “shared”, but only its buffers, I thought to do the follow:

  1. Create an object FBODescriptor that is a descriptor of the desired FBO, it contains just some information of what i want it to be, and it contains also opengl buffers that are shared.

  2. When doing the rendering , I create the FBO (so it is available for the current context), attach to it the buffers, does the rendering to it , and then delete the FBO container.
    Thus, I actually create and delete the FBO container for each rendering. In this way, I have a desired FBO that is available for any context.

My assumption is that because the resources buffers (textures, depth_stencil) are existing and no need to re-create each frame but only the FBO container, it doesn’t have a meaningful penalty.

May it works?

Thanks

That’s not a good assumption.

While most of the actual storage space is tied up in the framebuffer attachments, in terms of synchronization the framebuffer is one of the most heavy-weight objects in GL (in several drivers I’m somewhat familiar with). This is especially true in mobile.

Further, on some GL drivers, a “reconfig” of a framebuffer (e.g. change of resolution and/or formats) is treated effectively as a full delete and recreate of the framebuffer, which is very heavyweight.

Based on the advice I’ve gotten from a few vendors, I’d suggest you don’t dynamically delete and recreate FBOs, but rather keep a pool of them and reuse them in LRU fashion. On some drivers it pays to have separate pools of FBOs based on res+format, because in that case it can be fairly cheap to change out the underlying attachments (particularly if the work last queued for that FBO has already completed). For instance, if you last rendered to an FBO with a format of 512x512 RGBA8, try to make your next render to that FBO the same res and format.

[QUOTE=Dark Photon;1287508]That’s not a good assumption.

While most of the actual storage space is tied up in the framebuffer attachments, in terms of synchronization the framebuffer is one of the most heavy-weight objects in GL (in several drivers I’m somewhat familiar with). This is especially true in mobile…
.[/QUOTE]

Thank for the advice !