On a Galaxy Nexus with a PowerVR SGX 540 GPU, the GPU throws this error in the log and 2 others but this is a bit more interesting since it might be an issues purely related to GL ES 2.
It’s curious that this exact error message is nowhere to be found on the entire internet 
Soon after this type of message is thrown there’s a high chance the device will entirely shut down and a restart is possible only after removing and putting back the battery.
The error arrays as I see them on device:
03-14 15:54:31.595: E/IMGSRV(2000): :0: SGXKickSubmit: failed acquire CCB space!
03-14 15:54:31.595: E/IMGSRV(2000): :0: DoKickTA: SGXKickTA() failed with error 9
03-14 15:54:31.595: E/IMGSRV(2000): :0: glBindFramebuffer: ScheduleTA did not work properly
03-14 15:44:26.599: E/IMGSRV(8747): :0: SGXKickSubmit: failed acquire CCB space!
03-14 15:44:26.599: E/IMGSRV(8747): :0: DoKickTA: SGXKickTA() failed with error 9
03-14 15:44:26.599: E/IMGSRV(8747): :0: FlushRenderSurface: ScheduleTA did not work properly on the attachment
03-14 15:54:33.446: E/IMGSRV(2000): :0: SGXKickSubmit: failed acquire CCB space!
03-14 15:54:33.446: E/IMGSRV(2000): :0: DoKickTA: SGXKickTA() failed with error 9
03-14 15:54:34.298: E/IMGSRV(2000): :0: SGXKickSubmit: failed acquire CCB space!
03-14 15:54:34.298: E/IMGSRV(2000): :0: DoKickTA: SGXKickTA() failed with error 9
03-14 15:54:34.298: E/IMGSRV(2000): :0: EmitState: Couldn’t flush HW
Some more error messages that pop when you leave it render for a while :
03-14 15:45:27.896: E/IMGSRV(129): :0: WaitForRender: Trying force-flip workaround
03-14 15:45:27.896: E/IMGSRV(129): :0: WaitForRender: Trying force-flip workaround
03-14 15:45:30.435: E/IMGSRV(129): :0: WaitForRender: Timeout
03-14 15:45:30.435: E/IMGSRV(129): :0: HW operation timeout occurred.
03-14 15:45:30.435: E/IMGSRV(129): :0: MapperLogSyncObjects: Dumping all active sync objects..
03-14 15:45:30.435: E/IMGSRV(129): :0: ID=843, 0xP...FHWR=0x00000b00, WOP/WOC=0x23/0x22, ROP/ROC=0x0/0x0, ROP2/ROC2=0x42/0x42, WOC DevVA=0x0d80884c, ROC DevVA=0x0d808854, ROC2 DevVA=0x0d80885c
Hi Cippyboy,
Sorry that we haven’t gotten back to you before about this! So we had to do some digging for this one, and unfortunately we don’t have a direct answer for you at the moment, we need a bit more information to figure it out.
This may require a lot of debugging to track down, so I would recommend that you actually email us about this at DevTech@imgtec.com. Once we have an answer we’ll post back on the forum with details for any readers that are interested.
The first things I would ask for is if you could give us a little bit of detail about your application; what it’s doing, what it’s rendering, if it’s threaded, etc. Also if you could get a trace with PVRTrace (https://www.imgtec.com/powervr/insider/pvrtrace.asp) and possibly a tune file (https://www.imgtec.com/powervr/insider/powervr-pvrtune.asp) from when the crash occurs, it would give us a better idea of what might be going wrong. If you also have a sample application that reproduces the crash that would be useful, or even just sharing the original application with us for testing internally would be great.
Regards,
Tobias
Hi,
Thanks for replying. This is my app :
https://play.google.com/store/apps/details?id=com.re3.benchmark
And after a lot of debugging it seems like it’s a performance thing. If the framerate drops under ~1-2 frames per second those messages pop in my Galaxy Nexus log. If it’s above 3 FPS it most surely does not. I am getting the impression that the driver waits at most 1 second for all the draw commands to be submitted and then bails out if it takes longer. My app is a benchmark app so it does do some intensive processing there, with around 100 texures in a scene, 100+ draw calls and so forth. To completely remove the issue I’m thinking to monitor the framerate and then post a warning to the user that his phone may shut down if he continues to run the app :).
On a side note, when I was testing this on my Galaxy Nexus, the phone made a clicking sound in the middle of it and then shut down. I was a bit scared as I thought my phone died but with a battery remove later it was ok :).
wow i just try it on my nexus 7 , it crash and reboot my phone !!!
Hi Cippy,
I’ve tried this out on a number of devices and driver revisions. So the driver does in fact have a number of timeouts to prevent it locking up - and on more recent drivers it will simply exit the application rather than crashing the phone as you’re seeing. It seems that in earlier versions it was causing a crash, there’s not much I can really suggest other than, as you’ve suggested, check the frame rate and either warn the user (and pause the app in the meantime!) or just exit cleanly, saying that the mobile is not fast enough to render the benchmark. For later drivers we can’t really do anything other than exiting the app as we don’t want to allow programs to lock up the system - which is something you’ll probably see in a number of other drivers after varying amounts of time.
Sorry I can’t be of more help than this!
Regards,
Tobias
Thanks for the insight. I’m still curious as to why it would timeout ? The driver can’t switch to a different rendering thread while waiting for the GPU commands ? is that why the timeout exists ? It’s weird cause I initially tested my app on an iPad 1 which has a really low performance, something like 0.3 FPS and it didn’t crash or anything, and that’s a device with iOS 5.0, released around 2011.
As a side note, if you actually have driver knowledge, does the driver or OS restrict as to how much memory the GPU can use from the entire memory ? Like if I say have a device with 1 GB of ram, can I have the GPU use 500MB or 800MB ? or does it have an internal limit ?
The timeout exists to prevent a lock-up of the system - there’s no way to tell whether a slow frame time is an accident or a malicious DoS type application. Obviously on the older drivers, it doesn’t help as a malicious app would now crash the device instead… but with the later drivers it simply quits out correctly.
The iPad drivers are modified by Apple from our reference platform quite a bit, and there are different constraints on Android with regards the OS, all of which means that we occasionally see different behaviour in the drivers between the two, such as this.
The Android OS does place limits on memory allocation, though it varies between platforms. As far as I’m aware, memory is reserved for GPU usage ahead of time, whether this is at boot time or manufacture I’m not sure, but it’s not something that will dynamically change or is easily modifiable.
Thanks, that was my guess all along and I’m a bit scared that on lower end devices I may hit that limit and crash my app. Is there a way to retrieve the limit though ? That would surely help. Or rather, I HOPE GL will return an OUT_OF_MEMORY error once that is hit… right ?
Yes, if you hit the limit, GL will return GL_OUT_OF_MEMORY whenever it tries to allocate memory and fails to do so. There are other mechanisms which can flush out data if you start running out of room as well, but if it’s unable to continue, it will alert the app developer via glGetError.
One more question so I won’t start a new thread on this 
Why do some shaders fail silently but say that they’re compiled ok ? I have a shader with a dozen instructions and if I use a lot of temporary variables it usually compiles successfully but the shader does not get computed correctly. If however I just put a lot of calculations in a single line it manages to make the correct calculations. I’ve noticed this on a dozen Android devices though so not sure who’s at fault. It’s kind of weird because again, on iOS I can put a ton of temporaries and it works correctly.
Usually I’ve seen that if I have :
uniform float VarA;
void main()
{
float TempA = VarA;
//Compute something with TempA;
}
It usually seems like TempA=0 (don’t try my test though, rather try it with 10-20 vec4s ). I’d also like to know if I can tell the GPU to unwind for loops as I’ve seen some performance improvements when unwinding for(s) and I thought it would do that automatically since it sees that the loop only has like 4 iterations (for(int i=0; i<4;i++) ). It makes the code really mess to do that manually…
Unfortunately, a number of drivers on popular Android devices are fairly out of date at this point. Our drivers - in particular the compilers - have gone through significant changes since the 1.5/1.6 drivers you’re probably seeing the issues on. Our recent compilers do a much better job of optimisation and correctness. Again, the iOS compilers are modified from our reference, so differences between Android and iOS would be expected. The iOS drivers are also more up to date than the ones mentioned above. There’s currently no way to give the compiler any hints.
I’d suggest the best way of combating these problems is to write your shaders as naturally as you want, then run them through the glsl optimizer before deployment, which should unroll loops and remove unnecessary temporary variables, as well as providing a level of obfuscation to protect your IP. The glsl optimizer is also built into PVRShaderEditor, so you can just click a button and it will provide optimised output with minimal effort.
Thanks,
Tobias
I tried the glsl optimizer and while it does seem to minimize instructions it also has some quirks like it doesn’t preserve the global precision qualifier and then my uniforms miss qualifiers and it spills out errors right after clicking optimize.
I also have a brand new project full of complex shaders and I have a really big issue: only the first applied shader is visible. The rest are completely ignored. No idea why. On other GPUs (Mali 400, Adreno 320, iPad 2) it works flawlessly but with my Galaxy Nexus/SGX 540 I’m missing stuff.
Do you have an email address where I can send an apk ? This app is not released yet and I don’t wanna release it unless I figure out how to fix this issue
Hi Cippy,
Ok so as I pointed out in the PM, send it to DevTech@imgtec.com and I’ll try to take a look at it.
I’ll have to take a look at the glsl optimiser precision issue - it might be worth feeding this back to Aras. At least it’s relatively simple to fix manually I suppose?
Regards,
Tobias
