Framebuffer objects and software fallback

I have a partially implemented deferred rendering pipeline set up. I use framebuffer objects to perform multiple simultaneous renders. When I start using a lot of render targets (7, though only up to 4 simultaneously using glDrawBuffers) the process’s CPU usage suddenly hits the roof and performance hits the floor. I’ve read somewhere that most cards can only work with 4 attachments to a FBO. I have a 9500GT. Are the attached textures, even if they’re not enabled, causing the software fallback? Is there any way to even tell? It’d be nice if GL had a function like glError that could relay warnings such as the triggering of a software fallback. I can quite easily break it into two FBOs, but does the render buffer I use for depth count in this limit of 4? I have it working like this:


Diffuse ---------------------------------------------------------->\
Normal ---------> Normalise -------------> (used to build lights)   \
Specular ----------------------------------------------------------->\___Multiply into final image
World position -> Build specular normal -> (used to build lights)    /
-----------------------------------------> Build diffuse light----->/
-----------------------------------------> Build specular light--->/
(depth rb)

3D Pass (world) | 2D passes (screen-space quad)

You mean, like with this (admittedly new) extension :
http://www.opengl.org/registry/specs/ARB/debug_output.txt

New extensions are pretty much useless for code that needs to run on older (and it’s not always that much older) hardware though. :frowning:

ARB_debug_output should be supported on the fairly modern 9500GT, afaik.

What are the internal texture formats of the FBO attachments, what is the texfmt of the depth-renderbuffer? Any chance that your code uses a nasty texfmt, or goes over VRAM size?

On a similar note, the way GL is designed, FBO attachments will probably be copied to SysRAM, right? (in case the gpu gets reset) Any way to mark textures as streaming (unnecessary for state restoration)?

New extensions are pretty much useless for code that needs to run on older (and it’s not always that much older) hardware though

Define “older”? Any DX10 hardware should have these extensions work on it (in the fullness of time). ATI and NVIDIA both are supporting their DX10 hardware line for at least the near future.

On a similar note, the way GL is designed, FBO attachments will probably be copied to SysRAM, right?

It depends on the OS. On Windows Vista+, that is unnecessary, as the OS itself manages video memory and virtualizes it. Textures and framebuffers cannot be lost.

APPLE_object_purgeable addresses the situation where you know FBO texture content is streaming and you don’t care if they are simply purged instead of paged off to system memory.