how long does it take to get to a place to repro this?

(I'm assuming that sharing saves isn't possible with this game because, well, online memes)

Unable to reproduce on either the RTX 2060 or RX 6900XT, seems like this is specific to 4000 series.

@runar-work https://github.com/HansKristian-Work/vkd3d-proton/pull/1675 should work around it.

I'm convinced now this is an NV compiler bug that affects Ada only.
There is something happening with the vertex allocation scheme that is completely bogus.

The shader is actually okay here as far as I can tell.

First time we hear about anyone running this on RTX 3000 series, so I guess it's those two architectures. Turing is not affected.

But yeah, since this looks like a straight-up driver bug there's not much we can do; disabling mesh shaders on our end isn't really a great option either considering that the legacy path in UE5 is (generally) significantly slower on GPUs where mesh shaders actually work properly.

Thanks. I'll investigate further.

@adamnv Thanks for looking into this.

However, I don't think the undefined value should be the issue here if we look at the actual uses more closely:

%1290 = OpLabel
...
        OpBranchConditional %99 %1291 %1292
%1291 = OpLabel
...
        OpBranch %1292
%1292 = OpLabel
 %147 = OpPhi %uint %86 %1290 %141 %1291

// %148 and %150 are well-defined if we come from %1291, i.e. if %99 was true
 %148 = OpPhi %uint %149 %1290 %143 %1291
 %150 = OpPhi %uint %149 %1290 %145 %1291
...
 %586 = OpISub %uint %150 %148

// Only uses %148 and %150 if %99 was true, fallback value otherwise
 %587 = OpSelect %uint %99 %586 %571
 %588 = OpSelect %uint %99 %148 %uint_0

In other words, the pattern is similar to this, where the undefined values always end up being discarded:

uint x, y;
if (cond) {
  x = foo;
  y = bar;
}
...
uint value = cond ? x + y : 0u;

I also noticed that this shader exports a clip distance, which isn't well-tested. I wrote a test now which passes on Nvidia drivers, but I'll still look into whether or not this could be the culprit, especially. w.r.t. invariance.

@adamnv Testing this on a 4070 now. It looks like there's a problem with how the compiler handles SetMeshOutputsEXT inputs.

For reference, the shader I'm working with is 05d3d244d33727ed from Talos Principle 2.

If I manually insert some uniform control flow after SetMeshOutputsEXT that depends on the vertex and primitive count, the issue seems to go away. we'll have to implement this as a workaround in vkd3d-proton to confirm for sure whether this is actually a legitimate fix or not.

Specifically, changing

               OpSetMeshOutputsEXT %722 %611

to

               OpSetMeshOutputsEXT %722 %611
       %2002 = OpExtInst %uint %310 UMin %722 %611
       %2003 = OpGroupNonUniformBroadcastFirst %uint %uint_3 %2002
       %2004 = OpIEqual %bool %2003 %uint_0
               OpSelectionMerge %2501 None
               OpBranchConditional %2004 %2500 %2501
       %2500 = OpLabel
               OpReturn
       %2501 = OpLabel

or, in GLSL terms,

    SetMeshOutputsEXT(_813, _686);
    if (subgroupBroadcastFirst(min(_813, _686)) == 0u)
        return;

seems to make the problem go away without changing how the shader behaves (the condition is always false in practice).