Validation for sync in varying flow control

[kayru]

FXC HLSL compiler has a useful validation feature that catches invalid synchronization, such as barriers in varying flow control.

Consider the following example HLSL shader:

RWBuffer<uint> g_buf0;
RWBuffer<uint> g_buf1;
groupshared uint g_scratch[64];
[numthreads(64, 1, 1)]
void main(uint3 dtid : SV_DispatchThreadID)
{
    g_scratch[dtid.x] = g_buf0[dtid.x];
    if((dtid.x & 1) == 0)
    {
        GroupMemoryBarrierWithGroupSync();
        g_buf1[dtid.x/2] = g_scratch[dtid.x] + g_scratch[dtid.x + 1];
    }
}

FXC reports the following error:

unknown(10,9-41): error X3663: thread sync operation found in varying flow control, consider reformulating your algorithm so all threads will hit the sync simultaneously
unknown(8,5-14): error X3663: this variable dependent on potentially varying data: dtid

It would be very useful to get similar analysis and error reporting in DXC.

One can try using different compilers (FXC, DXC and glslang) here: http://shader-playground.timjones.io/fe2ad3d9372d4a20f0f7de065e95e139

A similar issue is filed for glslang here: https://github.com/KhronosGroup/glslang/issues/1389

[antiagainst]

For SPIR-V CodeGen, to properly understand whether we are barrier'ing in varying control flow, a bunch of transformations (like const evaluation & folding, etc.) should be applied first. We leverage SPIRV-Tools to do the transformations. So I feel this is more suitable to happen in SPIRV-Tools validator.

@dneto0 @alan-baker

[dneto0]

Yes, I think this would be generally useful as a SPIR-V validation step. But the messages would be terrible (today) since we don't carry source level debug info into SPIR-V. Well, at best we could carry line info which might not be too bad. Also, optimizations are not set up to really track debug info.

Whatever path we take for DXC would also apply to Glslang. E.g. if we do this in SPIR-V validation then it would cover both DXC and glslang.

I could see a useful feature in a front end like DXC where you can detect control dependence based on an expression that is known to be varying, and issue that as a warning. Because you don't have precise value information you get some false positives as well, so at best it's a warning.

[kayru]

@antiagainst this feature is not specific to SPIR-V. Such validation is also useful/desired for DXIL path.

[damyanp]

If we had uniformity analysis we could look into solving this in clang. Related microsoft/hlsl-specs#246