For me usually on the 2nd try of starting a new game it does not disconnect.

The main issue I run in to is that the game gets stuck on the loading screen when resuming the campaign. It runs fine until I quit the game, after which I become unable to resume the campaign. I can however still start a new game.

steam-2183900.log

Update: I think I found a workaround, disabling internet seems to allow me to launch a solo game.

The game also crashes any time I receive a Steam achievement.

Update 2: Actually, maybe the disabling internet trick does not work, and I just got lucky a few times.

Update 3: Disabling the Steam overlay solves the crashing issue. I managed to do a full playthrough with this workaround. Game may still crash on shutdown but otherwise works fine.

Just to be sure, you have the Proton EasyAntiCheat runtime installed, right?

Just to be sure, you have the Proton EasyAntiCheat runtime installed, right?

Sure, the install script will add it either way if you don't (my mistake this is false, the runtime isn't automatically installed). FWIW I can run other EAC games fine - Elden Ring and Hunt: Showdown from what I have installed atm. I guess I can try reinstalling the whole thing. You can run the game I presume?

For me usually on the 2nd try of starting a new game it does not disconnect.

Interesting. I'm getting 100% failure rate, always in the same spot when the camera shows the green goo cannister. Tried with various Proton versions probably 20 times.

I've cleaned the prefix and reinstalled EAC runtime but unfortunately the "Failed to connect" problem persists 😢
The install script for the game seems to correctly set up both EAC and EOS as far as file structure, although I couldn't find any specific logs from the process. FWIW I've also connected the game to the PROS account, seems that can't be easily disconnected again - might or might not be related.

At this point I'm out of ideas, hopefully someone chimes in. The perks of early access on Linux 😄

Replying to https://github.com/ValveSoftware/Proton/issues/8072#issuecomment-2332663938

I was looking into getting regular version but it looks like the game devs didn't put on the game page that it uses Epic Online Service (Lots of bad reviews because of that) so maybe Steam wouldn't install it automatically, but if you are playing Hunt, you should have installed.

So for me using GE-proton 9-4 and turning cross play off under Game settings seems to make everything work fine.

started a new game and saw no disconnect message

Disabling Steam Overlay works! 🥳

(Settings > In Game > uncheck Enable Steam Overlay while in-game)

Finally could give it a try, and as the others, needed to disable Steam Overlay to make it work (Suck, because this games deserves getting some screenshots...) and crashing when closing it, have to stop it from the Steam client

This game seem to also affected by https://github.com/HansKristian-Work/vkd3d-proton/issues/1406.
launching the game with VKD3D_CONFIG=no_upload_hvv %command% have ~20% fps improvement for me.

Can confirm a performance improvements with that flag! :D

Can confirm a performance improvements with that flag! :D

didn't work here, on windows the difference is 30% , but i think the issue is the nvidia linux driver and directx 12 , not really related to proton.

I've encountered another issue with space marine 2. For some reason when certain light sources are present on screen, weird green and red artifacts can be spotted on the edge of the screen when moving the camera. Here is a video displaying the issue.

My specs:

• OS: Nixos unstable branch
• Kernel: 6.10.9 default
• Mesa: 24.2.2
• Compositor: Hyprland v0.42
• GPU: Sapphire 7900XTX pulse
• CPU: 7800X3D
• RAM: 2x16GB 6000Mhz CL 30

• OS: NixOS 24.05.20240907.68e7dce (Uakari) x86_64
• Host: ASUSTeK COMPUTER INC. TUF GAMING X570-PLUS (WI-FI)
• Kernel: 6.6.49
• Uptime: 2 hours, 7 mins
• Packages: 1466 (nix-system), 1379 (nix-user)
• Shell: bash 5.2.32
• Resolution: 1920x1080, 2560x1440, 1920x1080
• WM: sway
• Terminal: WezTerm
• CPU: AMD Ryzen 9 3900X (24) @ 4.000GHz
• GPU: AMD ATI Radeon RX 7900 XT/7900 XTX/7900M
• Memory: 10634MiB / 128724MiB
• ✦ ❯ glxinfo | grep "OpenGL version" prints "OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.0.7"

the game launches but once the cutscenes stop and I'm about to be handed control over character the game freezes with weird graphical artifacts

Replying to https://github.com/ValveSoftware/Proton/issues/8072#issuecomment-2349260726

looks like we have similar GPU + nixos, might that be some configuration problem with nixos?

Haven't seen any weird artifacts on the prologue and first level on:

7800X3D + 7800XT
Arch + Gnome + Mesa 24.2.2

Or at least didn't notice, but I see the last messages are all about artifacts and using Nixos, maybe something related to how mesa is build there? Are you using Proton Experimental?

Replying to https://github.com/ValveSoftware/Proton/issues/8072#issuecomment-2350138190

yeah it's proton experinental. tbh its a pretty fresh install, im still trying to figure out how it's configured, i might be missing something

✦ ❯ glxinfo | grep "OpenGL version"
OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.0.7

✦ ❯ glxinfo | grep "OpenGL version" OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.0.7

That's kinda outdated mesa

