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,
shader0292 only loops when using the r3p0 software driver version. On versions r4p0 and r4p1 of the driver, this issue has been identified and fixed.
Unfortunately, regarding your device, we do not control when Samsung will release updates, so although this has been fixed for a while, I cannot give you an ETA on when/if Samsung will provide an update to end users.
The specific offending call in this instance is the discard call. Commenting out the discard keyword will allow your shader to successfully compile on r3p0, however I dont know if that is an acceptable solution for you.
If you have any further questions, feel free to ask.
Kind Regards,
Michael McGeagh
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,