Hi,
When porting our Vulkan application to Mali GPUs I noticed that a specific compute shader always caused a device lost error upon dispatch and narrowed it down to an odd miscompile. In the following excerpt, the memory access in the second if statement is still performed despite the branch to it not being taken, the memory access then causes an OOB access as the first if statement works fine and '_1456' is set to zero:
#version 450 #extension GL_EXT_scalar_block_layout : require layout(local_size_x = 32, local_size_y = 1, local_size_z = 1) in; layout(set = 0, binding = 0, scalar) uniform _30_33 { uint _m0[16384]; } _33; layout(set = 0, binding = 1, std430) buffer _35_38 { uint _m0[]; } _38; layout(set = 0, binding = 4, std430) buffer _65_71 { uvec4 _m0[]; } _71; void main() { uint _1443 = (_33._m0[0] << 1) >> 33; // This is enough to trick the compiler into not optimising out the ifs, will always be 0 bool _1452 = (_1443 > 0u); // _1452 will always be false as _1443 will always be 0 uint _1456 = 0; if (_1452) { _1456 = _33._m0[180u]; } uint _1486; if (_1452) { uint _1476 = (_1456 - _33._m0[180u]) >> 4u; _1486 = _71._m0[_1476].x; // <!!OOB!!> } else { _1486 = _1456; } _38._m0[0] = _1486 ; return; }
The bindings used here don't refer to any particular data, but are enough to convince the compiler to not optimise things out.
HW Info:
Google Pixel 6 Pro
Android 13
Mali-G78
Driver 36.0.0
Great to hear, thanks for letting me know!
These days the kernel interface is quite stable, so decent chances a newer user-space can work with an older kernel -- but no hard guarantees. Bigger problem here could be user-space compatibility as it's usually compiled for a specific GPU model -- some models are compatible, some are not (e.g. Immortalis-G715 to Mali-G715 might work, other combos are less likely to). Could be worth a try, but don't get your hopes up too much. :)