Forums - glBlitFramebuffer crashes Adreno 320

22 posts / 0 new
Last post
glBlitFramebuffer crashes Adreno 320
Evan
Join Date: 5 Mar 13
Posts: 34
Posted: Fri, 2013-09-20 15:37
We're seeing a crash that seems to be caused by using glBlitFramebuffer to blit a regular non-msaa 2D texture (which is attached to GL_COLOR_ATTACHMENT0 on an FBO) to the back buffer. In other words something like this:
 
glBindFramebuffer(GL_READ_FRAMEBUFFER, fbo);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);
glReadBuffer(GL_COLOR_ATTACHMENT0);
GLenum db = GL_BACK;
glDrawBuffers(1, &db);
glBlitFramebuffer(0, 0, 512, 512, 0, 0, 512, 512, GL_COLOR_BUFFER_BIT, GL_NEAREST)
 
512 here is just an example, the texture and back buffer really have dimensions larger than that. I found that restricting the width and height to 128 stops the crash but appears to blit garbage to that portion of the buffer. This is causing the phone to completely reboot (tested on Nexus 4 and Samsung Galaxy S4).
 
Here is a link to an APK of our application, just load any of the sample documents and you should hit the crash immediately.
 
 
I'm hoping to create a simpler test case using one of the NDK sample projects, I'll post that as well when I do.
 
  • Up0
  • Down0
Evan
Join Date: 5 Mar 13
Posts: 34
Posted: Wed, 2013-10-02 13:10

Any update on this issue? I can confirm that the Nexus 10 (Mali T604) doesn't show this problem but on Adreno devices it crashes and reboots the phone. 

  • Up0
  • Down0
RelativeGames
Profile picture
Join Date: 16 Apr 13
Posts: 56
Posted: Fri, 2013-10-04 01:23

I can confirm that glBlitFramebuffer works on Adreno 320, however in my code I don't have this part :

glReadBuffer(GL_COLOR_ATTACHMENT0);
GLenum db = GL_BACK;
glDrawBuffers(1, &db);
 
but I also don't use multiple render targets (in which case you would need that code)
  • Up0
  • Down0
mhfeldma Moderator
Join Date: 29 Nov 12
Posts: 310
Posted: Fri, 2013-10-04 11:15

Evan - Thanks for providing the apk.  It helped diagnose the problem.

1) Was able to successfully run the apk and view the bike model on a current dev kit (Adreno 330 based)

2) I was also able to duplicate the crash on a Samsung Galaxy S4.

 

In the Android log, there's the following line:

E/AndroidRuntime( 4961): java.lang.UnsatisfiedLinkError: Cannot load library: soinfo_link_image(linker.cpp:1636): could not load library "libGLESv3.so" needed by "libandroid_simple.so"; caused by load_library(linker.cpp:746): library "libGLESv3.so" not found
 

This indicates that you are attempting to use a GL3 library where one does not exist.

-mark

 

  • Up0
  • Down0
Evan
Join Date: 5 Mar 13
Posts: 34
Posted: Fri, 2013-10-04 11:50

Hi Mark, 

Thanks for looking into this. I don't see the libGLESv3.so error in the log on my Nexus 4, but presumably ES 3.0 is working because we're able to call glReadBuffer, glDrawBuffers and even glBlitFramebuffer between two FBOs, it's just the case where the destination is the back buffer that this problem is occuring. Are you saying the crash could be related to this missing libGLESv3 issue? Or is it just a separate problem you noticed?

Thanks,

Evan

 

  • Up0
  • Down0
mhfeldma Moderator
Join Date: 29 Nov 12
Posts: 310
Posted: Fri, 2013-10-04 13:09

Evan -

I'm able to duplicate with the same logcat message on a Nexus 4 as well.

It has Android 4.2.2, and build dated Jan, 29 2013 - JDQ39

Let me know what build information you have..

 

thanks,

mark

 

 

 

  • Up0
  • Down0
Evan
Join Date: 5 Mar 13
Posts: 34
Posted: Fri, 2013-10-04 13:27

The devices we are testing are all on 4.3, which I thought was a requirement to use ES 3.0. I guess you're seeing it fail to load then due to a missing system library not because of the BlitFramebuffer crash in question?

  • Up0
  • Down0
Evan
Join Date: 5 Mar 13
Posts: 34
Posted: Fri, 2013-10-04 13:30

The exact builds are:

Nexus 4: JWR66Y

Galaxy S4: JWR66Y.S003.130805

 

  • Up0
  • Down0
mhfeldma Moderator
Join Date: 29 Nov 12
Posts: 310
Posted: Fri, 2013-10-04 15:37

Hi Evan...

Some progress... I updated our Nexus 4 to a current build (JWR66Y - Jun 17, 2013) and I get a crash in our driver running the app you provided. 

.I'm guessing it's a bug that's been addressed on our newer drivers sine it works on our Snapdragon 800 hardware, but worth seeing what our driver team thinks.

-mark

  • Up0
  • Down0
Evan
Join Date: 5 Mar 13
Posts: 34
Posted: Fri, 2013-10-04 16:28

Hi Mark,

Thanks for all your effort on this. If it is indeed just a bug, we can work around it by drawing to the back buffer via a textured quad for now. If you guys find something unexpected that we're doing that's causing this (like something weird in our EGL surface config) it would be helpful to know what it is so we can avoid it. 

If this is fixed in your current drivers do you know how long it would take for an update to get to out to customers? I understand there's a 4.3.1 update coming soon, would it be included there or in a later release?

Thanks,

Evan

  • Up0
  • Down0
