We encountered a serious performance problem with FBOs on NVidia hardware (tested on 8800GT, 8800GTX and 9800GT, WinXP 32 SP3). The issue seems to have suddenly appeared around driver revision 180.48, and maybe earlier (late 17x). The problem is not apparent in the earlier 17x driver revisions.
The problem appears when using more resources than physically available VRAM, so that the driver starts swapping. It appears on several relatively simple scenes, but with heavy use of multiple large AA’ed FBO render buffers as well as many large textures.
From the aforementioned driver revision on, it seems that the driver will not swap out render buffers anymore, even if they were not bound for several hundred frames or even deleted. This used to work fine on earlier drivers.
Suppose we look into direction A. Only few resources are in use, and framerate is good. We turn by 180 degrees, and look into direction B. Several large textures are used in this view, as well as multiple AA render buffers are created on the fly. The framerate will drop considerably on cards without sufficient VRAM to fit all these resources. That is to be expected.
Now suppose we turn back to direction A. The render buffers are not used anymore in this view, and are never bound. In fact, after around ten seconds of non-use, they are destroyed by the application. It is expected that the framerate will jump up to the previous rate again, since all rendered resources will easily fit into VRAM (by a very large margin, even accounting for fragmentation). This is not the case with newer drivers. The framerate will stay very low. In earlier drivers, the FPS would in fact go up again.
The only workaround I found on the new drivers was to destroy all render buffers and FBOs, and recreate them. The framerate would then be acceptable again. However, this is a very unsatisfactory ‘solution’, for obvious reasons.
Did the allocation strategy changed somewhere during late 17x drivers ? Does anyone know of a better workaround ?