Forums - FBO attachment size

6 posts / 0 new
Last post
FBO attachment size
carrado.grant@g...
Join Date: 20 Sep 12
Posts: 38
Posted: Mon, 2014-06-30 10:38

I've run into another issue while running my app on a Adreno 205 GPU ( desktop GL, a PowerVR SGX 531 and a Mali-MP 400 again produces the correct result ).
OS: Android 2.3.
Device: HTC Inspire 4G

The application uses several FBO, with attachemt of dimensions 256 x 256 and 64 x 64. Rendering is done using the FBOs with the 256 x 256 attachment first. However, as soon as the FBO with a 64 x 64 is bound and rendered to, the FBO with the 256 x 256 attachment seems to get corrupted. The FBOs with the different size attachment do not share anything in common ( render buffer, texture etc ). If I make the FBO sizes all 256 x 256, the application works fine. Are all FBOs required to be the same dimension by the Adreno 205 driver ?

  • Up0
  • Down0
mhfeldma Moderator
Join Date: 29 Nov 12
Posts: 310
Posted: Mon, 2014-06-30 11:42

Generally all attachments in an FBO need to have the same size.  if you call glCheckFrameBufferStatus, you'll probably get an GL_FRAMEBUFFER_INCOMPLETE_DIMENSIONS  returned if they don't.

Are the FBO's sharing any attachments? - is glCheckBufferStatus returning GL_FRAMEBUFFER_COMPLETE?

 

 

  • Up0
  • Down0
carrado.grant@g...
Join Date: 20 Sep 12
Posts: 38
Posted: Mon, 2014-06-30 18:32

All the attachment are of the same size. Just to clarifiy with a simple example.
The app uses 4 FBO.
2 of the FBO have attachments with dimensions 256 x 256  and the other 2 have attachment of dimension 64 x 64. After each FBO bind call in the debug build, there is a validation check ( call glCheckFrameBufferStatus and return true if the result is GL_FRAMEBUFFER_COMPLETE ). The debug build assert on this being true along with printing out an error if the framebuffer is not complete. There is no assertion being thrown, printout indicating that the framebuffer is not complete. The debug build also do a check for GL error each frame and there is no error being thrown.

The lower dimension FBO ( 64 x 64 ) are sharing a depth attachment.
One point to note is that the FBO being affected is one of the larger dimension one.

I ran the app through the Adreno Profiler and I did see some disturbing output. There is a blocking resolve when the 64x64 FBO is unbound, but the sizes are all the same 256 x 256, the resolve shows up as non-blocking. This is without any changed in the codepath, only the dimension is change.

  • Up0
  • Down0
carrado.grant@g...
Join Date: 20 Sep 12
Posts: 38
Posted: Mon, 2014-06-30 18:32

All the attachment are of the same size. Just to clarifiy with a simple example.
The app uses 4 FBO.
2 of the FBO have attachments with dimensions 256 x 256  and the other 2 have attachment of dimension 64 x 64. After each FBO bind call in the debug build, there is a validation check ( call glCheckFrameBufferStatus and return true if the result is GL_FRAMEBUFFER_COMPLETE ). The debug build assert on this being true along with printing out an error if the framebuffer is not complete. There is no assertion being thrown, printout indicating that the framebuffer is not complete. The debug build also do a check for GL error each frame and there is no error being thrown.

The lower dimension FBO ( 64 x 64 ) are sharing a depth attachment.
One point to note is that the FBO being affected is one of the larger dimension one.

I ran the app through the Adreno Profiler and I did see some disturbing output. There is a blocking resolve when the 64x64 FBO is unbound, but the sizes are all the same 256 x 256, the resolve shows up as non-blocking. This is without any changed in the codepath, only the dimension is change.

  • Up0
  • Down0
mhfeldma Moderator
Join Date: 29 Nov 12
Posts: 310
Posted: Tue, 2014-07-01 07:06

thanks for the details and verification on glCheckFrameBufferStatus.

1) Adreno 205 is a bit old and the HTC Inspire 4G was released in 2011  This could have been a fixed driver bug.  Have you tried running on other more recent Adreno hardware, and/or updated to the latest OS the device supports?

2) Was the display output in the Adreno Profiler correct?  The blocking resolve messages are common and refer to a delay in rendering, not necessarily an error.

3) If you can share an apk, we can try it out a few devices.

4) You might want to review our developer documentation on how we recommend to use FBOs per frame to minimize resolves.

  • Up0
  • Down0
carrado.grant@g...
Join Date: 20 Sep 12
Posts: 38
Posted: Tue, 2014-07-01 08:24

1) I've kinda figure the Adreno 205 is pretty old, but my minimum specification is based on GLES 2.0 and not per device. I haven't tried a later Adreno based device yet, but thats in the works.

2) The display output from the Adreno Profiler, just reflect what was being seen on the device ( ie. they were both incorrect ). Yeah, I wasn't considering the blocking resolve an error, it was just strange that it was been done for the 64 x 64 FBO and not the 256 x 256.

3) Working on getting an apk to upload, but, again, if this is been tested on newer devices, it doesn't really help to confirm that this is/was an  issue.

4. The only documentation I referenced was the Adreno 200 Tips and Tricks. One suggestion I have for the site is to provide access to the documentation outside of the SDK installation if thats not already been done. Having the reference documents handy is always a plus.

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