steam-3058630.log

And NVIDIA-Linux-x86_64-595.44.07 to give an exact driver version

(Let me first say that there's a possibility this doesn't happen on AMD hardware, if so it's probably a nvidia driver bug but putting that aside until I get some confirmation on that....
edit: https://images.steamusercontent.com/ugc/12560336593843223685/78698CB60996DA934780ACC7F96DB07EA7B79117/ this looks ok so perhaps points to nvidia vulkan driver being the culprit?
)

The dx12 disassembly has

SamplerState samLinearWrap : register(s0, space0);
SamplerState samLinearClamp : register(s1, space0);
SamplerState samAnisoHighWrap : register(s4, space0);
SamplerState samAnisoLowWrap : register(s5, space0);
SamplerComparisonState samShadow : register(s6, space0);

And then the code (tons of it) is referencing SamAnisoHighWrap et al all over.
Far too much code for me to start debugging that. The 'it works' thing I guess is that it renders beautifully on windows dx12 suggesting there's no obvious 'they're using the wrong sampler in the shader' bug.

In renderdoc pipeline state tab (for dx12) I see 'Samplers' and those 5 samplers described above and the parameters look ok - and they look the same as the vulkan equivs.

In the vulkan / proton fragment shader I see the same 5 samplers

layout(set = 3, binding = 0) uniform sampler _155;
layout(set = 3, binding = 1) uniform sampler _156;
layout(set = 3, binding = 4) uniform sampler _157;
layout(set = 3, binding = 5) uniform sampler _158;
layout(set = 3, binding = 6) uniform samplerShadow _159;

And everything looks fine on these parameter wise.

And these are referenced throughout the shader, e.g

sampler _270 = *_159;
sampler _271 = *_158;
sampler _272 = *_157;
sampler _273 = *_156;
sampler _274 = *_155;

and then

  if(_1465) {
      float4* _1651 = &_127._child0[89];
      float4 _1652 = *_1651;
      float _1653 = _1652.x;
      SampledImage<float, 2D> _1654 = SampledImage(_1460, _272) : [[NonUniform]];
      float2 _1656 = CompositeConstruct({_1025, _1027});
      float4 _1655 = ImageSampleImplicitLod(_1654, _1656, Bias(_1653));
      float _1657 = _1655.x;
      float _1658 = _1655.y;
      float _1659 = _1655.z;
      float _1660 = _1655.w;
    } else {
      SampledImage<float, 2D> _1661 = SampledImage(_1460, _272) : [[NonUniform]];
      float2 _1663 = CompositeConstruct({_886, _888});
      float4 _1662 = ImageSampleImplicitLod(_1661, _1663, );
      float _1664 = _1662.x;
      float _1665 = _1662.y;
      float _1666 = _1662.z;
      float _1667 = _1662.w;
    }

    float _1262 = Phi(_1657, _1664);
    float _1265 = Phi(_1658, _1665);
    float _1268 = Phi(_1659, _1666);
    float _1271 = Phi(_1660, _1667);

I note that on the Descriptor Layout there's actually 8 samplers, but presumably 3 of them are not referenced and not shown in renderdoc 'pipeline state'

The odd thing is, if I edit the shader code in renderdoc and change it from layout(set = 3, binding = 4) uniform sampler _157; to layout(set = 3, binding = 3) uniform sampler _157; This binding = 3 shader (which isn't referenced in the code until I add it) says 'CLAMPEDGE' but it tiles ok then? So that confuses me. It's like opposite day or something, yes means no and no means yes.

i.e the original code (that renders clamp edge incorrectly for the floor) uses a shader in renderdoc that looks like this

Set 3, 4: _157 Sampler Sampler 3627 UVW: Repeat Min&Mag&Mip: Anisotropic Aniso 16x, LODs: 0 - FLT_MAX and I change it to

Set 3, 3: _157 Sampler Sampler 2510 UVW: ClampEdge Min&Mag&Mip: Point, LODs: 0 - FLT_MAX

But the effects seem reversed, i.e running 'Start replay loop' with the 3,3 gives me a nice tiled plane and with 3,4 gives me clampedge?!?!

Same thing happens on windows using vkd3d-proton so if it's a nvidia bug it's in their windows driver too.

Perhaps I need some software reference driver that can output something correct to point the finger or eliminate the nvidia driver...and perhaps I should put some hard-coded aniso 16x on all the samplers and see if it's not that. Because that's another notable difference here between the samplers where repeat seems to function and where it doesn't, one has 16x Aniso.

But yeah, I appreciate any insight or ideas to test further.

Thanks for your help Hans & pushing the bug report forwards.

I'll try the descriptor heap (but I can easily get pretty enough graphics with my hard-coded hack until the bug fix appears)

Reported to NV. You can try using heap path and see if that helps, otherwise I don't know what to do.

Our latest Vulkan beta driver (found at https://developer.nvidia.com/vulkan-driver) should have a fix for this problem. Let me know how it works out for you if you have a chance to give it a try. Thanks.

Firstly apologies for not seeing your post earlier.

I've just tested latest vulkan beta driver and it seems to be rendering fine now. Many thanks for the speedy fix.

(Hans : I used the descriptor-heap-rebase all week with this game and that path has been rendering fine too)

Awesome, thanks for trying the beta driver out. :-)

Sorry if this is off-topic, but since this issue is referenced in the NV patch notes for the latest driver with AC EVO, I thought it would be appropriate to ask here @pdaniell-nv

I have a problem with texture flickering, that is e.g. on Nordschleife the trees, trailers, and other stuff off-track is popping in and out, may be of low resolution or distorted in shape. Sometimes the car textures (e.g. dashboard elements) are not rendered too.

Cachyos, Proton Experimental, driver 610.57.04. Many thanks for any help!

We are aware of an issue with depth image corruption after copies from color images. I'm not sure if this is the same one you're seeing. Once we fix the depth image problem we should revisit the issue you describe if it still exists.