Compatibility Report

I just had it crash mid-game, with https://steamdb.info/sub/1306963/history/?changeid=U:28307095. Due to https://bugzilla.redhat.com/show_bug.cgi?id=2447147#c14 and https://bugzilla.redhat.com/show_bug.cgi?id=2447146#c13, ^1 all I have elsewhere is some Abrt traces, from the FAF server, amalgamated into existing RHBZ tickets:

• https://retrace.fedoraproject.org/faf/reports/bthash/3d8a8e8d33f96e8bac01a4f023bac522fd7fa06c

• https://retrace.fedoraproject.org/faf/reports/bthash/a9144b30c6a873383f0141eede1b4da3bedf46b5

However, I've uploaded the original crash reports, too, inside ccpp-2026-05-15-16:46:.zip. I wonder whether it's due to https://discussion.fedoraproject.org/t/kde-trying-to-rename-a-file-the-name-disappears-replacing-with-the-extension-in-bold-making-it-really-hard-to-edit/183657/6.

When this occurs, my screen appears frozen. To remediate it, I disable, then re-enable, it.

I'm forced to reboot, each time I want to invoke Subnautica 2, I've realised:

A logout is insufficient, somehow.

Same thing happened to me, the solution was to use Proton 7 with no parameters or Proton Experimental with VKD3DDISABLEEXTENSIONS=VKEXTmeshshader,VKNVrawacces…"Same thing happened to me, the solution was to use Proton 7 with no parameters or Proton Experimental with VKD3D_DISABLE_EXTENSIONS=VK_EXT_mesh_shader,VK_NV_raw_access_chains %command%
It's a bug exclusive to RTX 5000 GPUs

OS: Fedora Linux 44 (KDE Plasma Desktop Edition) x86_64
Kernel: Linux 7.0.6-200.fc44.x86_64
CPU: AMD Ryzen 9 9950X3D (32) @ 5.76 GHz
GPU 1: NVIDIA GeForce RTX 5090 [Discrete]
GPU Drivers: 595.71.05

Game crashes on experimental regardless using gamescope unless I use the following parameters on launch:
VKD3D_DISABLE_EXTENSIONS=VK_EXT_mesh_shader,VK_NV_raw_access_chains %command%

