[QUOTE=emanuele3d;1266578]Thank you for your reply Osbios.
I’m currently refactoring some OpenGL 2.1 legacy code that I have not originally authored and the original author has moved on. In this context a number of rendering passes follow the pattern “bind an FBO, enable the shader” or viceversa. Differently from the scenario you portray, the code I’m dealing with has somewhere between 15 and 20 FBOs and most post-processing passes (i.e. light shafts, tone mapping, bloom filter, depth of field…) all have their own shader and their own FBO. [/quote]
If you have between ~20 FBO binds, but also only ~20 shaders, then it’s probably not going to be a problem. Or rather, the cost of changing FBOs that often will dwarf the added cost of also changing shaders.
That being said, you could probably consolidate some of those changes, using different images in the same framebuffer via glDrawBuffers. Of course, whether that would improve speed or not is something you’d have to profile.
Changing shader state isn’t cheap, but it isn’t as expensive as FBO changes.
Really, framebuffer completeness is the least of the issues with framebuffer binding. It’s more about how the GPU has to clear all of its caches, swap a bunch of memory pointers, stall the rendering pipeline (so that the old stuff is finished processing), and so forth.
Framebuffer completeness is a drop in the bucket compared to that.
Also, completeness checking can be done ahead of time; it is a property of the framebuffer itself and is unaffected by other state. So unless the FBO’s state is changed, it will always be complete, so there’s no need to check it.