3

I seem to have run into a known iOS issue where a call to glDrawElements causes delayed shader compilation. I used instruments to find the sub-function causing most overheads in this case.

While I'm not very happy that compilation happens while drawing, what really baffles me is that I've been seeing shader compilation times between 0.2 seconds and 5.0 seconds or more. Running in instruments with memory allocation tools, I actually got a 40.0 seconds delay(!)

Typical stack looks like this:

18 OpenGLES 2939.0  glDrawElements
17 GLEngine 2939.0  glDrawElements_ACC_ES2Exec
16 GLEngine 2939.0  gleDoDrawDispatchCoreES2
15 IMGSGX543GLDriver 2939.0  gldUpdateDispatch
14 IMGSGX543GLDriver 2938.0  gpusLoadCurrentPipelinePrograms
13 IMGSGX543GLDriver 2915.0  glrUpdateCtxSysFragmentProgram
12 IMGSGX543GLDriver 2761.0  sgxUpdateCtxSysProgram
11 IMGSGX543GLDriver 2760.0  ppimgCompileShader
10 IMGSGX543GLDriver 2759.0  PVRUniFlexCompileToHw
9 IMGSGX543GLDriver 2658.0  CompileIntermediate

Where '2930.0' etc... is the time spent in that function in milliseconds.

The 'culprit' appears to be a bulky fragment shader (350 lines). Okay, it's big, but it compiles without any error or warning. I'm sorry I'm not able to post the shader code or link to it, but I think others may have run into similar errors (I believe the size of the shader magnifies the issue, if anything).

Anybody ran into this before? Can you help?

Issue observed in iOS7 running an iPad2 and iPod touch. From one build to the next the issue may arise on one of the devices, or both, or neither. I couldn't clearly determine whether running the app over and over again changes anything, so far it would appear that it's showing up on a per build basis.

Some more info: - never happened the second (or any over time) the shader is loaded by the app. - shader is loaded very soon after app start but it's not the first shader loaded by this app. - postponing loading this shader for a while (e.g. 0.5 to 1.0 seconds) does not help

1 Answers1

2

This is a known issue actually and the apple documentation says:

Creating a shader program is an expensive operation compared to other OpenGL ES state changes. Compile, link, and validate your programs when your app is initialized. Once you’ve created all your shaders, the app can efficiently switch between them by calling glUseProgram.

Unfortunately I do not think you can compile your shader faster but at least compile it earlier when you initialize your app.

Vincent Zgueb
  • 1,491
  • 11
  • 11
  • I appreciate your input and I do think it's an answer of sorts, but really what I'm wondering about (and need help with) is the large discrepancies observed between builds!? I'd say this has a smell, and needs more explaining. So, have adjusted the question title to clarify. As to compiling earlier all I could do is displaying a nice "loading" message as the shader is needed to display the app's home screen :( –  Mar 03 '14 at 18:13