Hello.
I am working on a game and one of the device (Samsung Galaxy S3 (GT-I9300) with gpu Mali-400MP4, android version 4.0.4) is displaying problems while trying to compile one of the shaders. The gl call glCompileShader takes exceptionally long time for this shader (20+seconds). It is not a necessarily a big complicated shader and I am attaching the source file here. I have tried experimenting with changing the sahders and the compile time does go down if I start taking out instructions but even a simple acceptable shader for the game is taking 5-10 seconds to compile depending on the features. Unfortunately I have hit a wall while trying to figure out exactly which instruction is causing this issue and am not getting anywhere. Since it doesnt technically crash I get no information from glGetShaderInfoLog. Any help on this will be greatly appreciated.
PS - I am not seeing this issue on most of the other devices. I also trying using the offline compiler but I ran into other issues like the compiled shader would not link complaining (L0101 All attached shaders must be compiled prior to linking).
Thanks for reporting.
Some ideas which may help. I'm guessing it is auto-generated, but you seem to have a lot of code which does something like:
r0_5.w = (r0_5.wwww * pc[6].xxxx).w;
Why not just write is as scalar code in the first place rather than using vector ops and throwing away 75% of it? I would guess that the following is a little easier for the compiler to handle ...
r0_5.w = r0_5.w * pc[6].x;
Similarly operations such as ...
r1_4.x = max (pc[4].xxxx, r0_5.xxxx).x;
... would also seem to massively over-complicate it. What's wrong with ...
r1_4.x = max(pc[4].x, r0_5.x);
... and for this ...
r2_3.xyw = (r0_5.yyyy * pc[11].xyzz).xyw;
... why not ...
r2_3.xyw = r0_5.yyy * pc[11].xyz;
There are other places where you write scalar code, and force the compiler to re-vectorize it. This ...
r2_3.x = exp2(r1_4.xxxx).x; r2_3.y = exp2(r1_4.yyyy).y; r2_3.z = exp2(r1_4.zzzz).z;
... could be ...
r2_3.xyz = exp2(r1_4.xyz);
I'm not sure how much this adds up to in terms of compiler overhead - but it is all work which takes at least some time for the compiler to unpick. That said, I suspect that doesn't add up to much - it would just make the code more readable . I suspect the main issue is the amount of working data you have hanging about in registers which has quite a long lifetime in the program. The register allocator is going to have to work quite hard to pack that into the register file as efficiently as possible to avoid spending a lot of time stacking and unstacking variables.
Some unrelated observations which may help - you have a relatively bulky block of uniforms in the "pc" array - many of them you only use one of the vector channels so you're losing some efficiency there. You end up with some things which you forcefully devectorize such as ...
r3_2.w = tmpvar_9.w; r3_2.xyz = (tmpvar_9 * pc[5]).xyz;
Given that you never use the pc[5].w uniform for anything, why not set it to 1 when you upload the uniform and just do ...
r3_2 = tmpvar_9 * pc[5];
It may not solve your compile time issues, but it should go faster once it's compiled .
I also trying using the offline compiler but I ran into other issues like the compiled shader would not link complaining
The best way to get a binary which will work is to compile it once on the target (e.g. at install time), and cache the binary, which can be reloaded later. The reload may fail if the driver is updated (binaries may become incompatible), so you may need to recompile from source and recache an updated binary after a firmware update.
See this extension:
http://www.khronos.org/registry/gles/extensions/ARM/ARM_mali_program_binary.txt
HTH, Pete
Thanks for your prompt reply The shader gets compiled as hlsl through D3DXCompileShader (using max optimizations) and then we translate it to glsl which is why the code is the way it is. I will go through the translator code to see if we can improve it based on your suggestions.
I suspect the main issue is the amount of working data you have hanging about in registers which has quite a long lifetime in the program. The register allocator is going to have to work quite hard to pack that into the register file as efficiently as possible to avoid spending a lot of time stacking and unstacking variables.
By this do you mean local registers like the following?
mediump vec4 r4_1;
mediump vec4 r3_2;
mediump vec4 r2_3;
mediump vec4 r1_4;
mediump vec4 r0_5;
Eliminating them would be hard because these get generated by D3DXCompileShader. I am just surprised as to why this problem only occurs on Mali400MP4 devices. I was hoping it was a something to do with a specific instruction. I will also spend some more time digging into the offline compiler a bit more.
The shader gets compiled as hlsl through D3DXCompileShader (using max optimizations) and then we translate it to glsl which is why the code is the way it is.
Yep - I guessed it would be something like that - it definitely has that "written by a machine" look about it.
I will go through the translator code to see if we can improve it based on your suggestions.
Try hand fixing one first. It may make no difference, so I'd hate for you to spend a load of time improving the translator for that effort to be wasted .
By this do you mean local registers like the following? mediump vec4 r4_1; mediump vec4 r3_2; mediump vec4 r2_3; mediump vec4 r1_4; mediump vec4 r0_5;
Indirectly yes. Any variable which exists in the program needs to have register storage (spilling to stack storage if we run out of space) from the point it is first assigned a value to the point it is last used. Things like uniforms and constants are handled differently - so are not counted in this.
This program has quite a lot of "working state". Most of the variables are assigned relatively early and stay "alive" for a long time because they are used in the final few instructions of the program, so the compiler has to work out how to most optimally keep this data in registers, while also packing things efficiently for the vector ALUs.
If you can change the algorithm to need fewer live variables it could help - but it would change the visual output of course.
P.S. I've just checked with the current offline compiler from http://malideveloper.arm.com/develop-for-mali/tools/analysis-debug/mali-gpu-offline-shader-compiler/ and this seems to perform OK on a desktop PC (4ms to compile) so I suspect you are running in to an issue which is only present on older driver releases.
chrisvarns can you please raise a support ticket.
Cheers,
Pete
Will do on Tuesday, UK bank holiday on Monday.
Thanks,
Chris