RelativeGames
Profile picture
Join Date: 16 Apr 13
Posts: 56
Posted: Fri, 2013-10-04 23:49

@Evan

I think you misunderstand how GLES 3 works in Android.

You have 2 options :

1) Link to GLES3 library (like you're doing now). This will fail on all Android versions prior to 4.3 (duh, the library is just not there). This also means you're targetting API level 18 as a Minimum Version

2) Link only with GLES2 and not with GLES3 and get your function pointers via eglGetProcAddress. This also comes with a twist. It fixes Android 4.2.2 and lower devices that have drivers with GLES3 support. BUT on Android 4.3+ it also gets you the GLES3 function pointers even if there is no driver support. I'm working around this by doing something simple like trying to generate a new ID from a new GLES3 functionality like glGenSamplers. If it does generate a new ID, then the function actually works, if not, then it has no GLES3 support.

Shittty OS Support, on iOS 7 it's much clearer though.

  • Up0
  • Down0
mhfeldma Moderator
Join Date: 29 Nov 12
Posts: 310
Posted: Mon, 2013-10-07 07:28

I'll need to wait for an answer from our driver team to figure out what exactly the fix is and whether its in a 4.3.1 update.

  • Up0
  • Down0
Evan
Join Date: 5 Mar 13
Posts: 34
Posted: Mon, 2013-10-07 10:51

Sounds good, thanks.

@RelativeGames Yes we are actually querying functions at runtime with eglGetProcAddress so we don't have to require API level 18. The build I posted here was just an exerimental one that was linking directly to GLES3. To determine which type of hardware we're running on we're just checking the GL_VERSION string, have you tried this? It seems more straight-forward than trying to generate objects from ES 3.0 APIs.

  • Up0
  • Down0
RelativeGames
Profile picture
Join Date: 16 Apr 13
Posts: 56
Posted: Mon, 2013-10-07 11:36

@Evan

Yes, I'm trying the version string too, however you'll find out that the version string is sometimes reported as "OpenGL ES X.X" or simply "X.X" and who's to say a third format doesn't exist ? Each vendor will probably implement the version format however he wants. I don't think the OpenGL specs have conventions on versioning.

Another thing about my object testing is that on Android 4.2 (there's a lot of devices with Adreno 320 that are still on 4.2) with an OpenGL ES 3 driver, the version string will still return 2.0. Actually I'm certain of this (just checked gfxbench.com ), if you look on the version reported by Adreno 320 for Nexus 4 you'll see 2.0 and 3.0 while the driver supported 3.0 from the initial release of the Nexus 4.

  • Up0
  • Down0
Evan
Join Date: 5 Mar 13
Posts: 34
Posted: Thu, 2013-11-14 22:50

Just updated to 4.4 and the crash seems to be gone. 

  • Up0
  • Down0
cageman
Join Date: 30 Sep 13
Posts: 3
Posted: Thu, 2013-12-26 15:53

Hi Evan,

Were you able to work BlitFrameBuffer correctly?  It seems to me that the texture image in color attachment got transposed while it got blit to the default framebuffer and displayed.  Is there anyone experiencing rotation or transposition issues while blitting framebuffer?  I was running it on Nexus 7 (2013) with Android 4.4.2.  Thanks!

-E

  • Up0
  • Down0
Evan
Join Date: 5 Mar 13
Posts: 34
Posted: Fri, 2013-12-27 12:22

Yes it seems to be working fine as of 4.4 (in all our use cases at least). I've tested with a Nexus 4 and 5. I suppose you've checked that your src/dst/ xy parameters are correct right?

 

 

  • Up0
  • Down0
cageman
Join Date: 30 Sep 13
Posts: 3
Posted: Mon, 2013-12-30 16:04

It turns out that glBlitframebuffer works well when the screen is in the Portrait mode.  However, when it's in the Landscape mode, blitting rotates the texture image 90 degrees.  Is there any setting do I need to update to make it work correctly in the Landscape mode?  Thanks!

 

  • Up0
  • Down0
Evan
Join Date: 5 Mar 13
Posts: 34
Posted: Mon, 2013-12-30 17:59

I think you're right. I just checked our app and it does look like blitting to the back buffer is not working properly in landscape mode. It doesn't look rotated though, more like squashed. I'll have to do some more digging to be sure this isn't a problem in our code somewhere though.

  • Up0
  • Down0
Evan
Join Date: 5 Mar 13
Posts: 34
Posted: Thu, 2014-01-02 11:45

You can see this problem using the same build I posted at the start of this thread. Just start the app landscape mode and you'll see the image is stretched and sideways. Does anyone from Qualcomm have any insight on this? Is this another bug?

  • Up0
  • Down0
Sonicadvance1
Join Date: 2 Nov 12
Posts: 51
Posted: Thu, 2014-01-02 17:41

Dolphin developer here. I've long since struggled with the rotation while in landscape mode issue.

I've dealt with this from v14 to v53 drivers and there still isn't a fix that I could find on my end. This bug is a major pain in the butt.

  • Up0
  • Down0
Evan
Join Date: 5 Mar 13
Posts: 34
Posted: Thu, 2014-01-02 19:52

I did a quick google search to figure out what Dolphin was :D and I found this article which pretty much agrees with the experience we've had trying to support OpenGL ES on Android.

http://www.tested.com/tech/gaming/458345-dolphin-emulator-developers-dire-state-mobile-opengl-drivers/

The reason I didn't see this problem a few days ago was because we had another work-around in place for BlitFramebuffer on Mali which unfortuatenly seems to be broken in a different way. From what I've seen lately only Apple seems to have stable ES3 drivers at this point. 

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