Doom Eternal (782330)

[kisak-valve]

Due to the early flood of feedback for Doom Eternal while the community figured out how to get this game to run, the discussion for this game has been reset. If you have an interest in the community efforts made to run this game, feel free to read #3654.

Known hard requirements:

Proton 5.0-6 or newer
Mesa 20.0.3 / LLVM 9.0 (AMD only) (or equivilant AMDVLK / AMDGPU-PRO) (RADV/ACO needs 20.1+)
nVidia 440.82 (nVidia only, mildly older drivers may work with degraded performance.)
vulkan-icd-loader 1.2.135 (This is provided by the Steam runtime. Drivers can report support for an older vulkan spec and that is okay.)

Known Quirks:

As of this writing, Denuvo is having a hard time with something in Wine-Staging, and third party Proton builds based on that may hit a 24 hour lockout after 5 runs per day.
Steam overlay degrades performance when visible. Improved Steam Overlay and FPS counter performance for games using Vulkan async compute (such as DOOM Eternal). in the 2020-04-16 Steam client beta update.
Alt-Tab may break the game rendering.

Tinkerer guides:

Please do not re-post tinker guides in this issue report. If you have one to share, please put it in a gist and request that the gist be shared in this section.

[poperigby]

I'm getting a hard crash that seems to happen after 30 minutes or so. Here's the log file:
https://send.firefox.com/download/945b855f1dd20e0d/#dP9yXbTc4PGFlF5mkZL1EQ

I have a RX 5700XT and am using ArchLinux with RADV.

[kisak-valve]

Hello @poperigby, please copy your system information from Steam (Steam -> Help -> System Information) and put it in a gist, then include a link to the gist in this issue report.

As a side note, Proton logs are known to compress well, please consider throwing large logs into an archive.

[poperigby]

Here's the system information gist: https://gist.github.com/PopeRigby/263d2b99e3998f99fdf4e0d222845843

[jjbarr]

So does ACO work on Mesa 20.1 now? Last I heard ACO was not working.

[silviucc]

Is it still true that enabling the overlay causes performance issues?

My own experience shows the opposite:
https://forums.developer.nvidia.com/t/low-performance-in-doom-eternal/116394/30?u=silviu_c

[btegs]

@btegs, removing the pinned_libs_* folders prompts Steam to regenerate those folders the next time Steam is started (this is literally what I said previously). The folder's contents is the result of comparing the system libraries to the Steam runtime variants and pinning the Steam runtime variant if it is newer than the host system.

Steam prioritizes libraries in the following order: Pinned libraries > Host system > Steam runtime > ld.so.conf

Deleted those folders and were recreated once starting Steam. I checked the directory and they were symlinking to a 1.2.135 version of Vulkan. cool.