Replying to [#8072 (comment)](https://github.com/ValveSoftware/Proton/issues/8072#issuecomment-2349260726)

looks like we have similar GPU + nixos, might that be some configuration problem with nixos?

Cant say, I havent changed anything bout my mesa config. This would be my config.

Haven't seen any weird artifacts on the prologue and first level on:

7800X3D + 7800XT Arch + Gnome + Mesa 24.2.2

Or at least didn't notice, but I see the last messages are all about artifacts and using Nixos, maybe something related to how mesa is build there? Are you using Proton Experimental?

I mainly see the artifacts when moving the camera, I thought maybe my GPU might be dying, but I experience no such artifacts in other heavy games. They only appear during fast mouse movement and only in indoor areas where warm light sources are present.

Haven't seen any weird artifacts on the prologue and first level on:
7800X3D + 7800XT Arch + Gnome + Mesa 24.2.2
Or at least didn't notice, but I see the last messages are all about artifacts and using Nixos, maybe something related to how mesa is build there? Are you using Proton Experimental?

I mainly see the artifacts when moving the camera, I thought maybe my GPU might be dying, but I experience no such artifacts in other heavy games. They only appear during fast mouse movement and only in indoor areas where warm light sources are present.

Have no idea of Nix, you sure you using RADV and not AMDVLK right? I saw the env var to be setted correctly, but also AMDVLK installed?

Reply to https://github.com/ValveSoftware/Proton/issues/8072#issuecomment-2351557454

AMDVLK is currently disabled on my system, games are running through mesa/RADV.

Replying to https://github.com/ValveSoftware/Proton/issues/8072#issuecomment-2350082785

Got the exact same issue:
OS: Arch Linux
Host: ASUSTeK COMPUTER INC. ROG STRIX B650E-I GAMING WIFI
Kernel: 6.10.10-1-cachyos
Mesa: 24.2.2
Resolution: 2560x1440
WM: KWin
CPU: AMD Ryzen 7 7800X3D
GPU: AMD ATI Radeon RX 7900 XT/7900 XTX/7900M
Memory: 12176MiB / 64015MiB

For the moment got it to work switching to AMDVLK instead of RADV.

This game seem to also affected by HansKristian-Work/vkd3d-proton#1406. launching the game with VKD3D_CONFIG=no_upload_hvv %command% have ~20% fps improvement for me.

Adding that flag has no affect for me on my Nvidia 3090 with Proton Experimental.

I am also getting a long hang and then crash whenever I quit the game. Most of the time I get this dialog message.

Other times I get the crash reporter.

Replying to https://github.com/ValveSoftware/Proton/issues/8072#issuecomment-2357723450

To me on AMD game always crashes on exiting, have to stop it from the steam client. That flag helped me somehow for the game to make better usage of my CPU and GPU, if you were already CPU bounded it probably won't do anything.

I finished the campaign, what a bummer not to have the Steam Overlay, I would just non-stop make screenshots of it

To me on AMD game always crashes on exiting, have to stop it from the steam client. That flag helped me somehow for the game to make better usage of my CPU and GPU, if you were already CPU bounded it probably won't do anything.

The flag is for CPU bound. It trade gpu performance with cpu performance for some game, and it is for disabling rebar in vkd3d.

Check the issue https://github.com/HansKristian-Work/vkd3d-proton/issues/1406 for more information.

After 3.0 patch game doesn't playable in online mode. Looks like EGS services do not work anymore.

Online doesn't work on Proton 9.0-3 or Experimental or latest Proton-GE

After 3.0 patch game doesn't playable in online mode. Looks like EGS services do not work anymore.

Online doesn't work on Proton 9.0-3 or Experimental or latest Proton-GE

Not sure if because of not connection to EGS at all or if something fixed on the update, but the game is exiting fine now at least...

After 3.0 patch game doesn't playable in online mode. Looks like EGS services do not work anymore.

Online doesn't work on Proton 9.0-3 or Experimental or latest Proton-GE

Sigh.... Here they go again. It's really frustrating honestly. I was so excited for the new patch.

Steps I've taken:

• Proton Experimental, 9.0-3, GE 9-13. Will test bleeding edge and GE 9-14. Edit: GE 9-14, Experimental bleeding edge and Hotfix have same result. First launch after a prefix change results in immediate crash, second launch goes to menu fine. All testing with Steam Overlay disabled since that's the only way the game would work before.
• Verifying integrity (EAC file updated)
• Run through gamescope (same issue)
• Disabled crossplay from in game menu (initially the option was greyed out, then I managed to change it but it wasn't clear whether it had an effect)
• Linked Epic Games Account in game (recognised my account and enabled the Epic overlay but did not affect ability to connect to online server)

Running OpenSUSE Tumbleweed, everything up to date.

Look like AVF error is not linux only problem.
There are few message said they have this error on windows example.

Most seem to be on linux/steam deck though.

Looks like everything that using online features doesn't work. Even PROS account. EGS account doesn't work too. PROTON_LOG=1 says nothing. Maybe there is another way to get some information.

I'm not sure if this is a good moment to get more info on the Steam Interface with the game, now the game can boot with the interface enabled, but it will just freeze when trying to open it

There's a bug report on their forum for the AVF error. Please upvote/comment if you're experiencing the same issue

https://community.focus-entmt.com/focus-entertainment/space-marine-2/bugs/2517-connection-error-error-code-avf?page=1

Am also getting the AVF error, unable to use online play.
proton log: steam-2183900.log
sysinfo: https://gist.github.com/zaggynl/4d4649e98bcf1cf7b32a4945d6dec148

Update:

The response from the developer in the next message addresses the issues originally raised in this post now.

Dev just posted a announcement on discord that the issue linux/steam deck will be fixed next patch.

Regarding the black screen issue occurring on Oceania servers:

We are aware of it, the dev teams are on the matter at the moment.
We'll let you know when we get a fix.

For the Linux/Steam Deck issue:

The next patch should fix the launch issue on Linux and Steam Deck.

<@&1242516345237798942>

Discord link

Replying to https://github.com/ValveSoftware/Proton/issues/8072#issuecomment-2393686524

No expected date for that patch?

@alosarjos Nope, just this.
No date yet.

Hotfix 3.1 is released.steam link.

Space Marine 2 - Hotfix 3.1
Hello Space Marines!

We just pushed a small hotfix that brings various fixes. Thank you for your support!

Patch Notes

Fixed several crashes
Fixed heavy stutters on some CPUs
Fixed launch issue on Linux and Steam Deck
Fixed issue with dynamic resolution and ultrawide screens
Fixed issue with upscalers using wrong resolution parameters

Edit: Still getting AVF error. verifying game files.

Edit 2: Still getting AVF.

Edit 3:Adding env SteamDeck=1 seem to fix the online issue.From steam discussion

Yeah I just tried booting up in my lunch break. It works with the SteamDeck=1 variable. I can also run it alongside in gamescope by putting the variable in first. My env is SteamDeck=1 gamescope -h 1440 -r 165 --force-grab-cursor -- %command%

It's not the greatest fix, but it works I guess.

Edit: Note that the variable also sets all your in game settings to those optimised for the Steam Deck. If you were running on high graphics settings, they'll be turned down very low. I also don't know about people using Nvidia systems. There may be issues with DLSS, but I can't test this because I have an AMD GPU.

Works for me, and as previously said graphics are effectively nerfed...

Edit: Note that the variable also sets all your in game settings to those optimised for the Steam Deck. If you were running on high graphics settings, they'll be turned down very low. I also don't know about people using Nvidia systems. There may be issues with DLSS, but I can't test this because I have an AMD GPU.

DLSS works fine and AFAICT setting graphics settings back to ultra works, but will shoot out a warning about VRAM when doing so.

EDIT: It seems to be a Manjaro Problem: https://forum.manjaro.org/t/steam-games-wont-launch-after-2024-10-10-stable-update/169230
If someone has a solution, I will be happy anyways.

Unfortunality, the game does not work for me.

I only get a black screen and the game seems then to block my hole PC.
When I use gamescope with: SteamDeck=1 gamescope -h 1440 -r 165 --force-grab-cursor -- %command% as suggested by @LazyWings the game also just produces a black screen, but at least I can use my computer after the failed start attamped without rebooting.

I tried so far:

• Proton Experimental
• Proton 9.03
• Proton GE 9-15
• All with and without SteamDeck=1 %command

Computerinformationen:
Hersteller: Micro-Star International Co., Ltd.
Modell: X570-A PRO (MS-7C37)
Formfaktor: Desktop
Touch-Eingabe nicht erkannt
Prozessorinformationen:
CPU-Hersteller: AuthenticAMD
CPU-Marke: AMD Ryzen 7 5800X 8-Core Processor
CPU-Familie: 0x19
CPU-Modell: 0x21
CPU-Stepping: 0x2
CPU-Typ: 0x0
Geschwindigkeit: 4851 MHz
16 logische Prozessoren
8 physische Prozessoren
Hyper-Threading: Unterstützt
FCMOV: Unterstützt
SSE2: Unterstützt
SSE3: Unterstützt
SSSE3: Unterstützt
SSE4a: Unterstützt
SSE41: Unterstützt
SSE42: Unterstützt
AES: Unterstützt
AVX: Unterstützt
AVX2: Unterstützt
AVX512F: Nicht unterstützt
AVX512PF: Nicht unterstützt
AVX512ER: Nicht unterstützt
AVX512CD: Nicht unterstützt
AVX512VNNI: Nicht unterstützt
SHA: Unterstützt
CMPXCHG16B: Unterstützt
LAHF/SAHF: Unterstützt
PrefetchW: Nicht unterstützt
Betriebssystem:
"Manjaro Linux" (64 Bit)
Kernel-Name: Linux
Kernel-Version: 6.11.2-4-MANJARO
X-Server-Anbieter: The X.Org Foundation
X-Server-Release: 12101013
X-Fenstermanager: KWin
Steam-Laufzeitversion: steam-runtime_0.20240806.97925
Grafikkarte:
Treiber: AMD AMD Radeon RX 6800 XT (radeonsi, navi21, LLVM 18.1.8, DRM 3.59, 6.11.2-4-MANJARO)
Treiberversion: 4.6 (Compatibility Profile) Mesa 24.2.4-arch1.0.1
OpenGL-Version: 4.6
Desktopfarbtiefe: 24 Bit per Pixel
Monitor-Bildwiederholfrequenz: 165 Hz
Anbieterkennung: 0x1002
Gerätekennung: 0x73bf
Revision nicht gefunden
Anzahl Monitore: 1
Anzahl logische Grafikkarten: 1
Prim. Anzeigeauflösung: 2560 x 1440
Desktopauflösung: 2560 x 1440
Primäre Anzeigegröße: 27.44" x 15.43" (31.46" diag), 69.7cm x 39.2cm (79.9cm diag)
Primärer VRAM: 16384 MB
Soundkarte:
Audiogerät: USB Mixer
Arbeitsspeicher:
RAM: 32016 MB
VR-Hardware:
VR-Headset: Nicht gefunden
Sonstiges:
UI-Sprache: Deutsch
SPRACHE: de_DE.UTF-8
Verfügbarer Festplattenspeicher insgesamt: 937498 MB
Größter freier Festplattenspeicherblock: 270551 MB
Speicherplatz:
Anzahl SSDs: 3
SSD-Größen: 1000G,1000G,500G
Anzahl Festplatten: 0
Anzahl der Wechseldatenträger: 0

Replying to https://github.com/ValveSoftware/Proton/issues/8072#issuecomment-2405735800

Hi - sorry, I've been busy so not been able to respond, but you found out it was a Manjaro/Arch problem unrelated to this. Hopefully that's resolved now. In future, you could maybe try the flatpak version of Steam if you run into any issues like that, until they get resolved.

More generally, I wanted to comment that the command I put is what works for me! I'm hoping most people know this but I know some people might just run into an issue and randomly start throwing out commands and environments they've copy pasted. I was quickly trying to get the game to work during my lunch break that day so just rushed out a response. I should have probably put: SteamDeck=1 gamescope [options] -- %command%.

For those that don't know:

• -h sets the internal resolution height, defaulting to 16:9 if -w is undefined.
• -r sets the gamescope refresh rate. So that means my monitor is 1440p with 165hz refresh rate. You can launch gamescope at higher internal resolutions and such, but you'll just be wasting resources.
• --force-grab-cursor is something I use specifically for Space Marine 2 because there's a bug with multimonitor that breaks the cursor grab. I can still change window and free my cursor, but this just prevents the bug. I recommend it for SM2.
• You can also add other commands, see gamescope --help in a terminal for a full list.

I also should have clarified that the variable sets your graphics settings to what it considers Steam Deck optimised, but you can change it to whatever you want. I just didn't know whether it disabled DLSS or not, but seems like it just works and correctly recognises your graphics drivers, so it's all good.

Steam overlay is the only major outstanding issue for this game on Linux I believe. Which is weird because the Epic Games overlay works if you link your account.

Steam Deck LCD
SteamDeck=1 %command%
GE-Proton9-15
"SteamOS Holo" (64 bit)
Kernel Name: Linux
Kernel Version: 6.5.0-valve21-1-neptune-65-g33487bf05ed3
X Server Vendor: The http://X.Org Foundation
X Server Release: 12101011
X Window Manager: KWin
Steam Runtime Version: steam-runtime_0.20240806.97925
Video Card:
Driver: AMD AMD Custom GPU 0405 (radeonsi, vangogh, LLVM 16.0.6, DRM 3.57, 6.5.0-valve21-1-neptune-65-g33487bf05ed3)
Driver Version: 4.6 (Compatibility Profile) Mesa 24.0.5 (git-09d9c2fd7f)

game runs and appears to be stable, but the framerate is unbearable.

devs borked linux again, ever since WWZ this engine in particular struggles on linux smh, already tried 6.11, lts, same issue, crashes while loading a game, was working fine a few weeks ago, steamdeck=1 makes connection error go away but doesn't fix loading.

OS: EndeavourOS
GPU: Radeon RX 6700 XT
Kernel version: 6.12.0-rc1-1-mainline (6.11 or even lts 6.6 no difference)
Mesa version: 24.3.0-devel (doesn't matter, even stable crashes)
Desktop environment: KDE
Proton experimental, bleeding edge, proton-9, doesn't matter which proton version i use.

steam-2183900.log

The game keeps freezing for me at the seizure warning screen. Anyone got a fix for this? I tried the cinematic skip launch parameter and the SteamDeck=1 environment variable without any luck.

EDIT: For some reason disabling cloud saves did the trick.

The game keeps freezing for me at the seizure warning screen. Anyone got a fix for this? I tried the cinematic skip launch parameter and the SteamDeck=1 environment variable without any luck.

EDIT: For some reason disabling cloud saves did the trick.

did you disable the steam overlay ?

The game keeps freezing for me at the seizure warning screen. Anyone got a fix for this? I tried the cinematic skip launch parameter and the SteamDeck=1 environment variable without any luck.

EDIT: For some reason disabling cloud saves did the trick.

As the person above said, disable Steam Overlay. Also turn off Mangohud and any other overlays you might have running. For some reason the only overlay the game likes on Linux is the Epic one. I also recommend Proton Experimental. I've found it crashes the least with that proton version. I've not tried GE9-16 but I had issues with GE9-15 and GE9-14.

This game seem to also affected by HansKristian-Work/vkd3d-proton#1406. launching the game with VKD3D_CONFIG=no_upload_hvv %command% have ~20% fps improvement for me.

this isn't a solution and is more of a band-aid. It actually makes heavily CPU dependent scenes run with even less FPS. GPU utilization is a bit better but still far from perfect.

game is unlaunchable.
Debian Bookworm.
system info: https://gist.github.com/mathew2214/f75390c266e293080b8c44526849d8a2

proton logs: https://gist.github.com/mathew2214/a385727baff87d88fec697891ed9d4a2

Wanted to make more of a comprehensive report regarding a severe performance issue the game's had since launch on Proton. There's something wrong with GPU utilization on this game under Proton that results close to a 45% performance difference compared to how the game runs natively on Windows.

While I only have logs and screenshots as of the game's current version (Hotfix 5.1) running on my RTX 4070 Super, I know that while I was still running an RX 6700 XT I was having the same or similar issues back when the game first came out a few months ago.

VKD3D_CONFIG=no_upload_hvv only partially helps performance and it depends on the scene, so I don't believe Resizable BAR is the only culprit that's going on with this game regarding performance. Besides testing with that variable on and off, another confirmation for GPU utilization issues is that resolution scaling generally does not affect performance no matter what setting it's set to. Any lower resolutions simply lower GPU usage and power, and in some scenes it can actually cause a minor performance regression as shown in the later screenshots. These were all ran at Ultra preset with FSR upscaling set to Quality (barring the Ultra Performance comparison).

Windows	Proton	Proton (no_upload_hvv)

Proton, FSR Ultra Performance	Proton, FSR Ultra Performance (no_upload_hvv)

Proton log: steam-2183900.tar.gz
Proton (no_upload_hvv) log: steam-2183900_no-upload-hvv.tar.gz

If anyone else can help confirm this issue, would be greatly appreciated! Especially from AMD GPU users, because I don't have access to my RX 6700 XT anymore and can't directly find out if exactly the same issue and performance numbers are present there.

System Information

OS: "Fedora Linux 41 (KDE Plasma)" (64 bit)
GPU: NVIDIA GeForce RTX 4070 Super
Video driver version: NVIDIA 565.77
Kernel version: 6.12.4-200.fc41.x86_64
Link to full system information report as Gist: https://gist.github.com/CptCookies12/b2c753f8248d5c95cfe7f6dd0a87ac69
Proton version: experimental-9.0-20241217

Replying to https://github.com/ValveSoftware/Proton/issues/8072#issuecomment-2553355068

Tested using a 6700xt with mesa-git vs windows 11 on a 5700X3D both with SAM on.

Game has terrible performance on windows/linux. gpu usage is lower on linux indeed, albeit with not so large performance differences, it trades blows all around.

So it doesn't affect AMD GPUs just as much but its definitely a tad slower than windows (it can be faster at times), another factor is the CPU bottleneck as well....

Linux	Windows

Linux	Windows

Linux	Windows

how are you guys getting the game to launch?
see https://github.com/ValveSoftware/Proton/issues/8072#issuecomment-2547299252

update: using GE-Proton8-32, the game launches, and i get to title screen, but it crashes as soon as i press enter.
proton log: https://gist.github.com/mathew2214/7646f8304f6bb914fa33e481e956286a/

attached is the zip file generated by the game's crash reporter. examining which is far above my skillset.
crash_data.zip

Replying to https://github.com/ValveSoftware/Proton/issues/8072#issuecomment-2593697700

At least on a desktop, I disable the in-game overlay in the properties for the game on Steam.

Replying to [#8072 (comment)](https://github.com/ValveSoftware/Proton/issues/8072#issuecomment-2593697700)

At least on a desktop, I disable the in-game overlay in the properties for the game on Steam.

yeah, im doing it with steam overlay disabled. no difference.

I started playing the game again, now that it support 32:9 and I noticed that the issue I reported in my previous comment is still present. Has anyone encountered this?

using proton ge 10-3, i still cannot play the game on Debian.

proton log: https://gist.github.com/mathew2214/b2a895b4e4bda2e70961a98e23920ea0

system info: https://gist.github.com/mathew2214/af2665fd7772f408d506b518053466d1

using Valve's proton 10 also yields identical results.
valve, please fix.

This game will get slower and slower with FPS over time, starting with full 60fps i end up with average 45 FPS after doing 3 missions and the longer i play it becomes more and more unplayable. I tried on Windows and there are no FPS slowdowns over time with the same hardware.
It happens with all the Proton versions i tried, Proton experimental and Proton GE

PC Specs: AMD Ryzen 7 5800X3D , GeForce RTX 2080 , 32GB RAM

Looks like there is some kind of regression maybe on Proton Experimental with this game. I've been using the AMD stub to force FSR4 by using the DLL from AMD and FSR4_UPGRADE=1 with DXIL_SPIRV_CONFIG=wmma_rdna3_workaround

And this has been working perfectly for near more than a month, but now suddenly it started crashing the game. There have been no patches for the game in a month, but there was a Proton Experimental update a few days ago (Maybe yesterday?).

@alosarjos May be related https://github.com/HansKristian-Work/vkd3d-proton/pull/2679

Default build of vkd3d-proton now disable fp8 emulation by default.

FP16 version of fsr4 work though.

Really bad framerate drops since last patch. Not sure if a bug on the game, or something the game using now that has some issue on Proton.

Big fps drops and loading the game assets seems to be really broken after the last patch where loading screens take about 10x longer and switching your graphics settings take an eternity.

I expect this is down to the developers of the actual game tho

Big fps drops and loading the game assets seems to be really broken after the last patch where loading screens take about 10x longer and switching your graphics settings take an eternity.

I expect this is down to the developers of the actual game tho

I'm not reading about Windows users having theses issues...

There are some zones where Framerate will just do down forever. I took a screenshot showing how machine resources are not at full usage while having really bad framerate. Not sure if this helps somehow.

@alosarjos I think I'm seeing something similar, out of curiosity, does it still happen with EAC disabled?

if you don't already know how, the easiest way to disable it is to open the Warhammer 40000 Space Marine 2.ini file that's in the game's root directory and change ApplicationPath=start_protected_game.exe to ApplicationPath=client_pc\root\bin\pc\Warhammer 40000 Space Marine 2 - Retail.exe

@alosarjos I think I'm seeing something similar, out of curiosity, does it still happen with EAC disabled?

if you don't already know how, the easiest way to disable it is to open the Warhammer 40000 Space Marine 2.ini file that's in the game's root directory and change ApplicationPath=Warhammer 40000 Space Marine 2.exe to ApplicationPath=client_pc\root\bin\pc\Warhammer 40000 Space Marine 2 - Retail.exe

I will give it a try later. But sadly things have gone worse. On operations, I "only" get huge FPS drops, but on the waves survival mode, 3 times I tried playing, 3 times my GPU crashed putting me back on the Gnome login screen.

Worse thing about this is not knowing if it's a game issue, or a Linux issue.

Don't want to report issues for unsupported platform to devs

But neither want to report issues on mesa o VKD3D when all issues seems to come from the latest game patch

Any advice on how should I proceed @kisak-valve ?

Based off my testing, and assuming we have the same issue, I suspect EAC might be involved, after bypassing it (which launches the game in an offline/"modded" mode) I wasn't seeing any of the choppiness I was getting with it.

It's acting almost like I'd expect from a game on an HDD, despite being on my NVME

Based off my testing, and assuming we have the same issue, I suspect EAC might be involved, after bypassing it (which launches the game in an offline/"modded" mode) I wasn't seeing any of the choppiness I was getting with it.

It's acting almost like I'd expect from a game on an HDD, despite being on my NVME

Good afternoon, I've tried the suggested solutions, and I can confirm that the FPS drop issue has been resolved. The problem now is that I obviously can't play online.

Thanks

@DrymarchonShaun My .ini was pointing to the start_protected_game.exe instead, but changed to the values you said, and yes, now it's running flawlessly. So yeah, related to the EAC, though I think it's affecting Linux way harder than Windows

Just stopping in to report that I also ran the test with disabled EAC to find the same results.

It is unclear to me who to report the issue to, exactly, so if there is another space we should be documenting this finding let me know.

Edit: recent hotfix did not resolve the issue for me.

I also asked my buddy on windows if he's been having any of the issues and there does appear to be a few specific places where this happens to him, so it may actually be a game issue that is worse for linux as noted above.

Still having same issues with Hotfix 11.1

Same issue here, fresh copy of Space Marine 2.

My system configuration:

OS: openSUSE Tumbleweed, Mesa 25.3.1 (from Packman repo), Kernel 6.18.0, ProtonGE 10.26
CPU: Ryzen 7 5700X@4700MHz all core, 1.35v fixed
RAM: 32GB DDR4 3600MT/s
GPU: MSI MECH RX 7600

All my games are installed in a nvme 1TB PCIe 4.0 with BTRFS as filesystem. When the game load the assets (it takes about 5 mins to load into the lobby) my audio starts crackling and all the cpu cores kick the %100 of usage.

No mather what configuration preset I use (Low, Medium, High), after 10 - 20 mins, my FPS drop from 120/140 to 35/50 fps depending on the number of enemies and map zones.

patch 11.2 released on steam. issue still persisting for me. (EAC enabled in order to play online) https://store.steampowered.com/news/app/2183900/view/492711197218439388?l=english

Debian 13. game is unlaunchable normally. i have to do the ini edit to run Retail exe in order for game to even start.

Game works with latest patch, but suffers from constant FPS drops (from 60 to single digits). When the game drops the GPU usage drops to almost 0% while CPU goes up to almost 100%. Also the game sometimes fails to launch due to EAC errors. Loading missions can take some time, but it might be due to networking issues

Game breaks pipewire on every loading.

@taqd does this happen to mitigate your issue?

I think I'm seeing something similar, out of curiosity, does it still happen with EAC disabled?

if you don't already know how, the easiest way to disable it is to open the Warhammer 40000 Space Marine 2.ini file that's in the game's root directory and change ApplicationPath=start_protected_game.exe to ApplicationPath=client_pc\root\bin\pc\Warhammer 40000 Space Marine 2 - Retail.exe

worth noting, this means the game launches in offline/modded mode, so online play isn't possible and progress doesn't save. This can be reverted easily by editing the mentioned file back to what it was originally, however.

I tested Proton Experimental.
I played one round and defeated the Swarm Tyrant. There were significant performance drops during startup and loading screens, with the loading screen for the mission taking a particularly long time.
During the mission with other players, there were occasional freezes and stutters.

It has gotten better, but there is still a lot of room for improvement.

Replying to https://github.com/ValveSoftware/Proton/issues/8072#issuecomment-3726575632

Note: the issue I reported was auto-merged here, but the symptoms are different from the original description.

My experience is not a connection/authentication failure — the game loads + runs under Proton Experimental, but after Update 11 which was released for Space Marine 2 on November 25, 2025, it exhibits periodic main-thread stalls while playing missions with EAC enabled:

• Frequency ~30s – 2min
• Duration ~1–4s
• Input freezes + FPS drops
• Disabling EAC eliminates the problem
• CPU scheduling mitigations reshape but do not remove the stalls
• Extensive log attached previously shows high resource churn and view map pressure under DX12 + vkd3d

This appears to be a performance regression after Update 11, not the original connection issue.

I can provide additional logs or traces if helpful.

I am using an AMD CPU and GPU, and tried disabling SMT in my bios. It did not fix the performance drops, but hte load times were much more stable and the performance drops did not last as long or occur as frequently. This might be a workaround for the time being.

CachyOS
GPU - 5700 XT
CPU - 3600

Ever since Update 11, I haven't been able to play online. Whether I'm in Public or Private, the game says I'm running mods (I've never used a mod on this game) and kicks me out of the 'public' game - even if I'm in Private. I can only play Solo.

And apparently I'm not the only one. Both the Steam Forums and the Focus forums are full of people reporting this. It does not appear to be associated with the AZW servers being unstable, which was what got the blame for this pre-U11. But afaict, all the reports of perma-Mod Detected since U11 appear to be Linux users. And Focus appears to be either uninterested or incapable in fixing it, despite the issue seeming to be directly caused by U11 detected Proton as a false positive for mods.

Note: the issue I reported was auto-merged here, but the symptoms are different from the original description.

@Kyrottimus you might already know this, but issues in this repo are per-game, not per-bug. So any issues related to SM2 go in this issue, even if the original reason the issue was created is different from what you are experiencing. The more recent comments in this thread are discussing the issue you are dealing with.

Is there any other news regarding to this game? I find hard to believe it's a 100% issue on the game or everyone would be unable to play this for months already...

Is there any other news regarding to this game? I find hard to believe it's a 100% issue on the game or everyone would be unable to play this for months already...

Nothing working on live as far as i know however there is a pts up for the new patch. Looking through the notes aside from memory and stability fixes i couldn't see anything about eac issues.

Pts notes here: https://community.focus-entmt.com/focus-entertainment/space-marine-2/blogs/339-pts-patch-notes-12-0

Summary

Space Marine 2 (AppID 2183900) on Linux regressed with Patch 11 on my setup: very long loading
times, severe frame drops/stutter (especially cutscenes), and occasional crashes.
Performance improved substantially with GE-Proton and split-lock mitigation workaround, but stability
is still not perfect.

System Information

• OS: Fedora Linux 43 (KDE Plasma Desktop Edition)
• Session: Wayland
• Kernel: 6.18.7-200.fc43.x86_64
• CPU: Intel Core i7-12700K
• RAM: 31 GiB
• GPU: NVIDIA GeForce RTX 3080 Ti (GA102)
• NVIDIA driver: 580.119.02
• Secondary GPU: Intel UHD 770
• Game: Warhammer 40,000: Space Marine 2 (Patch 11)

Proton Versions Tested

• Proton Hotfix
• GE-Proton10-29 (best result so far)

Repro / Symptoms

1. Launch game with Proton (Hotfix or GE).
2. Observe startup/loading and cutscene performance.
3. On default kernel split-lock behavior, experience severe stalls/frame drops.
4. Occasional crash can occur during/after heavy stutter periods.

What I Observed in Logs

• Repeated kernel split-lock events from game/Wine threads:
• x86/split lock detection: #AC: Warhammer 40000 ...
• Earlier crash session also showed:
• NVRM: Xid (PCI:0000:01:00): 13, pid=..., name=Warhammer 40000, Graphics Exception ...

Workaround That Helped a Lot

• Switch to GE-Proton10-29
• Dynamically set:
• kernel.split_lock_mitigate=0 while Steam game process is running
• restore to kernel.split_lock_mitigate=1 on exit

This significantly reduced load-time stalls and improved in-game/cutscene smoothness, but did not
fully eliminate crashes.

Current Status

• Playability: much better with workaround
• Remaining issue: occasional crash / not fully stable
• Not yet “works perfectly out of the box” on this hardware/software combo

I had an issue when game used 100% of my CPU and render like 5-7 fps. Disabling split lock mitigation fixed that issue. Previously I used gamemode that can disable it automatically, so I never seen this before I switched to falcond.

EAC issue with high CPU usage and FPS drops on loading before and mid-game still persists as of patch 12.0.

A combination of scx_bpfland, gamemode and proton-cachyos-slr reduced stuttering to 2-3 seconds on average per PvE match. High CPU usage and load times are still abysmal compared to what was before patch 11.0. The main culprit is still EAC.

System Information

|  
-- | --
OS | CachyOS (KDE Plasma Desktop Edition)
Session | Wayland
Kernel | 6.19.5-3-cachyos
Scheduler | scx_bpfland
CPU | AMD Ryzen 7 5800X
RAM | 32 GiB
GPU | NVIDIA GeForce RTX 5070 Ti
NVIDIA Driver | 590.48.01
Proton Version | proton-cachyos-10.0.20260207-slr

Description

On initial load into a mission, the CPU is pegged at 100% utilization and the framerate drops to 5–7 FPS. The game does not recover on its own — it stays in this degraded state indefinitely.

A full game restart resolves the issue immediately and completely. Performance returns to normal for the next mission. The workaround is 100% reliable.

Additionally, during loading screens, audio crackling/popping is consistently audible. This may be related to the same underlying CPU usage spike.

I also experience the stuttering issues reported by other users in this thread.

Reproduction Steps

1. Launch Space Marine 2 via Proton
2. Starting a mission from the HUB
3. CPU usage spikes to 100%, FPS drops to 5–7
4. Intro cutsecene gets a stuck at 1-2 fps
5. Game remains unplayable until fully restarted

Expected: Game loads into mission with watchable cutscene and playable perfomance Actual: CPU maxes out, game is unplayable. Restart required after every mission.

Additional Notes

• Issue is consistent and reproducible for every mission
• Restart workaround is fully effective — no degradation carries over
• Audio crackling during loads is present regardless of the CPU spike
• All three symptoms (CPU spike, audio crackling, stutter) appear to be part of the same regression introduced with patch 11

scx_cosmos fixed pretty much all stuttering for me. Pure magic!

scx_cosmos fixed pretty much all stuttering for me. Pure magic!

Can also confirm that using scx_cosmos scheduler fixed the stuttering for me too.

I implemented the the following on NixOS:

# Services
# https://search.nixos.org/options?channel=unstable&show=services
services = {

  # Services - SCX
  # https://search.nixos.org/options?channel=unstable&show=services.scx
  scx = {

    # Services - SCX - Enable
    # https://search.nixos.org/options?channel=unstable&show=services.scx.enable
    enable = true;

    # Services - SCX - Scheduler
    # https://search.nixos.org/options?channel=unstable&show=services.scx.scheduler
    scheduler = "scx_cosmos";
  };
};

I'll try the cosmos scheduler, I'm currently using lavd.

scx_cosmos fixed pretty much all stuttering for me. Pure magic!

Do you use any custom flags for cosmos or just the defaults?

Do you use any custom flags for cosmos or just the defaults?

https://wiki.cachyos.org/configuration/sched-ext/#gaming

Anecdotally, switching to scx_cosmos (with otherwise default settings FWIW) does appear to fix the biggest issue I was seeing.
It does still feel like it runs overall a little less well than it does on windows but "slightly slower" is much more playable than "randomly runs at 1fps for 5-15s at a time".

It is a strange workaround though, as there was also a data point saying that turning off the anticheat also resolves the issue (albeit removing the ability to multiplayer).
Combined with this discovery it indicates that the anticheat is potentially having some sort of issue that scx_cosmos mitigates?

It might be interesting to see which (if any) other schedulers also mitigate/resolve this issue, and if so (or not), potentially identify why.
Is something causing some kind of absolute worst case result in the default scheduler, or does scx_cosmos do something that happens to mitigate it?

After 1hr of gameplay I can confirm that the cosmos scheduler mitigates almost all the current issues. No more audio crackling while loading mission assets, no more low fps or drops. CPU usage in all cores is consistent during the gameplay with no performance degradation. I don't have any custom flags for cosmos.

Operating System: openSUSE Tumbleweed 20260304
KDE Plasma Version: 6.6.2
KDE Frameworks Version: 6.23.0
Qt Version: 6.10.2
Kernel Version: 6.19.5-1-default (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5700X 8-Core Processor
Memory: 32 GiB of RAM (31.3 GiB usable)
Graphics Processor: AMD Radeon RX 7600

Interesting, I'm seeing the same thing. I just set up scx_cosmos and the game just... works.

Since some of y'all seem to be more familiar with it, is there any downside to just using scx/sched-ext all the time?

EDIT- actually, I think it may just be that the game is working now, even without any of the schedulers the game seems to be running fine for me.

Interesting, I'm seeing the same thing. I just set up scx_cosmos and the game just... works.

Since some of y'all seem to be more familiar with it, is there any downside to just using scx/sched-ext all the time?

I don't see any issue here by using a custom scheduler, cosmos can handle different types of workloads, it's a general purpose scheduler.

I can also say that using the scx_cosmos scheduler works on my end. Using CachyOS with AMD an AMD 3600 CPU and 5700 GPU.

I can also say that using the scx_cosmos scheduler works on my end. Using CachyOS with AMD an AMD 3600 CPU and 5700 GPU.

Did you happen to check if it still wasn't working without scx_cosmos?

For those monkeys like me on non cachy arch distros and trying to find a "simple" way to implement changing your scheduler :

Install:

sudo pacman -S scx-scheds

Once installed, simply run this in terminal before starting the game:

sudo scx_cosmos

Leave the terminal open the whole time, you can ctrl+c to close it afterwards if you don't want the scheduler to be changed all the time.

edit: can confirm, game is completely playable with the new scheduler running.

Did notice that as the game stays open, performance degrades over time until you restart the game, might be NVIDIA specific though.

Fixed problem

Space Marine 2 crashes/freezes immediately after the first cutscene (story_intro scene) on Linux with
NVIDIA RTX 5000 series GPUs. The game menu works fine, EasyAntiCheat loads successfully,
but the GPU hangs during gameplay load.

Root cause: NVIDIA driver bug (Xid 109 — CTX SWITCH TIMEOUT). Certain compute shaders in SM2 use SPIR-V
instructions that the Blackwell GPU driver can't handle, causing a context switch timeout.

How to confirm you have this issue:

journalctl -b --no-pager -p warning | grep -i "xid"

You'll see:

NVRM: Xid (PCI:0000:01:00): 109, pid=XXXXX, name=Warhammer 40000, channel 0x0000000a, errorString CTX
SWITCH TIMEOUT, Info 0xc006

The Fix: pyroveil

Pyroveil is a Vulkan layer that rewrites problematic shaders through SPIRV-Cross, making them
compatible with the NVIDIA driver.

1. Install dependencies

sudo pacman -S ninja cmake gcc git

1. Build and install pyroveil

git clone --recursive https://github.com/HansKristian-Work/pyroveil.git ~/pyroveil
cd ~/pyroveil
mkdir -p build
cd build
cmake .. -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$HOME/.local
ninja
ninja install

1. Create SM2 config
   Create ~/pyroveil/hacks/space-marine-2-nv/pyroveil.json:

{
	"version": 2,
	"type": "pyroveil",
	"matches": [
			{ "spirvExecutionModel": 5, "action": { "glsl-roundtrip": true } }
	],
	"roundtripCache": "cache",
	"disabledExtensions": [ "VK_NV_raw_access_chains" ]
}

Then create the cache directory:

mkdir -p ~/pyroveil/hacks/space-marine-2-nv/cache

1. Set Steam launch options
   Right-click SM2 → Properties → Launch Options:

PYROVEIL=1 PYROVEIL_CONFIG=~/pyroveil/hacks/space-marine-2-nv/pyroveil.json DXVK_ASYNC=1 %command%

What this does:

• Roundtrips all compute shaders through SPIRV-Cross, rewriting the SPIR-V instructions that trigger
  the Nvidia driver bug
• Disables VK_NV_raw_access_chains (another Nvidia compatibility issue)
• Caches rewritten shaders so only the first launch is slower

Environment tested on:

• CachyOS (Arch-based), kernel 6.19.7
• NVIDIA RTX 5060 Ti, driver 595.45.04 (open kernel modules)
• Proton Experimental / GE-Proton
• Space Marine 2 Patch 12

Notes:

• Solution was found from this pyroveil PR: https://github.com/HansKristian-Work/pyroveil/pull/27/changes/73dfb8276378057aed10b076485e87469787f119
• Once NVIDIA fixes Xid 109 in a future driver, this workaround may not be needed
• May also help other games crashing with Xid 109 on 5000 series. Known - RE8.

More detail:
The problem is that VKD3D-Proton generates valid but unusual SPIR-V patterns (especially around subgroup/wave operations in compute shaders) that NVIDIA's Windows driver never sees. The Blackwell driver's SPIR-V compiler has a bug where certain patterns cause the GPU to hang during context switching.
Pyroveil fixes it by roundtripping the SPIR-V through SPIRV-Cross (decompile to GLSL, recompile back to SPIR-V). This produces equivalent but more "conventional" SPIR-V that the driver handles fine.

Replying to https://github.com/ValveSoftware/Proton/issues/8072#issuecomment-4075172775

I forgot to add that the game was working on the second SSD to which i did about 1/2 a second playthrough then after about 2 steam OS updates it would give me the error

Hello @target-bravo, can you check how the game behaves with the game's launch options set to PROTON_SET_GAME_DRIVE=1 %command%? (from [#1651 (comment)](https://github.com/ValveSoftware/Proton/issues/1651#issuecomment-3814151296))

Same issue sadly

Ok i think i have it sorted after 3 days of trial and error.

I previously set up a folder /run/media/deck/Games/ then setup the drive to mount to this location in KDE partition manager like SD-Cards.

when like this the game would give me the above error.... but only recently for some reason

I then unmounted the drive removed the folder and that mount point from kde partition manager and double clicked the drive to mount it.

Space Marine 2 now launches fine but the drive does not auto mount anymore.

Now for the weird fix mounting the drive by double clicking creates a folder /run/media/deck/Games/ same as above. Now if i use this folder in KDE Partition manager as the mount point Space marine 2 will launch just fine.

New hotfix https://community.focus-entmt.com/focus-entertainment/space-marine-2/blogs/367-hotfix-12-2-patch-notes

• Fixed an issue causing low FPS and 100% CPU usage on Steamdeck.

Interested to see if this will resolve the FPS and CPU issues on Linux in general, without the use of a custom scheduler.

Time to test

New hotfix https://community.focus-entmt.com/focus-entertainment/space-marine-2/blogs/367-hotfix-12-2-patch-notes

• Fixed an issue causing low FPS and 100% CPU usage on Steamdeck.

Interested to see if this will resolve the FPS and CPU issues on Linux in general, without the use of a custom scheduler.

Just completed the weekly normal, no issues. Looks like its fixed.

Game performance still unfortunately degrades over time, at least for Nvidia GPUs(590 driver.) After a couple missions performance will slowly get worse until you restart the game.

Better than it was, but still not perfect.

https://github.com/ValveSoftware/Proton/issues/8072#issuecomment-4071848316 - legend for posting this.

Game performance still unfortunately degrades over time, at least for Nvidia GPUs(590 driver.) After a couple missions performance will slowly get worse until you restart the game.

Nvidia driver 595.58.03
Operating System: Bazzite 43
KDE Plasma Version: 6.6.3
KDE Frameworks Version: 6.24.0
Kernel Version: 6.17.7-ba29.fc43.x86_64 (64-bit)
Graphics Platform: Wayland

didn't notice this issue. could be related to kernel/shell? in other games i noticed some settings like the vsync mess with frame timing which causes stutters at times. maybe there's an optimal way to configure the game?

Unfortunately running the pyroveil "hack" does nothing but absolutely nuke my framerate. Updating all my packages recently still doesn't help with performance degradation, after about 2 missions i notice a subtle hit, after about 3-4, frametimes are toast and the game needs restarted. Seems to accelerate if you spend a lot of time in the armory.

Garuda Linux x86_64
Kernel: 6.19.11-zen1-1-zen
Resolution: 3440x1440 2560x1440 1920x1080
DE: KDE Plasma 6.6.4
WM: KWin (Wayland)
WM Theme: Sweet-Dark
Theme: Dr460nized (Sweet) [Qt], Sweet-Dark [GTK2/3/4]
Icons: BeautyLine [Qt], BeautyLine [GTK2/3/4]
Terminal: konsole 25.12.3
Terminal Font: FiraCode Nerd Font Mono 12
dCPU: AMD Ryzen Threadripper PRO 5975WX 32-Cores (64) @ 4.561GHz
GPU: GeForce RTX 4090
GPU: ASPEED Graphics Family
Memory: 12349MiB / 257575MiB

Running the journal command

journalctl -b --no-pager -p warning | grep -i "xid"

Returns nothing, so i'm assuming i don't share the same issue.

I use these launch options normally:

PROTON_USE_NTSYNC=1 gamemoderun __GL_SHARPEN_ENABLE=1 __GL_SHARPEN_VALUE=100 PROTON_HIDE_NVIDIA_GPU=0 PROTON_ENABLE_NVAPI=1 PROTON_NVIDIA_LIBS=1 %command%

Using latest proton GE.

Playing the game on windows for now without any issues, here's hoping it sees some improvement eventually.

Unfortunately running the pyroveil "hack" does nothing but absolutely nuke my framerate.
GPU: GeForce RTX 4090

In my albeit small experience this hack is exclusively for 50x Nvidia series.
Have you tried Proton EM latest?

I've tried other proton versions but i haven't heard of proton-em, what makes it different from GE/Cachy/stock? The github doesn't really go into detail.

@Zeronthe i can't really tell. i've seen this in the tinker steps on protondb and during my attempts to launch the game i basically landed on the combo of this hack + proton EM latest. the version itself is available through the usual means on bazzite - protontricks, so seems legit enough

Unfortunately using proton-EM didn't do anything to resolve the issue here. After the third mission, like clockwork, performance started to degrade.

Compatibility Report

• Name of the game with compatibility issues: Warhammer 40000 Space Marine 2
• Steam AppID of the game: 2183900

System information

• OS: Arch Linux x86_64
• GPU: NVIDIA GeForce RTX 4080
• Video driver version: NVIDIA Driver 610.43.02
• CPU: AMD Ryzen 7 5800X
• Proton version: Proton experimental (default)
• Steam system info: System Info

I confirm:

• [x] that I haven't found an existing compatibility report for this game.
• [x] that I have checked whether there are updates for my system available.

Proton Log: steam-2183900.log.gz

Symptoms

Hello,
a new problem with this game has arisen for me. Up until about 2 weeks ago, I could play the game as usual. When I tried to play again yesterday, I couldn't reach the main menu anymore. The game starts, the "intro" videos play, shaders are precreating when cleaned, then the game will hang anytime before reaching the main menu. The "send report" dialog then appears after some time and the game exits upon answering the dialog box.

The driver error: "kernel: NVRM: Xid (PCI:0000:0c:00): 13, pid=2704, name=Warhammer 40000, Graphics Exception: channel 0x0000000b, Class 0000c997, Offset 00000000, Data 00000000", meaning that a GPU shader or compute kernel triggered an exception during execution.

Verifying files shows no error.
As the last successful game session was using previous NVIDIA driver version, I tried downgrading nvidia packages to last known good (595.71.05), cleaning shader caches and vkd3d-proton.cache files and rebooting, to no avail, same error.
I also tried the pyroveil route to counter some potentially problematic shaders, same error.

What was updated since last known good:

• Proton experimental
• Nvidia drivers
• The game itself

Reproduction

Run the game, and have the game crash anywhere near intro cinematics and main menu (instant depends if you skip videos or not).

The driver error: "kernel: NVRM: Xid (PCI:0000:0c:00): 13, pid=2704, name=Warhammer 40000, Graphics Exception: channel 0x0000000b, Class 0000c997, Offset 00000000, Data 00000000", meaning that a GPU shader or compute kernel triggered an exception during execution.

I had the same issue. Using these launch options (4k monitor)
gamescope -W 3840 -H 2160 -f -- %command%

and Proton Experimental got me into the main menu

I had the same issue. Using these launch options (4k monitor) gamescope -W 3840 -H 2160 -f -- %command%

and Proton Experimental got me into the main menu

No joy for me :(, same crash with gamescope.

After some tries, it seems the game does not crash if I set the game refresh rate to 60Hz or 90Hz:

• A try with gamescope -W 3840 -H 2160 -r 60 -f -- %command% has let me reach past the crashing point.
• Tries with -r 120 or -r 240, --adaptive-sync or not crashed every time.
• While in the game, I limited the game fps to 60 and tried without gamescope or any launch option (as before the crashes appeared): now the game works.
• I then tried 90 FPS, works too.
• Upping the FPS limit to 120 in the menu = insta-crash (NVRM xid 13)
• Reverted the FPS limit in the game settings using gamescope -W 3840 -H 2160 -r 90 -f -- %command% then removing the launch options: game works again.
• I did multiple rounds of the same loop to "ensure" it's not pure luck: same crashes and fixes every time.

So if you encounter the same bug: FPS limit to 90 may help.

Game has frame pacing issues on Intel hybrid CPUs.
Easily testable in-game in the hangar lobby, panning visual left-right.

I solved it on my setup using taskset to restrict it on P-Cores only.
taskset -c $(cat /sys/devices/cpu_core/cpus) %command%
Can this be integrated in Proton itself?
ty in advance

i7-13700K
RTX 4070 Ti
Proton Experimental

Replying to https://github.com/ValveSoftware/Proton/issues/8072#issuecomment-4595147633

I have encountered the same deal. I was able to play a few days ago and today I could not reach the main menu, when I press enter it crashes.

RTX 3080 / R7 5700x3D / CachyOS

I was able to get in by using this launch option.

VKD3D_CONFIG=descriptor_heap PROTON_VKD3D_HEAP=1

Hi

I've found quite interesting issue with the game i need to fully confirm this with more testing but on my end no matter the proton version game freeze at every even hour. I'm not quite sure what reason might be and is it just my configuration related, maybe its new mesa version that my os got like a week ago, or something related with proton.

I'm looking for some guesses/ideas what this might be.

my specs:
Operating System: PikaOS 4
KDE Plasma Version: 6.5.4
KDE Frameworks Version: 6.20.0
Qt Version: 6.9.2
Kernel Version: 7.1.4-pikaos (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5700G with Radeon Graphics
Memory: 32 GiB of RAM (30.7 GiB usable)
Graphics Processor 1: AMD Radeon RX 6700
Graphics Processor 2: AMD Radeon Graphics

thanks for any response in advance.

edit:
I've tested whether this might be somehow related to some service since it was weird that freeze always happened at even hours, but it's not related to any service i wonder whether its not something related to EAC runtime, but I'm not sure

steam-2183900-updated.zip
Updated proton log file, now containing freeze moment

Adding concrete evidence tying the periodic EAC main-thread stalls (previously tracked separately at #9379, merged here) to a specific, easily-measurable symptom: the controller goes completely dead during each stall, not just mouse/keyboard as reported before.

System: Bazzite (Fedora Atomic) desktop, kernel 7.2.0-ogc4.1.fc44.x86_64, AMD GPU (RADV), Proton-GE (latest), Steam Controller (Valve's own wireless "Puck" dongle, not a third-party pad).

Symptom: Mid-session, all controller input to the game stops entirely - only the Steam-button chord (handled by the Steam client itself, outside the game's input path) still works, confirming it's not a physical disconnect. Also hit a crash on exiting a level (matches earlier reports here from 2024 of crash-on-quit).

Concrete evidence of periodicity, pulled directly from the kernel log during one session:

$ journalctl -k --since "22:05:00" | grep "X-Box 360 pad"
Aug 24 22:05:39 kernel: input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input71
Aug 24 22:07:36 kernel: input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input72
Aug 24 22:07:42 kernel: input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input73
Aug 24 22:09:48 kernel: input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input74
Aug 24 22:11:51 kernel: input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input75
Aug 24 22:12:54 kernel: input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input76
Aug 24 22:14:14 kernel: input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input77
Aug 24 22:16:10 kernel: input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input78
Aug 24 22:16:21 kernel: input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input79
Aug 24 22:17:21 kernel: input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input80
Aug 24 22:17:45 kernel: input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input81
Aug 24 22:18:21 kernel: input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input82

That's Steam Input's virtual XInput device (uinput) being torn down and rebuilt roughly every 60-90 seconds, continuously, for the whole session - lining up closely with the "~30s to 2min" stall interval reported at #9379. My read: Steam Input is reactively rebuilding its virtual controller device each time it perceives the game/its input path as unresponsive during an EAC stall, which is why the controller (not just mouse/keyboard) goes fully dead each time.

Tried the usual Steam Input remedies first (forcing an Xbox-360-emulating controller layout instead of the native template) - confirmed via ~/.local/share/Steam/logs/controller.txt that this had zero effect on the underlying churn, so this isn't a per-game Steam Input config issue, it's downstream of the EAC stall itself.

Happy to grab a PROTON_LOG=1 capture or anything else useful if it'd help narrow this down further.

Correction to my comment above: I connected the controller churn to the EAC periodic-stall pattern based on a rough timing match, but further testing shows that's likely wrong. During the same kind of session, the game itself (framerate, rendering) ran smoothly the whole time with no stutter or freeze - only the controller went unresponsive, repeatedly. That doesn't match the "everything stalls together" symptom described for the EAC main-thread-stall issue, so I don't think these are the same bug. Apologies for the noise - leaving the kernel-log evidence above since the churn itself is still real and reproducible, just not (as far as I can tell) tied to the EAC stall specifically.