This question might sound a bit strange but seeing on how switching multiple FBOs perform faster than using one and switching attachments I could not get around wondering how much memory an FBO roughly consumes? I don't mean now the attachments as these I can calculate already. I could not find any information on what kind of memory consumption one should expect from creating holding a configurated FBO. Any ideas?

I checked my app with gDEBugger, and it showed that 3 FBOs consume less than 1KB memory --> insignificant. The attachments however consume 4 * 3.6 = 14.4MB @ 720p

Yeah, I did tests with a HW occlusion testing method I made recently (no occ-queries, a HZB oriented method but my own style). For creating the mip-map levels I used once a method where I use one FBO and switching the attachments around and one where I use one FBO for each mip-map level and switching those. The difference had been up to 1ms faster with the FBO switching version depending on the situation. That's though on ATI on Linux. I plan to switch everything now to individual FBOs to gain these speed improvements on various places. I estimate that I can end up with 50+ FBOs that way hence I wanted to see if I would get memory wise into troubles with the already tight GPU memory at hand. Could back-fire on me though as on Windows if I remember correctly switching FBOs is horribly slow compared to switching attachment points.

[quote name='RobinsonUK' timestamp='1333972494' post='4929522']Sounds about right. Did you work out whether switching FBO was faster than switching attachments? I'm curious to know.

There is actually no way it could be any different.

When you bind a different FBO, the driver internally does something like the equivalent of changing a pointer. When you switch attachments, the FBO is in an unknown/undefined state. The driver must run a number of checks on both the attachment and the FBO (render target size, bit depth, framebuffer completeness, and what not). What's worst, it has little choice to defer those checks and batch them together.

If a FBO is not bound, the driver can, as an optimization, choose to do the completeness check no earlier than either you ask for completeness or attempt to bind it. If it is bound already, the driver must do the check every single time you touch an attachment.
[/quote]
1ms difference sounds to me though like quite a large difference to begin with.

EDIT: Besides you can't change attachments on an FBO if it is not bound so it is not possible to optimized the attachment process of an FBO if it is not bound.