Then I load up a random game with Proton 5.0-6 with the DXVK hud set to 1 under Ubuntu 19.10. It shows up as Mesa 20.0.99 (using the bleeding edge git version from https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers for my RX 580. Shows Vulkan 1.2.128 for my Vulkan version. I obviously cannot start DOOM Eternal either.

What is going on and what steps are missing?

NOTE: I found an Ubuntu repo at https://packages.lunarg.com/ which gives me an updated libvulkan1 and libvulkan1:i386 without affecting my current Mesa. 1.2.135 is installed, but whenever I try a game on Steam or using GameHub with a GOG game, it is still at 1.2.128. I have no clue where this version of Vulkan is coming from!

[tyqualters]

"Alt-Tab may break the game rendering."
Arch Linux with KDE Plasma, can confirm Alt-Tabbing broke game rendering, but it also resulted in unresponsiveness to the close procedure by right clicking the process in the task bar and clicking the "Close" button..
sudo kill -SIGHUP 31117 did close the game though
System Information: https://pastebin.com/1z80Y7WG

[poperigby]

My hard crash seems to be happening after about 20 minutes every time I start the game. Maybe I could time it to check.

[Emanem]

Adding bugs (perhaps obvious/already known):

• have to skip initial intro logo ("+in_terminal 1 +com_skipIntroVideo 1")
• audio is crackling a little bit sometime (have to increase pulseaudio sampling to 48 kHz)
• multiplayer doesn't work (this is bad)

[DarkArc]

This game is also seems to be affected by #2927

If you're having problems, and you have a Ryzen 3xxx processor, try the workaround there ^

[kisak-valve]

Doom Eternal Monitor/Resolution fail

Issue transferred from #3797.
@Kalevr1 posted on 2020-04-24T23:18:50:

Compatibility Report

• Name of the game with compatibility issues: Doom Eternal
• Steam AppID of the game: 782330

System Information

• GPU: RTX 2060 SUPER
• Driver/LLVM version: 4.6.0 NVIDIA 440.82
• Kernel version: 5.5.6
• Link to full system information report: https://gist.github.com/Kalevr1/6f5f51d29cc2e60e370c7dda858ace34
• Proton version: 5.0-6

I confirm:

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

steam-782330.log.zip

Symptoms

After installing latest SteamPlay Proton 5.06 I got one perfect play session that lasted several hours. I took a break to eat and then came back to continue play. I have a 2 monitor setup. When I tried to launch the game a second time, it switched to a small window on the the secondary monitor. The lower monitor is my default screen and sits at eye level. I can see the upper left corner of the Doom Intro being rendered within the quarter-sized window on the secondary monitor. The game engine thinks it is rendering on the entire screen but I only see the portion that overlaps the window. I can see 2 buttons in the UI and I can interact with them. I Alt-F4 to exit.

Seems fixable if I can manually force the monitor and resolution for the app but I don't know if that would work. One workaround I have found is if I delete ../steamapps/compatdata/782330 the game does 'first run' again, which always runs perfectly.

I have included a screenshot of both monitors (1920x2160 pixels). Steam is fullscreen below on primary and you see the Doom Window above on the secondary.

Reproduction

---

@Kalevr1 commented on 2020-04-24T23:21:15:

This is my first post so I hope it is correct starting a new report rather than attaching to another. If not apologies.

[BloodyIron]

I'm effectively in the identical scenario, same versions, cannot figure out how to get DOOM Eternal not to crash on start. :(

Did you get this figured out @btegs ?

@btegs, removing the pinned_libs_* folders prompts Steam to regenerate those folders the next time Steam is started (this is literally what I said previously). The folder's contents is the result of comparing the system libraries to the Steam runtime variants and pinning the Steam runtime variant if it is newer than the host system.
Steam prioritizes libraries in the following order: Pinned libraries > Host system > Steam runtime > ld.so.conf

Deleted those folders and were recreated once starting Steam. I checked the directory and they were symlinking to a 1.2.135 version of Vulkan. cool.

Then I load up a random game with Proton 5.0-6 with the DXVK hud set to 1 under Ubuntu 19.10. It shows up as Mesa 20.0.99 (using the bleeding edge git version from https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers for my RX 580. Shows Vulkan 1.2.128 for my Vulkan version. I obviously cannot start DOOM Eternal either.

What is going on and what steps are missing?

NOTE: I found an Ubuntu repo at https://packages.lunarg.com/ which gives me an updated libvulkan1 and libvulkan1:i386 without affecting my current Mesa. 1.2.135 is installed, but whenever I try a game on Steam or using GameHub with a GOG game, it is still at 1.2.128. I have no clue where this version of Vulkan is coming from!

[Seltyk]

On the old thread a few users reported that battlemode can't find games, and I have the same issue. Nobody on that thread either suggested a cause or reported a fix, so I'd like to bring back attention to that issue.
When trying to find a match in battlemode, on any of the three choices, I simply cannot find a game, ever. There is not crash or error, though admittedly I haven't checked any log files.

[btegs]

I'm effectively in the identical scenario, same versions, cannot figure out how to get DOOM Eternal not to crash on start. :(

Did you get this figured out @btegs ?

@btegs, removing the pinned_libs_* folders prompts Steam to regenerate those folders the next time Steam is started (this is literally what I said previously). The folder's contents is the result of comparing the system libraries to the Steam runtime variants and pinning the Steam runtime variant if it is newer than the host system.
Steam prioritizes libraries in the following order: Pinned libraries > Host system > Steam runtime > ld.so.conf

Deleted those folders and were recreated once starting Steam. I checked the directory and they were symlinking to a 1.2.135 version of Vulkan. cool.
Then I load up a random game with Proton 5.0-6 with the DXVK hud set to 1 under Ubuntu 19.10. It shows up as Mesa 20.0.99 (using the bleeding edge git version from https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers for my RX 580. Shows Vulkan 1.2.128 for my Vulkan version. I obviously cannot start DOOM Eternal either.
What is going on and what steps are missing?
NOTE: I found an Ubuntu repo at https://packages.lunarg.com/ which gives me an updated libvulkan1 and libvulkan1:i386 without affecting my current Mesa. 1.2.135 is installed, but whenever I try a game on Steam or using GameHub with a GOG game, it is still at 1.2.128. I have no clue where this version of Vulkan is coming from!

I upgraded to Ubuntu 20.04 with that Vulkan package from lunarg and I still am stuck with 1.2.128. I removed the pinned libs (Steam even warns me when its recreating it on launch) and cannot get that newer version to sync up.

@kisak-valve ignored my comment before, but I'm glad that there are other people having this issue.

[luisalvarado]

The following is Ubuntu 20.04, latest Nvidia drivers 440 with a GTX 1080. After the game is started, a small black screen shows on the second monitor and stays like that.

Sometimes it would show the actual menu instead of the black screen like this

But if I try to make the game go fullscreen by pressing ALT+ENTER, then all hell breaks loose

[BloodyIron]

Alright well DOOM Eternal is now launching for me. I'm unsure what has changed for me to do this. It might have been a recent MESA driver update that fixed it, unsure. Just blind tried it again, and I'm able to get in and play the game. If I observe further issues I'll report them.

[Kalevr1]

The following is Ubuntu 20.04, latest Nvidia drivers 440 with a GTX 1080. After the game is started, a small black screen shows on the second monitor and stays like that.

Sometimes it would show the actual menu instead of the black screen like this

But if I try to make the game go fullscreen by pressing ALT+ENTER, then all hell breaks loose

Did it happen on first-run as well or only subsequent launch attempts? If it's like my situation you can do a workaround by deleting the folder under compdata as I explained in my report, so that every run is a "first" run. I had to dual boot my way through this game unfortunately. It was either that or delete that folder with every launch of the game. Until they fix the multi-monitor launch bug, there is no other way that I can see.

[mtb-xt]

But if I try to make the game go fullscreen by pressing ALT+ENTER, then all hell breaks loose

@luisalvarado instead of pressing alt-enter, try going into settings, and changing 'windowed' mode to 'borderless windowed' first. If it works, change it to 'fullscreen' then. Or just play on borderless?

[alasky17]

@ziprasidone146939277 Thank you for the details. This is a confusing issue (without even counting the fact that we haven't gotten other reports of environment variables not working, and have not been able to reproduce locally).

Another idea came up to try to diagnose what is going wrong with your system - could you try running DOOM Eternal with all of the launch options that used to make it run well (LD_PRELOAD etc) and Proton 8.0, and then run the following in a separate terminal and post the output here? cat /proc/$(pgrep python3)/environ | tr '\0' '\n' Please test this with launching DE both with the steam client and using the desktop shortcut, and upload both output results.

[ziprasidone146939277]

Replying to #3773 (comment)

Hello. I am not able to do those test right now. I will tr to do and post those test at UTC-3 more or less (if I have enough time). And I am replying via mail. Yes. I think that the last 10-15 messages on this thread makes everything quite a bit confusing. What I reported it's not new (keep this in mind). I've found time ago some workarounds (searching on github; protonDB, etc.) and since then I play in that way.; without further research or reporting anymore. I mean; the LD_PRELOAD workarround worked (launch the game from Steam) until Proton 8 released. And I realized because I use Experimental by default, as I said in older messages. But the neccesity of de LD_PRELOAD="" launching Doom from Steam client, was always a "requirement" to can play well (Proton 7). And now with Proton 8 and Experimental the new Workarraound (for me) it's launch the game from it's own shorcut or from CLI without any "tricks" (LD_PRELOAD; ...NVIDIA=blah, etc). But never from Steam client. I don't use "LD_PRELOAD="" anymore because Proton 8. I think that it's worth to explain or clarity what does "launching from Steam" and "from CLI or Desktop Shortcut" means when I mention that; because I think that was not clearly explained by me) will try to do that: Always and in all cases, speaking that this is with everything to steam process's related closed previously, i.e.: from scratch - Launching/Launch from Steam means: (this is what is not working with the expected FPS) 1. I am on the Desktop. 2. I open the Steam client from the Steam shortcut and main page appears. 3. I click on the desired Game (in this case Doom Eternal) 4. I click "Launch" on the selected game (again, Doom Eternal) 5. Game opens at 30 FPS; I am not able to play. 6. "OK, this does not work" So I close all Steam related software. Lets call this the "normal" way. (Just for reference) Launching from the game Desktop shortcut (this works at expected FPS) 1. Just click on "Doom Eternal" Desktop shortcut. (Note that this works in my case; but if I am not wrong, users who uses Steam's Flatpak version; does not have the shortcut and I think also that is not easily launch from CLI also, because the flatpak's integration with the OS or jail/isolated env.) - Launching from CLI: (this works at expected FPS) 1. Open a terminal. 2. `steam steam://rungameid/782330` Lets call the last two ones "alternative" ways. As You can see this is not a critical issue: one way or another; the game finally is playable. At least for me, I don't know for other users. Maybe they are using the "normal" way and that's all; idk. I've already reported the issue in the time; but there is no news yet. I will do the test You suggested asap. And finally all of this "noise" its to helps others and to try to make the gaming experience on Linus to be better (helping/reporting to You). Yesterday I played more than five hours Doom w/o any problems. The only problem its to beat the Master Level Super Gore Nest endurance at ultra-nightmare lol. Regards!

[ziprasidone146939277]

could you try running DOOM Eternal with all of the launch options that used to make it run well (LD_PRELOAD etc) and Proton 8.0, and then run the following in a separate terminal and post the output here? cat /proc/$(pgrep python3)/environ | tr '\0' '\n' Please test this with launching DE both with the steam client and using the desktop shortcut, and upload both output results.

Hello @alasky17

• Note 1: Remember that the purpose of the workaround LD_PRELOAD="" was to launch DE from Steam client and to get playable FPS with Proton 7. This is what stopped working since Proton 8 was released. And this way is what I called the "normal" way in my last comment.

• Note 2: At this point we could say that this issue more an "aesthetic" thing than any other thing. In comparison with others tinkering. But I am focusing on those users (including me) that maybe they just want "Install and Play" and don't want any kind of tinkering . I don't know, actually.
  I mean; I am not sure if You and me are understanding (or focusing) in the problem in the same sense.

• Note 3/CAVEAT: the command You indicated requires elevation, at least on my system. I used sudo -E to get de outputs.

Steam/DE configs:

First test

Doom Eternal running (with very playable FPS) from Doom Eternal's shortcut (not from Steam) and proton 8.

~$ sudo -E cat /proc/$(pgrep python3)/environ | tr '\0' '\n'
cat /proc/$(pgrep python3)/environ | tr '\0' '\n'
cat: /proc/3511: Is a directory
cat: 13971/environ: No such file or directory

Then I closed Doom Eternal. Its not running anymore/its closed. And the Steam client instance is still running (the same instance which launched the game previously just before)

~$ sudo -E cat /proc/$(pgrep python3)/environ | tr '\0' '\n'
LANG=en_US.UTF-8
LC_ADDRESS=es_AR.UTF-8
LC_IDENTIFICATION=es_AR.UTF-8
LC_MEASUREMENT=es_AR.UTF-8
LC_MONETARY=es_AR.UTF-8
LC_NAME=es_AR.UTF-8
LC_NUMERIC=es_AR.UTF-8
LC_PAPER=es_AR.UTF-8
LC_TELEPHONE=es_AR.UTF-8
LC_TIME=es_AR.UTF-8
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
XDG_DATA_DIRS=/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/
HOME=/root
LOGNAME=root
USER=root
SHELL=/bin/sh
INVOCATION_ID=99b0546d02734e599f14b51502359e6b
JOURNAL_STREAM=8:50993
SYSTEMD_EXEC_PID=3511

As far I can understand, this is weird, at least for me.

Second test

If I use the "normal" way; the game never launches. The output of /proc does not changes; except for the PID, etc. The behavior is that the "Id software" icon in the AppNotification tray appears and then a black window spawns and finally everything shuts down; including the black window. Except Steam Client.

Because of this; I added PROTON_LOG=1 in game's launch options and then "launch" the game again; so that, maybe You have more information. I guess that if I just simply say to You "Game does not launched" is not a useful data.

So:

Proton log attached: steam-782330.zip

I hope I explained myself well (My English is bad) and this helps to You or whoever to improve Steam.

[gardotd426]

@ziprasidone146939277 Your output for the cat /proc command might be no good, because you're using sudo. Which you shouldn't need it. I just ran the same thing on my system and I do not need elevated privileges. I'm not sure why you would. What's the output of groups $USER?

@alasky17 so, turns out it was MangoHud that breaks all Proton 8.X games, and it's gamemode that breaks performance for me in Doom Eternal. Without either, I get the expected fps. Only problem now is that DLSS stops working with the sniper runtime. Do you know if anyone on the team is aware of this? It isn't an Nvidia/Wine/DXVK/DXVK-NVAPI/VKD3D issue, as everything works perfectly with wine 8.X and current DXVK/VKD3D-Proton/DXVK-NVAPI master using Lutris. If it's not been reported I'll go ahead and fill out a report.

The weird thing about gamemode is that it does indeed work in all other games. What's also weird is that MangoHud DID used to work with Proton 8.X until about a month ago. Was Sniper the runtime that's always been used or did it start out using Soldier?

[gardotd426]

@alasky17 so, it turns out, gamemode was NOT the problem. I have no idea why uninstalling it made it work normally literally once. Nothing else has changed, same driver version and everything. I even deleted the prefix. But sure enough, I try to launch it today (for the first time since I last commented), and it's locked at 235W and only getting about 25-30 fps (when I should get about 200, that's what I was getting the other day).

gist

[Vash63]

@alasky17 so, it turns out, gamemode was NOT the problem. I have no idea why uninstalling it made it work normally literally once. Nothing else has changed, same driver version and everything. I even deleted the prefix. But sure enough, I try to launch it today (for the first time since I last commented), and it's locked at 235W and only getting about 25-30 fps (when I should get about 200, that's what I was getting the other day).

gist

Reviewing your replies here you still haven't commented whether you tried:

__GLX_LIBRARY_VENDOR_NAME="blah"

This worked for me and many others on Nvidia.

[gardotd426]

@Vash63 I was under the impression that the issue you guys were facing wasn't power-limiting.

[gardotd426]

But regardless, no, it doesn't do anything.

Note the highlighted power data and fps. It should be drawing full power here. And no, it doesn't change when I load into a level either.

[gardotd426]

I mean. Look at this absolute nonsense. This is an RTX 3090. I used to get over 200 fps on these exact settings. Not only that, but NO other game performs other than how I should expect. Actually, every test I've done seems to indicate that I perform slightly ABOVE expectations in all other games.

Even native Vulkan games like Metro Exodus and Wolfenstein: Youngblood. Hell Wolfenstein Youngblood uses idTech 6 (DE runs idTech 7 but still). I get well over 200 fps in Wolfenstein: Youngblood. I get like 120 fps in CP2077 at 1440p high with some RT enabled and DLSS Quality. I get like 120 fps in Dying Light 2 at 1440p with Ray Traced Sun Shadows and Flashlight and all other settings at their highest w/out RT. There is 100% a bug here. Especially since when I disabled and uninstalled gamemode, it worked as normal exactly once.

[gardotd426]

@Vash63 @alasky17 I wanted to add that I tried on both 530.41.03 and 525.47.26, no difference. It's really starting to get maddening where this NEVER happened once before until like two months ago, and I have more hours in Doom Eternal than any other game except Titanfall 2, over 200 hours, own both the DLC, etc, so it's not like I'm confused about my performance from before this bug occurred, and it doesn't happen in ANY other game, whether it's natively DX11, natively Vulkan, natively DX12, natively OpenGL, Unreal Engine, idTech, Unity, Source, nothing.

[kisak-valve]

Problem with validation Doom Eternal on Ubuntu Linux 22.04.2 LTS (Jammy Jellyfish) 64-bit

Issue transferred from #6833.
@grabarz666pg posted on 2023-06-08T09:49:32:

Hi.
I bought Doom Eternal on Steam. After about 7 hours of gameplay, the game stopped launching and the following message popped up:

support.codefusion.technology/de_d90127jd781/?e=88500006&l=polish

which takes me to the page:

https://support.codefusion.technology/de_d90127jd781/?e=88500006&l=polish

I will add that I have not changed anything in the game or system options. I am running Ubuntu Linux 22.04.2 LTS (Jammy Jellyfish) 64-bit, with kernel 6.3.0-060300-generic x86_64, and graphics: AMD Radeon Vega 8 Graphics (raven, LLVM 15.0.7, DRM 3.52, 6.3.0-060300-generic).
I do not have this problem with Doom (2016).
I will be grateful for any hint.

Paweł,
Poland

[kisak-valve]

Hello @grabarz666pg, that sounds like an issue related to Denuvo Anti-Tamper.

The servers for Denuvo Anti-Tamper hand out five activation tickets per 24 hours, and for some reason you've run out of tickets for today. That hints that the game thinks that it's being run on a different system, or the activation ticket isn't getting cached as intended.

[gardotd426]

@Vash63 @alasky17 so, I've discovered something EXTREMELY weird. I've figured out how to force my expected performance back, but it makes literally zero sense.

Okay, so. Right now, if I run the game with ZERO modifiers, zero launch options, it is artificially power-limited and locked to less than 30 fps.

If I add gamemoderun %command%, same issue - and yes, the above statement holds true even when I uninstall gamemode completely.

But I noticed that when trying to use gamemoderun %command% while running Steam through the terminal, a bunch of file not found errors show up, seemingly because of something to do with the Sniper runtime or something, saying that libgamemode.so isn't found, even though it's in /usr/lib.

So, I tried it with LD_PRELOAD=/usr/lib/libgamemode.so gamemoderun %command%.

Success. Game runs at 200 fps with Ray Tracing enabled at 1440p and pulls 366W instead of the 200 it was limited at before.

Only problem is that using LD_PRELOAD=/usr/lib/libgamemode.so kills the steam overlay so I can't actually see my fps.

Trying to use LD_PRELOAD=$LD_PRELOAD:/usr/lib/libgamemode.so OR LD_PRELOAD=/usr/lib/libgamemode.so:/home/matt/.steam/root/ubuntu12_64/gameoverlayrenderer.so brings BACK the steam overlay, BUT it also re-breaks performance and forces 200W.

I spent about an hour last night trying all sorts of permutations, and it seems that for some reason, as of about 6 months ago, on my setup, Doom Eternal CANNOT run without being artificially limited unless I force-load libgamemode.so with LD_PRELOAD and I can't add ANYTHING else to LD_PRELOAD.

But now that I found it, I am able to use MangoHud, I found that the problem where MangoHud was breaking all Proton 8.X games was only seen when using MANGOHUD=1, NOT when using mangohud. So, GAMEMODERUNEXEC=mangohud LD_PRELOAD=/usr/lib/libgamemode.so gamemoderun %command% gives me MangoHud and 200+ fps with no artificial power limit.

I need to reiterate here, this issue (artificial power limits) has NEVER shown up in ANY other game except Doom Eternal.

It was NOT a problem on the exact identical hardware up until a few months ago.

Even when I uninstall MangoHud and Gamemode completely from my system, it stays broken.

For some reason, there's some bug in the Nvidia driver, Proton, the Steam Runtime, or the game itself where gamemode enables it to run at the expected performance, but not using gamemode forces it to run at 200W and <30 fps.

[kisak-valve]

Doom Eternal - Steam Proton - Keyboard layout - Can't find dash

Issue transferred from #6843.
@DenverJoeJohnson posted on 2023-06-12T22:41:14:

APP ID = 782330
Linux - Ubuntu v20.04
GPU1 = Quadro Pro P5000
GPU2= Quadro Pro P5000
NVida Driver = 530.41.03

When playing Steam - Doom Eternal - I need to jump a large gap. I am only using a keyboard and mouse. Per the video helper guides I need to jump then dash. However I dont have a keyboard mapping for dash.

Any help would be greatly appreciated.

Thanks
Joe

[kisak-valve]

Unable to Play Doom Ernal in Mint Linux 21.1 64-bit (kernel 6.3.7-060307 x86_64)

Issue transferred from #6874.
@grabarz666pg posted on 2023-06-25T19:50:53:

Hello.
I bought a new HP Pavilion (Model 14-dv2121nw) with a Intel Core i5-1235U x12 processor and IRIS x (ADL GT2) integrated graphics (also Intel). I installed Linux Mint 21.1 Vera with kernel 6.3.7-060307 (x86_64) on it (updated manually). I am unable to play Doom Eternal on it. After displaying Bethesta logo it crashes to desktop. I tried to rug a game on all versions of Proton, according to the advice:

https://www.youtube.com/watch?v=g3UPxd8iUsU&ab_channel=ChrisTitusTech

where the author successfully launched Doom on the Proton-5.4-GE-2 with the boot options from the video content. This way also doesn't work in my case I also tried all the above methods on kernel 5.15 (default for Mint) and 5.19 - no effect. Mesa drivers are up to date.
I would like to add that on my previous computer – Lenovo IdeaPad S400-14API (AMD Ryzen 3500U and Radeon Vega 8 LLVm graphics, DRM 3.52) with Ubuntu Linux 22.0.4 LTS and kernel 5.15.75 the game was possible.

System Information

System:
  Kernel: 6.3.7-060307-generic x86_64 bits: 64 compiler: N/A
    Desktop: MATE 1.26.0 Distro: Linux Mint 21.1 Vera
    base: Ubuntu 22.04 jammy
Machine:
  Type: Laptop System: HP product: HP Pavilion Laptop 14-dv2xxx
    v: N/A serial: <superuser required>
  Mobo: HP model: 89F3 v: 14.24 serial: <superuser required>
    UEFI: AMI v: F.07 date: 10/14/2022
Battery:
  ID-1: BAT0 charge: 43.8 Wh (100.0%)
    condition: 43.8/43.3 Wh (101.1%) volts: 13.1 min: 11.6
    model: HP Primary status: Full
  Device-1: hidpp_battery_1
    model: Logitech Wireless Mouse M280/320/275
    charge: 55% (should be ignored) status: Discharging
CPU:
  Info: 10-core (2-mt/8-st) model: 12th Gen Intel Core i5-1235U
    bits: 64 type: MST AMCP arch: Alder Lake rev: 4 cache:
    L1: 928 KiB L2: 6.5 MiB L3: 12 MiB
  Speed (MHz): avg: 1572 high: 2500 min/max: 400/4400:3300 cores:
    1: 652 2: 2500 3: 694 4: 2500 5: 614 6: 796 7: 2500 8: 2500
    9: 509 10: 2500 11: 610 12: 2500 bogomips: 59904
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
  Device-1: Intel vendor: Hewlett-Packard driver: i915 v: kernel
    bus-ID: 00:02.0
  Device-2: Cheng Uei Precision Industry (Foxlink) HP Wide Vision
    HD Camera
    type: USB driver: uvcvideo bus-ID: 3-3:3
  Display: x11 server: X.Org v: 1.21.1.4 driver: X:
    loaded: modesetting unloaded: fbdev,vesa gpu: i915
    resolution: 1920x1080~60Hz
  OpenGL: renderer: Mesa Intel Graphics (ADL GT2)
    v: 4.6 Mesa 22.2.5 direct render: Yes
Audio:
  Device-1: Intel Alder Lake PCH-P High Definition Audio
    vendor: Hewlett-Packard driver: sof-audio-pci-intel-tgl
    bus-ID: 00:1f.3
  Sound Server-1: ALSA v: k6.3.7-060307-generic running: yes
  Sound Server-2: PulseAudio v: 15.99.1 running: yes
  Sound Server-3: PipeWire v: 0.3.48 running: yes
Network:
  Device-1: Realtek RTL8822CE 802.11ac PCIe Wireless Network Adapter vendor: Hewlett-Packard driver: rtw_8822ce v: N/A port: 3000
    bus-ID: 01:00.0
  IF: wlo1 state: up mac: <filter>
Bluetooth:
  Device-1: Realtek 802.11ac WLAN Adapter type: USB driver: btusb
    v: 0.8 bus-ID: 3-10:4
  Report: rfkill ID: hci0 rfk-id: 4 state: down
    bt-service: not found rfk-block: hardware: no software: yes
    address: see --recommends
Drives:
  Local Storage: total: 476.94 GiB used: 376.64 GiB (79.0%)
  ID-1: /dev/nvme0n1 vendor: Western Digital
    model: WD PC SN740 SDDPNQD-512G-1006 size: 476.94 GiB
    temp: 34.9 C
Partition:
  ID-1: / size: 36.37 GiB used: 14.63 GiB (40.2%) fs: ext4
    dev: /dev/nvme0n1p2
  ID-2: /boot/efi size: 475.1 MiB used: 6.1 MiB (1.3%) fs: vfat
    dev: /dev/nvme0n1p1
  ID-3: /home size: 431.26 GiB used: 362.01 GiB (83.9%) fs: ext4
    dev: /dev/nvme0n1p3
Swap:
  ID-1: swap-1 type: file size: 1.72 GiB used: 1.72 GiB (99.6%)
    file: /swapfile
Sensors:
  System Temperatures: cpu: 51.0 C mobo: N/A
  Fan Speeds (RPM): cpu: 0 fan-2: 0
Info:
  Processes: 316 Uptime: 3d 1h 41m Memory: 15.29 GiB
  used: 4.68 GiB (30.6%) Init: systemd runlevel: 5 Compilers:
  gcc: 11.3.0 Packages: 2351 Shell: Bash v: 5.1.16 inxi: 3.3.13

Anyone have an idea how to run the game?
I will be very grateful for any advice.

Regards,
Paul from Poland

[sonic2kk]

I tried to rug a game on all versions of Proton, according to the advice:

https://www.youtube.com/watch?v=g3UPxd8iUsU&ab_channel=ChrisTitusTech

where the author successfully launched Doom on the Proton-5.4-GE-2

Just to make sure, have you tried running the game with a newer Proton version? Such as Proton 8.0-2.

Aside from that, you might want to check/attach a Proton log (running with PROTON_LOG=1 in the launch options should create a log file in your home directory).

It is possible that the Mesa drivers for Intel don't implement the required Vulkan features, the log file might make this clearer. From what I understand, Vulkan support for integrated Intel chips (ANV driver) is not quite as good as the support for AMD chips (RADV). There could also be an entirely different issue.

If it is GPU-driver related, Mess 23 might have some improvements (from what I can see you're using Mess 22). Since DOOM Eternal uses Vulkan, I believe there is pretty much direct passthrough to use the system Vulkan, and DXVK isn't required here. So the issue shouldn't be related to DXVK, but there may be improvements with updated Wine versions in newer Proton versions (or other Proton flavours, such as GE-Proton or Proton-tkg) that may fix the issue.

[mbriar]

Doom eternal not working on Intel is a driver issue: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7838, https://gitlab.freedesktop.org/mesa/mesa/-/issues/7600, https://gitlab.freedesktop.org/mesa/mesa/-/issues/7721

[kisak-valve]

Doom Eternal crash when launch game using Proton8.0 and experimental - Proton7.0 works fine

Issue transferred from #6886.
@Reger95 posted on 2023-06-28T08:40:57:

System Infomation:
CPU: AMD 5800X3D
GPU: AMD 6900 XT
OS: ubuntu 22.04

Similar issues is reported here #6782 (comment).
I did some further research but stuck now.

Doom Eternal fails to launch on the AMD open-source and proprietary drivers with the Proton8.0 and Proton experimental,
and here is a msg get from game launch crash, Assertion failed: !status, file ../src-wine/dlls/winevulkan/loader_thunks.c, line 3043.
What the assertion is point to VkResult WINAPI vkDeferredOperationJoinKHR(VkDevice device, VkDeferredOperationKHR operation).
I tried to dump api from the game using vkconfig, and the last one is also vkDeferredOperationJoinKHR.

The address of vkCreateRayTracingPipelinesKHR is same as vkCreateGraphicsPipelines when I use proton8.0.
The address of every vkCreateWhateverPipelines is different when I use proton7.0. As shown in the picture below.

The reason is probably related to the deferred operation. For raytracing pipeline, it will be used deferred for some reason, and in this condition when using proton 8.0, the deferred operation will can't find the address of original raytracing pipeline because the memory address of this pipeline had been occupied by other type pipelines.

RADV works fine. But I have a look in its source code and I found that the deferred operation isn't implemented completely yet. It will return success directly when using the deferred operation and what you can see it in the source code snip.

// source code snip of RADV
// From /mesa/src/vulkan/runtime/vk_deferred_operation.c
VKAPI_ATTR uint32_t VKAPI_CALL
vk_common_GetDeferredOperationMaxConcurrencyKHR(UNUSED VkDevice device,
                                                UNUSED VkDeferredOperationKHR operation)
{
   return 1;
}
VKAPI_ATTR VkResult VKAPI_CALL
vk_common_GetDeferredOperationResultKHR(UNUSED VkDevice device,
                                        UNUSED VkDeferredOperationKHR operation)
{
   return VK_SUCCESS;
}
VKAPI_ATTR VkResult VKAPI_CALL
vk_common_DeferredOperationJoinKHR(UNUSED VkDevice device,
                                   UNUSED VkDeferredOperationKHR operation)
{
   return VK_SUCCESS;
}

I also found memory allocation of VkRayTracingPipelineCreateInfoKHR things is different in the source code of wine between proton7.0 and proton8.0. This info may be useful.

In proton7.0, when using convert_VkRayTracingPipelineCreateInfoKHR_array_win_to_host the memory will be allocated directly by malloc.

Proton7.0
From /Proton/wine/dlls/winevulkan/vulkan_thunks.c
static inline VkRayTracingPipelineCreateInfoKHR_host *convert_VkRayTracingPipelineCreateInfoKHR_array_win_to_host(const VkRayTracingPipelineCreateInfoKHR *in, uint32_t count)
{
    VkRayTracingPipelineCreateInfoKHR_host *out;
    unsigned int i;
    if (!in || !count) return NULL;
    out = malloc(count * sizeof(*out));
    for (i = 0; i < count; i++)
    {
        out[i].sType = in[i].sType;
        ......
        out[i].basePipelineIndex = in[i].basePipelineIndex;
    }
    return out;
}

In proton8.0, when using convert_VkRayTracingPipelineCreateInfoKHR_array_win64_to_host the memory will be allocated by function conversion_context_alloc.

Proton8.0
From /Proton/wine/dlls/winevulkan/vulkan_thunks.c
static inline const VkRayTracingPipelineCreateInfoKHR *convert_VkRayTracingPipelineCreateInfoKHR_array_win64_to_host(struct conversion_context *ctx, const VkRayTracingPipelineCreateInfoKHR *in, uint32_t count)
{
    VkRayTracingPipelineCreateInfoKHR *out;
    unsigned int i;
    if (!in || !count) return NULL;
    out = conversion_context_alloc(ctx, count * sizeof(*out));
    for (i = 0; i < count; i++)
    {
        convert_VkRayTracingPipelineCreateInfoKHR_win64_to_host(ctx, &in[i], &out[i]);
    }
    return out;
}

I'm stuck here and I don't know what to do next, can anyone have a deeper investigate.

---

@lukelmy commented on 2023-06-28T09:11:35:

It seems like wine should consider the situation of deferred operations and modify the strategy of address-allocation in this case since same address may obtained from conversion_context_alloc() .

[bluestang2006]

Does this branch fix the Proton 8 issue - https://gitlab.winehq.org/DadSchoorse/wine/-/commits/wv-meme-feature ?

@Reger95 @lukelmy @kisak-valve

[bluestang2006]

Update - the branch works, I tested against Proton-8 BE - 466a789 and Doom Eternal is working with AMDVLK again.

[bluestang2006]

@Reger95 the fix has been applied to Proton 8 Experimental [Bleeding Edge] branch. Also thanks to you for posting the debug info, this got the ball rolling to fix the issue.