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_policy
echo 0 > /sys/kernel/debug/kgsl/kgsl-3d0/ft_policyecho 0 > /sys/kernel/debug/kgsl/kgsl-3d0/ib_checkecho 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.
I should probably make a note here that even though my two devices are running unofficial images, the stock 4.3 images for the Nexus 4 and the 2013 Nexus 7 also hit this issue.
I've got a couple profiles saved from a frame from the Adrneo Profile if they may help you in some way.
https://docs.google.com/file/d/0B61c0mwzuEltQmR0bkIzNzF3Wlk/edit
https://docs.google.com/file/d/0B61c0mwzuEltQnhSa3FNSGl3RGs/edit
I think this can be traced back to a issue with KGSL, but without further testing on a development platform I can't prove if it is or not.
1) Was able to install this version:
https://docs.google.com/file/d/0B2mTNE31f5JTaFJiWmVzSW9MQjQ/edit?pli=1
but not able to locate the starfield.dol file. Is there a specific place where it's installed.
2) Curious about kgsl commands you listed. Was there a source that mentioned why you should be using them?
3) Could you explain a bit more about calling eglSwapBuffers with every glDrawRangeElements call? (e.g. what your call sequence is like).
thanks
1) You've got to download the starfield.dol file separately, I've got it hosted on my server at http://sonicadvance11.dyndns.org/starfield.dol . Which then you can find it w/e you downloaded it on your device via the browse folder option, which then it'll add the file/folder to the game list and you can run it.
2) Rob Clark, of the Freedreno project, mentioned that there was long instruction buffer detection code in kgsl that was able to be disabled in some form. I took it upon myself to find where these were and disable the features. Most probably aren't necessary to disable, but I felt it was in my best interest to disable them all.
3) The "Swap Hack" I have in place in one of the apks calls a eglSwapBuffer each time we call glDrawRangeElements just for fact that it tends to help the device from crashing. In a normal rendering sequence, it would only be called as usual when we are done renderering the frame.
P.S. One should probably disable the On Screen Controls in the video settings of the application just because it'll throw OGL errors. This has been fixed in newer versions of the apk.