FrameBuffers Operations and Performance

[manu3d]

Hi everybody, my name is Manu and I'm -the- rendering department at Terasology.

If that emphasized -the- sounds too self-important it's because you have the wrong picture in mind. Think of a tiny mouse instead (that's me) trying to climb up a dark, mysterious, foggy mountain (that's the rendering code) shaped by a long lost God (that's the author of the code who eventually moved on).

I'm currently in the process of refactoring the code a) as a part of an effort to understand it b) to make it more accessible to others, as nobody dares venturing into it. During this process and due to some OpenGL reading I've done in the meantime, I noticed a pattern of operations that makes me wonder if we aren't loosing some time unnecessarily.

Specifically, most render passes (i.e. DoF blur, bloom filters, tone mapping, etc) are done this way:

• bind pass-specific FBO
• set viewport to FBO's dimensions
• set the buffers of the FBO to draw to
• clear the buffers
• do the actual rendering
• bind the display
• set the viewport to the size of the display

In particular, I'm worried about these aspects:
1. I seem to remember viewport settings are part of a FrameBuffer's state. So, can I just set them during the FBO's initialization if I do not need to change them again?
2. I seem to understand that also the draw buffers set with glDrawBuffer are part of an FBO's state. So, again, if I do not need to change them after initialization there's no need to set them every frame, right?
3. I seem to understand clearing a buffer is an expensive operation and ideally I should clear as many buffers as possible at once. Is that the main reason for comments I've read elsewhere to group all texture buffers of a given size (i.e. full screen) in a single FBO? (Consider I'm using OpenGL 2.1)
4. If you imagine the pseudo-code above repeated multiple time for a number of consecutive render passes, you can imagine how the binding of the display at the end of the pass is followed by the binding of a new FBO at the beginning of the next pass. Am I correct in saying that binding the display in this case is unnecessary and just wastes time?

Manu

[quew8]

OK so
1) I don't think so, but I did have a little read up on it and couldn't find anything from which I assume it is not part of the framebuffer state.

2) Yes, read and draw buffers are part of framebuffer state.

3) That is probably a good reason. The other would be to cut down on the number of framebuffer objs. I recall older hardware tending to not deal with that too well. Also will often cut down on number of different bindings to do.

4) Yes. If you are going to do another pass to another framebuffer without rendering to the default framebuffer (ie the display) first then there is no point binding it.

[manu3d]

Thank you quew8 for your reply.

On 1) I think you are right, I actually found explicitely written somewhere that the viewport needs to be reset appropriately every time a new FBO is bound.
On 2) Thank you for the confirmation.
On 3) Good point on the number of FBOs and bindings to do.
On 4) Thank you for the confirmation.

Again, thank you for everything!