I’m trying to copy the depthbuffer contents of the current framebufer (either window or FBO, either non-multisampled or not) into a non-multimsampled depthtexture (NPOT size).
I figured that using glBlitFramebufferEXT should be the best method since it supports all necessary scenarios.
Unfortunatly, on a certain machine t doesn’t work very well. Its a DellM70 Laptop with a built-in QuadroFX1400go graphics card. The very latest driver that can be installed on that machine is Forceware 178.24. The OS is WinXPpro 32bit.
The standard-scenario tries to copy the depthbuffer contents of the window into the depthtexture.
glBlitFramebufferEXT() is taking 7seconds(!!) to perform the blit (1280x800pixels), which is MUCH too slow.
glCopyTexSubImage2D() performs the same operation in around 1ms.
Using glCopyTexSubImage2D() when the texture format of the destination texture is GL_DEPTH24_STENCIL8_EXT instead of GL_DEPTH_COMPONENT24, the driver crashes.
Unfortunately, I cannot use glCopyTexSubImage2D() in all scenarios, especially in case the source FBO is multisampled. To my surprise glCopyTexSubImage2D() works on the window FBO(0) even though it is multisampled…
Performing a depth-blit from an offscreen-FBO into a texture works as expected.
The question is, is the observed behaviour a hardware limitation or a driver bug? If its a driver bug, is there some newer driver to be expected hat fixes it?
This is not because of GPU maker, but because of the laptop vendor. Even if this is silly, they want to avoid any driver change, because they perceive this will costs less in support…
Well, this is not really true. Up to 178.24 I always just downloaded the drivers from NVidia, Dell is stuck with 84.05 (year 2006!). I guess, NVidia just wants to phase out such “old” hardware. Its really sad that when the driver finally gets mature, you can’t install it on the right hardware. On the other hand, new hardware never has mature drives, which means at no point in time one has fully mature drivers on his hardware