I want to be as descriptive about this problem that I possibly can be. Ever since the Samsung Galaxy S4 came out to be the first OpenGL ES 3 device on the USA market, I've had /major/ issues under it that I haven't been able to rectify on the software side of things. The OpenGL ES 3 video backend in my application works great with both Mali-T604 and Intel HD graphics. The results aren't so satisfying with Adreno 320. In order for me to not crash the phone I have had to do a few things.
The first thing I had to do was that instead of using glBufferSubData, use glBufferData. Using glBufferSubData caused the device to /very/ quickly run out of RAM, while glBufferData worked. The Mali-T604 hit this issue as well, so this isn't a major change, I just figure glBufferSubData should be faster.
The second thing I have to do is run a few commands on the target Qualcomm device. These commands are required or else after a few seconds either the application force closes, or the entire phone itself hard resets. I've been able to get a few logs that say it is creating a long instruction buffer, but besides that I haven't got much information. These commands obviously aren't needed on Mali since they pertain to kgsl. The commands are as follows.
echo 0 > /sys/kernel/debug/kgsl/kgsl-3d0/fast_hang_detect
echo 0 > /sys/kernel/debug/kgsl/kgsl-3d0/ft_pagefault_policyecho 0 > /sys/kernel/debug/kgsl/kgsl-3d0/ft_policyecho 0 > /sys/kernel/debug/kgsl/kgsl-3d0/ib_check
echo 0 > /sys/kernel/debug/kgsl/kgsl-3d0/long_ib_detect
These commands are pretty terrible and I feel bad for using them, but they are a hard requirement at this point to prevent the device from going down hard.
I have found another thing to do that helps decrease the chance of it crashing, this is another terrible workaround but it "works." Every time I draw something with glDrawRangeElements, I insert a eglSwapBuffers. This has the downfall of absolutely murdering performance and introducing flickering, but again, it helps lessen the chance of crashing.
To see the problems while it is running, I have a youtube video here.
The correct video output can be seen in this photo here.
I've been trying to fix this issue before I update my application on the Android market place, so any help in this would be greatly appreciated. I tried profiling with the Adreno profiler but with how unstable it is, the enabling of debugging seems to just cause bigger issues. The two devices I've been testing on is a HTC Droid DNA and a Samsung Galaxy S4, both of these devices have a unofficial Android 4.3 ROM on them running the drivers that Google has sent out with the devices.
As for testing this yourself on your own dev devices, I have a couple of downloads that can be used to test.
I've got an updated version of the APK that isn't yet available on the market place.
This one has the eglSwapBuffers hack to try to lower the crashing rate.
This one is the same as the previous one except calling eglSwapBuffers when we are done rendering each frame.
This is a completely free and legal homebrew that I have been using to test this issue.
To test this, one must install the APK, go in to the settings from the navigation drawer then video settings, and change the video backend to OpenGL ES 3. Sometimes this setting resets so it would be good to check it. The application will output a string to logcat as it is drawing the frame that either says "OGL" or "Software Renderer" to easily determine if it is enabled or not.
Then from the navigation drawer select browse folder and navigate to where the starfield.dol file is on the device and select it. That will bring it up on the gamelist and you can then click it to run it.
If you need any more information I will freely provide it to you.