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