6

I find that when I enable this developer option, my OpenGL project stops working. A bit alarming to say the least.

Logcat shows a zillion of these:

 E/libEGL  ( 1022): called unimplemented OpenGL ES API
 E/libEGL  ( 1022): called unimplemented OpenGL ES API
 E/libEGL  ( 1022): called unimplemented OpenGL ES API
 ...

The first scene renders perfectly well, but after that first swapbuffers(), all susbequent GL ES APIs (even glSetMatrixMode()) do nothing but log "unimplemented API".

This all works perfectly well (i.e. is implemented) if I have the "Force GPU rendering" option turned off.

So, what does this option actually do?

Reuben Scratton
  • 38,595
  • 9
  • 77
  • 86

4 Answers4

3

That option is intended for developers, so that they could easily test their apps with H/W Acceleration turned on. As I understand it, a 2D app that uses Canvas Apis can benefit from this option since turning this on will indeed force the system to create a native GLES2.0 Context on a different thread and have the Canvas Class use the GLES h/w accelerated backend instead of the Skia one. This native GLES2.0 context creation happens in C Native code and the app developer has no control over this.

Going back to your issue, the "called unimplemented error message" is basically saying that either (1) you're indeed using the wrong GL Context (for example, making GLES1.1 calls with a GLES2.0 context or viceversa) or (2) your device wasn't able to load the GLES drivers and thus the system failing to find the actual GL function pointer. The system knows what to load by reading the egl.cfg file found under /system/lib/egl/ and the GL driver itself is found under /system/vendor/lib/.

I would follow up with Google as this may just be a bug.

csanta
  • 512
  • 4
  • 5
  • That's close enough for me, and fits with observations and what I've learnt elsewhere. I got a tweet from Android graphics person Romain Guy... he said OpenGL apps will only have this problem if they create their EGL context on the main UI thread. It's more common for all GL calls to run on a dedicated thread, a practice I dont like for reasons too boring to go into. – Reuben Scratton Dec 29 '11 at 14:24
  • 1
    @ReubenScratton I'm having the exact same problem here, and I'm also creating the EGL context on the main thread. Did you ever find a solution to this or did you end up using a separate thread for GL? – James M Apr 12 '13 at 11:42
  • 1
    I ended up creating a dedicated rendering thread and moving all the GL code into it. This was overkill for my needs, and presumably yours, but this particular OS feature assumes that all GL apps render off the main thread and we have to go along with that. – Reuben Scratton Apr 12 '13 at 12:22
2

It forces hardware acceleration in all applications. You can read more about it here: http://developer.android.com/guide/topics/graphics/hardware-accel.html

Make sure to check out the Unsupported operations, which is likely where you are running into issues.

smith324
  • 13,020
  • 9
  • 37
  • 58
  • Thanks for the link, but my UI is *entirely* OpenGL ES... it's already accelerated. I don't use any Canvas APIs, and don't understand why this setting would affect a GL-based app. It looks like this setting causes an alternative GL driver to be loaded. – Reuben Scratton Dec 21 '11 at 10:52
  • Interesting, I wouldn't be surprised if it was loading another driver to do the hardware acceleration for the canvas apis. (Which I'm almost 100% certain is what you are forcing) To test my theory you could enable hw acc in your applications manifest with a sdk target of at least 3.0. Instructions for that are in the link in the org answer. – smith324 Dec 22 '11 at 00:09
0

Acceleration mode in ICS is not more special then in Honeycomd. By default acceleration mode is enabled for all applications targeted to api 14 or higher. But at the same time, there are applications that are targeted to other versions of SDK. So, you can enable hardware acceleration in these applications by setting "Force GPU Rendering". There is a great explanation and a post from Dianne that explains this.

Yury
  • 20,618
  • 7
  • 58
  • 86
  • That is indeed a good post from hackbod, but unfortunately doesn't help me much. I am increasingly of the opinion that this is a bug in ICS. Latest observation is that after the first frame draws (successfully), my EGLImpl.mEGLContext changes. Pretty sure that shouldnt happen. – Reuben Scratton Dec 26 '11 at 17:02
  • Try to ask this specific question in android-platform google groups. https://groups.google.com/forum/#!forum/android-platform Also I found a good explanation of this error here: http://stackoverflow.com/questions/5926316/android-gles20-called-unimplemented-opengl-es-api – Yury Dec 26 '11 at 17:10
  • I might do that, am still investigating. It looks like the OS is forcing the app to swap to a 2.0 renderer, which is why glMatrixMode etc APIs all suddenly unsupported. This is despite manifest declarations that only 1.1 is used. Bit of an epic ICS fail if this observation is correct... – Reuben Scratton Dec 26 '11 at 19:20
  • I'm having a similar issue, I have an entirely opengl activity, that does not work on ICS if I set the targetSdkVersion=15 if I set it targetSdkVersion<13 it works – Julian Suarez Jun 01 '12 at 21:35
0

As has been said here, that option forces Graphics Hardware Acceleration and it is supposedly a default on API Level 14 or 15, I mean ICS.

I do not recommend testing this on an Emulator because it will make your computer and Eclipse sluggish and/or to crash. I've tried this setting on Emulators with a wide range of resource configurations (different sizes for display, caches, CPU and RAM) with API Level 14 and 15 and it always crashes.

It would be better to test your App on a Dual Core device such a recent Samsung Galaxy 10.1, 8.9 Tablet or Motorola Xoom Tablet what have actual hardware like the nVidia Tegra GPU to support the acceleration since Honeycomb, making it better for OpenGL ES Apps... And since there are no Tablets with ICS on the market yet you won't be able to match the mentioned configuration of API Level 14 and ICS.

I would finish by agreeing with that there's a bug Google has not addressed/solved on the SDK yet.

Oscar Salguero
  • 10,275
  • 5
  • 49
  • 48