Hello @ragne1d, we're using one issue report per unofficially supported game title, so I've gone ahead and transferred this issue report to https://github.com/ValveSoftware/Proton/issues/8543#issuecomment-4659997084.
Thanks so much @kisak-valve. I did not know that. Sorry.
Adding data to this issue, since the environment matches closely but the
failure mode differs in one important way: here the device is explicitly
lost, rather than the process hanging with the device still alive.
| GPU | RTX 5070 Ti (Blackwell) |
| Driver | NVIDIA open 610.43.03 |
| Kernel | 7.1.3 (CachyOS) |
| Proton | cachyos-11.0-20260602-slr |
| DXVK | v2.7.1-788-g30f6f8338e3f88a |
| Compositor | KWin Wayland, native Wayland (PROTON_ENABLE_WAYLAND=1), HDR on |
Image freezes, audio stops, process stays alive and never exits. It has to be
killed. Reproduced three times in one evening, at 77 min, ~6 min and
~2 min — so time-to-failure is highly variable and it is not tied to any
particular area or action in the game.
Process state while hung — this is a spin, not a wait on I/O:
ACShadows.exe ~100-175% CPU, 80 threads, main thread futex_wait_multiple
disk read/write ZERO bytes over 10 s
RSS completely flat
GPU pinned at a constant 20% / ~40 W, never varies
err:vkd3d-proton:vkd3d_wait_for_gpu_timeline_semaphore:
Failed to wait for Vulkan timeline semaphore, vr -4.
warn:vkd3d-proton:d3d12_device_mark_as_removed:
Device ... is lost (reason 0x887a0005, "VK_ERROR_DEVICE_LOST").
err:vkd3d-proton:d3d12_command_queue_execute: Failed to submit queue(s), vr -4.
err:vkd3d-proton:d3d12_command_queue_signal_shared:
Failed to submit signal operation, vr -4.
The timeline-semaphore wait fails ~10.5 s after the last forward progress,
which looks like a GPU-progress timeout rather than a crash. After that every
submission fails and the game spins retrying forever.
1. There is no Xid. At all.
journalctl -k -b | grep -ciE 'Xid|NVRM' -> 0
Zero for the entire boot, across both failures. The kernel driver never
reported a channel fault, yet userspace was told the device was lost. If the
GPU had genuinely hung I would expect an Xid; its complete absence suggests the
loss is being signalled from somewhere above the kernel driver.
2. It is preceded by an enormous volume of descriptor-pressure warnings.
d3d12_command_allocator_allocate_meta_index:
Meta descriptor pressure! Falling back to global heap (potentially slow)
Counts per session, immediately before the device loss:
| session | time to failure | device-lost events | meta-pressure warnings |
|---|---|---|---|
| 1 | 77 min | 10 | 368,879 |
| 2 | ~6 min | 10 | 43,706 |
| 3 | ~2 min | 8 | (short session) |
Note VKD3D_CONFIG is not set here, so this is the default descriptor
path, not the opt-in descriptor_heap one. Mentioning it because a separate
report on the NVIDIA developer forums describes VK_ERROR_DEVICE_LOST via the
VKD3D-Proton descriptor heap path as a 595 → 610 driver regression (fine on
595, broken on 610), which is the same driver boundary as this machine. It may
be worth checking whether these share a root cause.
Both failures occurred with frame generation forced to maximum:
DXVK_NVAPI_DRS_NGX_DLSSG_MODE=ON
DXVK_NVAPI_DRS_NGX_DLSSG_MULTI_FRAME_COUNT=MAX
PROTON_DLSS_UPGRADE=1
PROTON_NVIDIA_NVCUDA=1
The hung process had the full Streamline stack resident — sl.interposer.dll,
sl.dlss_g.dll, sl.dlss.dll, sl.reflex.dll, sl.pcl.dll,
nvngx_dlssg.dll, nvcuda.dll — plus an sl.pacer thread. That lines up with
the Streamline-CUDA-NVAPI deadlock suspicion already raised in this thread.
Tested, and the multi-frame count is NOT the trigger:
| run | NGX_DLSSG_MULTI_FRAME_COUNT |
result |
|---|---|---|
| 1 | MAX |
device lost after 77 min |
| 2 | MAX |
device lost after ~6 min |
| 3 | 1 (2x) |
device lost after ~2 min |
Dropping from max multi-frame generation to the lowest setting did not prevent
it, and did not even delay it. So if Streamline is involved at all it is not a
function of how many frames are generated. A frame-generation-off run is
the next test and has not been done yet; that is the only configuration that
unloads sl.dlss_g.dll / nvcuda.dll entirely, and I will follow up with the
result either way.
Full Proton trace (PROTON_LOG=1, ~262 MB for the 77-minute session), the
±400-line window around the first device-lost line, nvidia-smi -q captured at
the moment of failure, and per-thread stack states while hung.
ge-proton10-34x1 2026-06proton 10.0-4x1 2026-06proton experimentalx1 2026-06proton hotfixx1 2026-06DXVK_NVAPI_DRS_NGX_DLSSG_MODE=ONx1 2026-08DXVK_NVAPI_DRS_NGX_DLSSG_MULTI_FRAME_COUNT=MAXx1 2026-08PROTON_DLSS_UPGRADE=1x1 2026-08PROTON_ENABLE_WAYLAND=1`),x1 2026-08PROTON_LOG=1`,x1 2026-08PROTON_NVIDIA_NVCUDA=1x1 2026-08VKD3D_CONFIGx1 2026-08dlss.dllx2 2026-08dlss_g.dllx2 2026-08interposer.dllx2 2026-08nvngx_dlssg.dllx2 2026-08pcl.dllx2 2026-08reflex.dllx2 2026-08nvcuda.dllx1 2026-08common.dllx1 2026-06nvapi64.dllx1 2026-06nvngx_dlss.dllx1 2026-060x887a0005x1 2026-08
Compatibility Report
System Information
I confirm:
Symptoms
Assassin's Creed Shadows hangs reproducibly on my system when loading a save and walking toward a specific city/area. The screen freezes, audio continues briefly, then stops. The process does not crash by itself and remains killable from a TTY with:
pkill -f ACShadowsThis does not look like a normal crash, OOM, or NVIDIA Xid/GPU reset. Multiple hang captures taken while the game was frozen show:
The process appears stuck in Wine/Proton waits with vkd3d-related threads involved. Repeatedly visible in the captures/backtraces:
NVIDIA Streamline / NVAPI / CUDA libraries are loaded in the process even when DLSS/frame generation are disabled or minimized in the game UI:
The hang occurs across several Proton versions:
The hang also occurs with both higher and reduced graphics settings.
Reduced settings tested:
The hang still occurred with the same route/scene. This makes it unlikely to be simply Ultra settings, high FPS, frame generation, or pure VRAM exhaustion.
Things tested / ruled out:
I also tested with Proton logging previously, but the Proton log did not show an obvious crash/error at the moment of the hang. The attached emergency captures were taken from TTY while the process was still frozen/alive.
Important NVIDIA driver note:
I attempted to test the proprietary 580xx NVIDIA DKMS driver, but the RTX 5080 refused it with:
NVRM: The NVIDIA GPU 0000:01:00.0 (PCI ID: 10de:2c02) installed in this system requires use of the NVIDIA open kernel modules.So the system was restored to NVIDIA open 610.43.02.
Main launch options used for the relevant tests:
VK_DRIVER_FILES=/usr/share/vulkan/icd.d/nvidia_icd.json VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/nvidia_icd.json %command%Reproduction
Interesting observation:
If I walk in the opposite direction from the same save, the game may not hang immediately. The issue appears route/scene/workload dependent rather than completely random. However, it can also hang later in other areas.
Attachments
I am attaching hang captures generated while the game was frozen, before killing it:
Request
Could this be investigated as a possible vkd3d-proton / NVIDIA open 610.43.02 / Streamline-CUDA-NVAPI deadlock?
The most suspicious repeated pattern is that the process does not crash but gets stuck in waits involving vkd3d fence/queue/swapchain, while NVIDIA Streamline/CUDA/NVAPI libraries are loaded, with no NVIDIA Xid, no OOM, and no segfault.
acs-emergency-2026-06-09-114150.tar.gz
acs-emergency-2026-06-09-114911.tar.gz
acs-emergency-2026-06-09-115613.tar.gz
acs-emergency-2026-06-09-120048.tar.gz
acs-emergency-2026-06-09-120507.tar.gz