Good catch, thanks for the correction—`no_subgroups` was just an arbitrary flag passed while testing that was obviously ignored.
After isolating the options individually, the exact flag that fixes the launch is:
\`VKD3D_CONFIG=single_queue\`
This points directly to a regression in driver 615.71.09 regarding multi-queue / async compute allocation during \`vkCreateDevice\`
(returning `vr -3`).
Coupled with the native Wayland EGL crash (\`NVRM: VM: invalid mmap context\`), both issues disappeared immediately after downgrading
Just to expand on my report from a bit back, this appears to be a wider display issue than just sleep related to DisplayPort functionality with 615.
This weekend I was attempting to get some work done on odd hours, but also watching football on my PC. I attempted to use the Picture in Picture (split view) mode of my Display (Odyssey G95C): 5120x1440 in 49", 240 Hz [External] even though sleep is now disabled to get around this bug. Going from the input of HDMI 2 (active working on the work dock/Macbook) to a split of HDMI 2 and DP 1 (which has worked before without issue) the request for the DP and resolution change produced the same black screen (never a display, Samsung monitor detects no input, never recovers from black screen).
This behavior then carried over when turning PIP mode off, attempting to switch over to DisplayPort proper, the same unrecoverable/no input detected black screen then persisted. The only way to reset this was a hard power off, similar to the sleep/no recovery state myself and others have reported.
Not sure if this addition helps at all, but it appears to be any change state to DP (wake state or otherwise) is no longer producing valid output to the monitor over the DP channel. Sleep causes this reliably, but other selection changes that produce similar change/wake events also appear impacted.
Running 007 First Light with Path Tracing enabled freezes the game at random points with Xid 109 CTX SWITCH TIMEOUT error. I’m currently on the The Past Never Dies (Mauritania) mission in the market area, and the game keeps freezing at random times and in different places. It may freeze after an hour of gameplay, or it may freeze in the first 10 seconds.
All graphics settings on Ultra, Path Tracing on Medium. DLSS Performance, Frame Generation off. GE-Proton 11-7.
I can confirm that I have this issue. I spend the majority of my day in PIP (3x3). The monitor wakes up 99% of the time. But when Ii switch to DP fullscreen, I’m greeted with a black screen after I come back from it being idle. As mentioned, the only fix is to press the power button to turn it back and even then its not 100%.
I also have found that if you move your mouse around for about 1 minute that it will sometimes come back on its own. Very strange but worth testing.
I was able to recover after fiddling around with the monitor’s power settings in the OSD by switching it back and forth from Standard Mode and Power Savings. It took like 3 or 4 tries to get the connection to come back but fortunately it did. However, sometimes the drop in connection crashes my monitor and the OSD will not pull up so a shutdown is the only way to bring things back.
Recurring slowdowns with 615: follow-up with results from additional testing
I did some additional testing concerning the recurring slowdowns with nvidia-open 615.71.09 in Gothic 1 Remake (see screenshots and description in original post).
The stalls do not occur in Shadow of the Tomb Raider which might indicate that it could be a regression with 615 affecting either specifically Gothic 1 Remake or UE5-based games (I don’t have other UE5 titles available to test though). Since rolling back to 610 completely solves the issue it must be something 615 does differently.
It is (in my case) independent of DLSS. I can now confirm that the stalls also occur with DLSS disabled in-game.
It is unrelated to thermal throttling.
VRAM is not saturated, neither is RAM.
It only occurs when GPU load as shown by MangoHud is above ~95%.
GPU load (MangoHud, also btop) does not drop during the slowdowns.
It happens both with NTSync or FSync.
Already mentioned this, but it happens both on Proton Experimental and Proton-CachyOS. Game is launched from Steam. Enabling Wayland in Proton-CachyOS did not make any difference. Otherwise empty launch command except MangoHud (but also launching without MangoHud didn’t have any effect).
It is not insufficient performance. The GPU can maintain stable 30 fps with 610. The effect does not feel like dropped frames but rather like slowdowns (a bit like rubber-banding) as if it was some sort of synchronization or queuing issue.
It occurs with fps capped (to 30, using MangoHud) and uncapped.
TL;DR: I think it is a regression of 615 that I was only able to reproduce in Gothic 1 Remake as of now, while it didn’t occur in SOTR (which is also DX12/vkd3d-proton) or other, less-demanding titles.
I hope the additional observations from this post are helpful for tracking down and eventually solving the issue.
Guys I have a issue as well. I’m on the latest Nvidia open drivers on a fully up to date arch system and when I try playing Euro Truck Simulator 2, it works smoothly until it suddenly crashes the game and sometimes the entire environment and I have to hard reboot the whole pc. I play on a 5070 on max graphics and it really works smooth until it crashes. Also, the crashes happen at completely random time after I start the game, sometimes I can complete half deliver sometimes I can barely reach the main menu. This issue persisted across multiple games and platforms such as War Thunder.
Specifications:
OS - Arch Linux
DE - KDE Plasma
Window Manger - Wayland
CPU - Ryzen 7 9700X
GPU - RTX 5070
I will also provide a screenshot with the crash the journalctl -k shows:
do you use an amd cpu? have you tried disabling the iGPU? I’ve been playing deadlock for a bit on 615 (multiple matches on wayland proton ge 11.8) and had 0 issues, everything is fine.
Reporting a GPU hang / context timeout I ran into on driver 615.71.09 while playing God of War Ragnarök on Steam.
What happened:
After about 30–35 minutes of gameplay, the screen froze completely. Audio kept playing for a few seconds before cutting out, and the window became unresponsive until I had to kill it with Alt+F4.
Checking dmesg / journalctl right after, the kernel logged an Xid 109 (CTX SWITCH TIMEOUT) on the game executable:
NVRM: GPU at PCI:0000:07:00: GPU-20b829fe-f1ff-cde3-04a0-e11e6b345ff9
NVRM: Xid (PCI:0000:07:00): 109, pid=7276, name=GoWR.exe, channel 0x00000014, errorString CTX SWITCH TIMEOUT, Info 0x13c01c
System Specs:
GPU: NVIDIA GeForce RTX 4070 (12GB)
Driver: 615.71.09
OS: CachyOS (Kernel 7.2.7-1-cachyos)
Desktop / Display Server: KDE Plasma (Wayland)
Runner: Steam Proton Experimental
Relevant In-Game Settings:
Resolution: 1080p Fullscreen
Upscaler: DLSS (Set to DLAA)
NVIDIA Reflex: Enabled + Boost (reflex_boost)
Textures: Ultra
Frame Generation: Off
Suspecting it might be a scheduling or command buffer hang between VKD3D-Proton and the driver when Reflex Boost is engaged under heavy VRAM load.
Also has an AMD Raphael iGPU; the game runs on the NVIDIA GPU
Game: Monster Hunter Wilds (Steam 2246340), GE-Proton11-5 (D3D12 via vkd3d-proton)
Issue
The GPU hangs every time at the same spot in the game (Windward Plains, area 12). vkd3d-proton reports VK_ERROR_DEVICE_LOST and the game crashes. The kernel logs an Xid 109 for every crash:
It happened 11 times in one session, always Xid 109 with slightly different Info values (0x11c025, 0xbc027, 0xfc027, 0x25c027, 0xbc029, 0x34c029, 0x27c029).
Turning off DLSS, frame generation and async compute (UseComputeQueuePairing=Disable) made no difference.
Regression
Downgrading to 610.57.04 fixes it completely, with the same game, Proton version and settings. The kernel was also rolled back from 7.2.8 to 7.1.8, because the CachyOS module package ships with the kernel.
Bug report
nvidia-bug-report.log.gz is attached. It was captured after downgrading to 610.57.04, so it shows the working setup rather than the crash. Personal info (MAC/IP addresses, serial numbers, UUIDs, username) was removed.
I have the same issue in Ubuntu with a 3090. I’ve been living with a similar issue with 610 where I needed to CTRL-ALT-F1 then CTRL-ALT-F2 to bring up the display every day after locking the night before. Today this does not work at all. I turned my monitor off last night instead, but this did not make things better as my screen still refused to wake this morning until I rebooted my system. Maybe some of that fancy AI NVIDIA loves so much fix the problem!
