On Bazzite with 570.144 Proton Experimental bleeding edge the game will launch via the desktop steam client without frame generation and HDR. The color space will be completely wrong however as mentioned above even when it's running in SDR (everything Magenta).

Under Gamescope session the game will crash before loading the actual menu if frame gen is enabled but works fine with HDR enabled without frame generation. DLSS super resolution is Working as well.

Game crashes to desktop on my AMD machine during the first bethesda logo cutscene. I have seen the same reports on the Linux_Gaming reddit. Tested with Experimental Bleeding Edge and Hotfix.

Operating System: Arch Linux
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.14.0
Qt Version: 6.9.0
Kernel Version: 6.14.6-zen1-1-zen (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 5700X3D 8-Core Processor
Memory: 62.7 GiB of RAM
Graphics Processor: AMD Radeon RX 7800 XT
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: B550 AORUS ELITE AX V2

steam-3017860.tar.gz

No major issues so far with me. Only issue is DLSS, which causes the game to go purple/pink and enabling fsr on my 5080 causes the game to display a black screen but with audio working

Kernel: 6.14.6
CPU: intel 12600k
Gpu: Nvidia RTX 5080
Driver: 570.144
Proton experimental bleeding edge

For RADV, I think the issue is enabling options to make it compatible. It seems like this already happened for the steam deck, but I have no idea how to do this for desktops

For RADV, I think the issue is enabling options to make it compatible. It seems like this already happened for the steam deck, but I have no idea how to do this for desktops

Can you please tell us where it can be done?

Game crashes to desktop on my AMD machine during the first bethesda logo cutscene. I have seen the same reports on the Linux_Gaming reddit. Tested with Experimental Bleeding Edge and Hotfix.

Operating System: Arch Linux KDE Plasma Version: 6.3.5 KDE Frameworks Version: 6.14.0 Qt Version: 6.9.0 Kernel Version: 6.14.6-zen1-1-zen (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5700X3D 8-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon RX 7800 XT Manufacturer: Gigabyte Technology Co., Ltd. Product Name: B550 AORUS ELITE AX V2

steam-3017860.tar.gz

Same issue I am having. AMD Radeon 6800XT, Fedora 42, latest updates. No iGPU at all.

For RADV, I think the issue is enabling options to make it compatible. It seems like this already happened for the steam deck, but I have no idea how to do this for desktops

Can you please tell us where it can be done?

I tried putting the option names as environment variables (just a wild guess), and it didn't work. (shrug)

I figured out that those options come from 00-radv-defaults.conf: https://github.com/bazzite-org/mesa/blob/54cf223f100a114680f51f43f5dfc632eeeefb3b/src/util/00-radv-defaults.conf#L126-L131. It was in /usr/share/drirc.d/00-radv-defaults.conf for me, and I added the entry for doom there, but the game still crashes at the bethesda logo.

steam-3017860.tar.gz

For RADV, I think the issue is enabling options to make it compatible. It seems like this already happened for the steam deck, but I have no idea how to do this for desktops

Can you please tell us where it can be done?

I tried adding these parameters in the launch options, the game still crashes, but with those options I get a boat load of artifacting.

I figured out that those options come from 00-radv-defaults.conf: https://github.com/bazzite-org/mesa/blob/54cf223f100a114680f51f43f5dfc632eeeefb3b/src/util/00-radv-defaults.conf#L126-L131. It was in /usr/share/drirc.d/00-radv-defaults.conf for me, and I added the entry for doom there, but the game still crashes at the bethesda logo.

steam-3017860.tar.gz

Sad that I can't test it right now because Denuvo banned me for 24 hours because I was trying to launch game with different Proton versions.

I can't understand it. They removed Denuvo from Doom Eternal but re-added it in TDA.

Sad that I can't test it right now because Denuvo banned me for 24 hours because I was trying to launch game with different Proton versions.

I can't understand it. They removed Denuvo from Doom Eternal but re-added it in TDA.

They put Denuvo on there for the first few weeks to protect initial sales until the game gets cracked. They will probably remove it later with this game as well.

EDIT: Also, you have to remember that when DOOM eternal released, they accidentally released the denuvo free version on the bethesda launcher, meaning there was no point in keeping it at that point.

Regarding running the game under RADV:

Before you're able to apply all of those settings in 00-radv-defaults.conf, you need to make sure your Mesa version has the patch that implements radv_force_64k_sparse_alignment. Right now this patch is only available in Valve's Mesa tree from SteamOS unless it's been cherry-picked into your Mesa build.

I took these from Valve's tree via SteamOS's Mesa source package and rebased them for mesa-25.1.0: https://github.com/matte-schwartz/mesa/commit/8119f91113b775afe34cdf980550425639bab7cd and https://github.com/matte-schwartz/mesa/commit/17676b7686aa3f99a4132656376c62e6f5360c4b, and now I can run the game on my 7900XTX rig

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2874956966

Is this a complete fork for mesa or just the files that needed to be changed? Tried compiling it and installing it but it didn't seem to install.

I use the Mesa-git pkgbuild and just saved those two commits as individual patches. Up to you how you want to apply them. Mostly posted them there for better visibility than the source tarball they came from.

If anyone wants more specific instructions, this is a diff of the PKGBUILD that I had after making changes that worked for me.

15c15
< pkgver=25.2.0_devel.204321.de6efc01c12.d41d8cd
---
> pkgver=25.1.0.204437.e8011985b02.d072636
94c94,96
<     'mesa::git+https://gitlab.freedesktop.org/mesa/mesa.git#branch=main'
---
>     'mesa::git+https://gitlab.freedesktop.org/mesa/mesa.git#branch=25.1'
>     'tda-workarounds.patch::https://github.com/matte-schwartz/mesa/commit/17676b7686aa3f99a4132656376c62e6f5360c4b.patch'
>     'radv-force-64k-sparse-alignment.patch::https://github.com/matte-schwartz/mesa/commit/8119f91113b775afe34cdf980550425639bab7cd.patch'
97a100,101
>             'SKIP'
>             'SKIP'
103a108,109
>         'SKIP'
>         'SKIP'

I use the Mesa-git pkgbuild and just saved those two commits as individual patches. Up to you how you want to apply them. Mostly posted them there for better visibility than the source tarball they came from.

Got it working, haven't ever patched a PKGBUILD before so had trouble figuring this out. Thanks for posting the patch!

@DoomSlinger would you mind pointing me in the right direction, never really have patched a pkgbuild before either

Just tried this on my RTX 4070 Laptop running Fedora 42 (latest updates). Everything worked well with Steam defaults. Seems Mesa is the biggest issue causing AMD card users the crashing issues.

I haven't tried any of the original posts issues (DLSS frame gen), but overall the game is playable on nvidia hardware.

@matte-schwartz Thanks a lot for that, got it working!

Though I'm not sure what did I touch the first time that completely broke the menu of the game, not sure if it was frame gen. Had to delete the prefix to get it working

Curiously, I don't see any commit / MR / Issue on upstream mesa...

Are these patches some workaround for something that ID will fix on their end?

I don't see any other reason for Valve not reporting/fixing it there 🤔

Can confirm that the game does work on my 7900XT Arch Linux system after installing mesa with the diff ColinSalem posted. For readers who aren't sure what to do with it, here's the steps I took:

1. Clone the mesa-git repository from the AUR (git clone https://aur.archlinux.org/mesa-git)
2. Move into the newly created directory
3. Create a file named tda.patch and paste in the diff
4. Apply the patch with patch PKGBUILD < tda.patch
5. Compile and install with makepkg -sic

Enabling FSR frame generation gave me a black screen, and after deleting my prefix to try and reset my settings I've unfortunately tripped Denuvo's activation limit.

Curiously, I don't see any commit / MR / Issue on upstream mesa...

It's up now: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34944

@bsmntoid I'm in the same situation as you with black screen on FSR Frame Gen, but I haven't tripped Denuvo & trying to avoid that.

@bsmntoid I'm in the same situation as you with black screen on FSR Frame Gen, but I haven't tried Denuvo & trying to avoid that.

Disable temporally cloud-saves and delete the prefix to go back to default config

@alosarjos Wouldn't deleting the prefix be what trips Denuvo?

@alosarjos Wouldn't deleting the prefix be what trips Denuvo?

Yes, you can only do it like 5 times a day max or something like that. For one time there is no problem

If you DO trip Denuvo, the game will still work if you play it on another Steam account via family sharing.

FSR framegen does indeed result in a blackscreen. Struggling to disable it too, deleting the prefix didn't work, validating files didn't work. Anyone got any ideas?

FSR framegen does indeed result in a blackscreen. Struggling to disable it too, deleting the prefix didn't work, validating files didn't work. Anyone got any ideas?

Disable cloud saves first and then delete the prefix

FSR framegen does indeed result in a blackscreen. Struggling to disable it too, deleting the prefix didn't work, validating files didn't work. Anyone got any ideas?

Disable cloud saves first and then delete the prefix

Still not resetting my config

Edit:

Looks like you need to disable cloud saves, close steam, delete the prefix and delete the local cloud save data. At least I had to.

The way I fixed the fsr issue on nvidia was by deleting the amd fx fidelity DLL and then restarting the game

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issue-3058471061

I'm running into similar issues here, enabling DLSS Frame Gen causes purple screen. HDR doesn't need to be enabled though for it to occur.

on fedora, i switched back to the original mesa:

sudo dnf swap mesa-va-drivers mesa-va-drivers-freeworld
sudo dnf swap mesa-vdpau-drivers mesa-vdpau-drivers-freeworld
sudo dnf swap mesa-va-drivers.i686 mesa-va-drivers-freeworld.i686
sudo dnf swap mesa-vdpau-drivers.i686 mesa-vdpau-drivers-freeworld.i686

NOTE: upgrade will fail due dependency errors if u do not switch back to original mesa!

then, i enabled this repo: https://copr.fedorainfracloud.org/coprs/xxmitsu/mesa-git/

That installed the following:

Upgrading:
 mesa-dri-drivers                                                                                                                                    i686                         25.2.0-0.3.20250513.10.4b73d7e.fc42                                                                                                                  mesa-git-x86                                                                             48.5 MiB
   replacing mesa-dri-drivers                                                                                                                        i686                         25.0.4-2.fc42                                                                                                                                        updates                                                                                 172.8 MiB
 mesa-dri-drivers                                                                                                                                    x86_64                       25.2.0-0.3.20250513.10.4b73d7e.fc42                                                                                                                  mesa-git                                                                                 45.1 MiB
   replacing mesa-dri-drivers                                                                                                                        x86_64                       25.0.4-2.fc42                                                                                                                                        updates                                                                                 164.5 MiB
 mesa-filesystem                                                                                                                                     i686                         25.2.0-0.3.20250513.10.4b73d7e.fc42                                                                                                                  mesa-git-x86                                                                              3.6 KiB
   replacing mesa-filesystem                                                                                                                         i686                         25.0.4-2.fc42                                                                                                                                        updates                                                                                   3.6 KiB
 mesa-filesystem                                                                                                                                     x86_64                       25.2.0-0.3.20250513.10.4b73d7e.fc42                                                                                                                  mesa-git                                                                                  3.6 KiB
   replacing mesa-filesystem                                                                                                                         x86_64                       25.0.4-2.fc42                                                                                                                                        updates                                                                                   3.6 KiB
 mesa-libEGL                                                                                                                                         i686                         25.2.0-0.3.20250513.10.4b73d7e.fc42                                                                                                                  mesa-git-x86                                                                            349.8 KiB
   replacing mesa-libEGL                                                                                                                             i686                         25.0.4-2.fc42                                                                                                                                        updates                                                                                 349.8 KiB
 mesa-libEGL                                                                                                                                         x86_64                       25.2.0-0.3.20250513.10.4b73d7e.fc42                                                                                                                  mesa-git                                                                                335.0 KiB
   replacing mesa-libEGL                                                                                                                             x86_64                       25.0.4-2.fc42                                                                                                                                        updates                                                                                 335.2 KiB
 mesa-libGL                                                                                                                                          i686                         25.2.0-0.3.20250513.10.4b73d7e.fc42                                                                                                                  mesa-git-x86                                                                            337.6 KiB
   replacing mesa-libGL                                                                                                                              i686                         25.0.4-2.fc42                                                                                                                                        updates                                                                                 447.4 KiB
 mesa-libGL                                                                                                                                          x86_64                       25.2.0-0.3.20250513.10.4b73d7e.fc42                                                                                                                  mesa-git                                                                                306.3 KiB
   replacing mesa-libGL                                                                                                                              x86_64                       25.0.4-2.fc42                                                                                                                                        updates                                                                                 420.2 KiB
 mesa-libGL-devel                                                                                                                                    x86_64                       25.2.0-0.3.20250513.10.4b73d7e.fc42                                                                                                                  mesa-git                                                                                 80.8 KiB
   replacing mesa-libGL-devel                                                                                                                        x86_64                       25.0.4-2.fc42                                                                                                                                        updates                                                                                  80.8 KiB
 mesa-libgbm                                                                                                                                         i686                         25.2.0-0.3.20250513.10.4b73d7e.fc42                                                                                                                  mesa-git-x86                                                                             85.7 KiB
   replacing mesa-libgbm                                                                                                                             i686                         25.0.4-2.fc42                                                                                                                                        updates                                                                                  18.9 KiB
 mesa-libgbm                                                                                                                                         x86_64                       25.2.0-0.3.20250513.10.4b73d7e.fc42                                                                                                                  mesa-git                                                                                 87.4 KiB
   replacing mesa-libgbm                                                                                                                             x86_64                       25.0.4-2.fc42                                                                                                                                        updates                                                                                  19.7 KiB
 mesa-libgbm-devel                                                                                                                                   x86_64                       25.2.0-0.3.20250513.10.4b73d7e.fc42                                                                                                                  mesa-git                                                                                 18.9 KiB
   replacing mesa-libgbm-devel                                                                                                                       x86_64                       25.0.4-2.fc42                                                                                                                                        updates                                                                                  18.9 KiB
 mesa-va-drivers                                                                                                                                     i686                         25.2.0-0.3.20250513.10.4b73d7e.fc42                                                                                                                  mesa-git-x86                                                                            116.0   B
   replacing mesa-va-drivers                                                                                                                         i686                         25.0.4-2.fc42                                                                                                                                        updates                                                                                  92.0   B
 mesa-va-drivers                                                                                                                                     x86_64                       25.2.0-0.3.20250513.10.4b73d7e.fc42                                                                                                                  mesa-git                                                                                116.0   B
   replacing mesa-va-drivers                                                                                                                         x86_64                       25.0.4-2.fc42                                                                                                                                        updates                                                                                  92.0   B
 mesa-vdpau-drivers                                                                                                                                  i686                         25.2.0-0.3.20250513.10.4b73d7e.fc42                                                                                                                  mesa-git-x86                                                                            318.0   B
   replacing mesa-vdpau-drivers                                                                                                                      i686                         25.0.4-2.fc42                                                                                                                                        updates                                                                                 294.0   B
 mesa-vulkan-drivers                                                                                                                                 i686                         25.2.0-0.3.20250513.10.4b73d7e.fc42                                                                                                                  mesa-git-x86                                                                            122.4 MiB
   replacing mesa-vulkan-drivers                                                                                                                     i686                         25.0.4-2.fc42                                                                                                                                        updates                                                                                 118.4 MiB
 mesa-vulkan-drivers                                                                                                                                 x86_64                       25.2.0-0.3.20250513.10.4b73d7e.fc42                                                                                                                  mesa-git                                                                                119.2 MiB
   replacing mesa-vulkan-drivers                                                                                                                     x86_64                       25.0.4-2.fc42                                                                                                                                        updates                                                                                 114.8 MiB
Installing dependencies:
 mesa-vdpau-drivers                                                                                                                                  x86_64                       25.2.0-0.3.20250513.10.4b73d7e.fc42                                                                                                                  mesa-git                                                                                318.0   B

then looking in

cat /usr/share/drirc.d/00-radv-defaults.conf | grep DOOM
        <application name="DOOM VFR" application_name_match="DOOM_VFR">
        <application name="DOOM Eternal" application_name_match="DOOMEternal">
        <application name="DOOM (2016)" application_name_match="DOOM$">

it seems doom eternal is not there. strange, since that repo builds from mesa gitlab a hour afther a new update has been detected. The last build time of the copr was 3 hours ago. this copr is the closest to mesa git, and the pr was merged, but i do not see it. do i need to add it myselfes?

According to the package version, this is a build from commit 4b73d7e. This is from before the MR was merged (see https://gitlab.freedesktop.org/mesa/mesa/-/commits/main - 4b73d7e corresponds to "radv: fix SDMA copies for linear 96-bits formats")

I'm not sure when the packages will be updated again, but you may need to wait some more.

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2875705205

Where was the local cloud save data stored? I was able to hunt down where the prefix was hidden but I'm not sure where the cloud save data is.

According to the package version, this is a build from commit 4b73d7e. This is from before the MR was merged (see https://gitlab.freedesktop.org/mesa/mesa/-/commits/main - 4b73d7e corresponds to "radv: fix SDMA copies for linear 96-bits formats")

I'm not sure when the packages will be updated again, but you may need to wait some more.

waiting it is then. i was looking if the game runnes on linux. appears i will need to wait some time then. patience it is.

@pixelcluster I see you are doing a lot of work on mesa :D Not sure if this is the best way, if I can help testing any of the MR you have (I'm using an AMD 7800XT) let me know :D

For those using Flatpak Steam: Here's how to get this working:

For the game to run, you need a mesa with this PR applied. It was merged, but has not yet made it into a released version of mesa. As such, we will need to build mesa ourselves. Luckily, there is this flatpak package designed for exactly this purpose. So what we'll do is the following:

• install the buildstream python package (make sure it's as new as possible, as that will save us work)
• Clone the repo
• Get the runtime steam is currently using with flatpak info --show-runtime com.valvesoftware.Steam (in my case, I get org.freedesktop.Platform/x86_64/24.08)
• Checkout the corresponding branch in the mesa-git-extension repo (in my case, that's git checkout release/24.08)

Now we need to tell it what version of git it should build. The PR was merged as the commit 4339cf0aff0d23d70a9acb6adbc92ac35a542611 so that is our git-ref

• Modify the elements/mesa-sources.yml file in the repo, pointing it to our commit (the ref: 25.1-branchpoint-1108-gef63e3e4d211e491164fea8ec494fdf7ca71d9c8 line needs to be changed to ref: 4339cf0aff0d23d70a9acb6adbc92ac35a542611)
• As we are using a specific commit, the build system's way of extracting the commit will break, so we need to also modify the elements/mesa-metainfo.yml and replace the CURRENT_REF=$(git describe --match *branchpoint*) with CURRENT_REF=4339cf0aff0d23d70a9acb6adbc92ac35a542611

This should be everything needed to get the mesa-git package to compile. Now to compile and install it, we simply do:

• make export-repo ARCH=x86_64 REPO=repo
• make export-repo ARCH=i686 REPO=repo
• Make sure you have no other instances of mesa-git installed with flatpak uninstall org.freedesktop.Platform.GL.mesa-git org.freedesktop.Platform.GL32.mesa-git
• flatpak install ./repo org.freedesktop.Platform.GL.mesa-git
• flatpak install ./repo org.freedesktop.Platform.GL32.mesa-git

Now we should have a fixed version of mesa installed for flatpak. To now use that, we need to start steam as FLATPAK_GL_DRIVERS=mesa-git flatpak run com.valvesoftware.Steam. Now the radv_force_64k_sparse_alignment fix should be in effect.

With that fix, I can confirm, that the game runs on my RX 5700 XT:

Fedora 42, AMD Ryzen 7 7800x3d, AMD 9070, proton experimental bleeding edge

Crash at Bethesda logo, currently banned by Denuvo :|

OS: Arch Linux x86_64
Kernel: Linux 6.14.6-arch1-1
CPU: AMD Ryzen 9 5900X (24) @ 4.95 GHz
GPU: AMD RX 9070/9070 XT [Discrete]
mesa from main#a87c9bc49ee426514eb617e048413ae663586f8b

I just took mesa-git from AUR and removed zink and d3d12 to fix compilation errors:

-D gallium-drivers=r300,r600,radeonsi,nouveau,virgl,svga,softpipe,llvmpipe,i915,iris,crocus

@0x000C0A71 Could you help me? I've sent you an email, I've got the same gpu.

OS: Arch Linux
Kernel: Linux 6.14.6-zen1-1-zen
CPU: AMD Ryzen 9 7900X3D (24) @ 5.66 GHz
GPU: NVIDIA GeForce RTX 4070 Ti SUPER
Driver: 570.144

The game itself runs great at 200+ FPS on HIGH settings but unfortunately I can confirm setting Frame Gen to ON causes the game image to turn Purple. I have tried various combinations with HDR/DLSS on and off but Frame Gen seems to be the culprit. Hope this gets fixed soon!

OS: Fedora 41
Kernel: Linux 6.14.5-200.fc41.x86_64
CPU: AMD Ryzen 9 7900X3D (24) @ 5.66 GHz
GPU: AMD Radeon RX 7900 XTX
OpenGL version string: 4.6 (Compatibility Profile) Mesa 25.2.0-devel (git-da7c716869)

I built Mesa from source using this guide and tweaked my environment variables to use it instead of the Mesa package from my distro.

I am now able to make it past the initial logos, but as soon as the final health warning message disappears and the game attempts to load the main menu, it crashes.
Before doing this I would get an instant crash at the initial Bethesda logo splashscreen, so its progress. I'm pretty sure the version of Mesa I built includes pixelcluster's commits, so I don't think that's the problem anymore.

If there's something obvious I'm missing please let me know. I'm pretty comfortable with Linux, but this is my first time attempting something like this.

@curtmgray

Where was the local cloud save data stored? I was able to hunt down where the prefix was hidden but I'm not sure where the cloud save data is.

<your steam directory>/userdata/255003801/3017860

Your steam directory is the one that has the following paths (as you likely know these):
<your steam directory>/steamapps/common/<game>: Where your game files are. That's where you get when you right-click on a game -> manage -> browse local files

If you want to reset settings, you might have to delete the prefix aswell, as there are DOOM config files in there aswell

For those using an AMD GPU and not sure how to fix game crashes, here's a one-line command to install everything, fix compilation issues, and compile the latest mesa-git. After that, the game works just fine for me.

git clone https://aur.archlinux.org/mesa-git.git && cd mesa-git && sed -i 's/-D gallium-drivers=[^ ]*/-D gallium-drivers=r300,r600,radeonsi,nouveau,virgl,svga,softpipe,llvmpipe,i915,iris,crocus/' PKGBUILD && makepkg -si 

Can confirm on a RTX 5090 running the latest beta 575.51.02 driver on PopOS! alpha 7. Game crashes almost immediately after enabling FG, GameScope is utterly broken with it on. Crashes immediately after the splash screen. Purple hue all over the screen without Gamescope before another immediate crash to desktop.

Does anyone know where the settings file is on the install? The game is now completely unplayable. No way to stop it falling over.

Now Denovo has locked me out of a game I paid extra to play early FFS. Wasn't this tested. For a major release that has already had a patch to Proton pushed out, it's pretty bad. That wasn't checked.

Now Denovo has locked me out of a game I paid extra to play early FFS. Wasn't this tested. For a major release that has already had a patch to Proton pushed out, it's pretty bad. That wasn't checked.

This pretty much happens with any Bethesda+Denuvo release since Doom: Eternal. Sometimes the ban doesn't actually last 24 hours and other times it does. There's no way to submit a ticket or anything to get the ban removed so you're just out any Deluxe edition early release money. 🙃 If you open a bethesda support ticket they might give you 1xp or something for your troubles.

and tbc this is a "Denuvo is stupid" problem and not a Proton problem

Quick tip: Make an alt steam account and add it to your family sharing. I'm pretty sure that still works but I haven't bothered since it seems like this is related to a missing mesa feature so I'm just waiting.

Oh mannn, i just can not get it to get past the startup logo. It keeps crashing after a few seconds.

OS: EndeavourOS x86_64
Kernel: Linux 6.14.6-arch1-1
WM: Hyprland 0.49.0-4-g60cd5b7a4 (Wayland)
CPU: AMD Ryzen 9 5900X (24)
GPU 1: AMD Radeon RX 6900 XT [Discrete]

Mesa / Vulkan:

$ glxinfo | grep "OpenGL version"
OpenGL version string: 4.6 (Compatibility Profile) Mesa 25.2.0-devel (git-a87c9bc49e)
$ vulkaninfo | grep "Vulkan Instance Version"
Vulkan Instance Version: 1.4.313

I used the same commit as @Keroosha

main#a87c9bc49ee426514eb617e048413ae663586f8b

Changed the gallium-drivers
-D gallium-drivers=r300,r600,radeonsi,nouveau,virgl,svga,softpipe,llvmpipe,i915,iris,crocus

After rebooting still with the same problem of only the logo showing up.

Currently using proton experimental bleeding edge

FOR FELLOW BANNED DENUVO PLAYERS

If you have a second steam account you can use family sharing to get around the ban by playing on the other account.

This sadly didn't work for me. I am using proton experimental bleeding edge.

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2877922246

Sooo after some more fiddeling around i found a solution for me. Since i have never build mesa before i simply just did it in ~/Documents 🤷🏻.

My gamescope simply didn't run because it couldn't find the Vulkan ICD or something with the error [Error] vulkan: vkAllocateDescriptorSets failed SDL_Vulkan_CreateSurface failed: VK_KHR_wayland_surface extension is not enabled in the Vulkan instance.terminate called without an active exception.

To fix this I created the following run-gamescope.sh:

#!/bin/bash

export LD_LIBRARY_PATH="/home/roy/Documents/mesa-git/pkg/mesa-git/usr/lib:$LD_LIBRARY_PATH"
export VK_ICD_FILENAMES="/home/roy/Documents/mesa-git/pkg/mesa-git/usr/share/vulkan/icd.d/radeon_icd.x86_64.json"
export VK_LAYER_PATH="/home/roy/Documents/mesa-git/pkg/mesa-git/usr/share/vulkan/implicit_layer.d"

exec gamescope "$@"

Slapped some exec permissions on it chmod +x ./run-gamescope.sh.
And threw that in the steam launch options:
/home/roy/Documents/run-gamescope.sh -W 2160 -H 1440 -r 144 -- %command%

For mesa-git I used the command from @ZhL0b1X

git clone https://aur.archlinux.org/mesa-git.git && cd mesa-git && sed -i 's/-D gallium-drivers=[^ ]*/-D gallium-drivers=r300,r600,radeonsi,nouveau,virgl,svga,softpipe,llvmpipe,i915,iris,crocus/' PKGBUILD && makepkg -si 

This solution is definitly not a great one! But it enables me to play doom without having to wait for a mesa release :)

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2877979711

I was referring to the FG issue and the inability to get into the game to turn it off.

Luckily I had left the game installing onto my ROG Ally running Bazzite. Out of curiosity to see how it ran. So I've just spent the last hour or so playing the game on that device. Moral of the story install the game in more than one place...before breaking it.

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2876666242

I just followed this on Fedora 42 which updated my Mesa version to 25.2.0-devel. I can now play DOOM The Dark Ages on my 6800XT! Just played about an hour without issues.

I just followed this on Fedora 42 which updated my Mesa version to 25.2.0-devel. I can now play DOOM The Dark Ages on my 6800XT! Just played about an hour without issues.

Can confirm (now that I'm not denovo banned) that it works after a quick sudo dnf copr enable xxmitsu/mesa-git and update

For those using an AMD GPU and not sure how to fix game crashes, here's a one-line command to install everything, fix compilation issues, and compile the latest mesa-git. After that, the game works just fine for me.

git clone https://aur.archlinux.org/mesa-git.git && cd mesa-git && sed -i 's/-D gallium-drivers=[^ ]*/-D gallium-drivers=r300,r600,radeonsi,nouveau,virgl,svga,softpipe,llvmpipe,i915,iris,crocus/' PKGBUILD && makepkg -si 

And how do I revert back to the non-git mesa after they released the fix or I finished the game?

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2878843729

@FokiSensei Simply install mesa again using pacman

has anyone managed to make it work on Intel Arc system? I am using A750 and Mesa 25.1.0 and the game freezes upon title showed

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2878464711

that is good to hear glad it helped you. seems they updated it. it is set to build after x hours of the original mesa, if there is a update.

ofc, afther enablding the repo do sudo dnf up -y --refresh if u want to revert it, disable the repo and do sudo dnf distro-sync

also this is the correct command to fix the dependency issues at least in my case

sudo dnf swap mesa-va-drivers-freeworld mesa-va-drivers
sudo dnf swap mesa-vdpau-drivers-freeworld mesa-vdpau-drivers
sudo dnf swap mesa-va-drivers-freeworld.i686 mesa-va-drivers.i686
sudo dnf swap mesa-vdpau-drivers-freeworld.i686 mesa-vdpau-drivers.i686

that fixed the issues with the mesa from the rpm fushion repo

and now its there

cat /usr/share/drirc.d/00-radv-defaults.conf | grep DOOM
        <application name="DOOM VFR" application_name_match="DOOM_VFR">
        <application name="DOOM Eternal" application_name_match="DOOMEternal">
        <application name="DOOM (2016)" application_name_match="DOOM$">
        <application name="DOOM: The Dark Ages" application_name_match="DOOMTheDarkAges">

With a 7900xtx im getting froze on the loading screen right before the main menu.

Built latest mesa from source (which got me past the bethesda logo crash)

Now it gets to loading screen then when mouse cursor appears it goes black. Music continues to play and i can close out of it but i dont see the main menu

Anyone else experiencing this?

@aamaanaa Hi, I'm new to linux, only using it for this game. How do I enable the repo that you just told about?

@aamaanaa Hi, I'm new to linux, only using it for this game. How do I enable the repo that you just told about?

In a terminal:

sudo dnf copr enable xxmitsu/mesa-git
sudo dnf up -y --refresh

follow instructions in my other comment.

Okay @aamaanaa , I just ran this command that you told me in the last comment. it's installing something.

Just seeing this. Do I need to add patches myself? Compiled mesa-git this morning and the game launched. Tho upon enabling fsr frame generation it started to have only black screen. Also be careful changing proton versions because the launcher counts that as validations and you will be locked for 24 hours.........

Just seeing this. Do I need to add patches myself? Compiled mesa-git this morning and the game launched. Tho upon enabling fsr frame generation it started to have only black screen. Also be careful changing proton versions because the launcher counts that as validations and you will be locked for 24 hours.........

i have enabled fsr frame gen and now i have a black screen.... no option from internet helped. i wonder if there is a way to reset all graphics settings to default without doing it in the game

Just seeing this. Do I need to add patches myself? Compiled mesa-git this morning and the game launched. Tho upon enabling fsr frame generation it started to have only black screen. Also be careful changing proton versions because the launcher counts that as validations and you will be locked for 24 hours.........

i have enabled fsr frame gen and now i have a black screen.... no option from internet helped. i wonder if there is a way to reset all graphics settings to default without doing it in the game

just don't go around messing with different protons if you don't wish to access your game after 24 hours... Also wondering if there is some ini or config? Deleted compatdata, did not remove the saved settings.

You can do this without deleting saves nor your cloud saves lol:

• Open steam
• Right click Doom: Dark Ages > Manage > Browse local files
• Open "amd-ffx"
• Rename "amd_fidelityfx_vk.dll" to like "amd_fidelityfx_vk.dll.old"
• Open the game
• Disable frame gen
• Close the game
• Rename "amd_fidelityfx_vk.dll.old" back to "amd_fidelityfx_vk.dll"

No saves were harmed in the making of these instructions.

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2880737270

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2881096111

well haha if i had knew that before.... but i thought it was simply impossible to get to the settings menu if u did not clear it all. guess i learned something new.

@aamaanaa thanks alot, the game runs now.

@0x000C0A71 Thanks alot to you, for helping out, especially with ours being the same non rt gpu.

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2877881450

Same gpu as you with same issue (black screen instead of main menu). Were you able to resolve it?

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

Same gpu as you with same issue (black screen instead of main menu). Were you able to resolve it?

black screen look at my comment and SuperMewio comment.
for latest mesa, no need to compile ur self on fedora. look at my comment for using the latest mesa from the copr repo. it is mesa from git, already build for fedora. enable it and do a update. that is it. dont enable frame gen. it causes black screen.

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

Same gpu as you with same issue (black screen instead of main menu). Were you able to resolve it?

black screen look at my comment and SuperMewio comment. for latest mesa, no need to compile ur self on fedora. look at my comment for using the latest mesa from the copr repo. it is mesa from git, already build for fedora. enable it and do a update. that is it. dont enable frame gen. it causes black screen.

Thanks

I'm currently on void linux so i had to self compile which went smooth and is reporting correctly. currently on git HEAD 7eb7a4d27813a3054090adef0810bb6a847e6447 as the only mesa on my system. All other games are working and vulkaninfo reports 25.2.0-devel

I haven't been able to get to the main menu at all so i couldn't of enabled frame gen (unless its on by default). Also have cleared my userdata(cloud saves off) and prefix. I figure its related to frame gen per other peoples comments but i haven't been able to make it to settings at all yet as it goes black after the loading screen

Thanks in Advance

Next problem on NVidia. On a 5090 on beta 575.51.2, PopOS Alpha 7, DLSS Quality, Ultra Nightmare settings and largest texture pool running via gamescope set to full screen at 4K res with VRR enabled and MangoHud. Trying to use a Sentinel shrine to upgrade weapons etc causes the game to become unresponsive and hang. Leaving it for 30s or so the game eventually responds. I've seen similar when a tutorial appears. EG in the second level when Shield recall jumps are introduced the game will hang and become unresponsive. Then again will eventually become responsive again. No idea if AMD cards will do the same.

There seems to be some problem with applying an overlay over the action.

Is anyone stuck at 60fps? Nvidia 4090.

No matter what graphic quality option, or even DLSS Ultra Performance it will not break 60fps but it's tacked at it so something feels off. Doesn't seem performance related at all but some setting or something.

Using Experimental.

Edit: Issue appears to be with Gamescope, runs at 120fps without it.

anyone got the patched mesa running on ubuntu?

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2881096111

You magnificent marvel! THANK YOU!

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2880716746

You can simply rename: amd_fidelityfx_vk.dll to amd_fidelityfx_vk.bak and launch the game and turn off frame gen, close the game and rename it back.

~/.local/share/Steam/steamapps/common/DOOMTheDarkAges/amd-ffx/

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2881096111

Thanks. It helped me a lot. I was looking for hours.

anyone got the patched mesa running on ubuntu?

Im attempting to do this right now but so far no luck.
After the most recent issues with ubuntu servevr as well , I'm probably going to switch to arch after this.

Anybody got a ntsync enabled proton running with this? I don't want to retry with the tkg proton I have as it errored out for not founding steam api (an we already discussed the 24h ban from swapping proton frequently). There seems to be some data that ntsync might benefit upscalers (also saw 20fps increase with ntsync with FSR FG on space marine 2). At this point on 1080 I see no point in using xess/fsr as they make the monitor be like is is smeared with vaseline in their quality presets. Native FSR has a bigger FPS impact than TAA so it is useless without FG. When FSR FG gets fixed the only benefit will be FSR NA FG plus maybe a nysync enabled proton.
P.S. maybe for the time being XeSS ultra ultra (whatever was pre AA) with setting sharpness to 2.0 is okayish. It provided 10 additional frames without making everything a blur. Again, maybe the way to go will be FSR NA FG when it is available.

The colorspace with HDR enabled looks purple if DLSS Frame Generation is also enabled.

It's framegen, not HDR - I can reproduce it without any HDR enabled.

Also, in my case - I can't pass loading screen is I enabled DLSS framegen

Finished first level without any issues, maybe this helps - I played on high settings with DLSS performance on 4K display.
My GPU is 5070, driver version is 575 beta (don't use stable because of smooth motion). Using Fedora 42 + KDE.

Have around 70-80+ frames per second, even in fights with many enemies and vfx

More like framegen and HDR issues is crappy NVIDIA blob issues.

Getting a GPU hang after ~30 minutes of gameplay.

6900XT, cachyos mesa 25.1.0-4
kernel 6.14.6-2-cachyos
cachyos proton 10.0.20250509-6

[ 2383.732753] amdgpu 0000:0b:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:4 pasid:32795)
[ 2383.732764] amdgpu 0000:0b:00.0: amdgpu:  in process Titan pid 14706 thread Foreground Work pid 14725
[ 2383.732767] amdgpu 0000:0b:00.0: amdgpu:   in page starting at address 0x0000000000000000 from client 0x1b (UTCL2)
[ 2383.732771] amdgpu 0000:0b:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00401030
[ 2383.732773] amdgpu 0000:0b:00.0: amdgpu:      Faulty UTCL2 client ID: TCP (0x8)
[ 2383.732776] amdgpu 0000:0b:00.0: amdgpu:      MORE_FAULTS: 0x0
[ 2383.732777] amdgpu 0000:0b:00.0: amdgpu:      WALKER_ERROR: 0x0
[ 2383.732779] amdgpu 0000:0b:00.0: amdgpu:      PERMISSION_FAULTS: 0x3
[ 2383.732780] amdgpu 0000:0b:00.0: amdgpu:      MAPPING_ERROR: 0x0
[ 2383.732782] amdgpu 0000:0b:00.0: amdgpu:      RW: 0x0
[ 2394.308490] amdgpu 0000:0b:00.0: amdgpu: Dumping IP State
[ 2394.310624] amdgpu 0000:0b:00.0: amdgpu: Dumping IP State Completed
[ 2394.320667] amdgpu 0000:0b:00.0: amdgpu: ring gfx_0.0.0 timeout, signaled seq=3000512, emitted seq=3000514
[ 2394.320670] amdgpu 0000:0b:00.0: amdgpu: Process information: process Titan pid 14706 thread Foreground Work pid 14723
[ 2394.320673] amdgpu 0000:0b:00.0: amdgpu: Starting gfx_0.0.0 ring reset
[ 2394.604769] amdgpu 0000:0b:00.0: amdgpu: Ring gfx_0.0.0 reset failure
[ 2394.604772] amdgpu 0000:0b:00.0: amdgpu: GPU reset begin!
[ 2398.604666] amdgpu 0000:0b:00.0: amdgpu: failed to suspend display audio
[ 2398.879685] amdgpu 0000:0b:00.0: amdgpu: MODE1 reset
[ 2398.879689] amdgpu 0000:0b:00.0: amdgpu: GPU mode1 reset
[ 2398.879759] amdgpu 0000:0b:00.0: amdgpu: GPU smu mode1 reset
[ 2398.950249] snd_hda_intel 0000:0b:00.1: spurious response 0x0:0x0, last cmd=0x3f7c00
[ 2398.950253] snd_hda_intel 0000:0b:00.1: spurious response 0x0:0x0, last cmd=0x3f7c00
[ 2398.950259] snd_hda_intel 0000:0b:00.1: spurious response 0x0:0x0, last cmd=0x3f7c00
[ 2398.950260] snd_hda_intel 0000:0b:00.1: spurious response 0x0:0x0, last cmd=0x3f7c00
[ 2398.950265] snd_hda_intel 0000:0b:00.1: spurious response 0x0:0x0, last cmd=0x3f7c00
[ 2398.950267] snd_hda_intel 0000:0b:00.1: spurious response 0x0:0x0, last cmd=0x3f7c00
[ 2398.950272] snd_hda_intel 0000:0b:00.1: spurious response 0x0:0x0, last cmd=0x3f7c00
[ 2398.950273] snd_hda_intel 0000:0b:00.1: spurious response 0x0:0x0, last cmd=0x3f7c00
[ 2399.380444] amdgpu 0000:0b:00.0: amdgpu: GPU reset succeeded, trying to resume
[ 2399.380687] [drm] PCIE GART of 512M enabled (table at 0x0000008000300000).
[ 2399.380717] [drm] VRAM is lost due to GPU reset!
[ 2399.380719] amdgpu 0000:0b:00.0: amdgpu: PSP is resuming...
[ 2399.459201] amdgpu 0000:0b:00.0: amdgpu: reserve 0xa00000 from 0x83fd000000 for PSP TMR
[ 2399.600325] amdgpu 0000:0b:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available
[ 2399.600328] amdgpu 0000:0b:00.0: amdgpu: SMU is resuming...
[ 2399.600332] amdgpu 0000:0b:00.0: amdgpu: smu driver if version = 0x00000040, smu fw if version = 0x00000041, smu fw program = 0, version = 0x003a5a00 (58.90.0)
[ 2399.600335] amdgpu 0000:0b:00.0: amdgpu: SMU driver if version not matched
[ 2399.600365] amdgpu 0000:0b:00.0: amdgpu: use vbios provided pptable
[ 2399.673710] amdgpu 0000:0b:00.0: amdgpu: SMU is resumed successfully!
[ 2399.674462] [drm] kiq ring mec 2 pipe 1 q 0
[ 2399.682918] [drm] DMUB hardware initialized: version=0x02020020
[ 2399.913334] amdgpu 0000:0b:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
[ 2399.913337] amdgpu 0000:0b:00.0: amdgpu: ring gfx_0.1.0 uses VM inv eng 1 on hub 0
[ 2399.913338] amdgpu 0000:0b:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 4 on hub 0
[ 2399.913340] amdgpu 0000:0b:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 5 on hub 0
[ 2399.913341] amdgpu 0000:0b:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 6 on hub 0
[ 2399.913342] amdgpu 0000:0b:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 7 on hub 0
[ 2399.913343] amdgpu 0000:0b:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 8 on hub 0
[ 2399.913344] amdgpu 0000:0b:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 9 on hub 0
[ 2399.913345] amdgpu 0000:0b:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 10 on hub 0
[ 2399.913346] amdgpu 0000:0b:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 11 on hub 0
[ 2399.913348] amdgpu 0000:0b:00.0: amdgpu: ring kiq_0.2.1.0 uses VM inv eng 12 on hub 0
[ 2399.913349] amdgpu 0000:0b:00.0: amdgpu: ring sdma0 uses VM inv eng 13 on hub 0
[ 2399.913350] amdgpu 0000:0b:00.0: amdgpu: ring sdma1 uses VM inv eng 14 on hub 0
[ 2399.913351] amdgpu 0000:0b:00.0: amdgpu: ring sdma2 uses VM inv eng 15 on hub 0
[ 2399.913352] amdgpu 0000:0b:00.0: amdgpu: ring sdma3 uses VM inv eng 16 on hub 0
[ 2399.913353] amdgpu 0000:0b:00.0: amdgpu: ring vcn_dec_0 uses VM inv eng 0 on hub 8
[ 2399.913355] amdgpu 0000:0b:00.0: amdgpu: ring vcn_enc_0.0 uses VM inv eng 1 on hub 8
[ 2399.913356] amdgpu 0000:0b:00.0: amdgpu: ring vcn_enc_0.1 uses VM inv eng 4 on hub 8
[ 2399.913357] amdgpu 0000:0b:00.0: amdgpu: ring vcn_dec_1 uses VM inv eng 5 on hub 8
[ 2399.913358] amdgpu 0000:0b:00.0: amdgpu: ring vcn_enc_1.0 uses VM inv eng 6 on hub 8
[ 2399.913359] amdgpu 0000:0b:00.0: amdgpu: ring vcn_enc_1.1 uses VM inv eng 7 on hub 8
[ 2399.913360] amdgpu 0000:0b:00.0: amdgpu: ring jpeg_dec uses VM inv eng 8 on hub 8
[ 2399.921728] amdgpu 0000:0b:00.0: amdgpu: GPU reset(2) succeeded!

I installed the game trough Battle.net, and the game does get past startup logos and into the menu, but the menu is a blackscreen with fsr, can only see the rain, and the game freezes if you try to play this way, after some experimentation I disable fsr and got a partial menu, still cant see any skins, only a few fire effects, installed new mesa-git and denuvo got me... tomorrow i'll try again.

I installed the game trough Battle.net, and the game does get past startup logos and into the menu, but the menu is a blackscreen with fsr, can only see the rain, and the game freezes if you try to play this way, after some experimentation I disable fsr and got a partial menu, still cant see any skins, only a few fire effects, installed new mesa-git and denuvo got me... tomorrow i'll try again.

Maybe try gamescope? FSR does work for me but only with gamescope.

In my case the game gets stuck at a loading screen. The main menu music plays in the background but I don't see anything else other than a loading screen icon and a cursor.

I'm running fedora 42 kde with custom mesa (25.0.6) compiled based on this guide:

and my gpu is rx 7600s (laptop gpu)

launch options: LD_LIBRARY_PATH="/opt/mesa-git/lib64:$LD_LIBRARY_PATH" OCL_ICD_VENDORS="/opt/mesa-git/etc/OpenCL/vendors" VK_DRIVER_FILES="/opt/mesa-git/share/vulkan/icd.d/radeon_icd.x86_64.json" %command% +com_skipIntroVideo 1

Edit: tried both proton experimental and proton-ge 10
Edit2: Got it working with https://copr.fedorainfracloud.org/coprs/xxmitsu/mesa-git/

steam-3017860.zip

fsr and xess are busted. I can only see rain being rendered. Taa doesn't experience this issue.

Has anyone else had the game crash in Chapter 5 when landing into a demonic ship?

Has anyone else had the game crash in Chapter 5 when landing into a demonic ship?

Having the exact same issue, i have opened an issue in the Mesa repository (gitlab.freedesktop.org/mesa/mesa/-/issues/13176)

Has anyone else had the game crash in Chapter 5 when landing into a demonic ship?

If you're using an amd gpu a temporary workaround while they take a look at it is to use amdvlk.

Maybe you guys are running older mesa or not properly compiled? mesa-minimal-git against llvm-minimal-git had no problems witch chapter 5 on my R6800. Compiled yesterday. Today compiled Mesa 25.2.0-devel (git-be3ce07f58). You can link amdvlk just for the game and use it but I went from 100fps with ravd to 80 with amdvlk.

FSR FG is doable with gamescope. FSR Quality FG gives me 90 extra frames for total of 190 but the input lag is bad. Native 90 is 100x times for fluid and better. FSR NAA FG is laggy. Needed vk_x11_ensure_min_image_count=true vk_x11_override_min_image_count=6 as launch options. Those were from a previous mesa bug that resulted in Eternal dropping FPS and regaining when I change volume or move the mouse. Without them FSR FG didn't want to generate frames.

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2887322259

I'm using Mesa 25.2.0-devel, also on an RDNA3 card

Rebuild it. There could be multiple commits for 25.2.0.

I got past chapter 5 with mesa bade93c4472ffb1ac843405ee506514f4cf25446 on a 7900xtx

Rebuild it. There could be multiple commits for 25.2.0.

I have tried git as well, I already reported it and someone is looking into it.

Has anyone else had the game crash in Chapter 5 when landing into a demonic ship?

that's happening to me too, tried every video config possible and still crashes

amd gpu, mesa git, proton experimental

You need Mesa Drivers 25.2

I got them for fedora from freeworld repot.

On Fri, May 16, 2025 at 7:17 PM AndresNagel @.***>
wrote:

AndresNagel left a comment (ValveSoftware/Proton#8690)
https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2887830355

Has anyone else had the game crash in Chapter 5 when landing into a
demonic ship?

that's happening to me too, tried every video config possible and still
crashes

amd gpu, mesa git, proton experimental

—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2887830355,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOG4NI4WSDTNSGVRQXEBBH326ZWZTAVCNFSM6AAAAAB47HDXSCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQOBXHAZTAMZVGU
.
You are receiving this because you commented.Message ID:
@.***>

Has anyone else had the game crash in Chapter 5 when landing into a demonic ship?

I fixed it by installing the amd86 and i386 .debs from the latest release https://github.com/GPUOpen-Drivers/AMDVLK/releases and then changing the launch options to

VK_ICD_FILENAMES=/etc/vulkan/icd.d/amd_icd64.json:/etc/vulkan/icd.d/amd_icd32.json radv_force_64k_sparse_alignment=true %command%

this is my mesa info

glxinfo | grep "OpenGL version"
OpenGL version string: 4.6 (Compatibility Profile) Mesa 25.2.0~git2505141914.ea4c1ceb79e~o~mesaaco10

also you can undo the changes in the commandline after that mission if you want to

So, after the denuvo lift, I tried Mesa 25.2.0, the game does starts I can see the bethesda and Id software logos then all I get is a black screen, no menu at all. But the pc won't crash, just the game.

followed by this with only mouse cursor visible

If I roll back to the arch repo version 25.0.5 I got this:

Wich is somewhat closer, if I enable FSR I got the black screen with the rain only, reported here already. So overall cant run the game, proton experimental bleeding edge, Mesa 25.0.5 or Mesa 25.2.0.

Im running the game trough Battle.net over Game pass, not the steam version, this might have something to do with it.

If I try to start a new game while on Mesa 25.0.5 I get a crash with the game going black after the two starting quotes about the Slayer with a Ring gfx timeout with soft recover.

dmesg25.0.5.txt
steam-25.0.5.log

with 25.2.0 the black screen comes just after the initials video as mentioned prior
here is the dmesg
dmesg25.2.0.txt
and the proton log for some reason is 1.4GB now
steam-25.0.2.log.tar.gz

Hope this helps. Game runs with no issues on Windows.

CPU Ryzen 7 3800X
GPU XFX Radeon 7800XT Core Edition 16GB
32 GB Ram
Arch Linux x86_x64
Kernel: 6.14.6-arch1-1

Here are the systemreport and systeminfo from steam:

systeminfo.txt
systemreport.txt

You are compiling mesa-git with the proper llvm as per instructions, right?

llvm from extra, and I set the MESA_WICH_LLVM=4, I can try compiling with llvm-minimal-git as in the PKGBUILD comment recommends.

I tried cloning and using the instructions here https://gitlab.freedesktop.org/mesa/mesa, but when I do this for some reason, vulkan did not changed version in my setup, neither glxinfo | grep "OpenGL version" reported the new version, I will try again both ways and report back.

Getting a GPU hang after ~30 minutes of gameplay.

6900XT, cachyos mesa 25.1.0-4 kernel 6.14.6-2-cachyos cachyos proton 10.0.20250509-6
Click to expand

I'm also getting GPU hangs. While it only happened once during the first half of the game, I have ran into three of them in the past hour, it's really quite frustrating.

Getting a GPU hang after ~30 minutes of gameplay.
6900XT, cachyos mesa 25.1.0-4 kernel 6.14.6-2-cachyos cachyos proton 10.0.20250509-6
Click to expand

I'm also getting GPU hangs. While it only happened once during the first half of the game, I have ran into three of them in the past hour, it's really quite frustrating.

You can use amdvlk for now as a workaround, you can just set it for that specific game.

I'll give that a try and see how that pans out for me. Just as a heads up it's level 16 of the game that's crashing my GPU the most, 3 times in the span of an hour. If it happens again then let me know if there's any other info I should post to help anyone figure out the cause of these GPU crashes.

I'll give that a try and see how that pans out for me. Just as a heads up it's level 16 of the game that's crashing my GPU the most, 3 times in the span of an hour. If it happens again then let me know if there's any other info I should post to help anyone figure out the cause of these GPU crashes.

There's currently an open Mesa issue if you're interested, https://gitlab.freedesktop.org/mesa/mesa/-/issues/13176

You can use amdvlk for now as a workaround, you can just set it for that specific game.

Yeah and get a 20% reduction in performance. I'm pretty sure you guys have issues from poorly compiled mesa. AMDVLK isn't a fix for badly compiled mesa.. I'm going through level after level with my rx6800 with no issues. git-be3ce07f58 + proton bleeding.

@ruinedraziel compile mesa-minimal-git as it compiles less things (same maintainer as mesa-git). Use my script and guide if you need to:
https://github.com/d3vilguard/mesa-minimal-git-script

P.S. VkKhrDynamicRendering, I can't say if RDNA3 specific until I see one running proper mesa. The 6900 RDNA2 user has old mesa and a RDNA2 card. You are suggesting AMDVLK to a user using 25.1.0 which by your own bug report you know is pre-fixes that will drop in 25.1.1 yet I am cocky. Proper mesa might as well fix the issue instead of band-aiding it with AMVDLK. I'm not "cocky" about it. Most people just mash y in YAY or use strange prebuilds.

As ruinedraziel said, his mesa-git is compiled against llvm in extra. Numerous times I had issues with mesa compiled that way before I started doing it like it needs to be done, with llvm-git.

You can use amdvlk for now as a workaround, you can just set it for that specific game.

Yeah and get a 20% reduction in performance. I'm pretty sure you guys have issues from poorly compiled mesa. AMDVLK isn't a fix for badly compiled mesa.. I'm going through level after level with my rx6800 with no issues. git-be3ce07f58 + proton bleeding.

@ruinedraziel compile mesa-minimal-git as it compiles less things (same maintainer as mesa-git). Use my script and guide if you need to: d3vilguard/mesa-minimal-git-script

Dude this is not a "poorly compiled" mesa, i have tried that and it in fact did not work, also the "20% performance reduction" doesn't even matter when the alternative is your gpu crashing, are you even thinking right now?
Stop being so cocky about it.
You're also running an RDNA2 card and not RDNA3.

You can use amdvlk for now as a workaround, you can just set it for that specific game.

Yeah and get a 20% reduction in performance. I'm pretty sure you guys have issues from poorly compiled mesa. AMDVLK isn't a fix for badly compiled mesa.. I'm going through level after level with my rx6800 with no issues. git-be3ce07f58 + proton bleeding.

@ruinedraziel compile mesa-minimal-git as it compiles less things (same maintainer as mesa-git). Use my script and guide if you need to: https://github.com/d3vilguard/mesa-minimal-git-script

Actually there seems to be a radv bug or something similar to when the Indy game came out, amdvlk actually performs MUCH better than radv/mesa currently.

So, couple of things, first here:

Installed llvm-minimal-git as recommend in the PKGBUILD, change MESA_WICH_LLVM to 1 and cleanroot compiled mesa-git, however I can't say for sure if this has anything to do it as the maintaner updated the mesa-git package today and the version of the commit now is newer, so it could be a merge that fixed, could be the compilation... hope this help you guys as well.

As I said above, previously I had issues compiling mesa with old llvm as in Extra - game crashes, not properly displaying textures. There is a reason for it recommended do be done with git llvm. For me RAVD beats AMDVLK in the menu. In game maybe, just maybe AMDVLK is 2~3 frames faster but I have to benchmark more scenes. Just compiled git-033ce1bae1 myself too.

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2888610459

They are on RDNA 4 while you are on RDNA 2.

Rdna 2 and 3 support is pretty mature in Mesa while Rdna 4 is not which in such cases it shows. When rdna 2 was the newest amd offered, at that time amdvlk was beating radv in games like Doom Eternal.

https://gitlab.freedesktop.org/mesa/mesa/-/issues/4315

For example.

So what people in this thread with rdna4 are seeing and what you are seeing are completely expected.

That's true but I'm strictly speaking for 2 and maybe 3. AMDVLK was suggested to a RDNA2 user despite clearly stated pre-workaround mesa installed. Was suggested to a RDNA3 user too which as it turns out needed a proper recompile. In both instances the issue was not in mesa or at least not requiring a switch to AMLDLK. I have no problem with it being recommended on RDNA4. Enough DOOM and drivers for today, goodnight slayers.

Using AMDVLK for Doom seems to abate the GPU crashes so far, but I will have to play until the end of the game to know for sure. With how much I am adoring this game, I can see myself doing a replay right after my first run, so playing through more missions after beating it will give me a better sense of whether the crashing issue is resolved with the AMDVLK workaround.

Though there is a slight increase in judder while playing and GPU temps seem higher overall, forcing me to lock the game to 60FPS for a smoother ride (would normally get a smooth 80-90FPS on RADV with my 6800XT). But I'll gladly take that slight hit in order to minimise these crashes.

Not sure if anyone else has experienced this, but on my system running an RTX 4080s every runs well except the Frame gen which I dont mind, but the Max FPS I get seems to be locked to the Refresh Rate of the panel, in my case 144hz. I dont mind since it runs well, but I would be nice to be able to run above it since its an First Person Shooter...

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2888721595

Did you enable triple buffering ? it is a form of vsync if im not mistaken!

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2888746951

Nope, no Vsync at all, no adaptive I set it to OFF and works on Windows but not Linux.

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2888748635

im CPU bound, so not really passing monitor spec, so I cant reproduce it to check. But you might be on to something then.

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2888749622

I have been able to replicate this on 3 different machines with different GPUs and Linux versions. So it may be related to Proton, I have tried only the latest Proton Hotfix and gamescope, havent tested experimental or other versions since the DRM would lock me out for 24h.

For anyone with AMD using a custom-compiled Mesa that is not installed system-wide (while an old Mesa is installed in the system), there need to be more adjustments in order for the workarounds to apply. This does not apply to people installing mesa-git packages from COPRs or AURs. If you need to add VK_DRIVER_FILES to your game launch arguments, you're affected by this, otherwise you aren't.

Put simply, even if you override the Vulkan drivers using VK_DRIVER_FILES, the new driver will look up per-game workaround using the system-wide config (which is from the old driver, and thus won't contain any of the workarounds for this game). Behavior without the workarounds is unpredictable, including but not limited to black screens when enabling FSR/XeSS or random GPU hangs.

If you set VK_DRIVER_FILES=<install>/share/vulkan/icd.d/radeon_icd.x86_64.json you should also add DRIRC_CONFIGDIR=<install>/share/drirc.d to your environment variables - only then will the driver pick up the correct workarounds. <install> is the install location of your driver, the exact path varies per system.

Note: Working around this by installing a custom-compiled Mesa system-wide is not a good idea. System-wide mesa installations should always come from a package manager (distro packages, COPRs/PPAs, AUR are all fine).

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

I have been able to replicate this on 3 different machines with different GPUs and Linux versions. So it may be related to Proton, I have tried only the latest Proton Hotfix and gamescope, havent tested experimental or other versions since the DRM would lock me out for 24h.

Just went back to Indiana Jones and The Great Circle and is doing the same, no vsync, no FPS limit and running upscaled should be able to go above 144FPS and it doesnt, the game uses a similar engine to the new Doom so maybe is that. Same behaviour with Doom Eternal.

Update: It looks like its something related to Vulkan/Wayland and possibly Nvidia Drivers, doesnt matter what settings I change or if I enable Adaptive Sync or not on the display panel, I use Kubuntu 25.04 and drivers 575 however IF I set Vulkan games to Windowed Mode I can get above 144FPS, on none Vulkan games it works fine.

@nuudlman @Mankybus I was also able to reproduce GPU hangs on RDNA2, so I've made a Mesa issue for it here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13197

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2887940470

This work awesome. I was using the RADV on my 9070XT. Framew were bad in some levels, around 40 to 50 FPS even on FSR quality. I applied this driver plus the shortcut on doom paramenters. Now the game is on Native on the same level around 130 fps. On FSR Quality goes up to 180 fps.

Awesome!.

I am using Intel Arc A750 with mesa-git and linux-6.15-rc7, the game won't get me into title screen and dmesg outputs some strange things, should I disable this umip thingy?

[  172.769858] x86/split lock detection: #AC: CHTTPClientThre/6803 took a split_lock trap at address: 0x568eb59f
[  230.002916] umip: DOOMTheDarkAges[7348] ip:1536fa073 sp:816250: SGDT instruction cannot be used by applications.
[  230.002921] umip: DOOMTheDarkAges[7348] ip:1536fa073 sp:816250: For now, expensive software emulation returns the result.
[  230.047550] x86/split lock detection: #AC: DOOMTheDarkAges/7348 took a split_lock trap at address: 0x154f288ab
[  231.452376] x86/split lock detection: #AC: Titan/7355 took a split_lock trap at address: 0x14df3e643
[  231.456907] umip: Titan[7348] ip:156cc6de8 sp:818480: SGDT instruction cannot be used by applications.
[  231.456911] umip: Titan[7348] ip:156cc6de8 sp:818480: For now, expensive software emulation returns the result.
[  267.626959] umip: Titan[7348] ip:11e8e59 sp:8119b0: SGDT instruction cannot be used by applications.
[  268.279213] x86/split lock detection: #AC: Foreground Work/7349 took a split_lock trap at address: 0x140727189

Those umip kernel messages are a red herring. It's telling you that a CPU instruction which isn't allowed happened, and a slower path was used to emulate the CPU instruction. If you were to disable the kernel workaround, it would most certainly be fatal to the game.

You'll probably want to keep an eye on https://gitlab.freedesktop.org/mesa/mesa/-/issues/13209.

Welp actually that issue is also written by me, I wasn't sure if it was mesa or proton's problem back then

Game will now refuse to run on Linux due to Denuvo:
https://support.codefusion.technology/anti-tamper/?e=88500005&l=en-US&p=s
This is the error. No proton changes were made. The token error ends in 6, this one ends in 5. Was running just fine last night. Today there was an update made to the game. Probably that did something.
P.S. so switching from experimental bleeding to just experimental seems to have fixed it. Although first I tried going from exp bleeding to GE 10-3 which should be based on exp bleeding build that was working (exp bleeding builds were working till last night for me). All of a sudden the non bleeding exp proton loaded the game. Now it could be version change or my writing in the denuvo prompt to get the limitation lifted on my account. I really can't say. I strongly recommend all here to maybe use a locked proton version for this game. Maybe a locked proton exp version that you update manually. Dealing with Denuvo unjust bans isn't fun.

@d3vilguard supply the proton log https://github.com/ValveSoftware/Proton/wiki/Proton-FAQ#how-to-enable-proton-logs

This will help Valve to either contact id Software directly or to help pin point what needs to be done in order for proton to work again.

ID could not screw its paying customers with malware such as Denuvo to begin with.
steam-3017860.log

Game will now refuse to run on Linux due to Denuvo:

Well that sucks! It's till working for me but I'm using Proton 10 beta. I did get locked out for 12 hours the day after playing for the first time when having tried several different Proton versions the day before.

That's simply not true. Please don't spread misinformation. I just installed the game as a member of a steam family and it works without issues. Yes, the proton switching part is still aggravating but the game itself does not refuse to work on Linux.

Comment was edited shortly after being posted. That wasn't your typicall of token error (different error number) and I'm pretty sure there was infact an issue with denuvo that wasn't due to proton switching that they fixed. And no proton switching was done. As I said that day a game update did drop and this happened after the silent update, tho got reverted within an hour after me reporting it in the denuvo prompt. Not enough proton switches were made (one update to proton from steam itself with no prefix regeneration) for it to use up the 5 tokens and have the 24 hour out of token lock (and again the error code is different for when out of tokens). I'm pretty sure there was infact an issue with denuvo at that point. No idea how many users were affected. It works as of now.

No Proton changes were made.

If you use the bleeding-edge version of proton, you receive very frequent updates (i.e. every few hours). Since the underlying system binaries change with every update, the DRM system will consider this a separate activation. Over the course of a day, this can cause the activation threshold to be exceeded - this is not an intentional blocking of Linux machines by the developers, but merely an (unfortunate) side effect of how bleeding-edge works.

It's probably best not to run bleeding-edge Proton on Denuvo games (or make sure the Proton version you're using won't change multiple times a day).

Technically yea but 1-2 updates were downloaded of exp bleeding within a long timeframe. Not enough to cause a lock and again, the error for that is different and I regained access within an hour. Out of token slaps you with 24. Most likely it was something with the update of the game/denuvo and it got reverted shortly after. I would too advice to stick to a locked version or just experimental non-bending. Tho for a few days I played with exp bleeding that was updating through the day with no issues. That was pre game update. If there was indeed an issue with denuvo after the silent game update, it got fixed.

Has anyone gotten frame generation to work?

Only through optiscaler which is sub-optimal. Built-in FSR frame gen decimates my framerate and I end up with 22 fps.

After the recent game update (think it was released 5/22), I've been having short stutters whenever I throw the shield more than a small distance. Seems like it's at least somewhat widespread -- see more examples and a demo on this Reddit thread.

Before the update game was smooth; I've not made any system changes since then.

I enabled logging with PROTON_LOG=1 -- it seems like lines like this are emitted anytime I experience a stutter:

15529.294:02b8:02bc:trace:seh:sigsys_handler SIGSYS, rax 0x9a, rip 0x1572078b1.
15530.335:02b8:02bc:trace:seh:sigsys_handler SIGSYS, rax 0x9a, rip 0x14fead873.
15530.347:02b8:02bc:trace:seh:sigsys_handler SIGSYS, rax 0x9a, rip 0x15027a392.
15530.574:02b8:02bc:trace:seh:sigsys_handler SIGSYS, rax 0x9a, rip 0x14d0dd1ee.
15572.366:02b8:02bc:trace:seh:sigsys_handler SIGSYS, rax 0x9a, rip 0x14e30b597.
15572.366:02b8:02bc:trace:seh:sigsys_handler SIGSYS, rax 0x9a, rip 0x156ebd6f1.

System Information

GPU: 7900 XTX
CPU i7-12700
Proton version: experimental-10.0-20250522b (on the thread sounds like folks have experienced it on older versions as well -- I'm trying to avoid a Denuvo lockout so haven't tried many others)
Kernel version: 6.14.7
Mesa version: 25.1.1 (also happens on mesa-git from 051825)

Only through optiscaler which is sub-optimal. Built-in FSR frame gen decimates my framerate and I end up with 22 fps.

I cant use the optiscaler frame gen since I am using vulkan to emulate raytracing but yeah I guess I have to wait till they fix amd frame gen on linux.

Anyone have further news on 'enabling framegen in Doom The Dark Ages with Nvidia card/Linux causes colour space to be messed up & magenta tinted screen' ?

Thanks in advance.

Edit - Clarity.

@Lawstorant I am really curious how you got frame gen to work with Optiscaler. Do you perhaps have an Nvidia card?
I have a 7900XTX. According to my own research regarding Optiscaler frame gen:

• OptiFG does only support DX12
• nuksems (dlssg‐to‐fsr3) does not work because fakenvapi fails the spoofing process and DLSS cannot be selected in-game. This is confirmed with the compatibility report here: https://github.com/cdozdil/OptiScaler/wiki/Doom-The-Dark-Ages

I tried it anyway with no luck.
I might add besides frame gen I have no issues with this game. FSR and XeSS upscaling are both working.

For those having crashes with mesa - try this. I had some random crashes with my rx6800 here and there and after compiling with this commit they seem to be gone.
Would also like to share this (older version of mesa-git) on a rx6800 (RDNA2):

I'm currently having an issue with doom the dark ages. I'm unable to select 3440x1440 whens selecting the 21:9 aspect ration, it only shows me 2560x1080.

I can select the native res of my screen which is 32:9, 5120x1440. But for performance reasons, I would like to be able to select 3440x1440.

Is that resolution selectable in your desktop environment -> is it in your monitor's EDID?

I've tried linux 6.15 kernel just released recently and switched to Proton Experimental bleeding edge, instead of drm timed out message, the proton logs went crazy, spamming a set of information in a period, taking over 300 megabytes in a few seconds, it takes like over 5 seconds for my vim to open it

steam-3017860.tar.gz

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2906980895

I activated PROTON_LOG and I'm having the same logs to print matching the stutters. Seems like the game is trying to make the syscall 154 which in 64bit systems i the modify_ldt function. I'm not sure but it looks like the kernel may be blocking it.

As I pointed above, this merge request for mesa has completely eliminated all random crashes on my RDNA2 rx6800. I'm going level after level without a single crash. I still would advice mesa-git getting compiled against llvm-git to ensure it works (I've had crashes years back when compiling it against normal llvm). Here is some gameplay, it's smooth.

Kernel 6.15 might have issues with this game on AMD cards (https://gitlab.freedesktop.org/drm/amd/-/issues/4263)

Unpopular opinion: I love Vsync. I don't care about going over 165 Hz it's just a non-issue for me and should be for 95% of gamers, just like the tearing thing. Of course, the choice to disable it should be there, but I wish it was always the default to vsync max refresh.

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2906980895

This also occurs with Nvidia GPUs (using the new open-source kernel module). I'm experiencing it on my 12700k + RTX 4080Super system.

HOWEVER - it seems isolated to 12k, 13k, and 14k Intel CPUs. I can't find any reports of this happening to anyone else, and when I tried it on my Ryzen 9 5900XT+RTX 5070 there was no stutter or CPU spike present in the performance metrics overlay.

reply to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2912562680

Not really, the compositor I run is hyprland and I'm not able to set 2560x1080 based on the output of hyprctlr monitors.

[email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected]

I tested using the latest proton experimental, hotfix and GE 10-3.

So yeah, your screen does not expose such resolution and games won't detect it. Windows games in 99% cases base resolutions on what's available to the system. They could just do different resolutions internally, but they don't. It's because on windows, games have this "exclusive fullscreen mode" when they actually directly take control of what's send to the device.

In linux desktops, there's no notion of exclusive fullscreen. You have something similar, which is direct scanout, but it still goes through the windowing system.

If you still want to play at 21:9 at that resolution, I'd look for 21:9 mode in your monitor's OSD OR use gamescope to force this resolution on the game.

reply to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2915824923

Sadly gamescope isnt an option, since nested VRR doesnt work properly (I'm unaware if this issue has been addressed with the lastest release). Sadly my monitor only offers a 16:9 mode, not 21:9.

You could try adding this resolution to edid yourself and praying for the best, but it's quite a hassle on linux. Do you maybe have access to windows so you could try with CRU?

reply to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-2915925920

Sadly no. I dont really plan to install windows for a single game.

how long do you guys think till the frame gen issue on linux becomes fixed ?

Finished game with Proton 10.0 - crashed once. Not because of proton, because of game bug. It works fine on 570-575 drivers from NVIDIA. Without FG, but whatever.

Finished game with Proton 10.0 - crashed once. Not because of proton, because of game bug. It works fine on 570-575 drivers from NVIDIA. Without FG, but whatever.

You make an interesting suggestion with this, I've got a media machine running Mint with an Nvidia GPU. I'd have to check driver versions but it may be worth experimenting with it. I also posted my logs and issue with Mesa. Wonder if trying the AMD driver would be worth it.

I forced use amkvlk for Starfield, ran into the same issue. I loaded an older save and it was fine. There was something with the saves of the Watchtower mod that were my problem.

Need to experiment with Doom more.

Update: Loaded an earlier save before starting Watchtower in Starfield, game ran fine for about 30 min. Quit willingly.

Decided to force amdvlk for Doom TDA, game will not start, Incompatible driver in the error box.

Game doesn't show up when running on Proton 10, works fine on 9.

I also have the purple issue when nvidia frame gen is on.

Also, since it is Denuvo: Do not try to change the Proton version too many times, you get locked out for 24 hours!

@kisak-valve, worked after reboot! I am on Proton 10.4 now :)

A few days and a few crashes later, I still can't upload the log, when trying to upload it even causes gist to give me a server error. Copy and paste from Kate does the same. Copying and pasting the text makes it look like the file itself is corrupted though I can read it in Kate.

I am getting crazy mouse warp after the recent update

Update: Not sure what happened, but the warp went away. Nothing to do with Proton!

Update2: It is back...

Game works well except for one oddity where it will not start in 21:9, after switching between Fullcreen and Borderless Windowed it will switch to 21:9.

Fullscreen is messed up on cosmic desktop! It took 45 minutes for me to fix it, don't set it to fullscreen on cosmic de 😆

When it comes to the purple/ pink image with DLSS frame gen on seems to be a Wayland problem? Or least a Linux window problem, the purple goes away if the game is not in focus. Currently on Bazzite KDE 6.3
https://ibb.co/S4cW3syT
and ingame
https://ibb.co/1GBSVSzd
It hard locked and crashed, but a few frames without purple tint.

When it comes to the purple/ pink image with DLSS frame gen on seems to be a Wayland problem? Or least a Linux window problem, the purple goes away if the game is not in focus. Currently on Bazzite KDE 6.3 https://ibb.co/S4cW3syT

Same problem under X. With game update today, pink screen when framegen on is no longer happening on game menu, but in the game it goes purple maybe a second or so after you're dropped into it.

Ubuntu 24.04.2/6.11.0.26, Nvidia 570.153.02, 5090 mobile/285HX

Throwing my hat in for the frame generation issues. I'm able to reproduce all the problems with my system.

EndeavourOS 6.15.2-arch1-1
NVIDIA GeForce RTX 4080 575.64

I get a black screen as well.
I am on ubuntu 24

GPU: AMD AMD Radeon RX 6600 XT (radeonsi, navi23, LLVM 15.0.7, DRM 3.61, 6.11.0-26-generic)
Video driver version: 4.6 (Compatibility Profile) Mesa 24.2.3 - kisak-mesa PPA
Kernel version: Ubuntu 6.11.0-26-generic
Proton version: Tried Experimental and 9.0-4

When I added logging the file was 64mb, I clicked stop on the game after about a minute and the log blew up to 1.2GB
It is thousands and thousands of repetitions of this:

209.137:0294:0298:trace:unwind:RtlVirtualUnwind type 2 rip 6fffffeea098 rsp 80e8a0
209.137:0294:0298:trace:unwind:dump_unwind_info **** func 2a040-2a099
209.137:0294:0298:trace:unwind:dump_unwind_info unwind info at 00006FFFFFF041B0 flags 0 prolog 0x10 bytes function 00006FFFFFEEA040-00006FFFFFEEA099
209.137:0294:0298:trace:unwind:dump_unwind_info     frame register rbp offset 0x30(%rsp)
209.137:0294:0298:trace:unwind:dump_unwind_info     0x10: leaq 0x30(%rsp),rbp
209.137:0294:0298:trace:unwind:dump_unwind_info     0xb: subq $0x38,%rsp
209.137:0294:0298:trace:unwind:dump_unwind_info     0x7: pushq %r12
209.137:0294:0298:trace:unwind:dump_unwind_info     0x5: pushq %r13
209.137:0294:0298:trace:unwind:dump_unwind_info     0x3: pushq %r14
209.137:0294:0298:trace:unwind:dump_unwind_info     0x1: pushq %rbp

and this

341.678:0294:02d0:trace:unwind:execute_cfa_instructions 7ca260b52845: DW_CFA_def_cfa %rsp, 8
341.678:0294:02d0:trace:unwind:execute_cfa_instructions 7ca260b52845: DW_CFA_offset %rip, -8
341.678:0294:02d0:trace:unwind:dwarf_virtual_unwind fde 0x7ca260c2f5e0 len 10 personality (nil) lsda (nil) code 7ca260b52845-7ca260b5285a
341.678:0294:02d0:trace:unwind:execute_cfa_instructions 7ca260b52845: DW_CFA_undefined %rip
341.678:0294:02d0:trace:unwind:dwarf_virtual_unwind next function rip=00007ca260b52850
341.678:0294:02d0:trace:unwind:dwarf_virtual_unwind   rax=0000000000000020 rbx=00000001000ff820 rcx=000000000037e105 rdx=00007ca09992bb30
341.678:0294:02d0:trace:unwind:dwarf_virtual_unwind   rsi=000000000000000f rdi=0000000100ef9440 rbp=0000000000000000 rsp=0000000100f01eb0
341.678:0294:02d0:trace:unwind:dwarf_virtual_unwind    r8=00007ca16af39410  r9=00007ca16af393e0 r10=00007ca16af39410 r11=00007ca0c1a520f0
341.678:0294:02d0:trace:unwind:dwarf_virtual_unwind   r12=0000000100eff640 r13=000000000000000b r14=00007ca260ac07d0 r15=00000001000ff980
341.678:0294:02d0:trace:unwind:dwarf_virtual_unwind function 7ca260b52850 base 0x7ca260b52845 cie 0x7ca260c16f20 len 14 id 0 version 1 aug 'zR' code_align 1 data_align -8 retaddr %rip
341.678:0294:02d0:warn:seh:dwarf_virtual_unwind backtrace: 0x7ca260b52850: /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/libc.so.6 + 0x126850.

And the final clause with tail

365.996:0294:02d0:trace:unwind:dwarf_virtual_unwind fde 0x7ca260c2f5e0 len 10 personality (nil) lsda (nil) code 7ca260b52845-7ca260b5285a
365.996:0294:02d0:trace:unwind:execute_cfa_instructions 7ca260b52845: DW_CFA_undefined %rip
365.996:0294:02d0:trace:unwind:dwarf_virtual_unwind next function rip=00007ca260b52850
365.996:0294:02d0:trace:unwind:dwarf_virtual_unwind   rax=0000000000000020 rbx=00000001000ff820 rcx=000000000037e105 rdx=00007ca09992bb30
365.996:0294:02d0:trace:unwind:dwarf_virtual_unwind   rsi=000000000000000f rdi=0000000100ef9440 rbp=0000000000000000 rsp=000000010152a088
365.996:0294:02d0:trace:unwind:dwarf_virtual_unwind    r8=00007ca16af39410  r9=00007ca16af393e0 r10=00007ca16af39410 r11=00007ca0c1a520f0
365.996:0294:02d0:trace:unwind:dwarf_virtual_unwind   r12=0000000100eff640 r13=000000000000000b r14=00007ca260ac07d0 r15=00000001000ff980
365.996:0294:02d0:trace:unwind:dwarf_virtual_unwind function 7ca260b52850 base 0x7ca260b52845 cie 0x7ca260c16f20 len 14 id 0 version 1 aug 'zR' code_align 1 data_align -8 retaddr %rip
365.996:0294:02d0:err:virtual:virtual_setup_exception nested exception on signal stack addr 0x7ca25f01483e stack 0x7feeefa0
pid 7502 != 7501, skipping destruction (fork without exec?)

Edit, I switched from SNAP to .deb and the issue persists

Working great here on Arch Linux, even with wine wayland so I think you could test with newer kernel/mesa.

Working great here on Arch Linux, even with wine wayland so I think you could test with newer kernel/mesa.

Did you test with DLSS frame generation? otherwise the game works greate.

I was referring to people not being able to play at all. I can't test DLSS frame gen since I'm on 9070XT. FSR3 frame gen still cuts the framerate to 1/3

How often does mesa update? I searched for how to update and didn't find clear instructions for ubuntu.

How often does mesa update? I searched for how to update and didn't find clear instructions for ubuntu.

See Proton wiki here: https://github.com/ValveSoftware/Proton/wiki/Requirements

That worked thank you!

Again, what distro? What mesa version?

Again, what distro? What mesa version?

Hi,

Sorry could have wrote it down directly. Im not at my pc right now but im running Arch. Mesa version is 25.1.5-1. Did a clean reinstall on the 10.07. So it should be the newest one from the arch repos.

Oh yeah, should be good then. I'm playing and it's working great even with proton wayland enabled for HDR. You could try mesa-git though.

Oh yeah, should be good then. I'm playing and it's working great even with proton wayland enabled for HDR. You could try mesa-git though.

Okay, as is said my game crashes as soon as i hit spacebar to start. Ill try mesa-git when i get home and see if it works. I will report back.

Good evening. So i tried to use mesa-git through yay -S mesa-git, and i also build it myself. The Version im using is:

pacman -Qi mesa:
Name : mesa-git Version : 25.2.0_devel.208666.cf654be16b4.d41d8cd-1

Sadly the problem is still the same with both. Now i have NO clue where to go or what to do. Somebody told me it could be due to UMIP being enabled, so right now im building the linux-lts kernel myself without UMIP to see if this works (cant disable it through kernel parameters). If anybody has ANY idea what the problem could be or you wanna see some logs. Im gladly providing them!

What's your GPU and CPU?

What's your GPU and CPU?

CPU : 12th Gen Intel(R) Core(TM) i5-12400 @ 4.40 GHz
GPU : AMD AMD Radeon RX 7800 XT

Good evening. Sorry for the late response. I build the kernel now and tried it with UMIP forcefully deactivated - Same result.... then i saw split lock detection fires. I disabled this too - Same result... dmesg doesnt log anything regarding doom:tda now. The Proton log seems fine to me.

If i just let the game run after pressing spacebar. After a minute or so the same audio plays as it does when i press spacebar, and stops at the same time again. Dunno if all this was the case from the start.

If have literally NO idea what to do next i think ill just refund it and sadly just don't play it.

Hi @matte-schwartz, NVIDIA has provided a fix for this issue in pull request https://github.com/jp7677/dxvk-nvapi/pull/308. Could you please test it and let me know if everything works as expected?

After seeing the last message, I Solved The purple Screen for Doom the Dark ages on my Gentoo (NVIDIA) system, which I have been facing since launch. Did not realize it was related to Nvidia Reflex Support.

I added the Gentoo Repository:
thegreatmcpain

And Installed:
app-emulation/dxvk-nvapi
app-emulation/dxvk-nvapi-reflex-layer

Then when I ran
env DXVK_NVAPI_VKREFLEX=1 vulkaninfo | less
and searched for "LAYER"
I saw the new layer:

VK_LAYER_DXVK_NVAPI_reflex (DXVK-NVAPI Vulkan Reflex compatibility layer) Vulkan version 1.3.295, layer version 1:
Layer Extensions: count = 0
Devices: count = 1
GPU id = 0 (NVIDIA GeForce RTX 5070 Ti)
Layer-Device Extensions: count = 1
VK_NV_low_latency : extension revision 1

Since steam seems to have banned me for more than 24 hours for trying different proton versions, And their customer support is not responding on the same denuvo ticket, and I had Xbox gamepass, I installed battle.net through the Heroic Launcher, and installed Doom the Dark ages through Battle.net.

I added the Launch Option:
DXVK_NVAPI_VKREFLEX=1
To the Heroic Launcher Battle.net Launcher Options.

And now when I launch Doom the Dark ages, I can enable DLSS Frame Gen and the screen no longer has that purple tint.

Thank you.

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-3100701480

Does anyone know if this fix is available on Bazzite?

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-3102031015

@martinmitrovic You can follow the steps in this comment:: https://github.com/jp7677/dxvk-nvapi/pull/308#issuecomment-3102362440

@jeanluchayes Great job resolving the purple issue!

I'm on Linux Mint 22.1 and using Steam. I don't want to compile anything from source. Is this bug expected to be eventually resolved in Proton (Experimental)? Even then, will the DXVK_NVAPI_VKREFLEX=1 have to be used in game options?

@jeanluchayes Great job resolving the purple issue!

I'm on Linux Mint 22.1 and using Steam. I don't want to compile anything from source. Is this bug expected to be eventually resolved in Proton (Experimental)? Even then, will the DXVK_NVAPI_VKREFLEX=1 have to be used in game options?

Hi, you can use ProtonPlus to download the latest Proton-EM. Version 27 and above, includes the dxvk-nvapi merged PR fix, so you don't need to install the Vulkan Reflex layer.

Or use Experimental's bleeding-edge branch for the time being. Just be aware that it's only a workaround, unless you actually install and enable the layer, Reflex will not improve latency.

Not sure about anyone else, but today's game update + Nvidia 570.181 seems to have finally fixed the 'enabling framegen messes up colourspace causing magenta screen tint' thing for me.

Too bad I finished the game 6 weeks ago ;-)) But yeah, important thing is it's fixed.

@MistahBungle Fixed for me, too.

Even on Proton 10 (meaning, not Experimental)?

(Make sure you have enough Denuvo activations remaining for today before you try answering that question.)

system info:

Operating System: Bazzite 42
KDE Plasma Version: 6.4.3
KDE Frameworks Version: 6.16.0
Qt Version: 6.9.1
Kernel Version: 6.15.9-106.bazzite.fc42.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × 11th Gen Intel® Core™ i7-11700KF @ 3.60GHz
Memory: 16 GiB of RAM (15.4 GiB usable)
Graphics Processor: NVIDIA GeForce RTX 3060
Manufacturer: ASUS

problem

black screen with FSR frama generation, and unable to solve:
delated dave folder by delating compactdata/xxxxxx/prefix

steam-3017860.zip

Compatibility Report

• Name of the game with compatibility issues: Doom The Dark Ages
• Steam AppID of the game: 3017860

System Information

• CPU: Intel Core i5-13600K with e-cores disabled in bios
• GPU: RX 7900 XT
• Video driver version: 4.6 (Compatibility Profile) Mesa 25.2.1+git2508221109.71dcc1dc23b~p~mesarc1
• Kernel version: 6.14.4-061404-generic
• Kubuntu 25.10
• Link to full system information report as Gist: https://gist.github.com/stellaberrant/d976f08b8fca9a270a03b5439dc855df
• Proton version: various, tried Experimental, 9 and Proton GE-10-10

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.

Symptoms

Since a game update (Either update 2 or update 2.1), I am unable to play the game. It launches but then proceeds to freeze at the "Press Spacebar or (A) to Start" screen. It simply becomes unresponsive entirely and after a few seconds the music stops.

Dmesg log: dmesg_log_splitlock_kubuntu.tar.gz
Proton log: steam-3017860_splitlock_kubuntu.tar.gz
Proton log from a working installation: steam-3017860_ally_working.tar.gz
System information as a file: system information.txt

So far I tried:

• deleting the protonprefix
• deleting the userdata for the game
• disabling the Steam Overlay
• unplugging my Dualsense controller
• launching with SteamDeck=1 %command%
• importing a profile.bin from a working installation of Doom TDA
• launching with gamescope
• launching with +com_skipkeypressonloadscreens 1 +com_skipIntroVideo 1
• disabling split lock detection before boot
• Proton 9, Experimental, and GE 10-10 (and eventually got locked out by Denuvo)
• uninstalling and reinstalling the game
• skipping shader compilation
• updated my whole Kubuntu system which pulled in newer Mesa for example, same issue
• I tried to play the game on the same system with Bazzite instead of Kubuntu(Fedora-based, with newer Mesa and Kernel)

However, the game is still working on my ROG Ally X which is also running Bazzite. So I'm thinking it's somehow related to hardware maybe? I also attached the Proton log from this system where the game is still working so you can compare the 2

Reproduction

• launch game
• press (A) or Spacebar when prompted
• the game freezes and music stops, game needs to be exited via the steam ui

EDIT: I've combed this forum and protondb and reddit for reports, and have found others on Linux with the same issue, as well as one user on Discord. Windows does not seem to be affected. However, they all share an Intel 12/13/14th gen processor in common. Could this be the culprit???

I have the exact same issue as @stellaberrant - I get to the press enter to continue screen and then the game hangs there, as per my report on ProtonDB.

My system specs are:
Distro: Linux Mint 22.1
Kernel: 6.14.0-28-generic
RAM: 32 GB
GPU Driver: NVIDIA 575.64.03
GPU: NVIDIA GeForce RTX 5070
CPU: 12th Gen Intel Core i5-12400F

To resolve this I first tried to run various Proton versions, Experimental, GE. After that I actually tried to install CachyOS on a partition and install the game there. So I also tried this on Kernel 6.16.4-1 and NVIDIA driver 580.76.05-7.1 on the same computer and got the exact same issue.

Attaching Proton Logs: steam-3017860.log.zip

Update: In an unrelated PC upgrade I switch to a Ryzen 9800X3D, after that the game ran basically flawlessly. Maybe the problem is with Intel CPUs?

Update: In an unrelated PC upgrade I switch to a Ryzen 9800X3D, after that the game ran basically flawlessly. Maybe the problem is with Intel CPUs?

Yea i'm pretty certain the problem is with Intel. The game runs fine on my AMD handhelds and everyone I've seen have this problem so far, had an Intel 12-14th gen processor

update: I reenabled my e-cores (were disabled in BIOS) and now the game lets me proceed past the screen. When I launch with WINE_CPU_TOPOLOGY=12:0,1,2,3,4,5,6,7,8,9,10,11 %command% (just p-cores) then it freezes again. So it looks like the game requires e-cores somehow on Intel? btw I tested on Windows and there it would let me in without ecores

I am also unable to launch TDA with an AMD CPU and Nvidia GPU since the update. Not sure if it's just an Intel thing. The Steam Deck report above is also AMD CPU

Soon it will be a year since I bought the game and was unable to play it, from day 1. Same crash. Video link below. Logs attached. Warn: 136MB uncompressed size.

Video: https://github.com/user-attachments/assets/f6a86777-eeab-4d5e-b07e-9f6b0ce5e5f2

steam-3017860.tar.gz

Current Neofetch:

~ neofetch
                     ./o.                  pato@blade 
                   ./sssso-                ---------- 
                 `:osssssss+-              OS: EndeavourOS Linux x86_64 
               `:+sssssssssso/.            Host: B660M DS3H DDR4 
             `-/ossssssssssssso/.          Kernel: 6.18.5-arch1-1 
           `-/+sssssssssssssssso+:`        Uptime: 2 days, 3 hours, 50 mins 
         `-:/+sssssssssssssssssso+/.       Packages: 1609 (pacman) 
       `.://osssssssssssssssssssso++-      Shell: zsh 5.9 
      .://+ssssssssssssssssssssssso++:     Resolution: 1920x1080 
    .:///ossssssssssssssssssssssssso++:    DE: Plasma 6.5.4 
  `:////ssssssssssssssssssssssssssso+++.   WM: kwin 
`-////+ssssssssssssssssssssssssssso++++-   Theme: Breeze-Dark [GTK2], Breeze [GTK3] 
 `..-+oosssssssssssssssssssssssso+++++/`   Icons: breeze-dark [GTK2/3] 
   ./++++++++++++++++++++++++++++++/:.     Terminal: konsole 
  `:::::::::::::::::::::::::------``       CPU: 12th Gen Intel i5-12400F (12) @ 5.600GHz 
                                           GPU: AMD ATI Radeon RX 6800/6800 XT / 6900 XT 
                                           Memory: 23793MiB / 31931MiB 

Previous neofetch:
https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-3011128154

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-3757614309

Based on my thorough investigation into this issue, Doom: TDA will fail to launch with Proton if no E-Cores are present. And the 12400F does not have any.

The only known solutions to this problem are:

• play game on Windows
• enable E-Cores (not possible on your model sadly)
• play on an AMD CPU

It would be nice to get at least some acknowledgement from Valve about this issue, since it leaves some people totally unable to play the game on Linux over Proton, while Windows is not affected at all.

I'm not sure proton is here to blame as it works for most people. I don't have issues besides Frame Gen still being broken though honestly, I'm waiting for vulkan FSR4

I'm not sure proton is here to blame as it works for most people. I don't have issues besides Frame Gen still being broken though honestly, I'm waiting for vulkan FSR4

It's only an issue on specific hardware configurations, you won't be affected if you don't have one of the Intel hybrid CPU models without e-cores or you have one with e-cores but disabled them in BIOS or otherwise hide them from the game

Is that the case for Windows as well?

no Windows is not affected.

I'm struggling to run the game at a stable framerate even with the lowest possible graphics settings and highest upscaling with XeSS at 1920x1080 resolution. Averaging about 20fps with significant stutters. I'm using the latest version of ubuntu which has the latest Intel drivers pre-installed. Looking online it seems it can reach over 80fps with ultra nightmare graphics settings on Windows so is this just a linux issue?

My system specs are:
OS: Ubuntu 25.10
KERNEL: 6.17.0-14-generic
CPU: AMD Ryzen 7 5800XT 8-Core
GPU: Intel Mesa Intel Arc B580 (BMG G21)
GPU DRIVER: 4.6 Mesa 25.2.8-0ubuntu0.25.10.1
RAM: 32 GB

@mrcturner what's your CPU? the game is known to behave poorly on Intel CPU's without E-cores or with E-cores disabled

@mondalaci

@jeanluchayes Great job resolving the purple issue!

I'm on Linux Mint 22.1 and using Steam. I don't want to compile anything from source. Is this bug expected to be eventually resolved in Proton (Experimental)? Even then, will the DXVK_NVAPI_VKREFLEX=1 have to be used in game options?

With GE Proton 10-34 or whichever earlier version allowed it, I no longer set the DXVK_NVAPI_VKREFLEX=1 variable in games, etc. It detects it. I don't get the Purple Screen when enabling frame gen.

Or unrelated, I also no longer set PROTON_USE_NTSYNC=1 in games, etc. Game launches and automatically uses NTSYNC after I enabled it in my kernel as a module and made the module load on boot.

The only other thing that is affecting me, but is not of big concern, is
PROTON_ENABLE_WAYLAND=1, just does not work for me for Doom the Dark Ages. The game launches and immediately loads a black screen/freezes, while the audio works and plays in the background.

Since I record using OBS, with input overlays, I run the game normally, in XWayland anyhow, to have the key inputs work in OBS, so I don't need that line to work, but it looks to be an unsolvable problem, as I've seen online.

The most recent post was from a cachy OS user, who had it closed on the cachy os github->
https://github.com/CachyOS/proton-cachyos/issues/215
and moved it over to Nvidia developer forums->
https://forums.developer.nvidia.com/t/doom-the-dark-ages-black-screen-on-wayland-with-driver-610-43-02/372849
With no response yet.

Looks like he gave the solution at
https://github.com/CachyOS/proton-cachyos/issues/215
I was using the wrong launch option for setting vsync, although my method still produced where the issue lied ->

+set r_swapInterval 3
Actually changes the VSYNC values in Ultranighmare Performance Metrics
and
Allows it to launch
under PROTON_ENABLE_WAYLAND=1

Thank You!

I am able to reproduce the exact same Vertical Sync "Off" issue as @jeanluchayes. If I leave it at "Triple Buffering", it works fine on Wayland with everything else set to my preferences (DLSS, HDR, PT). As soon as I switch it to "Off", it stops rendering frames. For example, if I boot it up after changing Vertical Sync to "Off", it will render anywhere from 0 to 4 frames and then just stop. I hear music but it never goes beyond those frames unless I force it using +set r_swapInterval 2 in the launch arguments.

Lighting in the DLC is broken at least on a 7900xt with arch linux latest (on proton experimental for this screenshot, but also applies to proton ge and the like). This glitch is most apparent here in the first actual level as well as with some "ripples" on character models in cutscenes.

I made a Mesa issue for the DLC glitch here https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15818.

There has been progress 😊
Installed the latest updates over night and now the initial bug (screen freeze before entering menu) is gone. The screen freezes only after visiting the menu and starting an actual game.

My specs:

Z690M Phantom Gaming 4
12th Gen Intel(R) Core(TM) i5-12400F (12) @ 4.40 GHz
AMD Radeon RX 6600 [Discrete]

What I have tried so far today:

• PROTON_ENABLE_WAYLAND=1 +set r_swapInterval 2 +com_skipIntroVideo 1 as starting option
• No starting option
• Proton Hotfix
• GE-Proton 11-3

Maybe anyone has some other ideas and even manages to fully run the game?

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-5187586148

I think it's just id software updated their engine on DLC release, I have an I5-12490F and was there waiting for DLC release on zero-day and when I entered the game as soon as possible after DLC released, the freeze issue when entering main menu was gone, but I still can't make it to in-game.

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-5187586148

sorry, but i think you're out of luck. From my testing, the game completely refuses to work on intel and proton without e-cores present. And this processor does not have any. the only solution is to either get a different processor or play on windows

I had the same issue on Nobara Linux (Fedora 44) - Black screen as soon as i used PROTON_ENABLE_WAYLAND=1 PROTON_ENABLE_HDR=1 %command% as starting options and turning HDR on. The issue started just some days ago (maybe after the last wayland update). Game did not render at all most of the times, and if it did, the colors were wrong in HDR mode (red turned blue, the blue/green background went brown). According the proton logs Doom TDA tried to switch to a color presentation manager kwin does not support:

Compositor doesn't supports windows_bt2100, HDR10 ST2084 may look broken

I fixed mine using gamescope as a renderer. These are my starting options:

gamescope --backend wayland --hdr-enabled --fullscreen --adaptive-sync -w 2560 -h 1440 -W 2560 -H 1440 -r 240 -- %command% +com_skipIntroVideo 1

Mine is running smooth now with DLSS enabled, Vsync is off, even Frame Generation works. You might give it a try.

(I'm running an Nvidia RTX 4070Ti if that matters)

Replying to https://github.com/ValveSoftware/Proton/issues/8690#issuecomment-5230538583

Thanks. The error persists unfortunately. Probably the problem remains with intel and proton without e-cores like stellaberrant mentioned.

Hello,

i'm experiencing an issue with Doom: The Dark Ages where when you launch the game, as you get to the loading screen (no intros), the game starts consuming memory like crazy (RAM, not VRAM), up to the point where the OS just shuts down the game to prevent running out of memory. The game keeps running up until the os kills the process, because the "loading..." animation in the bottom left with the pentagram animation keeps going smoothly.

Tried:
-brute forcing it by giving it more swap - it just kept using that (used up to 200GB of swap)

Steps to reproduce:
-launch the game (that's about it)

Specs:
Kernel: Linux 7.1.7-200.fc44.x86_64
OS: Fedora Linux 44 (KDE Plasma Desktop Edition) x86_64
CPU: AMD Ryzen 7 5800X (16) @ 4.85GHz
GPU: Intel Arc B580 @ 2.85 GHz
Resolution: 1920x1080, 75 Hz
Memory: 32 GiB
Mesa 26.3.0-devel

System:

• Arch Linux / Omarchy 4.0.0-1
• Kernel 7.1.8-arch1-3
• Hyprland / Wayland
• Intel Core i5-12400F
• 32 GB RAM
• NVIDIA RTX 4070
• nvidia-open 610.57.04
• Proton Experimental 11.0-20260814b
• Game build 24368472

I'm getting a repeatable freeze in DOOM: The Dark Ages. It happens after I
press Space at the end of a campaign loading screen. I can also reproduce it
by opening the Rewards menu and displaying a 3D skin model.

The picture and audio stop, but the process stays alive. If I leave it running,
the audio sometimes comes back for a few seconds and then stops again, while
the picture never recovers.

I've also reproduced it with Proton 11.0-2, Proton 9.0-4 and GE-Proton 11-5.
A fresh profile, disabling Steam Cloud and Steam Input, clearing the shader
cache, forcing XWayland, and disabling FSync/ESync did not help. The kernel
log contains no NVRM Xid or GPU reset messages.

The Proton log reaches GAME_STATE_INGAME and LevelLoadCompleted before it
stops making progress. I also captured a GDB backtrace while it was frozen
and attached both files.

steam-3017860.log.gz

doom-hang-backtrace.txt