Hello ARM,
In testing today, we found what appears to be an infinite loop in the mali T6xx shader compiler. Tested against Galaxy Note 2014 running 4.4.2.
Two shaders are here attached:
-shader0291.txt, which compiles successfully.
-shader0292.txt, for which glCompileShader never returns (presumably in an infinite loop).
shader0292 is an alpha test variant of shader0291. However, as you may notice, it happens to be alpha testing against 1.0, something we've now optimized out of our shader code generation. However, despite the simple workaround, figured I'd share these since the compiler bug itself appears valid.
Thanks!
Stephane
Hi Stephane,
As McGeagh states, this is a known issue. Here is a modified version of your shader which compiles on r3p0, the solution is to move the discard op into its own control block.
Hth,
Chris
Thank you both for your answers! As I had mentioned initially, we have worked around the issue and glad to hear it is addressed in later versions of the MALI drivers.
Chris, Thanks for showing workaround. Good to know this. One thing that I was wondering about is the fact that we use this exact same alpha testing construct in dozens of other shaders without issue. Does the one_f constant have anything to do with it? Or is there anything more that is triggering this compiler behavior.
The constant is not related. Without going into too much detail the shader is just "unlucky" as it happens to cause the scheduler to fall into an infinite loop trying to schedule the discard op moving it to its own control block works around the scheduling issue. Thanks for reporting the bug, glad you worked around it separately, and hopefully this helps someone else googling this later .
Thanks,