This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Infinite loop in MALI T6xx shader compiler?

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

6767.zip
Parents
  • 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.

    Thanks!

    Stephane

Reply
  • 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.

    Thanks!

    Stephane

Children
  • Hi Stephane,

    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,

    Chris