Been investigating a freeze in our app, that randomly occurs on a specific device when rendering a specific object, and had discovered what looks like a deliberate dead loop that the driver might conditionally invoke inside the libGLESv2 library. The casue is not clear, as the app does not freese on other devices, including those with PowerVR GPU, and there appears to be no relevant diagnostic messages in the log prior to the freeze. I can however provide the exact call stack and the point inside the library where the dead loop is implemented, and looking for someone with enough insight into internal logic of the driver to help me figure out why it would opt to freeze, and then hopefully how to work around that.
Shared library info:
ELF 32-bit LSB shared object
version 1 (SYSV)
frame #0: 0x632038a5 libGLESv2_POWERVR_SGX540_121.so.1.9.2188537`USPInstBlockFinaliseInsts + 2069 frame #1: 0x631fc1ee libGLESv2_POWERVR_SGX540_121.so.1.9.2188537`FinaliseInstructions + 62 frame #2: 0x631f6652 libGLESv2_POWERVR_SGX540_121.so.1.9.2188537`PVRUniPatchFinaliseShader + 434 frame #3: 0x631ec6bf libGLESv2_POWERVR_SGX540_121.so.1.9.2188537`SetupUSEFragmentShader + 719 frame #4: 0x631f0320 libGLESv2_POWERVR_SGX540_121.so.1.9.2188537`ValidateState + 368 frame #5: 0x631bc5ac libGLESv2_POWERVR_SGX540_121.so.1.9.2188537`glDrawElements + 380 frame #6: 0x4086ea7a libGLESv2.so`glDrawElements + 58 frame #7: 0x67cf316b libgame.so`Render::RenderDeviceGLES2::DrawIndexedPrimitives(this=<unavailable>, type=TriangleList, elements_offset=<unavailable>, elements_count=<unavailable>, indices=<unavailable>) at RenderDeviceGLES2.cpp:2262
The instruction at #0:
0x632038a5 <+2069>: jmp 0x632038a5 ; <+2069> (eb fe jmp 0x0)
(0x5A8A5 is the actual offset of the jmp 0x0 instruction inside the library) It appears to follow a call to USPInstBlockInsertHWInst() at 0x5A5B7, and lays on its non-zero return execution path.
This unfortunatelly tells me nothing about what the driver doesn’t like about our shader.
thanks for reporting this, can you please let us know what platform this is?
Can you please also send us a PVRTrace file of the problematic applicaiton?
It’s an Android device. It isn’t rooted so I don’t think I’ll be able to use tools on it.
you can use PVRTrace on other devices and you should still be able to reproduce the issue on the original one.
Yes probably, but then I don’t quite understand how that would help.
I think I might have been misunderstood. This is not a bug report. There is basically no hope that an update would reach this device, even if driver is to be fixed on your side, so a bug report wouldn’t get me anywhere.
I have a device+software specific case, a call stack, and some other bits of information already collected. What I am looking for is someone with insight into driver’s internal logic to make general sense of the behavior I’m seeing. Sure there can’t be many logical paths that would get a driver to enter a deadloop at that specific point.
we can use that file to reproduce your issue and maybe find you a workaround.
I’ll also try to find a person who has insight into that driver for you, but in the meantime can you please provide us with a PVRTrace recording?
Not very likely, at least not in the immediate future. Rooting a device is a whole another set of hoops to jump through, and it might be a while before I get a time window to work on this issue again. We don’t develop OS-level software and usually have no use for the root access.
I can provide shader sources, though they don’t appear to contain the cause and would only add to the confusion I’m afraid.
Alright, I’ll try to contact someone for you.
I have recorded a PVRTrace of the app and will now PM it over, if that is ok.
It is from a different device, the point it would get stuck on is in the notes.txt . Shader source recorded is a reduction of the original 100+ lines that still causes the freeze, and will not necessarily make sense as a shader.
Any news here yet, maybe?
I just pinged the people I contacted (they were on holiday), will get back to you as soon as they reply.
it seems like this issue is caused by using too large textures. We have fixed this issue in 1.9@2524087.
I’m trying to get more info for you to work around this. I’ll get back to you soon.
it seems like this issue has to do with our compiler’s internal register allocation heuristics, which is complex that random tweaks might not do the trick. However, I would suggest playing around with precision qualifiers which might trigger a completely different codepath and solve your issue.
So is this issue limited to older software?
Yes it should be fine for 1.9@2524087 or later.