Forums - GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS error with Nexus 4 in landscape orientation

11 posts / 0 new
Last post
GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS error with Nexus 4 in landscape orientation
Evan
Join Date: 5 Mar 13
Posts: 34
Posted: Fri, 2013-03-08 14:25

 

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

 

This same code works fine on various PowerVR and Nvidia devices so I have to assume this is either an Adreno bug or some subtle detail of the implementation that I'm overlooking. Has anyone seen similar behavior to this?

 

 

 

  • Up0
  • Down0
Evan
Join Date: 5 Mar 13
Posts: 34
Posted: Fri, 2013-03-08 16:18

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, 

  • Up0
  • Down0
mhfeldma Moderator
Join Date: 29 Nov 12
Posts: 310
Posted: Fri, 2013-03-08 16:45

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

  • Up0
  • Down0
Evan
Join Date: 5 Mar 13
Posts: 34
Posted: Fri, 2013-03-08 18:02

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. 

  • Up0
  • Down0
Evan
Join Date: 5 Mar 13
Posts: 34
Posted: Fri, 2013-03-08 18:02

 

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. 

  • Up0
  • Down0
mhfeldma Moderator
Join Date: 29 Nov 12
Posts: 310
Posted: Mon, 2013-03-11 09:04

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..

 

 

 

  • Up0
  • Down0
Evan
Join Date: 5 Mar 13
Posts: 34
Posted: Mon, 2013-03-11 11:05

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.

  • Up0
  • Down0
Evan
Join Date: 5 Mar 13
Posts: 34
Posted: Mon, 2013-03-11 11:06

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.

  • Up0
  • Down0
mhfeldma Moderator
Join Date: 29 Nov 12
Posts: 310
Posted: Tue, 2013-03-12 07:50

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).

  • Up0
  • Down0
Evan
Join Date: 5 Mar 13
Posts: 34
Posted: Tue, 2013-03-12 09:46

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

 

  • Up0
  • Down0
mhfeldma Moderator
Join Date: 29 Nov 12
Posts: 310
Posted: Tue, 2013-03-12 12:03

thanks for this sample.  Is the corresponding apk file available as well?

  • Up0
  • Down0
or Register

Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Qualcomm Incorporated or its subsidiaries (“Qualcomm”). The content is provided for informational purposes only and is not meant to be an endorsement or representation by Qualcomm or any other party. This site may also provide links or references to non-Qualcomm sites and resources. Qualcomm makes no representations, warranties, or other commitments whatsoever about any non-Qualcomm sites or third-party resources that may be referenced, accessible from, or linked to this site.