OpenGL ES 2.0 - Reducing memcopies when rendering to textures

1
votes

Lets say I have four content layers: A, B, C and D; each one represents one type of visual content.

Each layer does several sequential render calls (there are no interleaved render calls from the various layers).

Also, layer B and D need to be rendered to textures in order to apply visual effects. In order to reduce the memory footprint, I use only one FBO with only one texture.

So, at the moment I do:

  • Render A content;
  • Bind FBO > Render B content > Unbind FBO > Render texture (B content);
  • Render C;
  • Bind FBO > Render D content > Unbind FBO > Render texture (D content).

My main problem with this approach is that every time I bind/unbind the FBO, the default framebuffer is saved/restored to/from memory.

I cannot simply draw layers B and D to the FBO first , since I cannot change the rendering order of layers.

Is there any better way to do this and avoid many saves/restores of the main framebuffer? Keep in mind that this is an example and the real case is more complex (more layers).

2
performanceopengl-esrenderingopengl-es-2.0fbo
"every time I bind/unbind the FBO, the default framebuffer is saved/restored to/from memory." - Are you sure about that? Isn't one of the major principles and advantages of FBOs the fact that this doesn't happen since there is no need to evict/restore the default framebuffer at all (yet it may be that ES hardware behaves differently in this regard, which would make FBOs quite a pain there, though)? - Christian Rau
I'm not sure if that happens on every chip, but according to Adreno 200 performance tips, every time you bind and unbind an FBO the driver resolves GMEM in/out of main memory. - amfcosta

2 Answers

0
votes

Being able to switch between render targets quickly is the primary original purpose of the FBO feature. It is generally faster than the older pbuffer approach because it does not have to deal with changing rendering contexts. Also, FBOs are not as dependent on the EGL to allocate the rendering surfaces as pbuffers are. If the Adreno 200 can not switch FBOs quickly, then that is an implementation problem specific to Adreno.

0
votes

The driver will bring the contents of the FBO back from memory (which is a costly operation), unless you clear the FBO with glClear() before drawing. Clearing the FBO will hint the driver to discard the current contents and not bring them from main memory. If your FBOs have a depth buffer, make sure you include that bit also when calling glClear().

Since you are only using one FBO, you may not be able to get around it. Check if your memory requirements are so strict that you can not use a second FBO, so you can render B to your first FBO, then D to your second, and then all your content layers together to the screen.