Do FBOs have a non-trivial memory footprint?

Hey, I have an app where I have a very large number of textures that I render to (100s). I have 1 FBO for each texture.
Eventually when I try to bind an FBO it fails and I get an OUT_OF_MEMORY error.
My graphics card is a Quadro 5600 with 1.5gigs of GPU memory. As far as I can tell all of my allocated textures are only taking about 200 megs of memory (whbitdepth).
Do FBOs have a large memory footprint? Should I be using as few as possible (1 FBO for each 16 textures I guess)

You should use as few FBOs as possible. Best, use only one FBO and rebind the texture.

Thanks for the reply. I heard that rebinding the texture is expensive if the format/width/height is different than the one the FBO is currently bound to. Should I have a different FBO for each combination?
Do FBOs do an implicit render to offscreen buffer->copy to texture? Where is the cost of extra FBOs incurred (why avoid more than 1?)
In my case am I better off just creating a renderbuffer and doing blits myself? That way I can have a single renderbuffer that’s will accommodate the max texture size I’m working with, and just render/blit from a subsection of this renderbuffer for smaller textures.

Technically, an FBO shouldn’t be costly at all. They’re just a set of binding-points.

Do FBOs do an implicit render to offscreen buffer->copy to texture?

They could, but there’s no way to know whether that’s happening. Besides, if you can’t render to a certain set of images, it’d just give you FRAMEBUFFER_UNSUPPORTED.

Ya thats what I though originally too. I’m about to finish up trying out 1 FBO per width/height/format combination, we’ll see if that works in the same case where 1 FBO per texture failed.

I don’t think the fbo number is a problem. Once I used several fbo (about ten or more at the same time) to perform a fast blur effect and this was really fast.

Asking nVidia tech support can give you the best info :wink:

I am having a similar problem under Linux and NVidia (Quadro 5600). While I am able to allocate a lot of textures, it is not possible for me to create a FBO for each texture.

Currently I am using one FBO and rebind a different texture each time I want to render into the texture. But this seems to be slow, so I had the same idea as MalcolmB to provide one FBO for every texture I want to render to. But after 100 FBOs or something like that I cannot create FBOs any more and I get “X Bad Alloc” errors on the console. And yes, I really need a lot of textures to which I want to render (it is a composition application).

MalcolmB: So I’d be interested in any outcome of your work using one FBO for each texture size. Does it work/help? Just wanted to ask before diving into the same work.

Thanks for any feedback.

First tests show using 1 FBO of each ‘type’ running quite a bit slower than using pbuffers.
Not sure whats going on here yet.

Maybe I should just match the pbuffer usage (draw then copy to texture) with RenderBuffers instead of trying to draw directly to the texture…

While it’d be a safe fallback, it seems to go against reason as to why FBO was created in the first place.

An idea to try could be to have two FBO’s of each format and toggle between them. While I don’t see a reason it should matter, it could be worth a shot.


While I have been spending some time in my vacations, others have implemented an FBO cache such that FBOs would be recycled for different textures with same size and image format. This gave us a performance boost of about 20% over the previous implementation where we"d have only one FBO and use it for different textures.

But I feel that we have still more room for optimizations, I am also thinking of just using one large texture and FBO and copy its contents into other textures. But toggling between different FBOs could be another interesting option.

To me it really seems that FBOs are much more than some simple structures in RAM, I even suspect that they use additional VRAM. I read in an old presentation from NVidia that the driver might allocate additional VRAM for FBOs and copy its content to the bound texture, because the internal memory organisation might differ. This would explain what I am seeing.