0

Here is the situation: I use 2 FBOs, 1 for image filtering resolution 640*480, the other for real rendering using filtered images resolution 1024*768. However the framerate is much lower than i expected, eg 30+ fps -> 15 fps. I checked each step of the code, and found that(this is a additional FBO i created):

// Render to our holefilling framebuffer
glBindFramebuffer(GL_FRAMEBUFFER, holeFillingFramebufferName);
//Attach depth buffer to the FBO
glFramebufferTexture(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, depthBufferTexture, 0);
// No color output in the bound framebuffer, only depth.
glDrawBuffer(GL_NONE);

// Always check that our framebuffer is ok
if(glCheckFramebufferStatus(GL_FRAMEBUFFER) != GL_FRAMEBUFFER_COMPLETE)
    return false;
// image filtering staff

This part takes a long time, 30ms average I believe. So I commented glCheckFramebufferStatus lines, and found the time was tranfered to the following part. I think this is because the system need time to prepare the FBO before the image filtering jobs start. I tried to change two FBOs to the same resolution, but it seemed make no difference. Any tips to speed it up?

P.S. I work with OpenGL/glsl 3.3 with glfw, VS2010 Win7

Christian Rau
  • 45,360
  • 10
  • 108
  • 185
MagicTracy
  • 35
  • 8
  • Have you tried not binding the same texture to the depth attachment every frame? I'll just stay there; you only have to do that once, when setting up your FBO. – Nicol Bolas May 08 '13 at 13:50
  • Yes, that's right. I'd try it tomorrow. BTW, i wana know wheather an OpenGL operation is expensive or not, where can i find the relative documents?it should be card and platform dependent, right? I guess texture attachment is expensive, because it might involve many state and cache changes. – MagicTracy May 08 '13 at 15:07
  • I think the thought "texture attachment is expensive " is wrong.... in this link "http://www.songho.ca/opengl/gl_fbo.html", is said "Framebuffer object (FBO) provides an efficient switching mechanism; detach the previous framebuffer-attachable image from a FBO, and attach a new framebuffer-attachable image to the FBO. Switching framebuffer-attachable images is much faster than switching between FBOs. FBO provides glFramebufferTexture2D() to switch 2D texture objects, and glFramebufferRenderbuffer() to switch renderbuffer objects." – MagicTracy May 08 '13 at 15:30

1 Answers1

2

Avoid changing the attachments on FBOs. This is an expensive operation, as it causes the driver to need to re-validate the FBO, which is what's happening here in your example. You only need to bind the depth attachment once, not every frame. If you bind it every frame, you cause driver validation of the FBO every frame, which is expensive.

The advice quoted by MagicTracy is, unfortunately, exactly opposite of the truth. Switching FBOs is cheap, while changing the attachments of FBOs is expensive (again, because it requires re-validation).

Valve described this in their presentation "Porting Source to Linux - Valve's Lessons Learned." See page 64 & 65: https://developer.nvidia.com/sites/default/files/akamai/gamedev/docs/Porting%20Source%20to%20Linux.pdf.

Josh Parnell
  • 1,166
  • 9
  • 10