Summary

On NVIDIA Pascal (GTX 10-series) GPUs on Linux, The Finals (Unreal Engine 5, DX12 via vkd3d-proton) renders volumetric fog as an opaque, near-fullscreen brownish-white haze that obscures the map, instead of the intended semi-transparent fog. The effect is inconsistent: it can fade/shrink over the first few seconds after loading a map, varies in intensity between maps, and is occasionally absent entirely. Forcing DX11 (-dx11) removes the artifact but makes the game unplayable due to severe CPU-bound stutter (expected, since UE5's renderer is primarily tuned for DX12).

Environment

• Game: The Finals (Steam AppID 2073850), Unreal Engine 5, Shipping build (function names stripped)
• GPU: NVIDIA Pascal (GTX 1060/1070/1080/1080 Ti class)
• OS: Pop!_OS (Linux)
• Compatibility layer: Steam Proton (tested on GE-Proton 11-1 and stock Proton builds; issue reproduces on all of them)
• vkd3d-proton: bundled with the above Proton builds

Symptom (screenshot attached)

Uniform, low-contrast brownish-white fog fills the entire visible scene, with no discernible volumetric shape — looks consistent with a volumetric-fog integration/history buffer being filled with either extreme/garbage values or a wrong/uninitialized resource, rather than a rendering-logic bug (e.g. wrong density constant).

What we've ruled out so far

We dumped every shader compiled during a play session via VKD3D_SHADER_DUMP_PATH (~16k shaders total) and did static SPIR-V analysis + targeted patching via VKD3D_SHADER_OVERRIDE, gated by spirv-val so nothing invalid was ever loaded:

1. Write-side check: Identified 52 compute shaders that perform a confirmed OpImageWrite into an image with Dim=3D (traced per-instruction through the SPIR-V type graph, not just "file contains both a 3D image type and an OpImageWrite somewhere" — we initially had that bug and it produced 2000+ false positives from bindless-heap boilerplate type declarations shared across nearly every compute shader). Patched 49/52 (3 had non-float/uint texel types we didn't attempt) to clamp any NaN, Inf, or finite value with |x| > 10000 to 0 immediately before the write. Reasoning: random garbage bits are ~100x more likely to decode as a huge finite float than as literal NaN/Inf (~46% vs ~0.4% in a random-bit-pattern simulation), so we wanted to cover both cases.

   • Result: no change in the fog artifact.

2. Read-side check: Extended the same approach to any shader (not just compute) performing OpImageSample*/OpImageFetch/OpImageRead against a Dim=3D image, on the theory that the actual composite/"apply fog to scene" pass (likely a fragment shader sampling the finished froxel volume) might be where a NaN/huge value first gets introduced or amplified.

   • This matched 6367 of ~16000 shaders — clearly not fog-specific. We believe this reflects that UE5 has several independent systems that read 3D textures (Mesh Distance Fields, Lumen voxel data, volumetric clouds, translucency lighting volumes, in addition to fog itself), likely via a shared/inlined bindless-heap sampling pattern, so "reads a Dim=3D resource" is far too broad a signal to isolate fog specifically via static analysis alone.
   • Patched all matches anyway as a blunt test: no change in the fog artifact, but visible unrelated regressions appeared (e.g. character eye/visor shading visibly darker/different than the unpatched original — screenshot attached), confirming we were touching unrelated material shaders. We've reverted this.

3. RenderDoc: Attempted to capture a frame via ENABLE_VULKAN_RENDERDOC_CAPTURE=1 to directly inspect the fog volume texture contents (NaN overlay). The game hangs for ~5-10s and then the process dies with no capture ever produced. We suspect Easy Anti-Cheat (which The Finals uses, with Linux/Proton support) is detecting the injected capture layer and killing the process, though we don't have a 100%-confirmed log line naming EAC specifically — happy to gather more targeted logs if useful. Given the risk/cost of forcing this, we haven't pursued it further.

4. Confirmed that VKD3D_SHADER_QUIRK_*-style manual quirk hacks from an earlier (unguided) attempt were built against invented API names that don't exist in the real dxil_spv_shader_quirk enum, so that avenue was a dead end from the start (our mistake, not vkd3d-proton's).

What we suspect but can't confirm without more visibility into internals

• Possibly uninitialized/garbage memory in a fog history or scattering-accumulation resource on first use (would explain the fade-in/first-frames convergence behavior and per-map variability), rather than a math bug in any single shader's instructions — which would explain why clamping values at every write and read site we could statically identify made no difference: if the corruption enters via something other than the arithmetic we're guarding (e.g. wrong resource bound, missing barrier/synchronization causing a stale/uninitialized read that our static per-instruction guards don't cover, or a resource that's read by fixed-function/copy operations we can't intercept with shader-level patches).
• Given Pascal's known constraints on this driver stack (SPV_KHR_vulkan_memory_model / device-scope barriers, compute shader derivative fallback added in 2.12, FP16 fallback), we wonder if there's a related but distinct edge case in how coherent writes/reads to storage images are synchronized specifically for 3D image dimensionality on Pascal that isn't covered by the existing quirks.

Attachments available on request

• Full shader dump (~16k .spv files, hash-named)
• List of the 52 write-candidate hashes with scores
• PROTON_LOG output around a RenderDoc-attach attempt (shows a burst of INT3/access-violation exceptions across new threads shortly before the process dies)
• Screenshots of the artifact and of the unrelated read-patch regression

Happy to run any specific diagnostic you'd suggest (env vars, targeted shader dumps, etc.) — we've built some tooling around VKD3D_SHADER_DUMP_PATH + VKD3D_SHADER_OVERRIDE for automated candidate patching that we can point at anything you want inspected.