The ARM Mali GPU driver miscompiles a fragment shader that uses the bitwise not operation on a uvec2 variable. The shader is expected to render a black color, but the Mali GPU renders a white color instead.
uvec2
The source code of the fragment shader is as follows:
#version 300 es
precision highp float;precision highp int;
precision highp float;
precision highp int;
uniform int input1; // input1 = 0
layout(location = 0) out vec4 color;
void main() { uvec2 a = uvec2(input1, 2u) | 1u; // a = (1, 3) uint b = ~a.y; // b = 4294967292 float c = float(b % 2u); // c = 0.0 color = vec4(c, c, c, 1.0); // color = (0.0, 0.0, 0.0, 1.0) a.k.a. black}
void main() {
uvec2 a = uvec2(input1, 2u) | 1u; // a = (1, 3)
uint b = ~a.y; // b = 4294967292
float c = float(b % 2u); // c = 0.0
color = vec4(c, c, c, 1.0); // color = (0.0, 0.0, 0.0, 1.0) a.k.a. black
}
The input uniform is set to 0 during runtime. The variable `a` is set to `(uvec2(0, 2) | 1) = (1, 3)`. The variable `b` is set to `~3 = 4294967292`. The variable `c` is thus `4294967292 % 2 = 0`. The expected color is black `(0.0, 0.0, 0.0, 1.0)`, but the Mali GPU renders the color as white.
I prepared an HTML file that can be simply opened in browser to reproduce this issue. The HTML webpage contains a minimal JS script that executes the fragment shader and outputs the color to the canvas. Also, I prepared a detailed README file describing the environment and steps to reproduce the issue. You can download them all here
You're welcome! Thanks for providing more details. We'll look into the issue with shaders containing the "uvec bit_op variable" pattern right away. I understand how this could affect your development, so we'll prioritize finding a solution. I’ll keep you updated on the progress! Let me know if there’s anything else in the meantime.