Multiple return statements in vertex shader results in corrupt geometry shader output

This doesn’t happen under Warp or on an older Win7 + GTX970 system, but it does happen on Win10 + RTX2080 + 417.35 driver.

I have a vertex shader that, to clip undesired vertices, sets their z position to -1 and returns an otherwise zeroe’d output struct. Then the geometry shader that follows checks if one of the input vertices has a z of -1 and, if so, doesn’t emit any geometry. However, what I exactly do in the vertex/geometry shaders isn’t important, it’s only the structure of the vertex shader that matters.

This works fine:

GS_FILLED_IN VSFilled(VS_FILLED_IN Input)
{
GS_FILLED_IN Output;

if (!all(Input.FilterMask & FilterMask)) //Discard vertices with incorrect filter mask
{
    Output = (GS_FILLED_IN)0;
    Output.Pos.z = -1;
}
else
{
   ...
}

return Output;

}

This results in graphics glitches - garbage triangles output by the geometry shader:

GS_FILLED_IN VSFilled(VS_FILLED_IN Input)
{
GS_FILLED_IN Output;

if (!all(Input.FilterMask & FilterMask)) //Discard vertices with incorrect filter mask
{
    Output = (GS_FILLED_IN)0;
    Output.Pos.z = -1;
    [b]return Output;[/b]
}
else
{
    ...

}

return Output;

}

This issue is reproducible in an nsight dump I made, I can send it on request.

We just ran into this same issue. We only saw problems running Windows 10 with any of the RTX 2070, 2080, and 2080ti cards (driver version 419.67). 1080 and 1080ti cards both work as expected.

We only saw the issue when using an early return statement in a vertex shader that was invoked from a DrawAuto call using a vertex buffer that was previously bound as a stream-output buffer. We have other shaders with early returns that don’t seem to exhibit the same problem.

I have a small reproduction project I can send if needed.

Since driver 430.39 (and maybe one or two versions earlier) the issue has been solved for us, even though the driver release notes don’t suggest anything relevant should have changed. I’m curious to know if a newer driver also fixes the issue for you.

Updating to the latest driver (430.64) does appear to have fixed it. I was using the latest ‘creator ready’ version which is still at 419.67, but I’m happy to know this is already fixed.