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

Device lost due to OOB accesses in not-taken branches

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

Parents
  • Hi ByLaws,

    Thanks for the report! Looking at the generated shader it does seem like the R36 driver is incorrectly pre-loading the value inside the branch here. I also tested the latest internal driver release, R42, which by contrast seems to handle this correctly.

    I'll check this with the compiler team and get back to you. Thanks again!

    Cheers
    Christian

Reply
  • Hi ByLaws,

    Thanks for the report! Looking at the generated shader it does seem like the R36 driver is incorrectly pre-loading the value inside the branch here. I also tested the latest internal driver release, R42, which by contrast seems to handle this correctly.

    I'll check this with the compiler team and get back to you. Thanks again!

    Cheers
    Christian

Children