In retrospect, discussion.fedoraproject.org/t/191627, which describes a significantly worse effect, than what I have previously described, may also be a direct consequence of the game (and/or Proton's emulation, thereof). Some relevant logs are undermentioned:

• bootstrap_log.previous.txt

• bootstrap_log.txt

• cef_log.previous.txt

• client_networkmanager.txt

• cloud_log.previous.txt

• cloud_log.txt

• compat_log.previous.txt

• connection_log_7777.txt

• connection_log.previous.txt

• console_log.previous.txt

• console_log.txt

• console-linux.previous.txt

• content_log.previous.txt

• content_log.txt

• controller_ui.txt

• controller.txt

• gameprocess_log.txt

• inventory_service_log.txt

• librarysharing_log.txt

• parental_log.txt

• remote_connections.previous.txt

• remote_connections.txt

• shader_log.txt

• sitelicense_log.txt

• stats_log.txt

• steam_api_log.txt

• steam-runtime-system-info-1765668915.txt

• steam-runtime-system-info-1778857189.txt

• steamsysinfo.txt

• steamui_audio.previous.txt

• steamui_audio.txt

• steamui_html.previous.txt

• steamui_librarycache.previous.txt

• steamui_librarycache.txt

• steamui_login.previous.txt

• steamui_login.txt

• steamui_update.txt

• steamui.txt

• streaming_log.txt

• systemdockmanager.txt

• systemperfreporting.txt

• text_filter_log.txt

• timedtrial_log.txt

• updateui_child.previous.txt

• webhelper_gpu.previous.txt

• webhelper-linux.txt

• webhelper.previous.txt

• workshop_log.txt

Should this be reported at steam-for-linux/issues? Not all are intact, per .part.zip…

Sometimes hangs on start-up. (Black screen, except for the “busy” indicator at the lower right corner.)

Telling Steam to kill the running instance doesn't function correctly: the game continues in its stuck state and needs to be killed in another way, which I've semi-automated with

kill $(ps ax | grep Win64-Ship | awk '{ print $1; exit }')

(I note that the devs are aware of a start-up hang on Steam Deck. They have a workaround based on forcing display refresh rate, which is interesting because I have the game window on a Freesync screen.)

steam-1962700.log.gz

It's a bug exclusive to RTX 5000 GPUs

@BoxGod14, it can't be, because mine is from AMD.

Confirming the VKD3D_DISABLE_EXTENSIONS=VK_EXT_mesh_shader,VK_NV_raw_access_chains workaround. Same driver version as the earlier RTX 5090 report in this thread, so not fixed in 595.71.05.

• GPU: NVIDIA GeForce RTX 5090 (Blackwell)
• NVIDIA driver: 595.71.05
• OS/Kernel: Fedora 44 / Linux 7.0.4-200.fc44.x86_64
• Proton: Experimental (2026-05-20), fresh prefix
• Game build: Subnautica 2 CL-113933 (build 53, packaged 2026-05-18)

Without the workaround: DXGI_ERROR_DEVICE_REMOVED ~5s after the loading screen appears (during the first frame's SkyLight real-time capture). With it: launches cleanly to main menu and lobby join.

The underlying vkd3d-proton issue (mesh shader / VK_NV_raw_access_chains path on Blackwell) may warrant its own upstream report at HansKristian-Work/vkd3d-proton, since this thread mixes the AMD launcher-freeze symptom (OP) with the NVIDIA Blackwell GPU hang.

I have a 7900 and mesa 26.1.4

For me the game crashes randomly after an undefined amount of playtime with
Illegal opcode in command stream.
Setting VKD3D_DISABLE_EXTENSIONS=VK_EXT_device_generated_commands helps, ever since I've set it I haven't crashed in a long time. I'll update this comment if it still crashes with this variable set in the future.

Confirming @NeoTheFox's report on a second RDNA3 card: random mid-game GPU hang with Illegal opcode in command stream. In my case the gfx ring reset also failed, so the driver fell back to a full MODE1 GPU reset — VRAM was lost and the whole desktop session (Cinnamon) crashed with it, requiring a hard reboot.

System

• GPU: AMD Radeon RX 7600 (Navi 33, RDNA3)
• OS: Linux Mint 22.2, kernel 6.14.0-37-generic
• Mesa: 25.2.8-0ubuntu0.24.04.2 (RADV)
• Proton: 11.0-100
• Game: Subnautica 2 (1962700)

Kernel log at the time of the crash

kernel: amdgpu 0000:2d:00.0: amdgpu: ring gfx_0.0.0 timeout, signaled seq=6276337, emitted seq=6276339
kernel: amdgpu 0000:2d:00.0: amdgpu: Process information: process GameThread pid 21671 thread vkd3d_queue pid 21737
kernel: amdgpu 0000:2d:00.0: amdgpu: Starting gfx_0.0.0 ring reset
kernel: [drm:gfx_v11_0_bad_op_irq [amdgpu]] *ERROR* Illegal opcode in command stream
kernel: amdgpu 0000:2d:00.0: amdgpu: Ring gfx_0.0.0 reset failure
kernel: amdgpu 0000:2d:00.0: amdgpu: GPU reset begin!
kernel: amdgpu 0000:2d:00.0: amdgpu: MES failed to respond to msg=REMOVE_QUEUE
kernel: [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
kernel: [drm:gfx_v11_0_cp_gfx_enable.isra.0 [amdgpu]] *ERROR* failed to halt cp gfx
kernel: amdgpu 0000:2d:00.0: amdgpu: MODE1 reset
kernel: amdgpu 0000:2d:00.0: amdgpu: GPU reset succeeded, trying to resume
kernel: [drm] VRAM is lost due to GPU reset!

The crash happened mid-game after an extended play session, not at startup — so this looks distinct from the launcher-freeze symptom in the OP and the NVIDIA Blackwell startup crash, and matches the RDNA3 mid-game hang.

I'm now testing the VKD3D_DISABLE_EXTENSIONS=VK_EXT_device_generated_commands %command% workaround and will report back if the crash recurs with it set.

@cgillinger ever since I've reported it I've played around with debugging some more, and I figured this fix was better than no fix, but still allowed for some crashes. If it's going to be the same for you - this is what solved crashes for good - VKD3D_CONFIG=single_queue
There's a race condition somewhere in VKD3D. This does lower the performance somewhat, but you can get virtually all of it back by using OptiScaler to swap DLSS for FSR4 with frame generation.

@NeoTheFox Thanks — that matches what I was hoping to learn before hitting the crash again. I've now set both on my RX 7600:

VKD3D_CONFIG=single_queue VKD3D_DISABLE_EXTENSIONS=VK_EXT_device_generated_commands %command%

keeping the DGC disable alongside single_queue since they address different mechanisms and a crash on my setup is expensive — the failed ring reset escalates to a full MODE1 reset that kills the whole desktop session.

A race condition in vkd3d-proton's queue handling would also explain why the crashes are random rather than tied to a specific scene. If that's confirmed, this probably deserves an upstream issue at HansKristian-Work/vkd3d-proton for the RDNA3 symptom specifically, since this thread is already tracking three distinct problems.

One note on the performance recovery tip for anyone else reading: FSR4 officially requires RDNA4, so on RDNA3 cards like mine OptiScaler with FSR 3.1 + frame generation is the realistic route instead.

I'll report back after a few longer sessions with single_queue set.

@cgillinger I have great news for you - since not so long ago FSR4 is supported on RDNA3, though being somewhat more expensive it's still gives you better visuals and makes good use of that extra performance left on the table by single_queue.
I suggest proton-cachyos so you can try FSR4_UPGRADE=1 PROTON_USE_OPTISCALER=1 for ease of testing. Having both VK_EXT_device_generated_commands and single_queue is superfluous.
I'd love to file a bug with VKD3D but that leads me to how I discovered this is a race condition - trying to get RADV_DEBUG=hang just solved the issue since it forces order. So I have nothing, and breadcrumbs also yields nothing. I do not know how to proceed.

@NeoTheFox Thank you — that's genuinely great news about FSR 4.1 on RDNA3, and I really appreciate you taking the time to share your debugging journey here. It's saved me (and probably others) a lot of trial and error. One small note for anyone else trying the CachyOS route: I believe the variables are spelled PROTON_USE_OPTISCALER=1 PROTON_FSR4_UPGRADE=1. You're right that my double workaround is redundant — I'll trim down to just VKD3D_CONFIG=single_queue once I've had a few stable sessions to compare against, and I'm looking forward to trying the FSR4 route after that.

On the vkd3d-proton question — I'm far from an expert here, so take this with a grain of salt, but I wonder if what you've found is already worth reporting as-is? The way I read it, "RADV_DEBUG=hang makes the crash disappear because it forces ordering" isn't a failed repro so much as a data point: combined with single_queue fixing it permanently, it seems to point fairly specifically at synchronization between queue submissions. My impression is that upstream has triaged timing-dependent issues before without a deterministic repro, and they may well know exactly which instrumentation to ask for next. Between the two of us we could offer:

• The symptom: random Illegal opcode in command stream on RDNA3 (7900 and 7600 confirmed in this thread), mid-game, scene-independent.
• Full amdgpu dmesg from the hang. If I understand correctly, recent kernels also produce a devcoredump (/sys/class/devcoredump/) at reset time, which captures ring state passively — so it might sidestep the heisenbug problem, though I haven't verified this myself.
• Game (Subnautica 2, 1962700, UE5), Proton and Mesa versions from two independent systems.

Of course, you've dug far deeper into this than I have, so you're in a much better position to judge. But if you do decide to file it, please tag me or link it here — I'd be glad to add my logs and hardware details to the report.

@cgillinger I'll consider reporting once you'll confirm it's fixed for you too and my findings are correct.
As for PROTON_FSR4_UPGRADE=1 - since the last release it does nothing, and they haven't updated their README yet in the master branch, if you'll look at releases you'll see the description of the new variables and changes.

I'll try to put in a few sessions the next few days!

Has anyone tried Proton Experimental Bleeding Edge? I've had that resolve issues that even the latest GE or Cachy Proton couldn't solve!

@NeoTheFox Following up as promised: I can now confirm stability with VKD3D_CONFIG=single_queue. Three sessions since setting it (July 18, 20 and 21, roughly 2 hours of play in total) — zero GPU hangs, clean exits every time, and nothing from amdgpu in the kernel log. Same setup as before: RX 7600 (Navi 33), Mesa 25.2.8, kernel 6.14.0-37, Proton 11.0-100, Linux Mint 22.2. So from my side the single_queue workaround looks solid — happy to provide logs if you file this upstream.

@Hoff16 I haven't tried Bleeding Edge myself — for me the vkd3d queue race seems fully worked around by single_queue on stable Proton 11.0-100, so I've stayed on that to keep the data point clean.