I just had a post about this but it seems to have vanished, so here's it is again:
We're getting sporadic GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS errors from glCheckFramebufferStatus when the device is in landscape orientation and we bind anything to the GL_DEPTH_ATTACHMENT attachment point in our renderer. When the framebuffer is first created we get FRAMEBUFFER_COMPLETE, but after a few frames the INCOMPLETE_DIMENSIONS error starts showing up.
I've checked the fbo and all the attachments when the error occurs with glGetFramebufferAttachmentParameteriv and glGetRenderbufferParameteriv and everything looks correct. All the attachments are there and have the correct (matching) dimensions. If I never bind a depth attachment then no error ever happens.
When removing the depth attachment the incomplete dimensions error goes away, but the screen is full of garbage (not just due to a missing depth buffer). There's a frozen, but correct looking image in the background, and then the left half of the screen updates with a stretched version of the image we're rendering.
Here are two screen shots showing the correct (except for lack of depth testing) image in portrait mode and the incorrect landscape image.
https://dl.dropbox.com/u/69927239/Screenshot_2013-03-08-14-20-07.png
https://dl.dropbox.com/u/69927239/Screenshot_2013-03-08-14-19-53.png
It looks like having a non-zero framebuffer bound before the eglSwapBuffers call at the end of the frame was the cause. Under certain circumstances this also seems to cause a crash on SwapBuffers,
Hi... Not sure why the previous post vanished...
I'm querying the driver team about this return code and what scenerio would generate it. In the meantime you might want to take a look at the Adreno SDK samples - you can download the SDK within this forum. I believe there are a few examples that use Framebuffers with depth attachments (e.g. Bloom, CascadedShadowMaps, DepthOfField), though none of them test for GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS. There might be some clues there...
-mark
Hi Mark,
Thanks for looking into this. I think our problem is resolved for now. Calling glBindFramebuffer(GL_FRAMEBUFFER,0) before calling eglSwapBuffers cleared up all the problems. I guess the EGL spec says that the EGL surface must be bound before SwapBuffers is called: https://mail.gnome.org/archives/commits-list/2011-December/msg02658.html so this makes some sense.
If your driver could just generate an error when SwapBuffers is called under these circumstances that would probably be helpful for other developers in the future though.
Hi Mark,
Thanks for looking into this. I think our problem is resolved for now. Calling glBindFramebuffer(GL_FRAMEBUFFER,0) before calling eglSwapBuffers cleared up all the problems. I guess the EGL spec says that the EGL surface must be bound before SwapBuffers is called: https://mail.gnome.org/archives/commits-list/2011-December/msg02658.html so this makes some sense.
If your driver could just generate an error when SwapBuffers is called under these circumstances that would probably be helpful for other developers in the future though.
Glad you got it working. It looks like our samples also call glBindFramebuffer(GL_FRAMEBUFFER,0) to break the current binding.
Not sure about setting an error (would be checked by calling glGetError)...need to follow up with driver team..
Maybe it could be an EGL error? Our code was apparently not checking the return value of eglSwapBuffers so I don't know if it was indicating a problem there, but I can confirm that no EGL errors were being reported.
Maybe it could be an EGL error? Our code was apparently not checking the return value of eglSwapBuffers so I don't know if it was indicating a problem there, but I can confirm that no EGL errors were being reported.
Our driver team reviewed the places where the error is triggered and it seems specifically related to the color and depth buffer's dimensions, or if the Multiple Render Target's dimensions don't match.
We're not convienced Mesa is doing the right thing by generating an error (there's no GL state dependency in EGL). If you're able to reproduce the problem in a simplified program, we can do some further analysis (However, I know this is difficult in many cases).
I haven't been able to reproduce the incomplete dimensions error outside of our application but I do have a test case that demonstrates a crash if a non-zero framebuffer object is bound when eglSwapBuffers is called. I ran into this trying to reproduce the dimensions error in one of the NDK samples. It was when I finally reproduced the same crash in our application that I tried unbinding the FBO at the end of the frame and that cleared up all the problems.
This is a modified version of the code from the NDK NativeActivity sample. Touch the screen so it starts rendering and once it gets into the "if (count++ > 1000)" block in engine_draw_frame it crashes on the Nexus 4.
https://dl.dropbox.com/u/69927239/main.c
thanks for this sample. Is the corresponding apk file available as well?