For the purpose of progressivly updating an image over several frames, I use a seperate FBO to hold the in-between-frames image.
The FBO is blitted into the window every frame, where other stuff is composed on top of it. In order for the composition to work, I need to copy the depthbuffer into the window as well.
Previously I did all that stuff with a separate PBuffer, doing various glReadPixel/glDrawPixel calls, copying the data across the system memory.
The FBO is created in a way that afterwards, various glGet()calls (GL_RED_BITS, GL_GREEN_BITS… GL_DEPTH_BITS and GL_SAMPLES) return the same values as for the normal rendering window. I assume that I create the FBO with the same format as the window this way.
The problem is, as soon as GL_DEPTH_BUFFER bit is part of the mask parameter for glBlitFramebufferEXT, the copy don’t work anymore. It just returns GL_INVALID_OPERATION.
The copy performs no scaling (source and destination rectangles are even identical), and is using GL_NEAREST as filter.
So, what’s the problem? The only reason left is, that the FBO and the window have not the same depthbuffer format. But how`s that possible? I cannot query the window format other than with those glGet() calls above.
So, several issues are left:
How to create a FBO wich has the same format as the window. EXT_framebuffer_blit is not specific about what “the same format” exactly means.
Is the window “FBO” (name 0) in any way special?
EXT_framebuffer_blit does not mention it explicitly and therefore I assume, glBlitFramebufferEXT handles it the same way as all other FBOs
Is it maybe just a driver bug that I can’t copy the depthbuffer over?
EXT_framebuffer_multisample says, that if I blit from or to a multisampled bffer, the “source and destination dimensions must be identical”. I’d assume that this refers to the width/height of the blitted region (so no scaling happens). But the current NVidia drivers don’t blit correctly, if the position of the rectangles is not identical. Is it a bug or correct behaviour?
Could it be something like coverage-antialiasing modes forced by the driver to my main window? If yes, I cannot “recreate” that pixelformat, because glGetRenderbufferParameterivEXT cannot be called (?) on the window (FBO 0) and there’s no accordng “simple” GL query like glGet(GL_COVERAGE_SAMPLES_NV). Sigh
Well, when blitting from multisample to multisample you also have to make sure the number of samples match. So I guess when your driver is set to 4xAA you should also create your GL framebufferblit source to be a 4xAA framebuffer.
Indeed, it does not seem to work with the other formats, only samples=3 and samples=4 seem to work when AA is forced in the driver. But why would you want to force AA? You already perform AA at application level, so you could just request a single sample window buffer and blit your multisample fbo there. Otherwise you’re blitting all samples from your fbo multisample to the window multisample buffer which in turn needs to resolve that multisample buffer to display a single sample result on screen.