Two FBOs bound at the same time

OpenGL OpenGL: Basic Coding
1

Hi,

I need to explain some unexpected behavior which I have been experiencing. I do the usual stuff:

  1. draw some objects into a multisampled FBO texture attachment
  2. draw a mirror reflection of the scene into another single sampled FBO texture attachment
  3. draw some more objects like in the first step
  4. resolve the multisampled attachment into a single sampled texture

Strange thing happens in the 4th phase. The glBlitFramebuffer overwrites both the texture used for mirror rendering (unexpected behavior) and the texture for antialiasing resolve (expected behavior). I thought that it is impossible to have more than one FBO bound at the same time. I can fix this at the end of the second step, where I bind again the FBO used in the first phase. It is done by a simple call:

glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, frameBufferObjectWithMultiSampledAttachments);

So to fix it I have to first unbind the mirror FBO by specifying the 0 object and then binding another object. I thought that any bound FBOs are unbound automatically by binding another FBO. Is this a common behavior or is just some quirk in my code? I use nVidia GT 220 Mobile with 260.99 drivers.

Thank you for your opinions

2

No, you should not need to call glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0) before binding another FBO.

Test it on another machine.

3

I could be wrong here but weren’t multisample texture attachments part of the GL 3.x spec and so only supported on ARB framebuffer objects?

4

No, there was a EXT extension for multisample
http://www.opengl.org/wiki/OpenGL_extensions#Framebuffer_related_extensions

Well, it is for a multisample render target.

5

Exactly.

From the specification of EXT_framebuffer_multisample

The new operation RenderbufferStorageMultisampleEXT() allocates
storage for a renderbuffer object that can be used as a multisample
buffer.

Therefore attatching multisample textures to EXT framebuffer is unsupported. If you switch to using ARB Framebuffer you may end up with correct behaviour.

In fact thinking abiout it more, just how are you attaching the multisample Framebuffer textures to you EXT Framebuffer?

glTexImage2DMultisample () was introduced by ARB_texture_multisample and is written against the OpenGL 3.1 specification (ARB_Framebuffer_Objects).

6

In fact thinking abiout it more, just how are you attaching the multisample Framebuffer textures to you EXT Framebuffer?

Probably because implementations map the same functions to the same internal code. They probably can’t tell the difference between an FBO created with the EXT version and one created with the ARB one.

7

I also have to mention the fact, that I observe this behavior in gDebugger. I did not verify it with any OpenGL debugging technique of my own so far. I hope this tool can be trusted (as it never gave me false information before).

So far, I have been using the aforementioned single sampled and multisampled FBOs and one FBO used for shadow rendering without any issues. I am definitely not giving up on this bug, so I will post a solution when I come up with something.

8

It turns out that the culprit here was really the gDebugger. Do not trust its texture viewer when it comes to FBO switching (and you happen to have a similar gpu/driver combo as me). After creating a debugging view of my FBOs right in my app, it showed that my app was working right. The fact that I had another unrelated bug (which caused that nothing could be seen in the color attachment) in my code added to the confusion.