Jogl on Android OS on Vivante GPU cores

Having recently battled through some difficult discoveries when trying to run on these troublesome GPU cores I wanted to share my findings.
They are very common so others may easily encounter the same problems; for example the entire line of 7.0 tablets from Samsung include this SoC.

The first major issue was receiving a eglMakeCurrent error in code that doesn't touch Jogl code at all.

Exception java.lang.IllegalStateException: eglMakeCurrent failed EGL_BAD_CONTEXT 
android.view.HardwareRenderer$GlRenderer.createSurface (HardwareRenderer.java:1069) 
android.view.HardwareRenderer$GlRenderer.createEglSurface (HardwareRenderer.java:961) 
android.view.HardwareRenderer$GlRenderer.updateSurface (HardwareRenderer.java:815) 
android.view.ViewRootImpl.performTraversals (ViewRootImpl.java:1850) 
android.view.ViewRootImpl.doTraversal (ViewRootImpl.java:1236) 
android.view.ViewRootImpl$TraversalRunnable.run (ViewRootImpl.java:5160) 
android.view.Choreographer$CallbackRecord.run (Choreographer.java:791) 
android.view.Choreographer.doCallbacks (Choreographer.java:591) 
android.view.Choreographer.doFrame (Choreographer.java:561) 
android.view.Choreographer$FrameDisplayEventReceiver.run (Choreographer.java:777) 
android.os.Handler.handleCallback (Handler.java:725) 
android.os.Handler.dispatchMessage (Handler.java:92)

It turns out that the fix is to add this to your manifest.xml file at the application level:
android:hardwareAccelerated="false"

This seems un-intuitive at first, and there are many comments on the internet suggesting you want this setting to be true, however this setting only affects the drawing of 2D items and can fatally fail after a Jogl Surface is created (I also got this with an off screen surface). The Android documentation states:

“If your application does not behave properly with hardware acceleration turned on…”

Which suggest a chance of trouble. That page has a lot of other ideas about controlling the hardware acceleration at a fine grain. I haven’t investigated deeply.

The only reference to this particular error I could find was on an Adobe AIR forum, but that gave me the clue.

Once I had it running I found 3 more issues before it would work nicely.

Issue 1:
Screen.getAllScreens() returns an empty Collection, so my code that was trying to use the first arbitrary screen for a width/height pair was crashing.

Issue 2:
Shaders can’t be too complex in one method, nor can they be too long. I don’t know the detail of this, but you get a simple “can’t link” error with no error message, even though the shaders compile fine.
I solved the “too complex” issue by moving the lighting calcs out to methods as much as possible, so the lighting loop was basically calling out to some diffuse, specular, and attenuation methods.
All credit for this fix goes to Helge at JPCT, and the generally excellent advice that I had to buy a Vivante device.

The “too long” issue was solved by not unrolling loops.

Issue 3:
I can’t seem to do matrix maths in shaders in the Vivante compiler, I can’t explain this and haven’t investigated. When I had uniforms of modelViewMat and projMat and the normal

gl_position = projMat * modelViewMat * vertPos; 

I get crazy results, some tris squashed against the camera oddly, not all, just some.
So I hand in a projViewModelMat and just do

gl_position = projModelViewMat * vertPos; 

And it's fine.

Finally I’ve noticed that I’m getting glDeleteBuffer errors on these devices that I don’t get elsewhere, but it doesn’t seem to affect anything so I won’t include it here.

I did my remedial work on a Samsung Galaxy Tab 3 7.0 (SM-T210)

I hope this helps someone somewhere.

Hi

I already do something similar in desktop environments, I disable hardware acceleration for Java2D, it makes sense to me.

Thank you for sharing your findings. The problem with getAllScreens() might be a real bug, we have to investigate.