OpenGL: Using only one framebuffer and switching target textures

1
votes

Instead of using multiple framebuffer objects, can I also create only one and achieve the same results by switching it's target texture when needed?

  • Is this a bad idea in all cases? If yes, why?

I've been implementing a function render.SetTargetTexture() in my program's API, and logically it wouldn't work if there were more framebuffers used behind the scenes. I'd have to fully expose framebuffers then.

2
openglframebufferfbo
I've never actually benchmarked this, but it seems kind of conclusive that binding a different FBO is more efficient. Binding a different texture to the FBO requires complicated consistency checks for framebuffer completeness (if not explicitly by you, then in any case inside the driver). Binding a different, unmodified framebuffer doesn't require that kind of thing. - Damon
I think another way to look at it is it probably doesn't matter. I don't know of any apps that switch targets thousands of times per frame. Most switch just a few times max. I agree that switching fbos should be faster than switching attachments but if it doesn't really matter than your API is fine. - gman

2 Answers

6
votes

A FBO itself is just some logical construct, maintained by the implementation and it will consume only the little memory that its parameters require. The main purpose of a FBO is to have an object that maintains a consistent state.

Whenever you do changes to a FBO's structure, the implementation must check for validity and completeness. The OpenGL specification doesn't say anything about the complexity of this operation, but it's safe to assume that changes to a FBO's structure is about the most time consuming operation (maybe by a large margin).

Since the FBO itself does not consume noteworthy memory, only the attachments take memory, which are independent objects, allocating multiple FBOs and swithing those is what I recommend.

-1
votes

Switching framebuffers is usually faster for the reasons people have given. In my experience, there are also problems when attaching different texture types to fbos (2D texture to fbo which previously had a 1D texture attached, so the first texture attached to the fbo set some kind of target state which could not be altered later). A solution I used was to have an fbo for each target type. This error occured on NVidia Quadro devices, not sure whether it's a driver issue.