[We're looking to file some possible bugs related to compilation of shaders for Mali. Please let us know if there's a different, preferable place to do so.]
The following issue is also logged here, which links to the relevant files.
Platform details are at the end.
This fragment shader:
https://raw.githubusercontent.com/mc-imperial/shader-compiler-bugs/master/ARM-Mali-T628-Chromebook-WebGL/wrong_images/sm… https://raw.githubusercontent.com/mc-imperial/shader-compiler-bugs/master/ARM-Mali-T628-Chromebook-WebGL/wrong_images/small-v100-webgl-804943b2b630b741_inv_variant_4/variant.frag
leads to an image like this being rendered on several GPUs that we have been testing (including an Intel GPU):
On our Mali GPU, via WebGL with Chrome, we find that this image is rendered:
Furthermore, we have created a shader that is almost identical to the one linked to above, except that a reference to variable k has been changed to (injectionSwitch.x > injectionSwitch.y ? 1.0 : k). This should have no effect on rendering if we set injectionSwitch to the vector (0.0, 1.0), because the condition in the ternary will evaluate to false.
k
(injectionSwitch.x > injectionSwitch.y ? 1.0 : k)
injectionSwitch
(0.0, 1.0)
Here is the modified shader:
https://raw.githubusercontent.com/mc-imperial/shader-compiler-bugs/master/ARM-Mali-T628-Chromebook-WebGL/wrong_images/sm…
When we set injectionSwitch to (0.0, 1.0) and render on Mali using the modified shader, we get this image:
which is visually very similar to the image that we see rendered on other GPUs we tried.
We speculate that a compiler bug is being triggered when the original shader is used for rendering, and that our modification somehow masks the compiler bug.
Platform details:
- Samsung Chromebook
- Chrome OS
* Version: 54.0.2840.101
* Platform: 8743.85.0 (Official Build) stable-channel peach_pit
* Firmware: Google_Peach_Pit.4482.95.0
- GPU: ARM Mali-T628
Version and renderer info obtained via WebGL API:
Hi Ally,
We've managed to reproduce this one internally on the latest driver release for the Midgard GPU family (Mali-T* GPUs), but we don't have an issue on the newer Bifrost GPU family (Mali-G* GPUs).
We'll try and get a fix into the next Midgard driver release (r16p0 is the earliest possible intersection point), but exactly when that bubbles into consumer devices it out of our control unfortunately.
Thanks for the bug report, with the thorough reproducer - our compiler guys were very appreciative.
Kind regards, Pete