- July 10, 2010 at 12:24 am #30206
KrisMemberMy app’s testers got an intermittent crash from iPad w/OS 3.2 that I’m finding it difficult to reproduce, but I did get this callstack in the report. It looks like the IMGSGX535GLDriver is trying to compile my simple fragment shader and crashing for some reason. Is there anything I could have done to cause this, or is it most likely a driver bug? The test in question has worked under every other circumstance I know of.The only thing I can think of is that I called glReleaseShaderCompiler() long before the crash occurred. I assumed that since all my shaders had already been compiled at glCompileShader() time (at app init for me), shader compiler resources wouldnt be needed afterwards, so it’s a bit of a mystery why the driver is trying to ‘recompiling’ them later on. Does it need to do that to ‘patch’ every updated shader constants into the fragment program?0 libSystem.B.dylib 0x000790a0 __kill + 8
1 libSystem.B.dylib 0x00079090 kill + 4
2 libSystem.B.dylib 0x00079082 raise + 10
3 libSystem.B.dylib 0x0008d20a abort + 50
4 IMGSGX535GLDriver 0x0001fe96 UscAbort + 18
5 IMGSGX535GLDriver 0x00024620 PVRUniFlexCompileToHw + 688
6 IMGSGX535GLDriver 0x00017922 ppimgCompile + 986
7 IMGSGX535GLDriver 0x00009824 sgxUpdateCtxSysProgram + 92
8 IMGSGX535GLDriver 0x00009a36 glrUpdateCtxSysFragmentProgram + 234
9 IMGSGX535GLDriver 0x000034de glrUpdateFragmentProgramInline + 106
10 IMGSGX535GLDriver 0x000037b2 glrLoadCurrentPipelinePrograms + 626
11 IMGSGX535GLDriver 0x0000ad9c gldUpdateDispatch + 548
12 GLEngine 0x000a3f94 gleDoDrawDispatchCore + 208
13 GLEngine 0x00030360 glDrawArrays_IMM_Exec + 340
14 OpenGLES 0x000039c2 glDrawArrays + 26
15 mytestapp 0x0033caa0 Renderer::IPhone2xDevice::DrawTextured2DRect(Renderer::ShaderInfo const*, bool, float, float, float, float) (iphone2xdevice.mm:401)July 30, 2010 at 10:49 am #34112
This is most likely a driver bug. You should submit a bug report to Apple for this.
Calling glReleaseShaderCompiler mearly informs the driver that you no longer require the compiler. This gives the driver the option of releasing the compiler from memory at a later stage if additional resources are required. If at any point after calling glReleaseShaderCompiler you then call glCompileShader, the driver will load the compiler back into memory and perform the required compilation.
The recompilation you are seeing here is most likely the result of a state change that has occurred that will affect the way in which the shader operates, such as enabling/disabling blending or changing the format of textures that are passed into the shader. You should be able to work around this issue by creating separate shader programs for different states, i.e. create one program for alpha blending and another for rendering opaque objects.
Let me know if this helps.