is there any DLSS or other Cuda stuff at work here? There's some known issues in that area, but this whole thing just seems firmly outside our control, especially if it's specific to Blackwell for some reason.
I have tested DLSS, FSR 3.1 and without any upscaling, the game would still crash no matter to what upscaling I set it to. In addition to that, no matter to which Proton version I set it to, it would still crash.
Possibly-related data point from another RTX 5060 Ti (GB206), in case it helps with doitsujin's "is there any DLSS or other CUDA stuff at work here?" question.
Driver 610.57.04, Proton Experimental (11.0), 007 First Light (D3D12). With DLSS 5 neural rendering (NGX feature 18, CUDA-backed, driven from a ReShade add-on) the game dies within about a second of the first NR evaluate:
NVRM: Xid 31, name=007FirstLight.e, MMU Fault: ENGINE GR_HOST0 HUBCLIENT_ESC0 faulted @ 0x4_06b92000.
Fault is of type FAULT_PDE ACCESS_TYPE_VIRT_READ
Earlier routes on the same card and game gave Xid 32 (corrupted push buffer), Xid 69 class 0xce97 at offset 0x2384 (SET_CONSTANT_BUFFER_SELECTOR_B) with data-like values, and Xid 13 class 0xcec0 subchannel mismatch — i.e. always a host/command-stream fault, never a timeout first. Without NR, the game runs indefinitely. NVIDIA's NR kernels and the full network run clean on this card outside a game (CUDA directly, no vkd3d), so the failure seems to need the NGX-inside-vkd3d-proton combination.
To be clear about what I didn't see: no intermapRegisterDmaMapping failures around these crashes (the only ones in my journal are a single burst on Sep 13, before any of this testing). So I can't claim it's the same VA exhaustion — just the same chip, with an unmapped-VA fault, when CUDA work is involved. Happy to run a debug build or capture anything specific (e.g. VKD3D_CONFIG=breadcrumbs) if that's useful.
proton experimentalx1 2026-09ge-proton10-32x1 2026-03VKD3D_CONFIG=breadcrumbs`)x1 2026-09VKD3D_CONFIGx1 2026-03VKD3D_CONFIG=no_dynamic_resources,no_upload_hvv,force_host_cachedx1 2026-03whgame.dllx1 2026-030xc0000005x1 2026-03
System Information
Description
KCD2 freezes (not crashes) after approximately 1 hour of gameplay. The game hangs
indefinitely — the process stays alive but the screen is frozen and the game becomes
unresponsive. Only a hard kill recovers the system.
This is reproducible regardless of graphics settings (tested Medium and lower Global
Illumination). Related to issue #2718 but differs in that it occurs at Medium GI
settings and manifests as a slow accumulation over ~1 hour rather than an immediate
freeze.
Does NOT occur on Windows with identical hardware.
Root Cause (from diagnostic logs)
GPU Virtual Address space exhaustion. VRAM mappings accumulate over ~1 hour and
are never released. Once the VA space is exhausted the NVIDIA driver fails to create
new mappings, VKD3D timeline semaphores never signal, and the game hangs waiting
for GPU work that can never complete.
VRAM grows from ~5GB at session start to ~7.2GB+ (out of 8GB total) at time of freeze,
with only ~14MB free — despite sys_budget_videomem being set to 6656MB in game config.
The overshoot confirms the leak is in VKD3D/driver resource mappings outside the game's
own budget tracking.
dmesg at time of freeze
Previous sessions also showed:
Note: Class 0000ce97 is an Ampere-generation compute engine class being issued to a
Blackwell GPU — possible class mismatch in VKD3D command generation for Blackwell.
VKD3D log at time of freeze
vr 2 = VK_ERROR_DEVICE_LOST
nvidia-smi at time of freeze
VKD3D_CONFIG used
force_host_cached was added specifically to target ErrorCode 0x04 (MMU page fault)
and did reduce frequency of that specific error but did not resolve the VA space
exhaustion.
Additional notes
stack has no issues — see also #2718)
confirmed affected per #2718
and WHGame+0x645839) also occur independently of the GPU freeze — these appear
to be a game engine threading bug unrelated to VKD3D