blitting from FBO to multisample-window

[skynet]

Hello,

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:


1. 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.
2. 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
3. Is it maybe just a driver bug that I can't copy the depthbuffer over?
4. 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?

thanks for your help!

[-NiCo-]

Hmm, that's interesting, haven't worked with blitting in combination with depth buffer myself so I'm just guessing what the problem might be here...

Window provided depth buffers usually pack the 24bit depth values and 8bit stencil values in 32 bit words so maybe you can try using a packed depth/stencil (http://www.opengl.org/registry/specs/EXT/packed_depth_stencil.txt) format for the FBO

[skynet]

I', doing that, in case glGet(GL_STENCIL_BITS) returns !=0 and glGet(GL_DEPTH_BITS) returns 24 :-)

But for my window, GL_STENCIL_BITS is 0.

[-NiCo-]

Just tried it out. Everything seems to work just fine with GL_DEPTH_COMPONENT24.

OS: Ubuntu Gutsy Gibbon 7.10
GPU: Nvidia Quadro FX 1600M (driver version 169.12)

[skynet]

Uhh, this is getting weird...
Just by accident I happened to switch my driver settings back to 4xAA... and suddenly it works like charme!

2xAA...4xAA: works!
anything >4xAA: GL_INVALID_OPERATION

GF8800GTS, driver version 169.21, WinXP64

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*

[-NiCo-]

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.

[skynet]

I know. I'm doing this already - it wouldn't work with 2x and 4xAA otherwise. I just don't get why it won't work with higher AA settings :-/

[-NiCo-]

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.

[skynet]

I have to "mimic" the window pixelformat, because my code is not the one that creates the window in first place. So I test it by trying different AA levels enforced in the driver settings.

[-NiCo-]

Ah, I see, The only workaround that I see for now is blitting to a single sample fbo before blitting to the multisample window buffer...