OpenGL ARB 着色器 baloot readInvocationARB 为非活动调用返回不同的结果

Question

I am writing a shader that uses the same algorithm several times on different inputs to calculate some intermediate results that are later combined to get the final result. The data is dependent on the in-game world position, and for invocations in one group it is close enough, so I can process all inputs on different invocations simultaneously and them move intermediate results between invocations to calculate final results. The tricky part is that some intermediate results allow earlier exiting from the calculations, and that means that some invocations depend on other's calculations, and some of them may not (so they are inactive when the results are moved between invocations).

OpenGL has a ARB shader baloot extension, that allows reading values from other invocatoins. Specifically, readInvocationARB(genUType value, uint invocationIndex) function. Its description says that:

The function readInvocationARB() returns the <value> from a given <invocationIndex> to all active invocations in the sub-group. The <invocationIndex> must be the same for all active invocations in the sub-group otherwise results are undefined.

And does not explicitly state that <value> depends on whether read-from invocation is active or not. I decided to test what would the result be if the invocation is inactive.

#version 460
#extension GL_ARB_shader_ballot : enable

uniform uint data;
layout(location = 0) out vec4 color;

void main() { 
    uint var;
    var = data;
    
    if(gl_SubGroupInvocationARB != 20) {
        const uint result = readInvocationARB(var, 20);
        color = vec4(result == data);
    }
    else color = vec4(1, 0, 0, 1);
}

The result was white image with red dots, which means that in this case the <value> from inactive 20'th invocation is what had been written in the variable earlier.

Then I decided to add condition to var 's value:

#version 460
#extension GL_ARB_shader_ballot : enable

uniform uint threshold;
uniform uint data;

layout(location = 0) out vec4 color;

void main() { 
    uint var;
    if(gl_SubGroupInvocationARB < threshold)
         var = data;
    else var = 10;
    
    if(gl_SubGroupInvocationARB != 20) {
        const uint result = readInvocationARB(var, 20);
        color = vec4(result == data);
    }
    else color = vec4(1, 0, 0, 1);
    
    return; 
}

data uniform was set to 10 (so that value would actually always be the same), and the value of the threshold variable doesn't matter (the results are always the same regardless). In the second case the image was black with red dots, which means that <value> is not what has been written the variable earlier (it is actually 0).

I decided to test these two shaders on another computer, which had AMD graphics card (first one had Nvidia). In both cases the output image there was white with red dots, which differs from what the first PC displayed. It is not a rigorous testing, but it shows that different configurations of hardware and software produce different results for the same shader programs.

So the question is:

• Am I missing something and the result of readInvocationARB() for inactive invocation is undefined, in which case where can I find complete description of this extension? or,
• the result is defined and I do some other thing wrong or one of the outputs produced is incorrect.

Answer 1

As the quoted part of the specification states, invocationIndex must be an active invocation within the subgroup. As such, if it isn't an active invocation in the subgroup, you have passed the function faulty data and thus achieve undefined behavior.

Because of the branch, which invocations are part of the same subgroup is not known. That is, you did nothing to ensure that 20 was an active invocation index in the same subgroup. You didn't check to see if ballotARB(true) & (0x1 << 20) is true.

Since branch divergence is implementation-dependent, and you do nothing to verify that 20 is a valid active invocation index, whether your code has well-defined behavior depends on implementation-dependent stuff. And therefore, it can vary from implementation to implementation.