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.

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

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

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, 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!

"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

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

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)

This game is also seems to be affected by https://github.com/ValveSoftware/Proton/issues/2927

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

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!

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.

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.

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

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.

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.

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?

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?

Let me test. Thank you

I am on Fedora 32 Workstation with Steam flatpak. NVIDIA 1080 Ti. DOOM Eternal crashes at start. I have a tiny blank wine window for a few seconds. The window then closes and the game is not started. System info attached. I do have NVIDIA 440.82 drivers.

I use Proton 5.0.7

steam-hw.txt

@vatula I'm out of the loop when it comes to doom eternal, but could you get the stdout of wine by running doom manually? I don't think we have enough info to help you.

I was having a massive FPS drop in later stages of the arenas when a lot of monsters and particles appeared on the screen. I tried r_antialiasing 0, and the experience is greatly improved. I think there's an issue with the temporal antialiasing and particles for some reason.
Now the game feels smooth even in big battles.

@vatula I have a configuration almost exactly the same as yours (Fedora 32, GTX 1080 ti, latest released Proton). The only difference is that I don't use the Flatpak Steam. How averse would you be to trying the RPMFusion packge of Steam?

I used to use Flatpak (about a year ago or so), but I would sometimes have issues with games that I didn't have with the RPMFusion version.

DOOM Eternal runs really well for me.

@MagicRB @kisak-valve I'm attaching proton logs for the crash. It's hefty (3.7 GB), has some errors in it but because it's so large I couldn't figure out which one was critical. I have uploaded zipped log to mega.nz steam-782330.zip

@nathanjackson I confirm the game launches when Steam is installed from RPMFusion. @kisak-valve could that mean there's an issue with Steam flatpak?

I'm running into a weird issue after updating my OS. The intro video will freeze periodically, for almost exactly 5 seconds, then run for half a second or so, then freeze again and so on. The system is unresponsive during those freezes.

Specs:

• OS: Pop!_OS 20.04, kernel 5.4.0-7626-generic
• GPU: nVidia RTX 2070 Max-Q, driver version 440.82
• Vulkan: 1.2.140, installed manually
• Proton: happens both with 5.5-GE-1 and 5.0-7

The Proton logs show several lines that seem to repeat on each freeze:

10015.302:002d:002e:trace:seh:dwarf_virtual_unwind next function rip=0000000140325af5
10015.302:002d:002e:trace:seh:dwarf_virtual_unwind   rax=00007fffffea8000 rbx=00000000075a1cb0 rcx=00000000008fd690 rdx=000000007b475166
10015.302:002d:002e:trace:seh:dwarf_virtual_unwind   rsi=0000000000000005 rdi=0000000000000001 rbp=00000000008fee60 rsp=00000000008fed60
10015.302:002d:002e:trace:seh:dwarf_virtual_unwind    r8=00000000008fe910  r9=000000007b4751a0 r10=000000007bd225a8 r11=0000000000000000
10015.302:002d:002e:trace:seh:dwarf_virtual_unwind   r12=0000000000000001 r13=0000000000000001 r14=000000014293fd90 r15=ffffffffffffffff
10015.302:002d:002e:trace:seh:RtlRestoreContext returning to 7b475166 stack 8fe9d0
10015.432:002d:003e:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\dxvk_config.dll" at 0x69040000: native
10020.444:002d:002e:warn:debugstr:OutputDebugStringA "WARNING: PumpSessionAndNetworkPackets: Not called for 5.00 seconds\n"
10020.518:002d:002e:trace:seh:raise_exception code=40010006 flags=0 addr=0x7b00fdce ip=7b00fdce tid=002e
10020.518:002d:002e:trace:seh:raise_exception  info[0]=0000000000000044
10020.518:002d:002e:trace:seh:raise_exception  info[1]=00000000008fef10
10020.518:002d:002e:trace:seh:raise_exception  rax=00000000008fe930 rbx=00007fffffea8000 rcx=00000000008fe910 rdx=0000000000000000
10020.518:002d:002e:trace:seh:raise_exception  rsi=00000000008fea10 rdi=00000000008fe940 rbp=00000000008fed50 rsp=00000000008fe8f0
10020.518:002d:002e:trace:seh:raise_exception   r8=0000000000000002  r9=00000000008fea00 r10=000000007b47aa26 r11=0000000000000000
10020.518:002d:002e:trace:seh:raise_exception  r12=0000000000000001 r13=0000000000000001 r14=000000014293fd90 r15=ffffffffffffffff
10020.518:002d:002e:trace:seh:call_vectored_handlers calling handler at 0x69060d70 code=40010006 flags=0
10020.518:002d:002e:trace:seh:call_vectored_handlers handler at 0x69060d70 returned 0
10020.518:002d:002e:trace:seh:call_vectored_handlers calling handler at 0x14094ae30 code=40010006 flags=0
10020.518:002d:002e:trace:seh:call_vectored_handlers handler at 0x14094ae30 returned 0
10020.518:002d:002e:trace:seh:RtlVirtualUnwind type 1 rip 7b00fdce rsp 8fe8f0
10020.518:002d:002e:trace:seh:dump_unwind_info **** func fd80-fe07
10020.518:002d:002e:trace:seh:dump_unwind_info unwind info at 0x7b08e344 flags 0 prolog 0x11 bytes function 0x7b00fd80-0x7b00fe07
10020.518:002d:002e:trace:seh:dump_unwind_info     0x11: subq $0xc8,%rsp
10020.518:002d:002e:trace:seh:dump_unwind_info     0xa: pushq %rsi
10020.518:002d:002e:trace:seh:dump_unwind_info     0x9: pushq %rdi
10020.518:002d:002e:trace:seh:dwarf_virtual_unwind function 7b439ca1 base 0x7b439a58 cie 0x7b490710 len 14 id 0 version 1 aug 'zR' code_align 1 data_align -8 retaddr %rip

Here's a few more extracts around some of those freezes: https://gist.github.com/thebozzcl/d443097713938069abb233dabd4bba47

I'm still checking system logs to see if I find another pattern that could give me a clue.

When attempting to play Battlemode, I have not been able to connect to any games. I noticed some Bad Requests to AcceptGroupInvitation in the console, but I have been connected to Bethesda.net with no issue.

When attempting to play Battlemode, I have not been able to connect to any games. I noticed some Bad Requests to AcceptGroupInvitation in the console, but I have been connected to Bethesda.net with no issue.

I am having the same problem, this used to work on a previous Proton version.

When attempting to play Battlemode, I have not been able to connect to any games. I noticed some Bad Requests to AcceptGroupInvitation in the console, but I have been connected to Bethesda.net with no issue.
I am having the same problem, this used to work on a previous Proton version.

@nathanjackson Really? What was the version? I was never able to play Battlemode in any Proton versions :/

Battlemode worked for me when I had the following configuration:

• Proton 5.0-6 or 5.4-GE-3 (Glorious Eggroll)
• Fedora 30
• NVIDIA 440.82

However, I've recently upgraded to Fedora 32 and Battlemode stopped working, but a few variables changed:

• Proton 5.0-7
• Fedora 32
• NVIDIA 440.82

As a test, I tried Proton 5.4-GE-3 on Fedora 32 and Battlemode still did not work. So I think something about the OS upgrade has resulted in Battlemode no longer working. Although I think Bethesda pushed an update to DOOM Eternal for the Battlemode changes, so maybe that had something to do with it? It's weird because I can connect without issue to Bethesda.

From techraptor.net interview:

TR: Linux gamers were previously able to play the game on Steam via Proton in singleplayer. Adding Denuvo Anti-Cheat there has blocked that - is there any way that Denuvo Anti-Cheat could allow the single-player to run on virtual machines while protecting multiplayer or removing it?

MG: We've been tracking the Proton issue immediately after launch and are committed to delivering a fix soon. This isn't a request coming to us from a publisher or anything like that - we genuinely respect such an enthusiast community and regret introducing this incompatibility on day 1.

This makes me feel warm and fuzzy inside, thanks for sharing @mgreshis !

From techraptor.net interview:

TR: Linux gamers were previously able to play the game on Steam via Proton in singleplayer. Adding Denuvo Anti-Cheat there has blocked that - is there any way that Denuvo Anti-Cheat could allow the single-player to run on virtual machines while protecting multiplayer or removing it?

MG: We've been tracking the Proton issue immediately after launch and are committed to delivering a fix soon. This isn't a request coming to us from a publisher or anything like that - we genuinely respect such an enthusiast community and regret introducing this incompatibility on day 1.

Can you provide a link to this interview?

https://techraptor.net/gaming/news/doom-eternals-latest-update-breaks-game

"MG" is the product owner of Denuvo Anti-Cheat for context.

https://techraptor.net/gaming/news/doom-eternals-latest-update-breaks-game

"MG" is the product owner of Denuvo Anti-Cheat for context.

Who is also, judging by the username, @mgreshis, who posted the interview excerpt and the link. So we have the product owner right here in the issue.

Guys, I'm pretty frustrated about this situation as well. I'm not a huge fan of Kernel level anticheat in general, and it breaking a game that was working is certainly disheartening.

We can be frustrated with Bethesda for deploying this, however, let's give Denuvo a chance to deliver, that's certainly one of the most powerful and direct statements (I've seen at least) from an anticheat development company, and it's encouraging.

Also for @kisak-valve's sake and everyone else subscribed to this issue waiting for news of how to get this game running again... Let's keep this from turning into numerous rants, and discussions of refunds. We have reddit, bethesda forums, and steam forums to discuss this broader topic in.

Now that I think of it, I don't know how that would work, because you can't dictate wine or proton versions. You can't enable vkd3d or dxvk that way either, but this game obviously shouldn't need it because it's native Vulkan.

@btegs, the vulkan version on the HUD is just what's reported in /usr/share/vulkan/icd.d/radeon_icd.x86_64.json. It has nothing to do with launching the game, and the game doesn't check that file. If you have the latest libvulkan, or you're using the Steam runtime, you have 1.2.135. Look for yourself, open /usr/share/vulkan/icd.d/radeon_icd_x86_64.json in nano or vim or whatever, and you'll see 1.2.128, change it to 135 and launch some game with it, you'll see it says 1.2.135. It has no bearing whatsoever on being able to launch the game.

I suspect Steam simply won't allow downloading of older files. If one thinks about it it's understandable. The publisher don't want "cheatable" versions of the game to be out there.

Unless they changed something overnight, they do allow it. Multiple people in this thread have downloaded the old games files from Steam and are running the game on Linux. I downloaded them yesterday and have been playing the game today

I hope that proton will by pass this proton issue soon as possible...

From techraptor.net interview:
MG: We've been tracking the Proton issue immediately after launch and are committed to delivering a fix soon. This isn't a request coming to us from a publisher or anything like that - we genuinely respect such an enthusiast community and regret introducing this incompatibility on day 1.

@mgreshis is there any link for a progress update or anything like that? How would we know if it's ready to test? If you'll need betatesters, I'm sure lots of people will be keen to try

@mgreshis me either, if need some betatesters

From techraptor.net interview:
MG: We've been tracking the Proton issue immediately after launch and are committed to delivering a fix soon. This isn't a request coming to us from a publisher or anything like that - we genuinely respect such an enthusiast community and regret introducing this incompatibility on day 1.

@mgreshis is there any link for a progress update or anything like that? How would we know if it's ready to test? If you'll need betatesters, I'm sure lots of people will be keen to try

@mgreshis me either, if need some betatesters

Valve employees have asked numerous times for you to keep these discussions off of this thread.

I only saw them mentioning downgrading will be considered off-topic. But anti-cheat is responsible for breaking current version of the game. So I, myself, would consider all info about the anti-cheat getting a Linux compatibility to be relevant. Maybe I missed something?

Has anybody else noticed some weird graphical artifacts in game? With the Heavy Cannon + Micro Missiles, I get an absolute ton of green bars showing up on my display (to the point where it's unplayable). It's definitely NOT my GPU, as it's only with this certain weapon, and it doesn't happen on Windows.

I had a similar but not identical issue. However, that was on other things, not just heavy canon/micro missiles. And it was absolutely an graphics driver issue: Switching my Vulkan implementation fixed it.

@jjbarr Out of curiosity, are you talking about AMD's Vulkan implem/loader? I wasn't super clear about it but I'm using the proprietary NVIDIA driver on Void (440.82)

The loader is the same across implementations, but I'm using AMD, yeah.

You might be experiencing a different issue, but if it is a driver problem that's not great.

@hatf0 I had artifacts in strange colors for blood and other particles. The problem went away for me after resetting the ingame graphics settings. I'm guessing the artifacts I was seeing were caused by a certain combination of custom settings.

I hope this is relevant. The executive producer Marty Stratton tells that the anti-cheat requirement will be removed in an upcoming update:
https://www.reddit.com/r/Doom/comments/gnjlo7/latest_information_on_update_1_anticheat/

I hope that means the update means there's a chance of this working with proton once again without too many workarounds.

I hope this is relevant. The executive producer Marty Stratton tells that the anti-cheat requirement will be removed in an upcoming update:
https://www.reddit.com/r/Doom/comments/gnjlo7/latest_information_on_update_1_anticheat/

I hope that means the update means there's a chance of this working with proton once again without too many workarounds.

Denuvo Anti-Cheat will have Proton support out-of-the-box for releases beyond DOOM: Eternal. Feel free to @ me directly with feedback once you had a chance to try it. I'm happy access is restored for you guys.

Awesome news overall. Can't wait to get back to playing (and finishing) the game.

@mgreshis

Denuvo Anti-Cheat will have Proton support out-of-the-box for releases beyond DOOM: Eternal. Feel free to @ me directly with feedback once you had a chance to try it.

Can you link to the relevant upstream patches to wine that relate to this please?

@mgreshis does this mean the anti-cheat will automatically be disabled or did you implement compatibility for Wine?

looks promising, maybe even battlemode and invasion may work. Fingers crossed, and shotgun
cocked)

@mgreshis, I hope this is true. I don't know if you mean that there will also be a Ring 0 AC for Proton use, or whether it will just make an exception for Proton, but either way if this is true, it's monumental. This would be the first real client-side anti-cheat to work on Linux through Proton, and that's the biggest hurdle left for Linux gaming. This is huge, if it's true.

I hope this is relevant. The executive producer Marty Stratton tells that the anti-cheat requirement will be removed in an upcoming update:
https://www.reddit.com/r/Doom/comments/gnjlo7/latest_information_on_update_1_anticheat/
I hope that means the update means there's a chance of this working with proton once again without too many workarounds.

Denuvo Anti-Cheat will have Proton support out-of-the-box for releases beyond DOOM: Eternal. Feel free to @ me directly with feedback once you had a chance to try it. I'm happy access is restored for you guys.

@mgreshis That's fantastic news and I would love to know more about what this means or how it would work with Proton? Either way that's awesome, I'm sure many Linux gamers will appreciate it and take note, and will be hoping future Windows-only games protected by anticheat are protected by Denuvo Anti-Cheat.

If you wouldn't mind, could Denuvo make an announcement and let us know when the next Denuvo Anti-Cheat protected game comes out which includes this Proton support OOTB? I'd love to hear about it when it happens, I'd be keen to try it out and test it personally.

@mgreshis thanks for thinking about us.

If I could just provide some feedback - and this is applicable for Windows users as well - please do not provide anti-cheat solutions which run as kernel 0 level.
This precise reason is what triggered the whole community (Linux + Windows) and I'm not sure adding support for the former (Linux) would mitigate any of the feedback received so far.

Thanks again for supporting us.

@mgreshis would definitely like to see it cleared up if you mean DAT will work with Proton + Online or if you mean it will auto-detect to disable for offline play

@BloodyIron here's the article https://techraptor.net/gaming/news/doom-eternals-latest-update-breaks-game

Of course that's all now out of date, but just to provide the context.

proton_patches.zip

The attached work in progress patchset (on top of Proton 5.0.7) allowed me to start the game. I did not test it beyond the start screen yet. I hope that the game should work though, while that is unlikely for multiplayer.

Also, the chances are it will break on any DAC update.

Does this Proton patch allow installing and running the DAC driver or is it a bit more of a workaround to make the usermode side happy enough to start up in singleplayer?

@gofman, there won't be any more DAC updates, DAC is being removed from the game, so this patch won't be needed upon the next update. Apparently it's supposed to come within a week, and the game will work on Linux as it did before.

Does this Proton patch allow installing and running the DAC driver or is it a bit more of a workaround to make the usermode side happy enough to start up in singleplayer?

This is the former and it is confirmed working for now for single player. But it allows the driver to merely start and proceed through initial handshake sequence. The support for some facilities which are probably required to work in the "active" anticheat phase is just stubbed. I could not yet test multiplayer in DAC due to unrelated preexisting problem with multiplayer (which still fires now), but it doesn't look likely to me that it would work now.

There were some modifications of the patchset, so if anyone is interested in building and trying this I can provide an updated one.

Proton does have the framework for running kernel model drivers, and some anti-cheat drivers do work under it. The patchset adds some missing bits and pieces, stubs for some kernel API functions which are very hard to implement and other workarounds as well. However, drivers in Proton run in user mode on Linux, and certain things which kernel drivers do are just emulated. There are (and will always be) the ways the driver (or normal user space program as well) can detect that it is running under Proton and not under genuine Windows. So ultimately in the end the possibility to support for the given anti-cheat solution in Proton depends on whether the anti-cheat is willing (or can tolerate) running this way, or instead denies that.

@gofman That sounds great. Can you provide the updated patchset? Or maybe you have an updated GitHub fork with your updates?
(If possible, can you maybe provide some very brief instructions of how I would install it? I never did it. I would just git clone Proton 5.0.7, then apply your patches, then make install, and that's all, then it should work?)

(If possible, can you maybe provide some very brief instructions of how I would install it? I never did it. I would just git clone Proton 5.0.7, then apply your patches, then make install, and that's all, then it should work?)

Building Proton make take some time if you are doing that for the first time. I guess the easiest way is to follow the instructions here:
https://github.com/ValveSoftware/Proton

Basically you need to clone the sources, switch to correct branch (proton_5.0-next), apply my patches in 'wine' submodule' (you will need to make sure everything is applied cleanly) and follow the instructions in 'Building' section of Proton github page. If your build VM (see 'Set up the build environment') gets configured right, building and installing Proton to your local steam installation is as easy as 'make install' in Proton source tree root.

proton_patches.zip

@albertz, I wouldn't do it that way. It's far, far too complicated if you've never done it before. There is a much easier way, and that's using @tk-glitch's tkg build.

Just clone his repo, https://github.com/frogging-family/wine-tkg-git (it contains both wine and proton directories) and cd into wine-tkg-git/proton-tkg/. Then you'll just want to edit the configuration options to your liking (stuff like enabling certain fixes, tkg's proton builds include a ton of patches and workarounds, he was the first one to get a custom proton to get Doom Eternal up and running in the first place, his builds are very similar to Glorious Eggroll's, and they're what Lutris bases their wine builds on). Once you edit that, you just need to copy the patch into the proton-tkg directory and give it the .mypatch extension, and then run ./proton-tkg.sh. You'll get prompted during the build asking if you want to apply the patch, hit y, and that's it. His script automatically installs the proton build into the compatibilitytools.d/ directory and everything. It's far, far easier than building proton the traditional way.

That said, building proton requires a lot of dependencies you might not be aware of, regardless of which method you choose. So make sure you have everything you need.

That said again, I wouldn't even bother. It's much easier to just downpatch the game like most of the people here have done (including me), especially when DAC is being removed in a matter of days anyway.

@albertz, I wouldn't do it that way. It's far, far too complicated if you've never done it before. There is a much easier way, and that's using @Tk-Glitch's tkg build.

Just clone his repo, https://github.com/frogging-family/wine-tkg-git (it contains both wine and proton directories) and cd into wine-tkg-git/proton-tkg/. Then you'll just want to edit the configuration options to your liking (stuff like enabling certain fixes, tkg's proton builds include a ton of patches and workarounds, he was the first one to get a custom proton to get Doom Eternal up and running in the first place, his builds are very similar to Glorious Eggroll's, and they're what Lutris bases their wine builds on). Once you edit that, you just need to copy the patch into the proton-tkg directory and give it the .mypatch extension, and then run ./proton-tkg.sh. You'll get prompted during the build asking if you want to apply the patch, hit y, and that's it. His script automatically installs the proton build into the compatibilitytools.d/ directory and everything. It's far, far easier than building proton the traditional way.

That said, building proton requires a lot of dependencies you might not be aware of, regardless of which method you choose. So make sure you have everything you need.

That said again, I wouldn't even bother. It's much easier to just downpatch the game like most of the people here have done (including me), especially when DAC is being removed in a matter of days anyway.

I have done as you said, but I'm not able to get this work.
Compile was ok, but the game don't start.
I placed the proton patches into the proton-tkg directory, the only thing that I have not done is give the mypatch exension, but during the command I've seen that the patches were applied

Folks, you are wasting your time trying to do it with Tkg version. My patchset is based upon proton5.0.7-next, it won't even apply correctly on top of Tkg version. I have another version upon Wine-Staging, but I am not up to rebasing that for every custom build, that is not exactly trivial. Also, building with mainstream Proton is easier regardless if you use recommended way with Vagrant and Steam runtime.

Folks, you are wasting your time trying to do it with Tkg version. My patchset is based upon proton5.0.7-next, it won't even apply correctly on top of Tkg version. I have another version upon Wine-Staging, but I am not up to rebasing that for every custom build, that is not exactly trivial. Also, building with mainstream Proton is easier regardless if you use recommended way with Vagrant and Steam runtime.

Can you tell me how I have to apply the patches?

I was about to say, upstream/staging won't cut it. You can build stock proton with the -tkg build system but you need to enable a couple options to do it, it's not the default behavior.

@gofman I would definitely add an option to enable a 5.9-staging version of the patchset if that's something you'd be okay with. Any needed adjustment would be on me, of course.

I've read how to build proton.
Too difficult for me, I have to wait Id's denuvo remove :)

patches_staging.zip

@Tk-Glitch Sure, why not if you are up for that. Those patches are not in Staging itself, it is rather long patchset and given the Doom's rollback is expected I don't think maintaining it in Staging worth it. I am hoping to upstream most of that sooner or later though. Just in case you would like to make your build with those patches, I am attaching the version based on top on latest (5.9 release) Staging, it was working for me today.

I was about to say, upstream/staging won't cut it. You can build stock proton with the -tkg build system but you need to enable a couple options to do it, it's not the default behavior.

@gofman I would definitely add an option to enable a 5.9-staging version of the patchset if that's something you'd be okay with. Any needed adjustment would be on me, of course.

Can you tell us the options to enable ?
I've built a proton version with @Tk-Glitch ... maybe with the right options the game may will work for me..

@gofman Thanks! I'll add the patchset to the "community-patches" with all due credits. It'll be fully optional/non-default so folks who want it will have to mean it.

Edit: the patchset you sent contains multiple patches already mainlined/staged in 5.9. Is it expected? It also doesn't apply cleanly to staging outside of the already merged patches.
Edit2: Yeah the patchset is clearly outdated and looks more like a 5.8 version :D

@dylanmc1975 Considering what you said earlier, I can tell the patches weren't applied if you didn't switch the extension to .mypatch. You probably saw the staging patches getting applied. That being said, I'll add Paul's patchset as an option (please give me a few minutes to do that and review) so you can enable it by adding gofman_dac.mypatch to the _community_patches array in your proton-tkg.cfg.

Edit: Since I have to do a cleanup pass and rebase the patchset, it might will take me a while :frog:

I have renamed the patches, but nothing seems to work :(
But I get the error with the DRM free binary, with the original downloaded binary no errors but it doesen't start.

I have moved the renamed patches in myhome/wine-tkg-git-master/proton-tkg/proton-tkg-userpatches/
I've launch proton-tkg.sh but I'm not able to see if the patches were applied..

@dylanmc yes you are able. You will be prompted if you want to run the patches during build time. The build process starts, all of the automatic (non-user) patches get applied, and then you will get a yes or no prompt asking whether you really want to apply whichever userpatches you've selected, and it will display the name of the patch files.

And it seems the patches aren't working at the moment, because there are some already-upstreamed patches included, which the build won't allow for, if it detects that or if a patch fails to apply for any other reason, the build immediately aborts as failed. You'll have to wait until they get the patches sorted out to apply correctly, but even then, no one's really going to be able to help you if you don't post logs. You're just telling us "Well i don't know if it worked" when the log clearly shows whether it worked or whether you even have the patch in the right place with the right extension name, etc.

How I can enable logs?

What? You don't, I'm talking about the output of the build. Like the terminal output when you run the proton-tkg.sh script.

I have fount the way to use the patches, the script ask me to apply them.
But I got errors

`` -> Applying your own plain-wine patch /home/luca/Scaricati/wine-tkg-git-master/wine-tkg-git/0001-ntdll-Fill-NumberOfPhysicalPages-field-in-user-share.mypatch
->
-> ######################################################
patching file dlls/ntdll/tests/virtual.c
Reversed (or previously applied) patch detected! Skipping patch.
4 out of 4 hunks ignored -- saving rejects to file dlls/ntdll/tests/virtual.c.rej
patching file dlls/ntdll/thread.c
Hunk #1 succeeded at 357 (offset 131 lines).
Hunk #2 FAILED at 326.
1 out of 2 hunks FAILED -- saving rejects to file dlls/ntdll/thread.c.rej
-> Removed BIG_UGLY_FROGMINER - Ribbit
-> Removed Proton-tkg token - Valve Ribbit
-> exit cleanup done

And it seems the patches aren't working at the moment, because there are some already-upstreamed patches included, which the build won't allow for, if it detects that or if a patch fails to apply for any other reason, the build immediately aborts as failed. You'll have to wait until they get the patches sorted out to apply correctly, but even then, no one's really going to be able to help you if you don't post logs. You're just telling us "Well i don't know if it worked" when the log clearly shows whether it worked or whether you even have the patch in the right place with the right extension name, etc.

I've read this.. I have to wait now.

@Tk-Glitch

Edit: the patchset you sent contains multiple patches already mainlined/staged in 5.9. Is it expected? It also doesn't apply cleanly to staging outside of the already merged patches.
Edit2: Yeah the patchset is clearly outdated and looks more like a 5.8 version :D

Are you sure you took the patches_staging.zip from my latest comment (https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-633114122) and not the earlier one for proton 5.0.7-next? I redownloaded what I posted and I see clearly the patches which which I have applied and working on Staging 5.9. In case I am missing something obvious and screwed up something badly can you please link some patch from patches_staging.zip which is outdated or already upstreamed?

@gofman I redownloaded the file, and noticed the content was very different than what I had in my output folder from yesterday. It looks like I mistakenly merged both dirs, giving me huge headaches in the process. The patchset is, indeed, applying fine on 5.9-staging. I apologize for the noise, and thank you again for the patchset and all your work!

The patches is applying fine, but the games still don't start at all :(
With the downloaded steam binary, and also with the drm free version :(

There were reasons I suggested to use Proton 5.0.7-next as a base. While it can definitely work in different builds I am afraid it might be a more involved process. But since here a people who seem to know better how this should be done I am sure they can provide required troubleshooting.

@dylanmc1975 again, we can't help if you don't provide logs.

Add PROTON_LOG=1 to the launch options for the game in Steam. When it crashes, you'll get a steam-782330.log file in your home directory. Upload it.

Also, you need to tell us what launch options you're using in the first place.

I mean, the game is going to work any day now anyway, but still....

steam-782330.log

@dylanmc1975 please don't delete comments. The fact that you're not using any launch options might be the issue. Are you using an AMD or NVidia GPU? Set the launch options thus:

PROTON_LOG=1 PROTON_NO_ESYNC=1 %command% +in_terminal 1 +com_skipIntroVideo 1 +com_skipKeyPressOnLoadScreens 1 +com_skipSignInManager 1

If that doesn't help, if you're using AMD I would suggest using the AMDVLK driver instead of RADV, so you'd need to have AMDVLK installed and add it to the launch options, so your launch options would look like this:

VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/amd_icd64.json:/usr/share/vulkan/icd.d/amd_icd32.json PROTON_LOG=1 PROTON_NO_ESYNC=1 %command% +in_terminal 1 +com_skipIntroVideo 1 +com_skipKeyPressOnLoadScreens 1 +com_skipSignInManager 1

@dylanmc1975 also, is there some reason you're so insistent on using these patches instead of just downpatching the game like everyone else has done in order to play? That method is known to work, so I'm confused why you insist on trying to do it this way, which absolutely isn't guaranteed to work at all.

@dylanmc1975 also, is there some reason you're so insistent on using these patches instead of just downpatching the game like everyone else has done in order to play? That method is known to work, so I'm confused why you insist on trying to do it this way, which absolutely isn't guaranteed to work at all.

The only reason Is that I wad not able ti downgrade the game.
Later I try your Launch options and maybe I try Again downgrade

PROTON_LOG=1 PROTON_NO_ESYNC=1 %command% +in_terminal 1 +com_skipIntroVideo 1 +com_skipKeyPressOnLoadScreens 1 +com_skipSignInManager 1

With this launch options, the game launches, but crash on loading slot game cause denuvo.
I will re-try to downgrade the game.

Just FYI you'll probably always need those launch options, I always have.

On Sun, May 24, 2020 at 2:37 PM dylanmc1975 [email protected]
wrote:

PROTON_LOG=1 PROTON_NO_ESYNC=1 %command% +in_terminal 1
+com_skipIntroVideo 1 +com_skipKeyPressOnLoadScreens 1
+com_skipSignInManager 1

With this launch options, the game launches, but crash on loading slot
game cause denuvo.
I will re-try to downgrade the game.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-633274350,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y332RLB2TJXTLVBXUQ23RTFSQFANCNFSM4MI6DHIA
.

I've tryed to start another game.
The games works, but not the slot I have allways used to play.

How important is +com_skipSignInManager 1? What exactly does it do? @dylanmc1975 Maybe that causes that saved games are not compatible?

Earlier I just used +com_skipIntroVideo 1 and nothing else, and that was fine. I had a Bethesda.net account and using that (logging in) just work fine.

@albertz Maybe.
But I hope not .. I will see when Id's will remove denuvo..

@albertz it's nothing to do with signing in with Bethesda account. I have always used that flag because that's what literally everyone said was needed, and I was always able to sign in with my Bethesda account. I don't know what sign-in manager it skips, but it's not that one.

And it doesn't do anything with saved games, at least it didn't before Denuvo (and doesn't now with the downpatched game), saved games are able to be loaded for me.

And it doesn't do anything with saved games, at least it didn't before Denuvo (and doesn't now with the downpatched game), saved games are able to be loaded for me.

I hope it's only a denuvo thing

@dylanmc1975 I remember a few people said their save slots got wiped post update, so I wonder if what you experienced is just a bug that was introduced in the update.

WTF.
I was close to finish the game..

Il dom 24 mag 2020, 23:22 James McClain [email protected] ha
scritto:

@dylanmc1975 https://github.com/dylanmc1975 I remember a few people
said their save slots got wiped post update, so I wonder if what you
experienced is just a bug that was introduced in the update.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-633302709,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIQDG5LRYZ6GQT2LFZ6MO3DRTGF2JANCNFSM4MI6DHIA
.

There might be an issue with saved games.
I lost my saved slots once when I changed from proton 5.6-GE-2 to native proton 5.0.6 and then again when I switched to 5.8-GE-1.

Game now runs perfectly after Update 1.1. No more Denuvo.

I'm seeing very low performance on RADV: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3054

@libcg just use one of the AMD vulkan drivers. vulkan-amdgpu-pro has the best performance, but if you don't want to use a proprietary driver then AMDVLK is almost as good (and much better than RADV), is open-source, and can live alongside RADV.

The Doom Eternal performance issue with RADV is a known issue. We are working on.

EDIT: removed the tag

@hakzsam Yeah, I know. I think you meant to tag @libcg. Makes zero sense for that to be a reply to me, since my comment is telling him to use AMDVLK and his was about RADV's poor performance.

Hi, my game crashes every time, a "loading screen" appears whenever and crashes at that point. This are my launch commands: PROTON_LOG=1 PROTON_NO_ESYNC=1 %command% +in_terminal 1 +com_skipIntroVideo 1 +com_skipKeyPressOnLoadScreens 1 +com_skipSignInManager 1
My steam.log is too big to upload here, and im new to github, so i dont know how to shrae it.
I wish you can help me and thanks!

Update: it only crashes during cutscenes, it gets stuck in a sudden loading screen, but i was able to play the first level without trouble.

@libcg just use one of the AMD vulkan drivers. vulkan-amdgpu-pro has the best performance, but if you don't want to use a proprietary driver then AMDVLK is almost as good (and much better than RADV), is open-source, and can live alongside RADV.

For me here on an RX480, radv+aco is better than both amdvlk and the closed-source amdvlk in the amdgpu-pro package. Both the min and max fps are higher and it's a serious difference. Using radv+llvm seems similar performance as amdvlk, so I'm thinking aco is what's causing the difference.

The difference in fps is seriously large. I just tried switching between the open amdvlk and radv with the same savegame and got this:

This is with mesa 20.2 and llvm 10.0.0 and amdvlk 2020.Q2.4. About the pro version of amdvlk, I remember it wasn't as good as radv when I tried it. I don't have it installed right now. Screenshots showing what those fps numbers are about are here:

https://imgur.com/a/9jFhO7P

Only problem I found with radv is that it needs RADV_DEBUG=zerovram to fix artifact issues that sometimes show up in particles.

Hi all,

New day, new bug. Whenever I play the game at a non-native resolution. I see weird square flickering artifacts in place of special effects. This doesn't happen at all when playing the game at my monitor's native resolution (either my laptop at 1080p or my external monitor at 4K).

Here's an example, the Archvile in the Battlemode training level. Look at the right hand: https://imgur.com/zI2kGxM . It almost looks like the flame textures are not mapped correctly to the quads that hold them.

System specs:

• Pop!_OS 20.04 (5.4.0-7634-generic)
• nVidia RTX 2070 Max-Q, driver version 440.82
• Vulkan version 1.2.140 (though I think Proton bundles its own version?)

I haven't been able to find this exact problem anywhere else.

Hi, I'm having problems running Doom Eternal post 1.1 Update Patch. For reference, this is my current Hardware setup for my Linux PC:

OS: Pop!_OS 20.04 LTS x86_64
Host: MS-7B89 1.0
Kernel : 5.4.0-7634-generic
CPU: AMD Ryzen 7 3700X
GPU: NVIDIA GeForce RTX 2070 SUPER

Here is the timeline of the problem as I've encountered them so far:

A. Mid-May (right after the 1.1 Update Patch for PC)
Initially there were problems running the game, specifically the following:

1. During the Introduction chapters of the game (basically Chapter 1 & 2), the game noticeably experienced random crashes here and there when I was playing. So essentially I could be in the middle of clearing an arena with a few enemies left, but then suddenly the screen would freeze onto a 'Loading' screen and stop working entirely.
2. The freeze would still weirdly allow the game's audio to continue (basically having a 'Loading' screen, with continuous play of the BGM), but all types of game logic (be it enemies movement, spawns, mouse/keyboard inputs, etc.) seem to stop functioning in the background.
3. The worst part of this is that every time this happens I'm not able to stop the game via pressing the 'Stop' button on Steam, and instead needed to resort to Killing the DOOMEternalx64 PID Process from my 'System Monitor'.

However, the weird thing is that after clearing reaching levels 3 and beyond, this freezing issue seem to have stopped and I was able to finish my first 'fast' Nightmare run around a few weeks ago (sometime around end of May or early June if I recall).

B. Today (June 14, 2020):
I was trying to do a new 100% completion Nightmare run today, starting in a New Game Slot. However, to my surprise these exact same freezing issues re-surfaced during these first introductionary levels, causing me to re-try from the latest checkpoint everytime the Freeze happens. The weird part is that this time the freeze issue seems to happen more frequently (on average around the time to clear one 'arena' between each freeze instances), which made me suspect that there are some compatibility issues caused even by the 1.1 Patch (though I'm not sure whether it's connected with Denuvo or not). I've tried to run all the suggested flags in this thread as well (NO_ESYNC, skipIntroVideo, skipSignInLauncher, etc.), but to no avail.

Seeing this, I then tried different versions of Proton instead, notably the 'GE' versions of Proton, which seem to provide several additions to Proton itself. Unfortunately installing the 5.6 and 5.9 GE version of Proton didn't seem to fix the issue and instead made the Wine System Tray to throw out a GPU Driver error, saying that I have outdated NVIDIA driver version.

I've confirmed through 'nvidia-smi' command that I have the latest driver-440 version from NVIDIA. Weirdly enough, the Wine System Tray instead says my NVIDIA driver is of the driver-378 version, and asking me to update to the driver-445 version, which last time I checked, hasn't even been released for the RTX 2070 Super that I'm using.

What's worse now is that after several re-tries and even a re-installation in Steam, the Wine system now is unable to launch the game at all, stating that 'Something went wrong, and please visit https://support.codefusion.technology/de_d90127jd781/?e=88500006&l=english'. Visiting the error link seem to state that "Currently your game purchase cannot be re-validated successfully, please wait 24 hours and try again." I've then tried several suggestions on Steam on similar issues from other games, most notably this page. However, re-validating my Local Game Files seem to have not solved the issue, which brings me essentially back to pre-1.1 Patch version of the game. I'll wait for 24 hours after this, however that same page stated that waiting 24 hours didn't fix the issue for them, so I'll be updating if it somehow fixes mine.

Has anyone else over here have similar issues on the Linux version of Doom Eternal post 1.1 update so far? And For those who know how Steam's Proton works in detail, may I know what could be the main cause of such issue, and whether there is some solutions that could help me fix/alleviate some of these issues?

Any kind of replies/help is highly appreciated, and thanks for all replies in advance!

Same issues with random crashing and audio keeps playing but you have to force quit the game. Used to work fine before the updates 1.0 (anti cheat broke this completely)and 1.1 (said issues)

From: NickSadjoli [email protected]
Sent: Sunday, June 14, 2020, 8:35 AM
To: ValveSoftware/Proton
Cc: oogetyboogety; Comment
Subject: Re: [ValveSoftware/Proton] Doom Eternal (782330) (#3773)

Hi, I'm having problems running Doom Eternal post 1.1 Update Patch. For reference, this is my current Hardware setup for my Linux PC:

OS: Pop!_OS 20.04 LTS x86_64
Host: MS-7B89 1.0
Kernel : 5.4.0-7634-generic
CPU: AMD Ryzen 7 3700X
GPU: NVIDIA GeForce RTX 2070 SUPER

Here is the timeline of the problem as I've encountered them so far:

A. Mid-May (right after the 1.1 Update Patch for PC)
Initially there were problems running the game, specifically the following:

1. During the Introduction chapters of the game (basically Chapter 1 & 2), the game noticeably experienced random crashes here and there when I was playing. So essentially I could be in the middle of clearing an arena with a few enemies left, but then suddenly the screen would freeze onto a 'Loading' screen and stop working entirely.
2. The freeze would still weirdly allow the game's audio to continue (basically having a 'Loading' screen, with continuous play of the BGM), but all types of game logic (be it enemies movement, spawns, mouse/keyboard inputs, etc.) seem to stop functioning in the background.
3. The worst part of this is that every time this happens I'm not able to stop the game via pressing the 'Stop' button on Steam, and instead needed to resort to Killing the DOOMEternalx64 PID Process from my 'System Monitor'.

However, the weird thing is that after clearing reaching levels 3 and beyond, this freezing issue seem to have stopped and I was able to finish my first 'fast' Nightmare run around a few weeks ago (sometime around end of May or early June if I recall).

B. Today (June 14, 2020):
I was trying to do a new 100% completion Nightmare run today, starting in a New Game Slot. However, to my surprise these exact same freezing issues re-surfaced during these first introductionary levels, causing me to re-try from the latest checkpoint everytime the Freeze happens. The weird part is that this time the freeze issue seems to happen more frequently (on average around the time to clear one 'arena' between each freeze instances), which made me suspect that there are some compatibility issues caused even by the 1.1 Patch (though I'm not sure whether it's connected with Denuvo or not). I've tried to run all the suggested flags in this thread as well (NO_ESYNC, skipIntroVideo, skipSignInLauncher, etc.), but to no avail.

Seeing this, I then tried different versions of Proton instead, notably the 'GE' versionshttps://github.com/GloriousEggroll/proton-ge-custom of Proton, which seem to provide several additions to Proton itself. Unfortunately installing the 5.6 and 5.9 GE version of Proton didn't seem to fix the issue and instead made the Wine System Tray to throw out a GPU Driver error, saying that I have outdated NVIDIA driver version.

I've confirmed through 'nvidia-smi' command that I have the latest driver-440 version from NVIDIA. Weirdly enough, the Wine System Tray instead says my NVIDIA driver is of the driver-378 version, and asking me to update to the driver-445 version, which last time I checkedhttps://www.nvidia.com/Download/driverResults.aspx/159360/en-us, hasn't even been released for the RTX 2070 Super that I'm using.

What's worse now is that after several re-tries and even a re-installation in Steam, the Wine system now is unable to launch the game at all, stating that 'Something went wrong, and please visit https://support.codefusion.technology/de_d90127jd781/?e=88500006&l=english'. Visiting the error linkhttps://support.codefusion.technology/de_d90127jd781/?e=88500006&l=english seem to state that "Currently your game purchase cannot be re-validated successfully, please wait 24 hours and try again." I've then tried several suggestions on Steam on similar issues from other games, most notably this pagehttps://steamcommunity.com/app/582010/discussions/0/1734339624803551854. However, re-validating my Local Game Files seem to have not solved the issue, which brings me essentially back to pre-1.1 Patch version of the game. I'll wait for 24 hours after this, however that same page stated that waiting 24 hours didn't fix the issue for them, so I'll be updating if it somehow fixes mine.

Has anyone else over here have similar issues on the Linux version of Doom Eternal post 1.1 update so far? And For those who know how Steam's Proton works in detail, may I know what could be the main cause of such issue, and whether there is some solutions that could help me fix/alleviate some of these issues?

Any kind of replies/help is highly appreciated, and thanks for all replies in advance!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/ValveSoftware/Proton/issues/3773#issuecomment-643760832, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAZKLVQXB44S3CACP3QPQE3RWS7ZPANCNFSM4MI6DHIA.

The 24 hour message is from trying to launch it too many times, it's the
DRM kicking in. It's nothing to do with verifying files. You just have to
wait 24 hours.

On Sun, Jun 14, 2020 at 12:58 PM oogetyboogety [email protected]
wrote:

Same issues with random crashing and audio keeps playing but you have to
force quit the game. Used to work fine before the updates 1.0 (anti cheat
broke this completely)and 1.1 (said issues)

---

From: NickSadjoli [email protected]
Sent: Sunday, June 14, 2020, 8:35 AM
To: ValveSoftware/Proton
Cc: oogetyboogety; Comment
Subject: Re: [ValveSoftware/Proton] Doom Eternal (782330) (#3773)

Hi, I'm having problems running Doom Eternal post 1.1 Update Patch. For
reference, this is my current Hardware setup for my Linux PC:

OS: Pop!_OS 20.04 LTS x86_64
Host: MS-7B89 1.0
Kernel : 5.4.0-7634-generic
CPU: AMD Ryzen 7 3700X
GPU: NVIDIA GeForce RTX 2070 SUPER

Here is the timeline of the problem as I've encountered them so far:

A. Mid-May (right after the 1.1 Update Patch for PC)
Initially there were problems running the game, specifically the following:

1. During the Introduction chapters of the game (basically Chapter 1 & 2),
   the game noticeably experienced random crashes here and there when I was
   playing. So essentially I could be in the middle of clearing an arena with
   a few enemies left, but then suddenly the screen would freeze onto a
   'Loading' screen and stop working entirely.
2. The freeze would still weirdly allow the game's audio to continue
   (basically having a 'Loading' screen, with continuous play of the BGM), but
   all types of game logic (be it enemies movement, spawns, mouse/keyboard
   inputs, etc.) seem to stop functioning in the background.
3. The worst part of this is that every time this happens I'm not able to
   stop the game via pressing the 'Stop' button on Steam, and instead needed
   to resort to Killing the DOOMEternalx64 PID Process from my 'System
   Monitor'.

However, the weird thing is that after clearing reaching levels 3 and
beyond, this freezing issue seem to have stopped and I was able to finish
my first 'fast' Nightmare run around a few weeks ago (sometime around end
of May or early June if I recall).

B. Today (June 14, 2020):
I was trying to do a new 100% completion Nightmare run today, starting in
a New Game Slot. However, to my surprise these exact same freezing issues
re-surfaced during these first introductionary levels, causing me to re-try
from the latest checkpoint everytime the Freeze happens. The weird part is
that this time the freeze issue seems to happen more frequently (on average
around the time to clear one 'arena' between each freeze instances), which
made me suspect that there are some compatibility issues caused even by the
1.1 Patch (though I'm not sure whether it's connected with Denuvo or not).
I've tried to run all the suggested flags in this thread as well (NO_ESYNC,
skipIntroVideo, skipSignInLauncher, etc.), but to no avail.

Seeing this, I then tried different versions of Proton instead, notably
the 'GE' versionshttps://github.com/GloriousEggroll/proton-ge-custom of
Proton, which seem to provide several additions to Proton itself.
Unfortunately installing the 5.6 and 5.9 GE version of Proton didn't seem
to fix the issue and instead made the Wine System Tray to throw out a GPU
Driver error, saying that I have outdated NVIDIA driver version.

I've confirmed through 'nvidia-smi' command that I have the latest
driver-440 version from NVIDIA. Weirdly enough, the Wine System Tray
instead says my NVIDIA driver is of the driver-378 version, and asking me
to update to the driver-445 version, which last time I checked<
https://www.nvidia.com/Download/driverResults.aspx/159360/en-us>, hasn't
even been released for the RTX 2070 Super that I'm using.

What's worse now is that after several re-tries and even a re-installation
in Steam, the Wine system now is unable to launch the game at all, stating
that 'Something went wrong, and please visit
https://support.codefusion.technology/de_d90127jd781/?e=88500006&l=english'.
Visiting the error link<
https://support.codefusion.technology/de_d90127jd781/?e=88500006&l=english>
seem to state that "Currently your game purchase cannot be re-validated
successfully, please wait 24 hours and try again." I've then tried several
suggestions on Steam on similar issues from other games, most notably this
page<
https://steamcommunity.com/app/582010/discussions/0/1734339624803551854>.
However, re-validating my Local Game Files seem to have not solved the
issue, which brings me essentially back to pre-1.1 Patch version of the
game. I'll wait for 24 hours after this, however that same page stated that
waiting 24 hours didn't fix the issue for them, so I'll be updating if it
somehow fixes mine.

Has anyone else over here have similar issues on the Linux version of Doom
Eternal post 1.1 update so far? And For those who know how Steam's Proton
works in detail, may I know what could be the main cause of such issue, and
whether there is some solutions that could help me fix/alleviate some of
these issues?

Any kind of replies/help is highly appreciated, and thanks for all replies
in advance!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-643760832>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/AAZKLVQXB44S3CACP3QPQE3RWS7ZPANCNFSM4MI6DHIA

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-643793392,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y336KMEDIXCK2T5N63ZDRWT6SVANCNFSM4MI6DHIA
.

Update regarding my freezing problem:

The 24 hours restriction was indeed apparently a Denuvo thingy. Please ignore my issue regarding that one.

After getting the restriction resolved, I then tried to play more of Doom Eternal. However, the freezing issues still persist. What's most annoying is how this also happens on Ultra-Nightmare (The freezing that happened right after the 1.1 patch didn't extend to Ultra-Nightmare iirc). Tweaking some graphics settings didn't seem to help either, so I'm basically stuck right now.

9118.055:00c4:00c8:trace:seh:dwarf_virtual_unwind fde 0x7b4a8280 len 8c personality (nil) lsda (nil) code 7b439968-7b439e60
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b439968: DW_CFA_advance_loc 1
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b439969: DW_CFA_def_cfa_offset 16
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b439969: DW_CFA_offset %rbp, -16
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b439969: DW_CFA_advance_loc 10
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b439973: DW_CFA_def_cfa_register %rbp
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b439973: DW_CFA_advance_loc 39
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_expression %xmm6 7b4a829c-7b4a829f
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %r15, -24
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %r14, -32
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %r13, -40
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %r12, -48
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %rdi, -56
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %rsi, -64
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %rbx, -72
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_advance_loc 11
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399a5: DW_CFA_expression %xmm7 7b4a82b1-7b4a82b4
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399a5: DW_CFA_advance_loc 8
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399ad: DW_CFA_expression %xmm8 7b4a82b8-7b4a82bb
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399ad: DW_CFA_advance_loc 8
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399b5: DW_CFA_expression %xmm9 7b4a82bf-7b4a82c2
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399b5: DW_CFA_advance_loc 8
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399bd: DW_CFA_expression %xmm10 7b4a82c6-7b4a82c9
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399bd: DW_CFA_advance_loc 8
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399c5: DW_CFA_expression %xmm11 7b4a82cd-7b4a82d0
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399c5: DW_CFA_advance_loc 5
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399ca: DW_CFA_expression %xmm12 7b4a82d4-7b4a82d7
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399ca: DW_CFA_advance_loc 5
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399cf: DW_CFA_expression %xmm13 7b4a82db-7b4a82de
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399cf: DW_CFA_advance_loc 5
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399d4: DW_CFA_expression %xmm14 7b4a82e2-7b4a82e5
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399d4: DW_CFA_advance_loc 5
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399d9: DW_CFA_expression %xmm15 7b4a82e9-7b4a82ec
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399d9: DW_CFA_advance_loc2 553
9118.055:00c4:00c8:trace:seh:dwarf_virtual_unwind next function rip=0000000140329405
9118.055:00c4:00c8:trace:seh:dwarf_virtual_unwind   rax=00007fffffd9c000 rbx=00000000150ad710 rcx=00000000008eb8f0 rdx=000000007b475c96
9118.055:00c4:00c8:trace:seh:dwarf_virtual_unwind   rsi=0000000000000001 rdi=00000000fffffffd rbp=00000000008ed0c0 rsp=00000000008ecfc0
9118.055:00c4:00c8:trace:seh:dwarf_virtual_unwind    r8=00000000008ecb70  r9=000000007b475cd0 r10=000000007bd1d388 r11=0000000000000000
9118.055:00c4:00c8:trace:seh:dwarf_virtual_unwind   r12=0000000000000001 r13=0000000000000001 r14=000000014269b2f8 r15=00000000008f5208
9118.055:00c4:00c8:trace:seh:RtlRestoreContext returning to 7b475c96 stack 8ecc30
9136.848:00b8:00bc:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\api-ms-win-appmodel-runtime-l1-1-2.dll" at 0x6c100000: PE builtin
9136.849:00b8:00bc:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFFFFFFFFFA, 000000000091FA90
9137.895:0058:0068:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\drivers\\winehid.sys" : builtin
9137.895:0058:0068:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\hidclass.sys" : builtin
9137.896:0058:0068:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\drivers\\winebus.sys" : builtin
pid 127348 != 127347, skipping destruction (fork without exec?)
from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.

These error messages leads me to believe that there might be something wrong with my Wine installation, though I'm not completely sure. Do note that the pid message might have been produced from my 'Killing' of the DoomEternal.exe process from the System Monitor though, so it might not be related to the game's crash entirely.

Any help with this would be very appreciated, and thanks in advance!

@NickSadjoli I think you're maybe a bit confused about how Steam/Proton work.
Proton doesn't use any of your system wine whatsoever. It includes its own build of wine, you could uninstall wine with sudo apt remove wine or sudo apt remove wine-staging or whatever version of wine you have installed, and the game would still run. It has nothing to do with it.
And unless you built the version of Proton you're using yourself, if you're using a prebuilt version, then it's unlikely to be a "broken" wine/proton issue.

Actually, now I see where you said you were using GE's build of Proton, which is precompiled. So yeah, this has nothing to do with anything on your system as far as WINE is concerned. You've tried multiple versions of Proton (which again, don't even remotely interact with the wine you have installed system-wide).

It could definitely be an Nvidia driver or vulkan-icd-loader issue, though.

Maybe it is this problem that when the Steam app overlays some notification (e.g. new achievement), then it freezes (audio still continues to play, but graphics stop, and it does not respond to inputs anymore). This is the same when you Ctrl+Tab out of the game, or have any other overlayed notification from any other app in the game.

I already disabled the Steam Overlay while in-game (in Steam properties) but still I sometimes get these Steam notifications for new achievements. Maybe when you are playing Nightmare mode for the first time, you would get a couple of these Steam achievements, and that will always make it freeze?

@gardotd426 I see, thanks for the correction. I was indeed under the impression that Proton uses the Wine package that is installed into my machine (I thought it would've been installed as a separate package that was installed simultaneously with Steam), so that's why I thought that something was probably wrong with my Wine installation. Apologies for this assumption, and guess I do need to read more of the documentation of Proton again.

I'm not sure whether it's a vulkan-icd-loader issue, though now that I recall, I did install the Vulkan driver packages (via apt-get install) libvulkan1 and mesa-vulkan-drivers during either the periods that Doom Eternal was bricked (prior 1.1 patch), or sometime during my initial Nightmare complete run (just after 1.11 patch). Prior to the Update 1 fiasco I recalled the game never having any issues without these packages being installed, though I was under the impression that the Proton/Wine package already has Vulkan drivers support (since I'm able to click the 'use Vulkan' option in the Doom Eternal's Graphic setting). Could the installation of these 'separate' drivers possibly be the source of issue?

Just now I tried to perform some extra tests of the game between 9 pm and 10 pm local time. I initially tried out the suggestion given by @albertz to disable the Steam Overlay (cause I was actually experiencing the same issues that he described with regards to Ctrl + Tab or Alt + Tab crashing the game), but unfortunately no luck and still experiencing the exact same freezes. I then tried to Force the BPM overlay to off as well, but no dice as well. What's weird was that this change of setting seemed to have caused the game's save system to glitch out and seemingly 'wiped out' all the Save Files I have locally on my PC (similar to peoples' reports on Save File getting removed after Update 1 earlier in this thread), recognizing all Save Slots as a "New Slot". You can see this in the traces of the first log file output that I'll be posting below for more details.

After this weird issue, my PC then somehow froze outside the game, so I then proceeded to restart my PC. Weirdly enough once I boot into the game (after the 9:13 pm crash), the game seem to have recovered all my previous Save files, and recorded whatever progress I had in the previous session (before the 9:13pm freeze) to the designated slot I chose.

I then decided to give it some try and played the game with this latest state. It seemed to have been going well (didn't experience any freeze for quite a noticeably good period of time), but alas 15 - 20 minutes in the crashes happened again (9:46 pm crash). This was notably with only some of the recommended flags turned on (only Proton Logs, skipIntro, skipKeyPressLoadingScene flags were on) though.

As a final try, I then tried to turn on all the flags that has been recommended in this thread so far (NO_ESYNC and also skipSignInManager), but unfortunately the crash still happened (see 10.03 pm crash log).

I've recorded the last few ms traces of the log files captured for these crashed sessions, however they're quite long so I'll be posting these in subsequent comments one-by-one, limiting them to only the last few hundred lines (Github cannot seem to support all of these lines at once). I've also added the timestamp of the crash logs for reference.

EDIT: Added some comments regarding the log file recordings.

12804.774:00c4:00dc:warn:debugstr:OutputDebugStringA "WARNING: Invalid checkpoint name for target layer visibility_target_change_layer_28: checkpoint save aborted!!\n"
...
12993.870:00c4:0108:trace:seh:RtlRestoreContext returning to 7b475c96 stack 9b72bb0
12993.870:00c4:0108:warn:debugstr:OutputDebugStringA "WARNING: Destructible destructible/imp/leg_severed_left piece (mesh_1) has linear velocity greater than 30.0 m/s.  Please fix decl.\n"
12993.870:00c4:0108:trace:seh:raise_exception code=40010006 flags=0 addr=0x7b00fc3e ip=7b00fc3e tid=0108
12993.870:00c4:0108:trace:seh:raise_exception  info[0]=0000000000000085
12993.870:00c4:0108:trace:seh:raise_exception  info[1]=0000000009b730f0
12993.870:00c4:0108:trace:seh:raise_exception  rax=0000000009b72b10 rbx=00007fffffc9c000 rcx=0000000009b72af0 rdx=0000000000000000
12993.870:00c4:0108:trace:seh:raise_exception  rsi=0000000009b72bf0 rdi=0000000009b72b20 rbp=0000000009b72f30 rsp=0000000009b72ad0
12993.870:00c4:0108:trace:seh:raise_exception   r8=0000000000000002  r9=0000000009b72be0 r10=000000007b47b4e6 r11=0000000000000000
12993.870:00c4:0108:trace:seh:raise_exception  r12=0000000000000001 r13=0000000000000001 r14=00000001427349d0 r15=ffffffffffffffff
...
13016.476:00c4:00fc:trace:seh:execute_cfa_instructions 7b4399d4: DW_CFA_advance_loc 5
13016.476:00c4:00fc:trace:seh:execute_cfa_instructions 7b4399d9: DW_CFA_expression %xmm15 7b4a82e9-7b4a82ec
13016.476:00c4:00fc:trace:seh:execute_cfa_instructions 7b4399d9: DW_CFA_advance_loc2 553
13016.476:00c4:00fc:trace:seh:dwarf_virtual_unwind next function rip=0000000140329405
13016.476:00c4:00fc:trace:seh:dwarf_virtual_unwind   rax=00007fffffccc000 rbx=00000000150ad5a0 rcx=00000000083462b0 rdx=000000007b475c96
13016.476:00c4:00fc:trace:seh:dwarf_virtual_unwind   rsi=0000000000000001 rdi=00000000fffffffd rbp=0000000008347a80 rsp=0000000008347980
13016.476:00c4:00fc:trace:seh:dwarf_virtual_unwind    r8=0000000008347530  r9=000000007b475cd0 r10=000000007bd1d388 r11=0000000000000000
13016.476:00c4:00fc:trace:seh:dwarf_virtual_unwind   r12=0000000000000001 r13=0000000000000000 r14=000000014266ac50 r15=000000000834fbc8
13016.476:00c4:00fc:trace:seh:RtlRestoreContext returning to 7b475c96 stack 83475f0
13027.739:00b8:00bc:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\api-ms-win-appmodel-runtime-l1-1-2.dll" at 0x6c100000: PE builtin
13027.740:00b8:00bc:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFFFFFFFFFA, 000000000091FA90
13028.781:0058:0068:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\drivers\\winehid.sys" : builtin
13028.781:0058:0068:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\hidclass.sys" : builtin
13028.782:0058:0068:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\drivers\\winebus.sys" : builtin
pid 156633 != 156632, skipping destruction (fork without exec?)

I'd like to highlight the first recorded line of this log trace in particular, since this is the crash where the save files were somehow not recognized (almost gave me the impression that previous save files were wiped). This was noticeably happening after I adjusted the Steam Overlay option.

EDIT: Trimmed log file to avoid unnecessary cluttering

...
1458.379:00c4:00f0:trace:seh:dwarf_virtual_unwind   r12=0000000000000001 r13=0000000000000001 r14=00000001426d1cb0 r15=0000000006b1c408
1458.379:00c4:00f0:trace:seh:call_stack_handlers found wine frame 0x6b13fa0 rsp 6b141c0 handler 0x7b475d00
1458.379:00c4:00f0:trace:seh:call_teb_handler calling TEB handler 0x7b475d00 (rec=0x6b13d70, frame=0x6b13fa0 context=0x6b13210, dispatch=0x6b130e0)
1458.379:00c4:00f0:trace:seh:RtlUnwindEx code=40010006 flags=2 end_frame=0x6b13fa0 target_ip=0x7b475c96 rip=000000007bcdb792
1458.379:00c4:00f0:trace:seh:RtlUnwindEx  info[0]=000000000000002f
1458.379:00c4:00f0:trace:seh:RtlUnwindEx  info[1]=0000000006b14370
1458.379:00c4:00f0:trace:seh:RtlUnwindEx  rax=00007fffffcfc000 rbx=0000000006b13fa0 rcx=0000000006b12af0 rdx=000000007b475c96
1458.379:00c4:00f0:trace:seh:RtlUnwindEx  rsi=0000000006b13d70 rdi=0000000006b12500 rbp=0000000006b12ab0 rsp=0000000006b12380
1458.379:00c4:00f0:trace:seh:RtlUnwindEx   r8=0000000006b13d70  r9=000000007b475cd0 r10=000000007bd1d388 r11=0000000000000000
1458.379:00c4:00f0:trace:seh:RtlUnwindEx  r12=0000000006b13d70 r13=0000000006b13210 r14=0000000006b130e0 r15=0000000006b12500
... 
1460.262:00c4:00fc:trace:seh:execute_cfa_instructions 7b4399d4: DW_CFA_advance_loc 5
1460.262:00c4:00fc:trace:seh:execute_cfa_instructions 7b4399d9: DW_CFA_expression %xmm15 7b4a82e9-7b4a82ec
1460.262:00c4:00fc:trace:seh:execute_cfa_instructions 7b4399d9: DW_CFA_advance_loc2 553
1460.262:00c4:00fc:trace:seh:dwarf_virtual_unwind next function rip=0000000140329405
1460.262:00c4:00fc:trace:seh:dwarf_virtual_unwind   rax=00007fffffccc000 rbx=00000000150ad620 rcx=00000000083462b0 rdx=000000007b475c96
1460.262:00c4:00fc:trace:seh:dwarf_virtual_unwind   rsi=0000000000000001 rdi=00000000fffffffd rbp=0000000008347a80 rsp=0000000008347980
1460.262:00c4:00fc:trace:seh:dwarf_virtual_unwind    r8=0000000008347530  r9=000000007b475cd0 r10=000000007bd1d388 r11=0000000000000000
1460.262:00c4:00fc:trace:seh:dwarf_virtual_unwind   r12=0000000000000001 r13=0000000000000000 r14=000000014266ac50 r15=000000000834fbc8
1460.262:00c4:00fc:trace:seh:RtlRestoreContext returning to 7b475c96 stack 83475f0
1477.637:00b8:00bc:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\api-ms-win-appmodel-runtime-l1-1-2.dll" at 0x6c100000: PE builtin
1477.637:00b8:00bc:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFFFFFFFFFA, 000000000091FA90
1478.689:0058:0068:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\drivers\\winehid.sys" : builtin
1478.689:0058:0068:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\hidclass.sys" : builtin
1478.690:0058:0068:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\drivers\\winebus.sys" : builtin
pid 14108 != 14107, skipping destruction (fork without exec?)

EDIT: Trimmed log file output to avoid unnecessary cluttering.

...
--------------SAVEGAME----------- time: 2219839
2355.307:00c4:00d4:warn:debugstr:OutputDebugStringA "Game saved.\n"
2355.307:00c4:00d4:trace:seh:raise_exception code=40010006 flags=0 addr=0x7b00fc3e ip=7b00fc3e tid=00d4
2355.307:00c4:00d4:trace:seh:raise_exception  info[0]=000000000000000d
2355.307:00c4:00d4:trace:seh:raise_exception  info[1]=00000000032a4140
2355.307:00c4:00d4:trace:seh:raise_exception  rax=00000000032a3b60 rbx=00007fffffd6c000 rcx=00000000032a3b40 rdx=0000000000000000
2355.307:00c4:00d4:trace:seh:raise_exception  rsi=00000000032a3c40 rdi=00000000032a3b70 rbp=00000000032a3f80 rsp=00000000032a3b20
2355.307:00c4:00d4:trace:seh:raise_exception   r8=0000000000000002  r9=00000000032a3c30 r10=000000007b47b4e6 r11=0000000000000000
2355.307:00c4:00d4:trace:seh:raise_exception  r12=0000000000000001 r13=0000000000000001 r14=00000001429ff1f8 r15=00000000032ac1d8
2355.307:00c4:00d4:trace:seh:call_vectored_handlers calling handler at 0x69060a20 code=40010006 flags=0
2355.307:00c4:00d4:trace:seh:call_vectored_handlers handler at 0x69060a20 returned 0
2355.307:00c4:00d4:trace:seh:call_vectored_handlers calling handler at 0x140952400 code=40010006 flags=0
2355.307:00c4:00d4:trace:seh:call_vectored_handlers handler at 0x140952400 returned 0
2355.307:00c4:00d4:trace:seh:RtlVirtualUnwind type 1 rip 7b00fc3e rsp 32a3b20
...
...
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7bcdb2bb: DW_CFA_expression %xmm12 7bec89a8-7bec89ab
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7bcdb2bb: DW_CFA_advance_loc 5
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7bcdb2c0: DW_CFA_expression %xmm13 7bec89af-7bec89b2
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7bcdb2c0: DW_CFA_advance_loc 5
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7bcdb2c5: DW_CFA_expression %xmm14 7bec89b6-7bec89b8
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7bcdb2c5: DW_CFA_advance_loc 5
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7bcdb2ca: DW_CFA_expression %xmm15 7bec89bc-7bec89be
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7bcdb2ca: DW_CFA_advance_loc1 116
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind next function rip=000000007bcd45f9
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind   rax=00007fffffc9c000 rbx=00007fffffc9c000 rcx=0000000009b762b0 rdx=000000007b475c96
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind   rsi=0000000009b77630 rdi=0000000009b77560 rbp=0000000009b77970 rsp=0000000009b77010
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind    r8=0000000009b77530  r9=000000007b475cd0 r10=000000007bd1d388 r11=0000000000000000
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind   r12=0000000000000001 r13=0000000000000000 r14=000000014266ac50 r15=0000000009b7fbc8
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind function 7bcd45f9 base 0x7bcd45a4 cie 0x7bea6ce0 len 14 id 0 version 1 aug 'zR' code_align 1 data_align -8 retaddr %rip
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7bcd45a4: DW_CFA_def_cfa %rsp, 8
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7bcd45a4: DW_CFA_offset %rip, -8
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind fde 0x7bec7c90 len 14 personality (nil) lsda (nil) code 7bcd45a4-7bcd4601
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7bcd45a4: DW_CFA_advance_loc 7
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7bcd45ab: DW_CFA_def_cfa_offset 1280
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind next function rip=000000007b00fc3e
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind   rax=00007fffffc9c000 rbx=00007fffffc9c000 rcx=0000000009b762b0 rdx=000000007b475c96
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind   rsi=0000000009b77630 rdi=0000000009b77560 rbp=0000000009b77970 rsp=0000000009b77510
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind    r8=0000000009b77530  r9=000000007b475cd0 r10=000000007bd1d388 r11=0000000000000000
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind   r12=0000000000000001 r13=0000000000000000 r14=000000014266ac50 r15=0000000009b7fbc8
2360.129:00c4:0108:trace:seh:RtlVirtualUnwind type 2 rip 7b00fc3e rsp 9b77510
2360.129:00c4:0108:trace:seh:dump_unwind_info **** func fbf0-fc77
2360.129:00c4:0108:trace:seh:dump_unwind_info unwind info at 0x7b09a340 flags 0 prolog 0x11 bytes function 0x7b00fbf0-0x7b00fc77
2360.129:00c4:0108:trace:seh:dump_unwind_info     0x11: subq $0xc8,%rsp
2360.129:00c4:0108:trace:seh:dump_unwind_info     0xa: pushq %rsi
2360.129:00c4:0108:trace:seh:dump_unwind_info     0x9: pushq %rdi
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind function 7b439bb1 base 0x7b439968 cie 0x7b496a90 len 14 id 0 version 1 aug 'zR' code_align 1 data_align -8 retaddr %rip
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b439968: DW_CFA_def_cfa %rsp, 8
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b439968: DW_CFA_offset %rip, -8
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind fde 0x7b4a8280 len 8c personality (nil) lsda (nil) code 7b439968-7b439e60
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b439968: DW_CFA_advance_loc 1
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b439969: DW_CFA_def_cfa_offset 16
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b439969: DW_CFA_offset %rbp, -16
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b439969: DW_CFA_advance_loc 10
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b439973: DW_CFA_def_cfa_register %rbp
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b439973: DW_CFA_advance_loc 39
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_expression %xmm6 7b4a829c-7b4a829f
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %r15, -24
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %r14, -32
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %r13, -40
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %r12, -48
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %rdi, -56
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %rsi, -64
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %rbx, -72
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_advance_loc 11
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399a5: DW_CFA_expression %xmm7 7b4a82b1-7b4a82b4
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399a5: DW_CFA_advance_loc 8
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399ad: DW_CFA_expression %xmm8 7b4a82b8-7b4a82bb
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399ad: DW_CFA_advance_loc 8
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399b5: DW_CFA_expression %xmm9 7b4a82bf-7b4a82c2
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399b5: DW_CFA_advance_loc 8
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399bd: DW_CFA_expression %xmm10 7b4a82c6-7b4a82c9
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399bd: DW_CFA_advance_loc 8
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399c5: DW_CFA_expression %xmm11 7b4a82cd-7b4a82d0
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399c5: DW_CFA_advance_loc 5
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399ca: DW_CFA_expression %xmm12 7b4a82d4-7b4a82d7
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399ca: DW_CFA_advance_loc 5
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399cf: DW_CFA_expression %xmm13 7b4a82db-7b4a82de
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399cf: DW_CFA_advance_loc 5
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399d4: DW_CFA_expression %xmm14 7b4a82e2-7b4a82e5
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399d4: DW_CFA_advance_loc 5
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399d9: DW_CFA_expression %xmm15 7b4a82e9-7b4a82ec
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399d9: DW_CFA_advance_loc2 553
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind next function rip=0000000140329405
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind   rax=00007fffffc9c000 rbx=00000000150ad400 rcx=0000000009b762b0 rdx=000000007b475c96
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind   rsi=0000000000000001 rdi=00000000fffffffd rbp=0000000009b77a80 rsp=0000000009b77980
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind    r8=0000000009b77530  r9=000000007b475cd0 r10=000000007bd1d388 r11=0000000000000000
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind   r12=0000000000000001 r13=0000000000000000 r14=000000014266ac50 r15=0000000009b7fbc8
2360.129:00c4:0108:trace:seh:RtlRestoreContext returning to 7b475c96 stack 9b775f0
Flushing device resizeSwapChain: true, resizeViewDest: false, resizeImageNeedsFlush: false
2371.848:00b8:00bc:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\api-ms-win-appmodel-runtime-l1-1-2.dll" at 0x6c100000: PE builtin
2371.848:00b8:00bc:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFFFFFFFFFA, 000000000091FA90
2372.862:0058:0068:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\drivers\\winehid.sys" : builtin
2372.862:0058:0068:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\hidclass.sys" : builtin
2372.862:0058:0068:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\drivers\\winebus.sys" : builtin
pid 20758 != 20757, skipping destruction (fork without exec?)

I'm not completely sure which of the lines could've caused the freeze (since none of the debug lines in the last ms seem to show any kind of fatal graphics error), however I do note that the RtlRestoreContext and loaddll traces seem to be the most common lines to occur prior to the process termination (which I initiated manually). Additionally, this line Flushing device resizeSwapChain: true, resizeViewDest: false, resizeImageNeedsFlush: false seem to appear quite often. I'm not so familiar with this, however, may I assume that the RtlRestoreContext and loaddll lines were indicating the game engine's attempts to load in the necessary dll packages to restore context of game scene, with the 'Flushing device' line containing the flags of actions required to be performed by the 'device' (which I'm assuming is the GPU or other resources used to render the current game scene?)

Thanks in advance for any additional help/explanations!

EDIT: Created gists containing more detailed outputs from the log files, as per recommendation of @kisak-valve . Unfortunately only gists containing the detailed output for the first (9.13 pm) and latest (I did further testing as noted in the next comment) test logs (11.18pm). However, further testing could be done and added as another gist if required.

Oh apologies for that @kisak-valve! I didn't realize that the formatting of the code could be done in such a way as well.

I've provided the gists containing more detailed outputs for the first and latest instance of crashes. Unfortunately the 1MB size limit of the Gists prevented me from uploading the whole log files as well, so I just put in the log outputs right after the game has saved in the latest Checkpoint (marked by END SAVEGAME it seems).

Thanks in advance!

@NickSadjoli Check dmesg after the freeze. I've experienced similar issues that seem to be a result of issues with the AMD kernel drivers.

@jjbarr he's using the proprietary Nvidia drivers, he's not using kernel graphics drivers.

@NickSadjoli you definitely need to remove one of those packages you installed. Those are for AMD and Intel GPUs. You have an Nvidia GPU. You don't use Mesa vulkan drivers, you use the Nvidia drivers. I don't know if that's causing your problem, but it isn't helping. Remove the mesa-vulkan-drivers package. You actually do need libvulkan1 though. Not for Doom Eternal I don't believe, but definitely for any non-steam game you ever end up wanting to play that uses Vulkan or DX. Again, mesa-vulkan-drivers probably isn't causing your issue, but it's not helping either.

Also, just to make sure you have everything you need I'd install libvulkan1:i386 as well. Doom Eternal is all 64-bit, I believe, but still. Other things aren't.

After this, find a KNOWN GOOD proton configuration (whichever version of Proton you were using when it worked fine), switch to it in the game's properties on Steam, and then delete the games pfx. It'll be rm -r ~/path/to/library/steamapps/compatdata/782330/pfx.

@gardotd426 Noted. Unfortunately it seems that I cannot really un-install the mesa-vulkan-drivers directly right now since the pop-desktop environment used by PopOS seems to rely on this package. I do still recall apt-get mentioning that installing the libvulkan and mesa-vulkan-drivers did install new packages however, so what might have happened is that by default some of the sub-packages required for mesa-vulkan-drivers were already included in PopOS by default, but then additional, more optional pacakges, were installed when I asked for subsequent apt-get as well.

Also, with regards on reverting to the previously used version of Proton: I'm currently using Proton v5.0.9. The last Proton with a stable performance (pre-Update 1 and Update 1.1) that I recalled were either v5.0.7, or v5.0.8. Unfortunately it seems that Steam would automatically update the Proton 5.0 to include the latest version of Proton, and discarded the previously used ones in this case. Does the Proton Github keep a log of all previously used version of Proton that I could download and use (similar to the GE version)?

That said, I've tried further testing with the game today. For these tests, I also recorded my syslog to see what could've happened outside of the Proton/game interaction as well. I'll be providing the gists for both Proton and syslog outputs for each of these test sessions as follows:

1. First session, recorded at 11.24 - 11.27 a.m. [syslog_gist ]
   Unfortunately no Proton logs were recorded for this session (forgot to turn the flag on)

• Game state results: Froze after a few minutes of gameplay. Noticeably right around a Checkpoint save.
• Flags used: set 1 to all recommended non-proton related flags. no Proton flags were used
• Game Video settings: Disabled 'Present from Compute' options, which specifically stated to be turned off if having problems with external overlay softwares (which was suggested previously by @albertz)

1. Second session, recorded at 11.30 - 11.32 a.m. [syslog_gist]
   Unfortunately no Proton logs were recorded for this session (forgot to turn the flag on)

• Game state results: Froze after around < 1 minutes of gameplay. Noticeably right after changing theh 'Present from Compute' settings
• Flags used: set 1 to all recommended non-proton related flags. no Proton flags were used
• Game Video settings: Tried to enable 'Present from Compute' options. This time around the game froze a lot faster after enabling this option, with the freeze screen noticeably showing the 'Main Menu settings' screen, right when option was enabled.

1. Third session, recorded at 11.32 a.m. - 11.37 a.m [syslog_gist] [Proton_log_gist]

• Game state results: Froze after a few minutes of gameplay. Noticeably right around a Checkpoint save.
• Flags used: set 1 to all recommended non-proton related flags. Only PROTON_LOG was enabled
• Game Video settings: Kept same settings from previous session ('Present from Compute' Enabled, no other changes)

1. Last session, recorded at 11.42 - 11.46 a.m [syslog_gist] [Proton_log_gist]

• Game state results: Froze after a noticeably longer than last previous sessions of gameplay. Noticeably right around a Checkpoint save as well.
• Flags used: set 1 to all recommended non-proton related flags. Only PROTON_LOG was enabled
• Game Video settings: Kept same settings from previous session ('Present from Compute' Enabled, no other changes)

From all these log files there are a few things that I'd like to note and highlight:

• The line 'Window manager warning: Window 0xa000001 sets an MWM hint indicating it isn't resizable, but sets min size 1 x 1 and max size 2147483647 x 2147483647; this doesn't make much sense.' seems to constantly occur around the time the game froze. Is this an indication that it's a GNOME overlay issue with the game?
• The Proton log from the third session gave an interesting new type of trace error, namely '7370.996:0094:009c:err:clipboard:convert_selection Timed out waiting for SelectionNotify event'. Does this mean that the game was waiting for some sort of event, but then timed-out and causing an error (game freeze)?

Another thing to note is that I am running several background tasks when running the game (though these are mainly open Firefox tabs in the background). I believe these shouldn't really cause any kind of issue with the Game Freeze, however just a note for those who might be able to point out a possible conflict.

To ensure that the engine itself wasn't having an issue with my machine, I then tried to play Doom 2016 for a bit (which uses the previous version of the IdTech engine: IdTech 6), to see whether the current Proton version has caused any kind of problems with this title as well.

Interestingly enough, there were notably two extremely short (around 1 to 2 ms) 'screen blackout' occurences that happened during the Doom 2016 run (which for a splitsecond I thought would cause the freeze similar to Doom Eternal), however the game was able to recover from it and resume the entire gameplay smoothly. Here are the syslog and Proton Log files for the Doom 2016 testing, with a note that the 'blackout'-s seem to occur at around the similar line of 'Window manager MWM hint' warning (for the syslog file), or - in the case of the Proton Log - the 'Setting breakpad minidump' messages. Unfortunately since the Proton Log message seems to differ quite a lot from the Doom Eternal's Proton Log messages, this might not be very helpful, but nonetheless some extra information I was able to observe.

If anyone requires more testing or more information please do let me know and I'll see whether I could provide them as well.

EDIT: Unfinished comment
EDIT2: Formatting

I receiving "Unable to find any avaiable BATTLEMODE matches. Please try again later" and "Launch server failed" messages. On Win 10 everything works fine. Can anyone confirm this issue?

I wouldn't be surprised if they implemented some sort of anticheat that blocks Linux with the latest update (they always said they were bringing anticheat back but just wouldn't block the campaign for it). Obviously there probably aren't any matches going on right now because of the time in the Americas and Europe, but tomorrow (later today, technically) I'll try and see if I can reproduce the issue.

BTW @gardotd426

After this, find a KNOWN GOOD proton configuration (whichever version of Proton you were using when it worked fine).

Regarding your suggestion for this, may I know whether a pre-built version of Proton 5.0.7 or 5.0.8 is available? I understand that I could build a working version of these proton packages locally via Proton's build-guide, however I'd like to know if an already working and pre-compiled version of these could already be downloaded and put into the compatibilitytools.d/ directory for a much faster setup.

Thanks in advance!

@NickSadjoli you might also try to reset the pinned libs.
remove the pinned_libs* folders. they should be in a path like this: ~/.steam/steam/ubuntu12_32/steam-runtime
At next steam start, it'll re-add them.
I haven't tried it, but I think running steam --reset will do that too.

Hi everyone, apologies that this is quite late, however I have seem to have somehow resolved the issue on my end (for now), and managed to get Doom Eternal running smoothly from the second half of 2nd level all the way to currently 6th level without crashing once. There were some noticeable graphical glitches, but I believe that is something has sometimes happened previously as well, which I attribute more to that Proton drivers hasn't been fully optimized for some games yet (perhaps, but that isn't really bugging me too much, since it happens so rare)

TL;DR: the GNOME Extension Backslide seem to have caused some conflict with Doom Eternal. I'm not completely sure why this is happening, however there have been previous instances of GNOME having issues with games running already documented/discussed. So this could be a potential issue for other Proton users as well.

I initially tried @AllKind's suggestion to reset Steam last night. It initially seemed to have worked as I was able to get through a significant portion of the 2nd level without crashing, only to it to unfortunately crash during the transition area between the 2nd and 3rd level though. Another crash occurred when I tried running the game after that, so I think it only alleviated the issue for some time.

This morning I then looked up the syslog errors which I posted again, and noticed that the GNOME desktop apparently had previously been known to cause issues with some games before. With this, I then thought that perhaps some of the GNOME extensions on my PC that modified display-related behavior could've caused a similar conflict with the game's window when it's running.

From all extensions that were active, Backslide and Window Animations are the only extensions which stood out to me to be display-modifying extensions, so I turned off those and ran Doom Eternal again with these off.

Amazingly, the game then run smooth ever since, with only instances of crashing being when I got an incoming Steam message (which seems to relate back to the 'Alt+Tab' or 'Ctrl+Tab' issues that has been reported previously). I then managed to go through the entire 3rd level of the game this morning without any freeze or crashes in this setting, something that wasn't even possible just yesterday.

The question for me then became which extension of the 2 (Window Animation or Backslide) could've specifically caused the issue. To determine this, I then tried turning on Backslide, and ran the game again with it on.

Turned out the game froze just a few minutes after it ran with this configuration, which made me more ensured that Backslide is indeed the problem. I then turned it off, and after that managed to play the game all the way to Level 6 without any more freezes recorded.

Seeing this and the GNOME conflict thread that I linked here, has there been any other potential GNOME and Proton conflicts occurring for other games? Also, has any kind of debugging previously done on Proton to check any potential conflicts with any GNOME specific extensions (especially the ones that alter Desktop's views?). If there turns out to be multiple instances of Proton and GNOME extension conflict, a look into this would be appreciated.

For now, based on my experience I highly suggest turning off any display-modifying GNOME extension with the current state (i.e. post Update 1.1) of Doom Eternal, in the case that similar issues pop-up for anyone else I guess. If others have somehow solved similar issues with a similar kind of solution (turning off some GNOME extension), please do confirm and share it here.

EDIT: Accidentally posted before finishing comment.

I'm glad you got it fixed, but unfortunately even if it were looked into,
and discovered that a huge amount of GNOME extensions cause issues with
Proton, like you're asking about, there's nothing anyone could do. Valve
and Proton have no bearing or ability to fix that whatsoever (on the
whole). And GNOME itself doesn't even create extensions or sanction them at
all, really. They're all "unsupported." So there's nothing really that can
be done, outside of make people aware of it.

On Thu, Jun 18, 2020 at 10:49 AM NickSadjoli [email protected]
wrote:

Hi everyone, apologies that this is quite late, however I have seem to
have somehow resolved the issue on my end (for now), and managed to get
Doom Eternal running smoothly from the second half of 2nd level all the way
to currently 6th level without crashing once. There were some noticeable
graphical glitches, but I believe that is something has sometimes happened
previously as well, which I attribute more to that Proton drivers hasn't
been fully optimized for some games yet (perhaps, but that isn't really
bugging me too much, since it happens so rare)

TL;DR: the GNOME Extension Backslide seem to have caused some conflict
with Doom Eternal. I'm not completely sure why this is happening, however
there have been previous instances of GNOME having issues with games
running already documented/discussed. So this could be a potential issue
for other Proton users as well.

I initially tried @AllKind https://github.com/AllKind's suggestion to
reset Steam last night. It initially seemed to have worked as I was able to
get through a significant portion of the 2nd level without crashing, only
to it to unfortunately crash during the transition area between the 2nd and
3rd level though. Another crash occurred when I tried running the game
after that, so I think it only alleviated the issue for some time.

This morning I then looked up the syslog errors which I posted again, and
noticed that the GNOME desktop apparently had previously been known to
cause issues with some games
https://gitlab.gnome.org/GNOME/mutter/-/issues/361 before. With this, I
then thought that perhaps some of the GNOME extensions on my PC that
modified display-related behavior could've caused a similar conflict with
the game's window when it's running.

From all extensions that were active, Backslide and Window Animations are
the only extensions which stood out to me to be display-modifying
extensions, so I turned off those and ran Doom Eternal again with these off.

Amazingly, the game then run smooth ever since, with only instances of
crashing being when I got an incoming Steam message (which seems to relate
back to the 'Alt+Tab' or 'Ctrl+Tab' issues that has been reported
previously). I then managed to go through the entire 3rd level of the game
this morning without any freeze or crashes in this setting, something that
wasn't even possible just yesterday.

The question for me then became which extension of the 2 (Window Animation
or Backslide) could've specifically caused the issue. To determine this, I
then tried turning on Backslide, and ran the game again with it on.

Turned out the game froze just a few minutes after it ran with this
configuration, which made me more ensured that Backslide is indeed the
problem. I then turned it off, and after that managed to play the game all
the way to Level 6 without any more freezes recorded.

Seeing this and the GNOME conflict thread that I linked here, has there
been any other potential GNOME and Proton conflicts occurring for other
games? Also, has any kind of debugging previously done on Proton to check
any potential conflicts with any GNOME specific extensions (especially the
ones that alter Desktop's views?). If there turns out to be multiple
instances of Proton and GNOME extension conflict, a look into this would be
appreciated, and

t using some additional GNOME extensions which I suspected might have
caused some conflict with the game's windows (based on the Windows
management error that I got from syslog), and tried to turn off the
extensions that was tweaking the display/appearance of the desktop - namely
turning off Animations and the Backslide extension. Turning off Backslide
specifically seemed to have worked for me, as when I tried running Doom
Eternal again this morning with Backslide turned on caused the Freeze to
happen again.

So the details of how I managed to do it was as follows:
Yesterday night I tried out @AllKind https://github.com/AllKind's
suggestion to reset Steam. To my surprise, this seemed to have worked
initially as the game didn't crash for a significant amount of time, only
to then crash just as I was about to transition into the 3rd level (iirc).
Unfortunately this crash me

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-646068897,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y33ZKKR2JEZYALJZQSADRXISQPANCNFSM4MI6DHIA
.

@gardotd426 is there a way proton could behave well with overlays? I encounter these issues even without gnome (I use enlightenment on gentoo with openrc instead of systemd), so I don't think the problem can be isolated there

What do you mean by "overlays." That word has numerous definitions when it
comes to computing/gaming/etc.

On Fri, Jun 19, 2020 at 1:00 AM oogetyboogety [email protected]
wrote:

@gardotd426 https://github.com/gardotd426 is there a way proton could
behave well with overlays? I encounter these issues even without gnome (I
use enlightenment on gentoo with openrc instead of systemd), so I don't
think the problem can be isolated there

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-646435630,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y3346RUIEP3W2QM6QPW3RXLWGHANCNFSM4MI6DHIA
.

Referring back to this part of the previous post, where the issue appears to be correlated with some functionality where applications try to interrupt the game and the game crashes.

Amazingly, the game then run smooth ever since, with only instances of crashing being when I got an incoming Steam message (which seems to relate back to the 'Alt+Tab' or 'Ctrl+Tab' issues that has been reported previously). I then managed to go through the entire 3rd level of the game this morning without any freeze or crashes in this setting, something that wasn't even possible just yesterday.

Maybe i could dig further into what the root cause is in X or try it in Wayland. I havent looked into using proton with wayland but i thought i disabled "overlays" in terms of the one Proton shows related to the post above. Using wayland might force a different notification mechanism or something mitigating the root cause of this issue which would allow me to play continuously without crashes.

The notification popup you get from Steam while playing steam games is from
Steam itself. It's the Steam overlay. Some games have issues with it, but
not many. Using Wayland is unlikely to change anything, Steam will still be
using the same Steam overlay and even then I'm pretty sure Steam would be
running in XWayland. You could just try disabling the Steam overlay for any
games that seem to have trouble with it.

On Fri, Jun 19, 2020 at 1:08 AM oogetyboogety [email protected]
wrote:

Referring back to this part of the previous poat, where the issue appears
to be correlated with some functionality where applications try to
interrupt the game and the game crashes.

Amazingly, the game then run smooth ever since, with only instances of crashing being when I got an incoming Steam message (which seems to relate back to the 'Alt+Tab' or 'Ctrl+Tab' issues that has been reported previously). I then managed to go through the entire 3rd level of the game this morning without any freeze or crashes in this setting, something that wasn't even possible just yesterday.

Maybe i could dig further into what the root cause is in X or try it in
Wayland. I havent looked into using proton with wayland but i thought i
disabled "overlays" in terms of the one Proton shows related to the post
above, but using wayland might force a different notification mechanism orm
something mitigating the root cause of this issue which would allow me to
play continuously without crashes.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-646437725,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y334BPA7PDJVTDHLXON3RXLXF7ANCNFSM4MI6DHIA
.

OK I disabled it but am still getting the same error. I'll try to collect some logs and see if I notice a trend.

EDIT:
Appears to work again for a while. No crashes yet

They're all "unsupported." So there's nothing really that can be done, outside of make people aware of it.

@gardotd426 Darn, that's quite unfortunate then. Glad I performed the tests and helped highlighted this issue then. Hopefully this helps people at least, and hope that this issue could be one of the focus over at the GNOME development team to work on with Valve/Proton.

EDIT: Formatting

Hello @PopeRigby, are you still experiencing the hard crash you described in [#3773 (comment)](https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-614309204)? Additionally, while testing please use oibaf PPA or kisak-mesa PPA and RADV/ACO and let us know if you can reproduce the crash with that.

I no longer have Doom Eternal installed, but I'll report back when I re-install it. Probably when the first DLC comes out.

It is still pretty annoying that the game does not respond anymore once there will be some notification popup by some other app (maybe Steam itself), or when you accidently hit Alt+Tab or so.

Is this a problem which can be fixed in Wine? I guess this does not happen on Windows, right? It would be nice if this could be fixed. Otherwise it runs very well for me now (with Nvidia 2070). It seems to be even more smooth since Update 2.

@albertz In the game's graphics settings, are you using "fullscreen"? Try changing to the borderless windowed setting.

Game install is OK, but when i start, i can reach the menu, but screen is blinking like hell.

I've had that multiple times. I think when changing Proton versions and when installing a new video driver.
Had to reset video defaults (by keyboard shortcuts) and restart the game.

Hello @albertz, possibly related: "Fixed a visual glitch of Vulkan applications when they stop flipping due to a window change, such as when alt-tab is used to change window focus." in nVidia 450.51.

I have that one installed now, but Alt+Tab is still not working.

Also I've lost my saved games again, after switching from Proton-GE to native 5.0.9. And after Doom Eternal update 2.
Because of that I don't play it on linux any more. Lost my games too many times.

gist

I am also experiencing the same bug as @albertz, but in my case it also happens when the game shows steam progress awards. Is there a way to turn these off?

nvidia 2060S with nvidia 440.100
ubuntu 20.04 (5.4.0-39-generic)

edit: updating the drivers to 450.51 did not solve the issues mentioned above.

anyone play this with an intel gpu? i have a laptop with a uhd 620 and it won't start. first a window appears saying "not supported", then when i click play, the game supposedly loads for 10 or so minutes, but it never starts

P.S. I almost beat DOOM on this laptop, never had issues

Any updates on alt-tab? It's really annoying!

@Rush: Are you using "fullscreen" in the graphics settings of the game? Try setting the game to "borderless windowed" instead. That fixes the Alt-Tab crash problem here for me.

Been trying it with "borderless window". Still doesnt work, crashes on steam achievements aswell. Alt-Tab doesnt work. Im using nvidia-450.57.

Hello,

I've just tried the "borderless window" option on Fedora 32 with a GTX 1070 (driver 450.57). Game window still freezes as soon as Alt+Tab or Windows key is pressed on the Gnome desktop

Im getting a crash with the latest version of doom eternal and not sure whats going on:

Nvidia Driver: 450.57
CPU: AMD 3970x
Ubuntu: 20.04
Kernel: 5.4.0-40-generic
Proton: 5.0-9

Launch Options:
PROTON_LOG=1 %command% +com_skipIntroVideo 1

10121.137:00d0:00d4:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\api-ms-win-core-synch-l1-2-0.dll" at 0x6e340000: PE builtin
10121.138:00d0:00d4:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\api-ms-win-core-fibers-l1-1-1.dll" at 0x6b880000: PE builtin
10121.142:00d0:00d4:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\api-ms-win-core-localization-l1-2-1.dll" at 0x6e6c0000: PE builtin
10121.145:00d0:00d4:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\setupapi.dll" at 0x6a700000: PE builtin
10121.145:00d0:00d4:trace:loaddll:load_so_dll Loaded L"C:\\windows\\system32\\winex11.drv" at 0x7f35416f0000: builtin
10121.177:00d0:00d4:fixme:font:get_outline_text_metrics failed to read full_nameW for font L"Ani"!
10121.192:00d0:00d4:fixme:heap:RtlSetHeapInformation 0x10000 0 0x91c860 4 stub
10121.194:00d0:00d4:warn:debugstr:OutputDebugStringA "Winsock Initialized\n"
10121.194:00d0:00d4:trace:seh:raise_exception code=40010006 flags=0 addr=0x7b00fc3e ip=7b00fc3e tid=00d4
10121.194:00d0:00d4:trace:seh:raise_exception  info[0]=0000000000000015
10121.194:00d0:00d4:trace:seh:raise_exception  info[1]=0000000000914770
10121.194:00d0:00d4:trace:seh:raise_exception  rax=0000000000914190 rbx=00007fffffd9c000 rcx=0000000000914170 rdx=0000000000000000
10121.194:00d0:00d4:trace:seh:raise_exception  rsi=0000000000914270 rdi=00000000009141a0 rbp=00000000009145b0 rsp=0000000000914150
10121.194:00d0:00d4:trace:seh:raise_exception   r8=0000000000000002  r9=0000000000914260 r10=000000007b47b4e6 r11=0000000000000246
10121.194:00d0:00d4:trace:seh:raise_exception  r12=0000000000000001 r13=0000000000000001 r14=0000000140994838 r15=000000000091c808
10121.195:00d0:00d4:trace:seh:RtlVirtualUnwind type 1 rip 7b00fc3e rsp 914150
10121.195:00d0:00d4:trace:seh:dump_unwind_info **** func fbf0-fc77
10121.195:00d0:00d4:trace:seh:dump_unwind_info unwind info at 0x7b09a340 flags 0 prolog 0x11 bytes function 0x7b00fbf0-0x7b00fc77
10121.195:00d0:00d4:trace:seh:dump_unwind_info     0x11: subq $0xc8,%rsp
10121.195:00d0:00d4:trace:seh:dump_unwind_info     0xa: pushq %rsi
10121.195:00d0:00d4:trace:seh:dump_unwind_info     0x9: pushq %rdi
10121.195:00d0:00d4:trace:seh:dwarf_virtual_unwind function 7b439bb1 base 0x7b439968 cie 0x7b496a90 len 14 id 0 version 1 aug 'zR' code_align 1 data_align -8 retaddr %rip

10140.669:00dc:00e0:trace:seh:call_teb_handler handler at 0x7b475d00 returned 1
10140.669:00dc:00e0:warn:seh:virtual_unwind exception data not found in L"DOOMEternalx64vk.exe"
Unhandled exception: page fault on read access to 0x00000060 in 64-bit code (0x00007fd7eb4b08e3).
10140.675:0204:0208:fixme:dbghelp:elf_search_auxv can't find symbol in module
Register dump:
 rip:00007fd7eb4b08e3 rsp:00000000008d05f0 rbp:000000007f16d3c0 eflags:00010206 (  R- --  I   - -P- )
 rax:3fffffffffffffff rbx:000000007f16dd90 rcx:0000000000000009 rdx:0000000000000000
 rsi:0000000000000001 rdi:00000000008d0390  r8:0000000000000010  r9:00000000008d03a8 r10:00000000008d03a4
 r11:0000000000000001 r12:0000000000000000 r13:00000000008d0890 r14:0000000000000000 r15:0000000000000000
Stack dump:
0x00000000008d05f0:  0000000000000001 5c5c5c5c00000091
0x00000000008d0600:  000000007f16d448 8686868600000000
0x00000000008d0610:  9292929200000000 9696969600000000
0x00000000008d0620:  000000007f16d448 000000007ffffffa
0x00000000008d0630:  02b0b0b000000001 ffffffff00000001
0x00000000008d0640:  000000007dc58380 0000000000000000
0x00000000008d0650:  0000000200000002 00000367fffffc98
0x00000000008d0660:  000000007f16d301 00007fd7fab3e780
0x00000000008d0670:  0000000000000400 0000000000001000
0x00000000008d0680:  000000007fa4fb40 0000000000000000
0x00000000008d0690:  00000000000000a0 00007fd7fb391b80
0x00000000008d06a0:  000000007dc4e170 00000000008d0890
Backtrace:
=>0 0x00007fd7eb4b08e3 _nv018glcore+0xffffffffffffffff() in libnvidia-glcore.so.450.57 (0x000000007f16d3c0)
0x00007fd7eb4b08e3 _nv018glcore+0xffffffffffffffff in libnvidia-glcore.so.450.57: andq	0x0000000000000060(%rdx),%rax

Has anyone run into this ?

Been trying it with "borderless window". Still doesnt work, crashes on steam achievements aswell. Alt-Tab doesnt work. Im using nvidia-450.57.

After some more testing I have found out, alt tab seems to work on lower resolution but as soon I change it to native on borderless window it seems to freeze/black screen the game. I dunno if that helps.

nvidia 450.57-6 GTX 1060 6GB
kernel 5.7.12-arch1-1

Game is freezing whenever there is a Steam overlay popup. Now, I don't understand why because I disabled Steam overlay, yet it still shows something like achievement and freezes the game. Afterwards, game won't start anymore (black screen) and I have to reboot the PC in order to be able to play again. Also Alt+Tabbing freezes it to black screen as well, but that can be workarounded by not Alt+Tabbing.
Side-note: I play in offline mode.
EDIT: restarting X allows me to play again. Still annoying, but less so.

nvidia 450.57-6 GTX 1060 6GB
kernel 5.7.12-arch1-1

Game is freezing whenever there is a Steam overlay popup. Now, I don't understand why because I disabled Steam overlay, yet it still shows something like achievement and freezes the game. Afterwards, game won't start anymore (black screen) and I have to reboot the PC in order to be able to play again. Also Alt+Tabbing freezes it to black screen as well, but that can be workarounded by not Alt+Tabbing.
Side-note: I play in offline mode.
EDIT: restarting X allows me to play again. Still annoying, but less so.

Same here, nvidia 450.57-5 / GTX1070, linux 5.7.11.arch1-1

Steam overlay cannot be disabled on Linux (which would solve the problem):
https://github.com/ValveSoftware/steam-for-linux/issues/3239

However, I don't need to restart X. $ kill $(pgrep DOOM) is enough and I can simply restart the game from steam.

You guys need to definitely bring this to Nvidia's attention. Despite their reputation, they actually do seem to do a decent job with fixing stuff like that with an update.

Because it definitely seems like this is an Nvidia-specific issue, I have an AMD GPU and I don't see this at all. I do use a custom version of Proton with fshack re-enabled, I don't know if it's disabled on vanilla Proton or not (I know it's disabled on the recent versions of GE's Proton). Maybe that's part of it, too. But that can be solved by determining whether the proton builds you all are using contains the fshack patches or not.

But yeah, I played for about 5 hours last night and got a few achievements and they all worked exactly as they were supposed to. And unless it's a big coincidence that it seems to just affect Nvidia users (at least as of late), it sounds like a driver issue. Either that, or it is the fshack thing, or potentially a desktop environment thing.

In the ProtonDB about Rage 2, I read about very similar reports that tab/overlay freezes the game. Rage 2 is based on an older idTech engine. The solution seems to be to set AsyncComputeDisable to 1 in the settings.ini. Maybe there is something equivalent in Doom Eternal?

nvidia 450.57-6 GTX 1060 6GB
kernel 5.7.12-arch1-1

Game is freezing whenever there is a Steam overlay popup. Now, I don't understand why because I disabled Steam overlay, yet it still shows something like achievement and freezes the game. Afterwards, game won't start anymore (black screen) and I have to reboot the PC in order to be able to play again. Also Alt+Tabbing freezes it to black screen as well, but that can be workarounded by not Alt+Tabbing.
Side-note: I play in offline mode.
EDIT: restarting X allows me to play again. Still annoying, but less so.

Same here, kernel is 5.7.12-24-tkg-pds, Nvidia RTX 2060, any ideas how to fix alt+tab issue?
Game is literally unplayable, because any achievement will bring up steam overlay thus making game freeze. I am also using bordered window, but actually no diff between fullscreen and bordered window, freezing on both modes.

In the ProtonDB about Rage 2, I read about very similar reports that tab/overlay freezes the game. Rage 2 is based on an older idTech engine. The solution seems to be to set AsyncComputeDisable to 1 in the settings.ini. Maybe there is something equivalent in Doom Eternal?

There is similar option in doom, i have it disabled, so this is not the case =(

nvidia 450.57-6 GTX 1060 6GB
kernel 5.7.12-arch1-1
Game is freezing whenever there is a Steam overlay popup. Now, I don't understand why because I disabled Steam overlay, yet it still shows something like achievement and freezes the game. Afterwards, game won't start anymore (black screen) and I have to reboot the PC in order to be able to play again. Also Alt+Tabbing freezes it to black screen as well, but that can be workarounded by not Alt+Tabbing.
Side-note: I play in offline mode.
EDIT: restarting X allows me to play again. Still annoying, but less so.

Same here, kernel is 5.7.12-24-tkg-pds, Nvidia RTX 2060, any ideas how to fix alt+tab issue?
Game is literally unplayable, because any achievement will bring up steam overlay thus making game freeze. I am also using bordered window, but actually no diff between fullscreen and bordered window, freezing on both modes.

Would you be kind to attempt the workaround below to disable steam overlay notifications and see how that affects Doom Eternal, I have unfortunately almost all single player achievements and cannot check if the workaround fixes anything.

https://steamcommunity.com/discussions/forum/1/617329920710103124/

Workarounds are great (if they work) for actually getting through a game,
but this is a CLEAR case of a driver issue that needs to be reported. Has
anyone reported this to Nvidia?

Would you be kind to attempt the workaround below to disable steam overlay notifications and see how that affects Doom Eternal, I have unfortunately almost all single player achievements and cannot check if the workaround fixes anything.

https://steamcommunity.com/discussions/forum/1/617329920710103124/

As I already wrote, disabling steam overlay on Linux is not possible due to this six years old bug:
https://github.com/ValveSoftware/steam-for-linux/issues/3239

This would be the easiest solution but no...

Would you be kind to attempt the workaround below to disable steam overlay notifications and see how that affects Doom Eternal, I have unfortunately almost all single player achievements and cannot check if the workaround fixes anything.
https://steamcommunity.com/discussions/forum/1/617329920710103124/

As I already wrote, disabling steam overlay on Linux is not possible due to this six years old bug:
ValveSoftware/steam-for-linux#3239

This would be the easiest solution but no...

It is not the overlay that's the problem, it's the notifications. The workaround above should remove the notifications from displaying, at least in theory, thus making DE at least playable for nvidia users in the meantime. However, I cannot test the effect this has on DE because I have most of the achievements anyway.

Would you be kind to attempt the workaround below to disable steam overlay notifications and see how that affects Doom Eternal, I have unfortunately almost all single player achievements and cannot check if the workaround fixes anything.
https://steamcommunity.com/discussions/forum/1/617329920710103124/

As I already wrote, disabling steam overlay on Linux is not possible due to this six years old bug:
ValveSoftware/steam-for-linux#3239
This would be the easiest solution but no...

It is not the overlay that's the problem, it's the notifications. The workaround above should remove the notifications from displaying, at least in theory, thus making DE at least playable for nvidia users in the meantime. However, I cannot test the effect this has on DE because I have most of the achievements anyway.

Sorry, I didn't read through your link and thought it just explains how to disable the overlay in the menu options.

I just tried it and it really works! Thank you!

Would you be kind to attempt the workaround below to disable steam overlay notifications and see how that affects Doom Eternal, I have unfortunately almost all single player achievements and cannot check if the workaround fixes anything.
https://steamcommunity.com/discussions/forum/1/617329920710103124/

As I already wrote, disabling steam overlay on Linux is not possible due to this six years old bug:
ValveSoftware/steam-for-linux#3239
This would be the easiest solution but no...

It is not the overlay that's the problem, it's the notifications. The workaround above should remove the notifications from displaying, at least in theory, thus making DE at least playable for nvidia users in the meantime. However, I cannot test the effect this has on DE because I have most of the achievements anyway.

Sorry, I didn't read through your link and thought it just explains how to disable the overlay in the menu options.

I just tried it and it really works! Thank you!

Now please report this to Nvidia so there's actually a chance of something being done about it.

nvidia 450.57-6 GTX 1060 6GB
kernel 5.7.12-arch1-1
Game is freezing whenever there is a Steam overlay popup. Now, I don't understand why because I disabled Steam overlay, yet it still shows something like achievement and freezes the game. Afterwards, game won't start anymore (black screen) and I have to reboot the PC in order to be able to play again. Also Alt+Tabbing freezes it to black screen as well, but that can be workarounded by not Alt+Tabbing.
Side-note: I play in offline mode.
EDIT: restarting X allows me to play again. Still annoying, but less so.

Same here, kernel is 5.7.12-24-tkg-pds, Nvidia RTX 2060, any ideas how to fix alt+tab issue?
Game is literally unplayable, because any achievement will bring up steam overlay thus making game freeze. I am also using bordered window, but actually no diff between fullscreen and bordered window, freezing on both modes.

Would you be kind to attempt the workaround below to disable steam overlay notifications and see how that affects Doom Eternal, I have unfortunately almost all single player achievements and cannot check if the workaround fixes anything.

https://steamcommunity.com/discussions/forum/1/617329920710103124/

Thank you, I can confirm that this workaround worked for me.

@roman-bronis & @Sha1rath

it might be wise to leave a review in protondb for DE and mention the steam notifications workaround with the link to the guide. I've already done this in hopes that it would be useful to more Linux users with nvidia gpus.

Thanks for your patience.

@roman-bronis & @Sha1rath

it might be wise to leave a review in protondb for DE and mention the steam notifications workaround with the link to the guide. I've already done this in hopes that it would be useful to more Linux users with nvidia gpus.

Thanks for your patience.

Great idea, done!

About reporting this to NVidia, I personally am not in the position to give them a proper description of the problem. It would need detailed logs or traces rather than saying "someone said it doesn't happen on his AMD".

nvidia 450.57-6 GTX 1060 6GB
kernel 5.7.12-arch1-1
Game is freezing whenever there is a Steam overlay popup. Now, I don't understand why because I disabled Steam overlay, yet it still shows something like achievement and freezes the game. Afterwards, game won't start anymore (black screen) and I have to reboot the PC in order to be able to play again. Also Alt+Tabbing freezes it to black screen as well, but that can be workarounded by not Alt+Tabbing.
Side-note: I play in offline mode.
EDIT: restarting X allows me to play again. Still annoying, but less so.

Same here, kernel is 5.7.12-24-tkg-pds, Nvidia RTX 2060, any ideas how to fix alt+tab issue?
Game is literally unplayable, because any achievement will bring up steam overlay thus making game freeze. I am also using bordered window, but actually no diff between fullscreen and bordered window, freezing on both modes.

Would you be kind to attempt the workaround below to disable steam overlay notifications and see how that affects Doom Eternal, I have unfortunately almost all single player achievements and cannot check if the workaround fixes anything.
https://steamcommunity.com/discussions/forum/1/617329920710103124/

Thank you, I can confirm that this workaround worked for me.

U can now alt+tab out of the game? Or this just fixed the notification issue only ?

nvidia 450.57-6 GTX 1060 6GB
kernel 5.7.12-arch1-1
Game is freezing whenever there is a Steam overlay popup. Now, I don't understand why because I disabled Steam overlay, yet it still shows something like achievement and freezes the game. Afterwards, game won't start anymore (black screen) and I have to reboot the PC in order to be able to play again. Also Alt+Tabbing freezes it to black screen as well, but that can be workarounded by not Alt+Tabbing.
Side-note: I play in offline mode.
EDIT: restarting X allows me to play again. Still annoying, but less so.

Same here, kernel is 5.7.12-24-tkg-pds, Nvidia RTX 2060, any ideas how to fix alt+tab issue?
Game is literally unplayable, because any achievement will bring up steam overlay thus making game freeze. I am also using bordered window, but actually no diff between fullscreen and bordered window, freezing on both modes.

Would you be kind to attempt the workaround below to disable steam overlay notifications and see how that affects Doom Eternal, I have unfortunately almost all single player achievements and cannot check if the workaround fixes anything.
https://steamcommunity.com/discussions/forum/1/617329920710103124/

Thank you, I can confirm that this workaround worked for me.

U can now alt+tab out of the game? Or this just fixed the notification issue only ?

I just checked the notification issue, already that was fun because I had all the "easy" achievements. I don't think this is solving Alt+Tab issue but you will need to check on your own (sorry, I'm not going to install this huge game for 3rd time ;) ).

nvidia 450.57-6 GTX 1060 6GB
kernel 5.7.12-arch1-1
Game is freezing whenever there is a Steam overlay popup. Now, I don't understand why because I disabled Steam overlay, yet it still shows something like achievement and freezes the game. Afterwards, game won't start anymore (black screen) and I have to reboot the PC in order to be able to play again. Also Alt+Tabbing freezes it to black screen as well, but that can be workarounded by not Alt+Tabbing.
Side-note: I play in offline mode.
EDIT: restarting X allows me to play again. Still annoying, but less so.

Same here, kernel is 5.7.12-24-tkg-pds, Nvidia RTX 2060, any ideas how to fix alt+tab issue?
Game is literally unplayable, because any achievement will bring up steam overlay thus making game freeze. I am also using bordered window, but actually no diff between fullscreen and bordered window, freezing on both modes.

Would you be kind to attempt the workaround below to disable steam overlay notifications and see how that affects Doom Eternal, I have unfortunately almost all single player achievements and cannot check if the workaround fixes anything.
https://steamcommunity.com/discussions/forum/1/617329920710103124/

Thank you, I can confirm that this workaround worked for me.

U can now alt+tab out of the game? Or this just fixed the notification issue only ?

It only temporarily fixes the notification issue by removing all steam notifications in-game until nvidia deals with the bug in the drivers, assuming that it even is a driver bug. I managed to check this on my game yesterday and it works.

Hello there! Just got back into playing DOOM Eternal again and I'm facing some performance issues.

On a RX 5700 XT with Mesa 20.1.4 and ACO enabled on the launch settings, I get 70 - 120FPS playing on max settings with V-Sync on and Freesync activated.

With the same card, using the latest AMDGPU-PRO drivers and Freesync also activated I get consistent 144FPS when playing the game with V-Sync set to Triple Buffering (On and AUTO caps the frame rate at 72FPS outside of menus for some reason). But the PRO drivers makes blood looks like it have some kind of metallic rainbow effect.

From what I could found, the major performance issues with DOOM Eternal are already fixed on Mesa at least since 20.1.1, could the issue be somewhere else?

Don't know if it is worth mentioning, but I noticed that when using the PRO drivers, the Vulkan version reported by both DOOM and MangoHud is 1.2.139, while with Mesa 20.1.4, it reports 1.2.131 (my system have the latest available at Solus repos, version 1.2.141.0). Corectrl also reports the Vulkan API Version as being 1.2.131.

Hi, I've been having trouble with getting Doom Eternal to launch, after what feels like an age of it saying "Running", it eventually gives up and closes. I checked the log file from PROTON_LOG=1 %command%, was presently surprised when it said it was 3GB in size.

Looks like some script at startup is looping infinitely, eventually terminating with a StackOverflowException, so maybe recursion?

With some expert grepping for the term "exception", I found a repeating pattern of the following snippet in the log:

10394444:15734.269:002b:002c:trace:seh:NtRaiseException code=c0000005 flags=0 addr=0x7bc8ffc0 ip=7bc8ffc0 tid=002c
10394445:15734.269:002b:002c:trace:seh:NtRaiseException  info[0]=0000000000000000
10394446:15734.269:002b:002c:trace:seh:NtRaiseException  info[1]=ffffffffffffffff
10394447:15734.269:002b:002c:trace:seh:NtRaiseException  rax=000000007bc8ffc0 rbx=0000000000579aa0 rcx=fffffffffffc1bbc rdx=0010988c683ffff0
10394448:15734.269:002b:002c:trace:seh:NtRaiseException  rsi=0000000000000004 rdi=00000000005793d0 rbp=0000000000000005 rsp=0000000000577148
10394449:15734.269:002b:002c:trace:seh:NtRaiseException   r8=0000000000000000  r9=0000000000576d90 r10=0000000000000020 r11=0000000000000246
10394450:15734.269:002b:002c:trace:seh:NtRaiseException  r12=00000000005793d0 r13=0010988c68400010 r14=0000000000577198 r15=00000000005771a0

The number 10394444 is the line number, if you're wondering.

Running the command grep code=c0000005 steam-782330.log | wc -l gave me the number of times this loop happened, which was 290 (290 times too many).

System Info:

• Debian 10 Buster
• Nvidia Driver v450.66, RTX 2070
• Proton 5.0.9

I have played Doom Eternal successfully before on Linux, and then have not played in since a while (at least a month, probably longer). In the meantime, I think there were couple of updates of Doom, but also on my Ubuntu system, including new Nvidia drivers, etc.

Now I just wanted to play again, and it does not start. I see the id logo in systray, then screen gets black, and then I get back to the desktop, without any error.

This is with Proton 5.0, what I used before (just the standard installation, but with "PROTON_NO_ESYNC": "1" in the user_settings.py file).

I also tried with the new Proton 5.13, as I read some reports here that it runs even better now, and also the alt-tab issue is resolved. However, I get the same behavior, i.e. I see the id logo in systray, then black screen, then back to desktop.

======================
Proton: 1602709129 proton-5.13-1b
SteamGameId: 782330
Command: ['/mnt/zfs/SteamLibrary/steamapps/common/DOOMEternal/idTechLauncher.exe', '+com_skipIntroVideo', '1', '+in_terminal', '1']
Options: {'noesync', 'seccomp', 'forcelgadd'}
======================
ERROR: ld.so: object '/home/az/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/az/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
ERROR: ld.so: object '/home/az/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
ERROR: ld.so: object '/home/az/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
wineserver: using server-side synchronization.
ERROR: ld.so: object '/home/az/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
133049.882:0028:002c:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\ntdll.dll" at 000000007BC00000: builtin
133049.883:0028:002c:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\kernelbase.dll" at 000000007B000000: builtin
...
133050.864:00c4:00c8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\winex11.drv" at 00007FB7A2120000: builtin
133050.878:00c4:00c8:fixme:heap:RtlSetHeapInformation 0000000000010000 0 000000000091C710 4 stub
133050.879:00c4:00c8:warn:debugstr:OutputDebugStringA "Winsock Initialized\n"
133050.879:00c4:00c8:trace:seh:dispatch_exception code=40010006 flags=0 addr=000000007B010E0E ip=7b010e0e tid=00c8
133050.879:00c4:00c8:trace:seh:dispatch_exception  info[0]=0000000000000015
133050.879:00c4:00c8:trace:seh:dispatch_exception  info[1]=0000000000914640
133050.879:00c4:00c8:trace:seh:dispatch_exception  rax=0000000000914060 rbx=000000003fff8000 rcx=0000000000914040 rdx=0000000000000000
133050.879:00c4:00c8:trace:seh:dispatch_exception  rsi=0000000000914140 rdi=0000000000914070 rbp=0000000000914480 rsp=0000000000914020
133050.879:00c4:00c8:trace:seh:dispatch_exception   r8=0000000000000002  r9=0000000000914130 r10=000000007b666fb4 r11=0000000000000246
133050.879:00c4:00c8:trace:seh:dispatch_exception  r12=0000000000000001 r13=0000000000000001 r14=0000000000006e5c r15=000000000091c6d8
133050.879:00c4:00c8:trace:seh:call_vectored_handlers calling handler at 000000007B636150 code=40010006 flags=0
133050.879:00c4:00c8:trace:seh:call_vectored_handlers handler at 000000007B636150 returned 0
133050.879:00c4:00c8:trace:seh:RtlVirtualUnwind type 1 rip 7b010e0e rsp 914020
133050.879:00c4:00c8:trace:seh:dump_unwind_info **** func 10dc0-10e47
133050.879:00c4:00c8:trace:seh:dump_unwind_info unwind info at 000000007B0A1394 flags 0 prolog 0x11 bytes function 000000007B010DC0-000000007B010E47
133050.879:00c4:00c8:trace:seh:dump_unwind_info     0x11: subq $0xc8,%rsp
133050.879:00c4:00c8:trace:seh:dump_unwind_info     0xa: pushq %rsi
133050.879:00c4:00c8:trace:seh:dump_unwind_info     0x9: pushq %rdi
133050.879:00c4:00c8:trace:seh:dwarf_virtual_unwind function 7b638140 base 0x7b637e28 cie 0x7b67c810 len 14 id 0 version 1 aug 'zR' code_align 1 data_align -8 retaddr %rip
...
133057.159:00d0:00d4:trace:seh:RtlRestoreContext returning to 7b661c46 stack 8e88a0
resource invalid:image:models/customization/characters/doomslayer/set56/doomslayer_arm_left_set56_sss.tga$streamed$mtlkind=sssmask:NONE is stale: defaulting
133057.160:00d0:00d4:warn:debugstr:OutputDebugStringA "resource generated:image:models/customization/characters/doomslayer/set56/doomslayer_arm_right_set56_sss.tga$streamed$mtlkind=sssmask:NONE is stale: entry(s) not found\n"
133057.160:00d0:00d4:trace:seh:dispatch_exception code=40010006 flags=0 addr=000000007B010E0E ip=7b010e0e tid=00d4
133057.160:00d0:00d4:trace:seh:dispatch_exception  info[0]=00000000000000a9
...
WARNING: idBroadcastManager::ReleaseBroadcastEvent called with out of range system ID [65535]
Fossilize ERROR: Error: pNext in VkSamplerCreateInfo not supported. (pNext->sType chain: [1000130001])
Fossilize ERROR: Failed to record sampler.
Fossilize ERROR: Error: pNext in VkSamplerCreateInfo not supported. (pNext->sType chain: [1000130001])
Fossilize ERROR: Failed to record sampler.
Fossilize ERROR: Error: pNext in VkSamplerCreateInfo not supported. (pNext->sType chain: [1000130001])
Fossilize ERROR: Failed to record sampler.
Fossilize ERROR: Error: pNext in VkSamplerCreateInfo not supported. (pNext->sType chain: [1000130001])
Fossilize ERROR: Failed to record sampler.
133879.298:00d0:00d4:trace:seh:sigsys_handler SIGSYS, rax 0xf086, rip 0x14f92df98
....
133057.309:00d0:00d4:trace:seh:RtlRestoreContext returning to 7b661c46 stack 8e9780
WARNING: image:fonts/square721_ex_tl/64_df.tga$alpha$streamed$nomips:NONE can't generate in production while loading image:fonts/square721_ex_tl/64_df.tga$alpha$streamed$nomips from edit.Parms from material2:fontfx/square721/outline/normal/black
133057.310:00d0:00d4:warn:debugstr:OutputDebugStringA "resource invalid:image:fonts/square721_ex_tl/64_df.tga$alpha$streamed$nomips:NONE is stale: defaulting\n"
WARNING: generated/decls/material2/lights/analytical/point/point_p25.decl - ParmBlock Parse Warning : Invalid RenderParm Name lightfalloff while loading edit.Parms from material2:lights/analytical/point/point_p25
133881.461:00d0:01b8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\crypt32.dll" at 00007FA113A10000: builtin
133881.463:00d0:01b8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\dnsapi.dll" at 00007FA150020000: builtin
133881.463:00d0:01b8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\netapi32.dll" at 00007FA150050000: builtin
133881.463:00d0:01b8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\secur32.dll" at 00007FA150090000: builtin
133881.477:00d0:01b8:err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution.
133881.488:00d0:00d4:warn:debugstr:OutputDebugStringA "WARNING: generated/decls/material2/lights/analytical/point/point_p75.decl - ParmBlock Parse Warning : Invalid RenderParm Name lightfalloff while loading edit.perkFamilies.item.base.edit.disablePerkWhenActivated.edit.upgrades.item.edit.modifiersWeapon.item.data.valueDecl.edit.weaponFX.edit.e"...
...
133058.022:01c4:01c8:fixme:wbemprox:wbem_services_CreateInstanceEnum unsupported flags 0x00000030
133058.029:01c4:01c8:fixme:wbemprox:enum_class_object_Next timeout not supported
info:  Game: dxdiag.exe
info:  DXVK: v1.7.2-4-g280cd4b4
info:  Built-in extension providers:
info:    Win32 WSI
info:    OpenVR
133058.039:01c4:01c8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\shcore.dll" at 0000000064940000: builtin
133058.039:01c4:01c8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\shlwapi.dll" at 0000000068A40000: builtin
133058.039:01c4:01c8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\SHELL32.dll" at 00007F37BE260000: builtin
133058.039:01c4:01c8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\openvr_api_dxvk.dll" at 0000000180000000: native
133058.040:01c4:01c8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\api-ms-win-core-synch-l1-2-0.dll" at 000000006E340000: builtin
133058.040:01c4:01c8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\api-ms-win-core-fibers-l1-1-1.dll" at 000000006B880000: builtin
133058.041:01c4:01c8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\api-ms-win-core-localization-l1-2-1.dll" at 000000006E6C0000: builtin
133058.041:01c4:01c8:trace:seh:NtQueryInformationThread (0xfffffffffffffffe,1,0x31c6e0,20,(nil))
warn:  OpenVR: Failed to initialize OpenVR
info:  Enabled instance extensions:
info:    VK_KHR_get_surface_capabilities2
info:    VK_KHR_surface
info:    VK_KHR_win32_surface
warn:  D3D9: VK_FORMAT_D16_UNORM_S8_UINT -> VK_FORMAT_D24_UNORM_S8_UINT
warn:  D3D9: VK_FORMAT_A4R4G4B4_UNORM_PACK16_EXT -> VK_FORMAT_B4G4R4A4_UNORM_PACK16
info:  GeForce RTX 2070:
info:    Driver: 450.80.2
info:    Vulkan: 1.2.133
info:    Memory Heap[0]: 
info:      Size: 8192 MiB
info:      Flags: 0x1
info:      Memory Type[7]: Property Flags = 0x1
info:    Memory Heap[1]: 
info:      Size: 24070 MiB
info:      Flags: 0x0
info:      Memory Type[0]: Property Flags = 0x0
info:      Memory Type[1]: Property Flags = 0x0
info:      Memory Type[2]: Property Flags = 0x0
info:      Memory Type[3]: Property Flags = 0x0
info:      Memory Type[4]: Property Flags = 0x0
info:      Memory Type[5]: Property Flags = 0x0
info:      Memory Type[6]: Property Flags = 0x0
info:      Memory Type[8]: Property Flags = 0x6
info:      Memory Type[9]: Property Flags = 0xe
info:    Memory Heap[2]: 
info:      Size: 246 MiB
info:      Flags: 0x1
info:      Memory Type[10]: Property Flags = 0x7
info:  Process set as DPI aware
133058.165:01c4:01c8:fixme:ddraw:ddraw7_Initialize Ignoring guid {baafeb00-00eb-69ee-eba0-3c804c97f796}.
133058.166:01c4:01c8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\dxvk_config.dll" at 0000000069040000: native
133058.167:01c4:01c8:trace:seh:NtQueryInformationThread (0x98,0,0x31c8d0,30,(nil))
133058.186:01c4:01cc:trace:seh:NtQueryInformationThread (0xfffffffffffffffe,12,0xe8fc30,4,(nil))
...
133058.252:01c4:01c8:err:winediag:MIDIMAP_drvOpen No software synthesizer midi port found, Midi sound output probably won't work.
133058.254:00d0:01c0:trace:seh:NtQueryInformationThread (0xfffffffffffffffe,12,0x380afc50,4,(nil))
133058.257:01c4:01c8:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\dxdiagn.dll" : builtin
133058.257:01c4:01c8:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\d3d9.dll" : native
133058.257:01c4:01c8:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\vulkan-1.dll" : builtin
133058.257:01c4:01c8:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\devenum.dll" : builtin
133058.257:01c4:01c8:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\msdmo.dll" : builtin
133058.257:01c4:01c8:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\avicap32.dll" : builtin
133058.257:01c4:01c8:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\quartz.dll" : builtin
Unable to read VR Path Registry from C:\users\steamuser\Local Settings\Application Data\openvr\openvrpaths.vrpath
133058.342:00c4:00cc:trace:seh:NtQueryInformationThread (0x1c4,0,0x1c15f50,30,(nil))
133058.342:00c4:00cc:trace:seh:NtQueryInformationThread (0x1c4,0,0x1c15f50,30,(nil))
133058.343:00c4:00cc:trace:seh:NtQueryInformationThread (0x1c4,0,0x1c15f50,30,(nil))
...
133058.351:00c4:00cc:trace:seh:NtQueryInformationThread (0x1c4,0,0x1c15f50,30,(nil))
133058.351:00c4:00cc:fixme:dbghelp:fetch_thread_info Couldn't open thread 448 (87)
133063.612:00c4:00cc:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\lsteamclient.dll" at 00007FB7A14C0000: builtin
133063.612:00c4:00cc:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\lsteamclient.dll" : builtin
133074.355:00c4:00cc:warn:debugstr:OutputDebugStringA "Wrote minidump to Crash.dmp.\n"
...
133074.950:00c4:00c8:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFFFFFFFFFA, 000000000091F960
133075.960:003c:0070:trace:seh:NtQueryInformationThread (0xfffffffffffffffe,12,0x119fda0,4,(nil))
133075.960:0058:0080:trace:seh:NtQueryInformationThread (0xfffffffffffffffe,12,0x17dfda0,4,(nil))
133075.961:0084:0094:trace:seh:NtQueryInformationThread (0xfffffffffffffffe,12,0xf9fda0,4,(nil))
133076.062:0030:008c:trace:seh:NtQueryInformationThread (0xfffffffffffffffe,12,0x13cfda0,4,(nil))
133076.062:0030:01e8:trace:seh:NtQueryInformationThread (0xfffffffffffffffe,12,0x1c0fda0,4,(nil))
pid 103640 != 103639, skipping destruction (fork without exec?)

(I don't really know what is relevant from this. I hope it contains some relevant information...)

Edit Strangely, after a restart of my PC, it runs now correctly. I still have the alt+tab issue (i.e. alt+tab, or any overlay occurring within the game will freeze the graphics) but it runs very well otherwise. Maybe even better (smoother, faster) than before, but I don't know. But I mostly hoped that the alt+tab issue would be fixed. I'm using borderless window, as this is what I read somewhere.

Now I also have a log file in comparison from a correct run.

From that new log, I could not find these parts from the old log:

But I assume this is all already part of the error handling, the crash handler, which collects some information about my system. So this is probably not relevant. So basically I don't know which part of the (first) log is relevant for the error I had.

Hello,

Doom Eternal freezes on Loading screen.

steam-782330.zip

Here's the log file. As it too big I had to zip it.

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 94
model name	: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
stepping	: 3

NVIDIA Corporation TU104 [GeForce RTX 2080 Rev. A] (rev a1)

nvidia 455.28-7
Vulkan Instance Version: 1.2.153

Hi there! Just got the game during the sale. Tab key (For the inventory and stuff) is not working for me. I would swear it was working during the first mission but then nothing, even on the menus... Anyone else?

Hi there! Just got the game during the sale. Tab key (For the inventory and stuff) is not working for me. I would swear it was working during the first mission but then nothing, even on the menus... Anyone else?

Try pressing left alt. That should also bring up that same menu, and then you should be able to use Tab again.

It happens to me when I alt-tab out while playing the game. Once I alt-tab back in, I have to use alt one time to get tab to work again.

Even if you didn't alt-tab, try it anyway.

Hello,

Doom Eternal freezes on Loading screen.

steam-782330.zip

Here's the log file. As it too big I had to zip it.

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 94
model name	: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
stepping	: 3

NVIDIA Corporation TU104 [GeForce RTX 2080 Rev. A] (rev a1)

nvidia 455.28-7
Vulkan Instance Version: 1.2.153

I'm having this same issue, were you able to get it working? I'm also on a 2080, nvidia 455.34.01

No I have not 😔

On Tue, Nov 3, 2020, 22:45 George Gibbs [email protected] wrote:

Hello,

Doom Eternal freezes on Loading screen.

steam-782330.zip
https://github.com/ValveSoftware/Proton/files/5432527/steam-782330.zip

Here's the log file. As it too big I had to zip it.

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 94
model name : Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
stepping : 3

NVIDIA Corporation TU104 [GeForce RTX 2080 Rev. A] (rev a1)

nvidia 455.28-7
Vulkan Instance Version: 1.2.153

I'm having this same issue, were you able to get it working? I'm also on a
2080, nvidia 455.34.01

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-721245884,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAIQWG4SS2O2J7DNOMY7YTSOAXTPANCNFSM4MI6DHIA
.

No I have not pensive

Thanks for confirming, hoping to find a workaround. I submitted bug 1522 over on the mutter tracker as it does seem to work fine for me with KDE and disabling the compositor (which it does by default for fullscreen apps with the latest KDE). No idea if it's actually mutter at fault or something within wine/proton but I figured it couldn't hurt to try and get more eyes on it...

FWIW I run Nvidia and I'm not having any issues on Budgie, which uses GNOME and Mutter under the hood and therefore also has no way to disable the compositor.

No I have not pensive

Thanks for confirming, hoping to find a workaround. I submitted bug 1522 over on the mutter tracker as it does seem to work fine for me with KDE and disabling the compositor (which it does by default for fullscreen apps with the latest KDE). No idea if it's actually mutter at fault or something within wine/proton but I figured it couldn't hurt to try and get more eyes on it...

Interestingly, today it started working again!

Probably something to do with these updates?

[2020-11-03T16:51:12+0600] [ALPM] upgraded vulkan-icd-loader (1.2.153-2 -> 1.2.158-1)
[2020-11-03T16:51:12+0600] [ALPM] upgraded vulkan-tools (1.2.153-1 -> 1.2.158-1)

Interestingly, today it started working again!

It also did not work for me at some point, but then after I restarted my computer, it worked (but there were no updates in the meantime).

@kisak-valve Hi, it seems that because the game doesn't seem to recognize that my bethesda account is verified, I cannot access battlemode nor newer master levels because of it. Would be nice to see a fix soon.

Tested with proton 5.0.10

I'm experiencing the game freezes at "loading" (~10 seconds after launching). I've tried the nvidia 440, 450 and 455 drivers, result is the same. Tried proton versions 5.13-1, 5.0-10, and 5.9-GE, result is the same. Launch arguments used: PROTON_NO_ESYNC=1 %command% +in_terminal 1 +com_skipIntroVideo 1 +com_skipSignInManager 1 (I've tried them individually and together. Result is the same).

system info: https://gist.github.com/dymax78/24837a587c00eb59a2c68fc24c5b80da

proton log dump: steam-782330.zip

Thank you for your time and assistance.

@dymax78 have you tried playing the game with Esync enabled? I haven't had these issues on my end after doing so.

For months the game wouldn't run unless esync was disabled, so that doesn't
make much sense. I guess it might work with Esync now, but I doubt that's
the issue.

On Sun, Nov 8, 2020 at 11:46 PM Alexander Streng [email protected]
wrote:

@dymax78 https://github.com/dymax78 have you tried playing the game
with Esync enabled? I haven't had these issues on my end after doing so.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-723750943,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y33YMBZOHY57PSCZLOO3SO5X3TANCNFSM4MI6DHIA
.

@gardotd426 still worth trying. And the game works perfectly with esync(on nvidia hardware but that souldn't matter). In mh case if esync was disabled then 99% of the time the game would get stuck at a black screen before even booting to the main menu.

@gardotd426 still worth trying. And the game works perfectly with esync(on nvidia hardware but that souldn't matter). In mh case if esync was disabled then 99% of the time the game would get stuck at a black screen before even booting to the main menu.

Hi Warrior,

Yes, I've tried that as well. Unfortunately, it's the same result.

For everyone having it hang on the initial loading screen, try running in Windowed (I believe -window or -safe launch options) or try a different compositor (if you're on gnome, try kde or something uncomposited). I'm having a similar issue with mutter/gnome as listed in my post above which may be what you're running into.

Actually I'm seeing that Battlemode doesn't work either (I've never tried
to play it).

Idk if this is a Proton 5.13 issue or what, I'll try with another Proton
version and see what happens.

On Mon, Nov 9, 2020 at 1:21 PM George Gibbs [email protected]
wrote:

For everyone having it hang on the initial loading screen, try running in
Windowed (I believe -window or -safe launch options) or try a different
compositor (if you're on gnome, try kde or something uncomposited). I'm
having a similar issue with mutter/gnome as listed in my post above which
may be what you're running into.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-724188382,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y33526S7GAA3NM2AXZV3SPAXKBANCNFSM4MI6DHIA
.

Ive tried all the proton versions, including the GE versions, upgraded to the latest Nvidia drivers. Purged steam, reloaded everything.
But as all the rest of my games run it must be some kind of interaction - particular to DE and 20.10 - as Vash63 suggests, gnome?

@kisak-valve, so Doom Eternal Battlemode is confirmed not working with 5.13. Should that be in the 5.13 issues? Or just here?

For everyone having it hang on the initial loading screen, try running in Windowed (I believe -window or -safe launch options) or try a different compositor (if you're on gnome, try kde or something uncomposited). I'm having a similar issue with mutter/gnome as listed in my post above which may be what you're running into.

Thanks for the suggestion. Unfortunately, the windowed launch options are being ignored (-windowed, –windowed -w 1024, -sw, or -safe) and the game keeps opening in fullscreen. Based off your response, it's pertinent to note that I recently updated Gnome to 3.38.

Hello @gardotd426, please confirm that the issue doesn't occur with an older Proton version, then with Proton 5.13, add PROTON_LOG=1 %command% to the game's launch options, reproduce the issue, and attach the generated $HOME/steam-$APPID.log to this issue report as a file. (Proton logs compress well if needed.)

In general, this is the right place to discuss all issues you see with Doom Eternal.

@kisak-valve battlemode never worked with Proton due to "unverified account" issue

@kisak-valve battlemode never worked with Proton due to "unverified account" issue

@warriormaster12 I'm sorry, this is wrong.

Battlemode does work with other versions of Proton. I tested it after my previous post, and was able to play like 5 matches in a row with no issues.

And on Proton 5.13, it's not an "unverified account" issue. It's just "Unknown error occurred. Please try again later."

@kisak-valve I'll get those logs and post them later today.

Battlemode does work with other versions of Proton. I tested it after my previous post, and was able to play like 5 matches in a row with no issues.

@gardotd426 battlemode never worked for me with any proton versions, it just says unable to find matches.

@kisak-valve battlemode never worked with Proton due to "unverified account" issue

@warriormaster12 I'm sorry, this is wrong.

Battlemode does work with other versions of Proton. I tested it after my previous post, and was able to play like 5 matches in a row with no issues.

And on Proton 5.13, it's not an "unverified account" issue. It's just "Unknown error occurred. Please try again later."

@kisak-valve I'll get those logs and post them later today.

@gardotd426

Battlemode never worked on my end. I checked bethesda.net and it says that my account is verified but in Doom Eternal it's not.

@gardotd426 battlemode never worked for me with any proton versions, it just says unable to find matches.

This is apparently sometimes an issue with Windows users as well.

But no, I was able to play 5 or 6 matches in a row just by using "Quick Match" (so not like I was invited by anyone or anything) and it worked flawlessly.

Battlemode never worked on my end. I checked bethesda.net and it says that my account is verified but in Doom Eternal it's not.

@warriormaster12 that's unfortunate, but I don't have that issue whatsoever, and it's not the issue with 5.13 either, it's something else.

@gardotd426 battlemode never worked for me with any proton versions, it just says unable to find matches.

This is apparently sometimes an issue with Windows users as well.

But no, I was able to play 5 or 6 matches in a row just by using "Quick Match" (so not like I was invited by anyone or anything) and it worked flawlessly.

Battlemode never worked on my end. I checked bethesda.net and it says that my account is verified but in Doom Eternal it's not.

@warriormaster12 that's unfortunate, but I don't have that issue whatsoever, and it's not the issue with 5.13 either, it's something else.

@gardotd426 you might be an exception not the rule but we'll see. I'll send a lig later today and also try to send a ticket to Bethesda support.

That's not likely.

You pretty much never have situations where multiplayer only works for one
person and not everyone else. You do often have situations where it will
work for most people but a few can't get it to work.

I've tested this on multiple machines.

On Tue, Nov 10, 2020, 2:57 AM Alexander Streng [email protected]
wrote:

@gardotd426 https://github.com/gardotd426 battlemode never worked for
me with any proton versions, it just says unable to find matches.

This is apparently sometimes an issue with Windows users as well.

But no, I was able to play 5 or 6 matches in a row just by using "Quick
Match" (so not like I was invited by anyone or anything) and it worked
flawlessly.

Battlemode never worked on my end. I checked bethesda.net and it says
that my account is verified but in Doom Eternal it's not.

@warriormaster12 https://github.com/warriormaster12 that's unfortunate,
but I don't have that issue whatsoever, and it's not the issue with 5.13
either, it's something else.

@gardotd426 https://github.com/gardotd426 you might be an exception not
the rule but we'll see. I'll send a lig later today and also try to send a
ticket to Bethesda support.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-724530867,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y332BA7TH5INNNITWL6TSPDW7JANCNFSM4MI6DHIA
.

@gardotd426 guess you are right then, I already sent a ticket to Bethesda

Hopefully they give you anything other than "Sorry, this game is for
Windows only, we can't provide any help" which is 99.9999% going to be what
they say.

On Tue, Nov 10, 2020 at 4:43 AM Alexander Streng [email protected]
wrote:

@gardotd426 https://github.com/gardotd426 guess you are right then, I
already sent a ticket to Bethesda

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-724587166,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y33YYIFYFRLNL7ATKAUDSPEDKHANCNFSM4MI6DHIA
.

For everyone having it hang on the initial loading screen, try running in Windowed (I believe -window or -safe launch options) or try a different compositor (if you're on gnome, try kde or something uncomposited). I'm having a similar issue with mutter/gnome as listed in my post above which may be what you're running into.

Thanks for the suggestion. Unfortunately, the windowed launch options are being ignored (-windowed, –windowed -w 1024, -sw, or -safe) and the game keeps opening in fullscreen. Based off your response, it's pertinent to note that I recently updated Gnome to 3.38.

Its definitely Gnome. Just installed Plasma and it runs fine

For everyone having it hang on the initial loading screen, try running in Windowed (I believe -window or -safe launch options) or try a different compositor (if you're on gnome, try kde or something uncomposited). I'm having a similar issue with mutter/gnome as listed in my post above which may be what you're running into.

Thanks for the suggestion. Unfortunately, the windowed launch options are being ignored (-windowed, –windowed -w 1024, -sw, or -safe) and the game keeps opening in fullscreen. Based off your response, it's pertinent to note that I recently updated Gnome to 3.38.

Its definitely Gnome. Just installed Plasma and it runs fine

Thanks for confirming. I've opened an issue for this on GNOME's mutter tracker, though I'm still not sure if mutter is the fault or something not being handled right between Proton and mutter.

Denuvo was removed from the game in an update so the game should work out of the box. Proton 5.9 runs it well.

From what I've gathered reading this thread, and by personal experience:

• For the love of god do not use GNOME / MATE
• Alt-Tabbing while in full screen or changing the screen resolution can and in many cases will break the rendering and you will have to kill the game. If you need to access other programs while you are playing, play in Windowed mode. The game supports the maximize button.
• Audio crackling may occur. It can be mostly reduced using some custom Pulseaudio settings.
• GPU usage is slightly higher when playing on Proton. On Windows the absolute minimum would be a 1050 2GB, but for Proton you will need a 1060 3GB or better, which I'm pretty sure is recommended anyway.
• I tried multi-player. It doesn't work. The error message doesn't give me anything specific, it just tells me there was a connection issue, so I don't know if it's caused by some sort of anticheat. If anybody has a work-around, let me know.

Specs I've tested on:

GTX 1060 3GB
Intel Core i5 8400
16GB of HyperX Fury DDR4 Dual Channel RAM
GeForce Driver 450 LTS
Intel 660p Series 1TB (where the game is stored)

For everyone having it hang on the initial loading screen, try running in Windowed (I believe -window or -safe launch options) or try a different compositor (if you're on gnome, try kde or something uncomposited). I'm having a similar issue with mutter/gnome as listed in my post above which may be what you're running into.

Thanks for the suggestion. Unfortunately, the windowed launch options are being ignored (-windowed, –windowed -w 1024, -sw, or -safe) and the game keeps opening in fullscreen. Based off your response, it's pertinent to note that I recently updated Gnome to 3.38.

Its definitely Gnome. Just installed Plasma and it runs fine

Kubuntu 20.04, Proton 5.13-1 - multplayer never worked.

@gardotd426 well, I tried but they refused to fix the issue because of Proton. I should try to test the game on windows and creare a ticket afrer that.

Update, they are willing to continue to help me with account verification issue.

@kisak-valve Hi, I thought that it would be a good idea to send the same log that I sent to Bethesda here.

Here's the log
steam-782330.zip

@gardotd426 Bethesda support's conclusion was that the issue isn't with my account/account linking with steam but how Proton handles loging in to the game.

@warriormaster12 Of course, for me Battlemode works fine on Windows.

Have not tried Battlemode, but except alt+tab issue Doom Eternal runs perfectly on my Gnome setup. And it's run great! :-) Started to play the Ancient God DLC.

If anyone need anything that might help, please do ask, I will try to provide as much in my ability.

Have not tried Battlemode, but except alt+tab issue Doom Eternal runs perfectly on my Gnome setup. And it's run great! :-) Started to play the Ancient God DLC.

If anyone need anything that might help, please do ask, I will try to provide as much in my ability.

what version of Gnome?

Gnome 3.38.1

On Sun, Nov 15, 2020, 13:44 dymax78 [email protected] wrote:

Have not tried Battlemode, but except alt+tab issue Doom Eternal runs
perfectly on my Gnome setup. And it's run great! :-) Started to play the
Ancient God DLC.

If anyone need anything that might help, please do ask, I will try to
provide as much in my ability.

what version of Gnome?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-727529802,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAIQWGUK7GZKOHZJJ2S2GTSP6BE5ANCNFSM4MI6DHIA
.

Per Musenkishi at protondb: https://www.protondb.com/app/782330

Weird thing happened after upgrading Pop_OS from 20.04 to 20.10. Everything that use fullscreen has screen tearing and DOOM Eternal wont go past the loading screen. To fix this (if you use GNOME), you need to disable unredirect for display. An extension is available at GNOME Extensions. Will fix both the game loading and any screen tearing.

extension: https://extensions.gnome.org/extension/1873/disable-unredirect-fullscreen-windows/

This resolved the 'loading' freeze for me. Kernel 5.4.77-1-lts, Gnome 3.38.1

In one of the other issues someone mentioned that the game was not correctly utilising vram and instead was using system memory. I appear to have that problem with the latest nvidia driver (455.45.01):

I'm getting anywhere between 25 and 65 fps with a RTX 2080 at 1080p , changing the quality settings appears to have no effect - I'll get those framerates at low and ultra nightmare. As you can see from the above screenshot the game process is using around 800mb vram and about 8gb system memory.

Proton 5.13, Kernel 5.9.8 / Fedora 33

Hello I was trying to find if this had been solved already but haven't found a solution. If there is please direct me to it.
I am getting graphical artifacts in the game on textures and some of the blood turns into brightly colored partials (honestly unsure if that is intentional or not because it looks quit cool)
But the floor artifacts are not. Sometimes they are very small and I don't notice them. And other times they are very noticeable. Depends upon the surface.
Here is some screenshot showing it

Please notice the flag where it is showing the most

Also this one

These kinds of surfaces are the worse. It may not look that bad on the screenshot but these artifacts flicker, so it's very noticeable when playing the game.

I am running kubuntu 20.04 with
CPU: Ryzen 5 1600
GPU: Radeon RX570
RAM: 16GB
As for driver using the command
spci -vnn | grep -i VGA -A 12
I said I was using Kernel driver in use: amdgpu

System information https://gist.github.com/AnimatedFreak/9639c734bb1825e516322b4d5121e7f3
Thank you in advance.

Hello @AnimatedFreak, 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.

Thank you, I updated my report
Here is a gist https://gist.github.com/AnimatedFreak/9639c734bb1825e516322b4d5121e7f3

Thanks, your system information tells us that you're using the padoka PPA and that's badly outdated at this point, forcing you to use an older mesa version than provided by stock Ubuntu 20.04. Rendering artifacts with a random git mesa commit from the start of the year is not particularly interesting from a troubleshooting perspective.

Unfortunately, I'm not exactly sure what steps it would take to cleanly remove that PPA in your current system configuration.

I see, I don't remeber the reason for using padoka, I think it might have had something with 32bit games needed some other driver. Either way according to the padoka PPA one can revert to the old ubuntu driver using ppa-purge. Would you recommend me doing that? Or could that break my system.

Sorry if I wasn't clearer, there's a couple details I do know. First, yes, the normal way to cleanly remove a PPA is to ppa-purge it however ...
1> Padoka doesn't have any 20.04 packages, so you've gone through a system upgrade at some point, which disabled the PPA.
2> I think that ppa-purge requires that the ppa be enabled to work sanely.
3> The ppa has a rather aggressively selected mesa version, so it'll get used over any Ubuntu provided variant or other PPA variant.
4> I don't know what other packages were held onto past the system upgrade besides mesa.

As long as you replace packages instead of forcing them to removed, then in theory, nothing should break horribly. I'd recommend asking around your distro's community for some help where there's most likely someone else who has seen this situation before.

thank you, I am back up my system just in case. Even if it wouldn't solve the issue, I think removing an old PPA is a good idea anyways.

Hello I was trying to find if this had been solved already but haven't found a solution. If there is please direct me to it.
I am getting graphical artifacts in the game on textures and some of the blood turns into brightly colored partials (honestly unsure if that is intentional or not because it looks quit cool)
But the floor artifacts are not. Sometimes they are very small and I don't notice them. And other times they are very noticeable. Depends upon the surface.

Hello, I can confirm this issue on NVIDIA cards and Ubuntu 20.04 on KDE Plasma (basically the same software you are using). Minor floor artifacts appear for me as well, unfortunately I do not have screenshots and it doesn't seem to happen anymore. But during my first time running it on Proton, the blood puddles and decor on the final boss level had a very low render distance to what was actually intended. It's not nearly as severe as what you were experiencing but I thought it was worth noting.

EVGA GTX 1060 3GB

I just bought and installed the game, ran great for several minutes then got a hard crash while reading the codex.

OS: Arch Linux x86_64
Kernel: 5.9.10-arch1-1
Resolution: 2560x1440
DE: GNOME 3.38.1
WM: Mutter
WM Theme: Arc-Dark
Theme: Arc-Dark [GTK2/3]
Icons: Arc [GTK2/3]
CPU: AMD Ryzen 7 3800X (16) @ 3.900GHz
GPU: AMD ATI Radeon RX 5600 OEM/5600 XT / 5700/5700 XT
Memory: 1672MiB / 15989MiB
Proton: 5.13-2

Nov 27 22:44:41 lh-ryzen-desktop kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, signaled seq=15573166, emitted seq=15573168
Nov 27 22:44:41 lh-ryzen-desktop kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process DOOMEternalx64v pid 65656 thread DOOMEternalx64v pid 65656
Nov 27 22:44:41 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: amdgpu: GPU reset begin!
Nov 27 22:44:41 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring kiq_2.1.0 test failed (-110)
Nov 27 22:44:41 lh-ryzen-desktop kernel: [drm:gfx_v10_0_hw_fini [amdgpu]] *ERROR* KGQ disable failed
Nov 27 22:44:41 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring kiq_2.1.0 test failed (-110)
Nov 27 22:44:41 lh-ryzen-desktop kernel: [drm:gfx_v10_0_hw_fini [amdgpu]] *ERROR* KCQ disable failed
Nov 27 22:44:42 lh-ryzen-desktop kernel: [drm:gfx_v10_0_hw_fini [amdgpu]] *ERROR* failed to halt cp gfx
Nov 27 22:44:42 lh-ryzen-desktop kernel: [drm] free PSP TMR buffer
Nov 27 22:44:42 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: amdgpu: GPU BACO reset
Nov 27 22:44:45 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: amdgpu: GPU reset succeeded, trying to resume
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] PCIE GART of 512M enabled (table at 0x0000008000000000).
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] VRAM is lost due to GPU reset!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] PSP is resuming...
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] reserve 0x900000 from 0x8178400000 for PSP TMR
Nov 27 22:44:45 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: amdgpu: RAS: optional ras ta ucode is not available
Nov 27 22:44:45 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: amdgpu: SMU is resuming...
Nov 27 22:44:45 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: amdgpu: SMU is resumed successfully!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] kiq ring mec 2 pipe 1 q 0
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] VCN decode and encode initialized successfully(under DPG Mode).
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] JPEG decode initialized successfully.
Nov 27 22:44:45 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
Nov 27 22:44:45 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0
Nov 27 22:44:45 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0
Nov 27 22:44:45 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 5 on hub 0
Nov 27 22:44:45 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 6 on hub 0
Nov 27 22:44:45 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 7 on hub 0
Nov 27 22:44:45 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 8 on hub 0
Nov 27 22:44:45 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 9 on hub 0
Nov 27 22:44:45 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 10 on hub 0
Nov 27 22:44:45 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: amdgpu: ring kiq_2.1.0 uses VM inv eng 11 on hub 0
Nov 27 22:44:45 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: amdgpu: ring sdma0 uses VM inv eng 12 on hub 0
Nov 27 22:44:45 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: amdgpu: ring sdma1 uses VM inv eng 13 on hub 0
Nov 27 22:44:45 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: amdgpu: ring vcn_dec uses VM inv eng 0 on hub 1
Nov 27 22:44:45 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: amdgpu: ring vcn_enc0 uses VM inv eng 1 on hub 1
Nov 27 22:44:45 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: amdgpu: ring vcn_enc1 uses VM inv eng 4 on hub 1
Nov 27 22:44:45 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: amdgpu: ring jpeg_dec uses VM inv eng 5 on hub 1
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] recover vram bo from shadow start
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[65656]: amdgpu: The CS has been cancelled because the context is lost.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63529]: amdgpu: amdgpu_cs_query_fence_status failed.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.849109:ERROR:raster_decoder.cc(1110)] RasterDecoder context lost via ARB/EXT_robustness. Reset status = GL_INNOCENT_CONTEXT_RESET_KHR
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.849176:ERROR:raster_decoder.cc(868)]   RasterDecoderImpl: Context reset detected after MakeCurrent.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.849198:ERROR:gpu_service_impl.cc(929)] Exiting GPU process because some drivers can't recover from errors. GPU process will restart shortly.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.849437:ERROR:gles2_cmd_decoder.cc(17050)] Offscreen context lost via ARB/EXT_robustness. Reset status = GL_INNOCENT_CONTEXT_RESET_KHR
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.849467:ERROR:gles2_cmd_decoder.cc(4831)]   GLES2DecoderImpl: Context reset detected after MakeCurrent.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.850626:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.851137:ERROR:gles2_cmd_decoder.cc(17050)] Offscreen context lost via ARB/EXT_robustness. Reset status = GL_INNOCENT_CONTEXT_RESET_KHR
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.851159:ERROR:gles2_cmd_decoder.cc(4831)]   GLES2DecoderImpl: Context reset detected after MakeCurrent.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.851190:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.851345:ERROR:gles2_cmd_decoder.cc(17050)] Offscreen context lost via ARB/EXT_robustness. Reset status = GL_INNOCENT_CONTEXT_RESET_KHR
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.851363:ERROR:gles2_cmd_decoder.cc(4831)]   GLES2DecoderImpl: Context reset detected after MakeCurrent.
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] recover vram bo from shadow done
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: amdgpu 0000:2f:00.0: amdgpu: GPU reset(2) succeeded!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop kernel: [drm] Skip scheduling IBs!
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.851536:ERROR:gles2_cmd_decoder.cc(17050)] Offscreen context lost via ARB/EXT_robustness. Reset status = GL_INNOCENT_CONTEXT_RESET_KHR
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.851554:ERROR:gles2_cmd_decoder.cc(4831)]   GLES2DecoderImpl: Context reset detected after MakeCurrent.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.852231:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.852273:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.852830:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.852860:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.852879:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.853050:ERROR:gles2_cmd_decoder.cc(17050)] Offscreen context lost via ARB/EXT_robustness. Reset status = GL_INNOCENT_CONTEXT_RESET_KHR
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.853076:ERROR:gles2_cmd_decoder.cc(4831)]   GLES2DecoderImpl: Context reset detected after MakeCurrent.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.853102:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.853291:ERROR:gles2_cmd_decoder.cc(17050)] Offscreen context lost via ARB/EXT_robustness. Reset status = GL_INNOCENT_CONTEXT_RESET_KHR
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.853309:ERROR:gles2_cmd_decoder.cc(4831)]   GLES2DecoderImpl: Context reset detected after MakeCurrent.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.853334:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.853349:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.853364:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.853980:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.854005:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.854022:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.854613:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.854641:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.854657:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.854671:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.854791:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.854994:ERROR:gles2_cmd_decoder.cc(17050)] Offscreen context lost via ARB/EXT_robustness. Reset status = GL_INNOCENT_CONTEXT_RESET_KHR
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.855015:ERROR:gles2_cmd_decoder.cc(4831)]   GLES2DecoderImpl: Context reset detected after MakeCurrent.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.855127:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.855177:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.855259:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.856914:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.856946:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.856963:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.856978:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.857163:ERROR:gles2_cmd_decoder.cc(17050)] Offscreen context lost via ARB/EXT_robustness. Reset status = GL_INNOCENT_CONTEXT_RESET_KHR
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.857182:ERROR:gles2_cmd_decoder.cc(4831)]   GLES2DecoderImpl: Context reset detected after MakeCurrent.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.857210:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.857772:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.857814:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.857829:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.857853:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.858042:ERROR:gles2_cmd_decoder.cc(17050)] Offscreen context lost via ARB/EXT_robustness. Reset status = GL_INNOCENT_CONTEXT_RESET_KHR
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.858064:ERROR:gles2_cmd_decoder.cc(4831)]   GLES2DecoderImpl: Context reset detected after MakeCurrent.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.858085:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.858109:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.858684:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.858715:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.858731:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.858745:ERROR:gpu_channel.cc(681)] ContextResult::kTransientFailure: trying to create command buffer during process shutdown.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[65725]: [1127/224445.862379:ERROR:command_buffer_proxy_impl.cc(124)] ContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63930]: [1127/224445.862502:ERROR:command_buffer_proxy_impl.cc(124)] ContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63924]: [1127/224445.863724:ERROR:command_buffer_proxy_impl.cc(124)] ContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63607]: [1127/224445.865140:ERROR:command_buffer_proxy_impl.cc(124)] ContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer.
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.866007:WARNING:ipc_message_attachment_set.cc(49)] MessageAttachmentSet destroyed with unconsumed attachments: 0/1
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.866033:WARNING:ipc_message_attachment_set.cc(49)] MessageAttachmentSet destroyed with unconsumed attachments: 0/1
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.866042:WARNING:ipc_message_attachment_set.cc(49)] MessageAttachmentSet destroyed with unconsumed attachments: 0/1
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[63674]: [1127/224445.866051:WARNING:ipc_message_attachment_set.cc(49)] MessageAttachmentSet destroyed with unconsumed attachments: 0/1
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[66191]: [1127/224445.932235:WARNING:crash_reporting.cc(286)] Failed to set crash key: UserID with value: 0
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[66191]: [1127/224445.932294:WARNING:crash_reporting.cc(286)] Failed to set crash key: BuildID with value: 1603928085
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[66191]: [1127/224445.932299:WARNING:crash_reporting.cc(286)] Failed to set crash key: SteamUniverse with value: Public
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[66191]: [1127/224445.932303:WARNING:crash_reporting.cc(286)] Failed to set crash key: Vendor with value: Valve
Nov 27 22:44:45 lh-ryzen-desktop steam.desktop[66191]: [1127/224445.933130:INFO:crash_reporting.cc(247)] Crash reporting enabled for process: gpu-process
Nov 27 22:44:46 lh-ryzen-desktop steam.desktop[66191]: [1127/224446.014884:ERROR:sandbox_linux.cc(372)] InitializeSandbox() called with multiple threads in process gpu-process.

I encountered the same graphical artifacts as @AnimatedFreak; however, I was able to work around the issue by selecting another vulkan driver through the game. I also have an RX570 and encountered the artifacts with drivers 20.30 and 20.45. A listing from vulkaninfo shows two GPUs.

Adding +r_physicalDeviceIndex 1 to launch options makes the artifacts disappear.

GPU0
VkPhysicalDeviceProperties:
===========================
        apiVersion     = 0x40105a  (1.1.90)
        driverVersion  = 79695878 (0x4c01006)
        vendorID       = 0x1002
        deviceID       = 0x67df
        deviceType     = DISCRETE_GPU
        deviceName     = AMD RADV POLARIS10 (LLVM 8.0.1)
[..snip..]
VkPhysicalDeviceDriverProperties:
=================================
        driverID   = 3
        driverName = radv
        driverInfo = Mesa 19.1.6 (LLVM 8.0.1)
        conformanceVersion:
                major    = 1
                minor    = 1
                subminor = 2
                patch    = 0

VkPhysicalDevicePCIBusInfoProperties
====================================
        pciDomain   = 0
        pciBus      = 1
        pciDevice   = 0
        pciFunction = 0
[...snip...]

GPU1
VkPhysicalDeviceProperties:
===========================
        apiVersion     = 0x402098  (1.2.152)
        driverVersion  = 8388765 (0x80009d)
        vendorID       = 0x1002
        deviceID       = 0x67df
        deviceType     = DISCRETE_GPU
        deviceName     = Radeon RX 570 Series
[...snip...]
VkPhysicalDeviceDriverProperties:
=================================
        driverID   = 2
        driverName = AMD open-source driver
        driverInfo = 
        conformanceVersion:
                major    = 1
                minor    = 2
                subminor = 0
                patch    = 2
[...snip...]
VkPhysicalDevicePCIBusInfoProperties
====================================
        pciDomain   = 0
        pciBus      = 1
        pciDevice   = 0
        pciFunction = 0

Is the photo mode working for any of you?

Doom eternal won't load on me. it freezes on the first "loading" screen, and what you have to do to unfreeze your system can vary from just opening steam and stopping it to having to shut your computer down forcefully.

OS: Ubuntu 20.10
KERNEL: 5.8.0-33-generic
CPU: AMD Ryzen 5 4500U with Radeon Graphics
GPU: AMD AMD RENOIR (DRM 3.38.0, 5.8.0-33-generic, LLVM 11.0.0)
GPU DRIVER: 4.6 Mesa 20.3.0 - kisak-mesa PPA
RAM: 15 GB

I use Linux Mint 19.6, Cinnamon, 64 bit.
Is it possible to play Doom Eternal?

Read this thread man, or Protondb or anywhere else you can Google "Doom
Eternal linux," of course you can play it.

On Mon, Dec 14, 2020, 8:42 AM a_subscriber [email protected] wrote:

I use Linux Mint 19.6, Cinnamon, 64 bit.
Is it possible to play Doom Eternal?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-744448181,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y33ZBVH4VKZTPXFZU4UDSUYI5JANCNFSM4MI6DHIA
.

Doom eternal won't load on me. it freezes on the first "loading" screen, and what you have to do to unfreeze your system can vary from just opening steam and stopping it to having to shut your computer down forcefully.

OS: Ubuntu 20.10
KERNEL: 5.8.0-33-generic
CPU: AMD Ryzen 5 4500U with Radeon Graphics
GPU: AMD AMD RENOIR (DRM 3.38.0, 5.8.0-33-generic, LLVM 11.0.0)
GPU DRIVER: 4.6 Mesa 20.3.0 - kisak-mesa PPA
RAM: 15 GB

It appears to be related to Gnome 3.38 / Mutter. There is a issue opened on the tracker (see back further in the thread). You can still play on Ubuntu 20.10 but you have to load the Plasma desktop and effectively play through Kubuntu.

Others have got it work with this:
extension: https://extensions.gnome.org/extension/1873/disable-unredirect-fullscreen-windows/
Although it doesn't appear to work for me for some reason

I've installed plasma desktop, but it still doesn't work there. same issue. I also tried on lxqt and Fluxbox. No change. Is there any way to run the game in windowed mode?

I've installed plasma desktop, but it still doesn't work there. same issue. I also tried on lxqt and Fluxbox. No change. Is there any way to run the game in windowed mode?

Did you log into KDE to play?

yes, I logged out, logged into using plasma, launched steam and then launched doom eternal. Same issue persists, although I could say the loading icon moved a tiny bit more before freezing.

Sounds like you're having some other issue then.

On Mon, Dec 14, 2020 at 1:03 PM aggelalex [email protected] wrote:

yes, I logged out, logged into using plasma, launched steam and then
launched doom eternal. Same issue persists, although I could say the
loading icon moved a tiny bit more before freezing.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-744611872,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y3362YW5ET63EYF57PZTSUZHO7ANCNFSM4MI6DHIA
.

Sounds like you're having some other issue then.
…
On Mon, Dec 14, 2020 at 1:03 PM aggelalex @.***> wrote: yes, I logged out, logged into using plasma, launched steam and then launched doom eternal. Same issue persists, although I could say the loading icon moved a tiny bit more before freezing. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <[#3773 (comment)](https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-744611872)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM5Y3362YW5ET63EYF57PZTSUZHO7ANCNFSM4MI6DHIA .

How can it be troubleshooted?

It worked on Manjaro GNOME apparently 🤷

So, for the past month or so (maybe earlier), I've noticed that the game is crashing consistently after about 2 hours of play time, without exception. Tried Proton Experimental, Proton 5.13, and proton-tkg (and I think Proton GE but IIRC it didn't quite work right with GE).

Obviously it sucks that it only ever happens after well over an hour of play time, because reproducing it means you'll have to play the game for an extended period. And what's more, there's nothing I can see in the logs, just a TON of spam. The log file is huge after two hours. It's literally 35.5 million lines:

wc -l ~/steam-782330.log
35505017 /home/matt/steam-782330.log

Even just trying to look at the last few thousand, I can't find anything of use.

It crashes the exact same way every time. I'll be playing, and then the game will just freeze completely, and I can't alt-tab out or anything, it freezes up the whole desktop, and after maybe 10 seconds I can finally alt-tab out and hit "Stop" in Steam and the game exits. I can then launch it back up and play for two or so more hours, have it freeze again, rinse and repeat.

Arch Linux
Nvidia RTX 3090
Numerous driver versions (like all three 455/460 drivers currently available, and for a few versions before that)

What I could do is try deleting the log file (obviously from ssh since you can't alt-tab out of Doom Eternal without the game breaking) after like an hour and a half, but before it crashes, and if the logging continues, maybe I'll just end up with thousands of lines instead of 35.5 damn million.

Could it be crashing because it fills up disk space or that log file and it can't log anymore? Maybe a memory leak?

Nah it's definitely not anything about disk space, I have 6TB of storage
and even 35.5M lines of text is only 3GB. I also have 32GB of RAM. Also,
I've had PROTON_LOG=1 on from the beginning (so, March), even when I only
had 16GB of RAM, and I used to be able to play for 4, 5 and 6 hours without
a crash. Obviously I'll try it with logging removed, but I highly, highly
doubt that's it.

On Tue, Dec 29, 2020 at 11:58 PM Kevin McCormack [email protected]
wrote:

Could it be crashing because it fills up disk space or that log file and
it can't log anymore? Maybe a memory leak?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-752327870,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y334IE5S2NZ26HR74QULSXKXQDANCNFSM4MI6DHIA
.

Yeah, I just tried it with esync and fsync off, no logging, etc. and it still froze after about an hour.

It's definitely not VRAM, I have an RTX 3090 and it never even came close to saturating it at 1440p.

It's definitely not RAM, I had a system monitor open on my other monitor and it peaked at about 9GB, and I have 32GB.

Honestly it's pretty frustrating.

I finally fixed the unusual stuttering with Doom Eternal, I figured out it was DeadBeef somehow causing the stuttering, yes I know it might sound extremely strange but it was indeed DeadBeef, after closing it the stuttering disappeared, if I opened it again the stuttering would appear again. I just uninstalled DeadBeef and replaced it with a differet music player. Hope this helps someone who might have the same issue.

Having an issue with Doom eternal failing to start at all on Fedora 33. Tried Chris Titus' workaround, no go. Here's my system info: https://gist.github.com/eponafyrefly/b368ee6c617813ad1ee53a5ffbc8c351

You got a proton log?

I've got a 5800X and also run Nvidia (3090 not 980 Ti but still) and Doom Eternal has always worked for me, I've got over 100 hours in it (though probably 15 of those were with a 5700 XT but still all the rest were with Nvidia).

Which Proton version were you using? Did it give any error message? What exactly are your launch options (we shouldn't have to go watch a whole Chris Titus video just to know)

@gardotd426 Proton v6.1-GE-2.
plog.tar.gz

I followed this bit: https://christitus.com/doom-eternal-linux/ so you don't have to watch a video. ;) Launch options are PROTON_LOG=1 %command% PROTON_NO_ESYNC=1 %command% +in_terminal 1 +com_skipIntroVideo 1 +com_skipKeyPressOnLoadScreens 1 +com_skipSignInManager 1. Upon starting, a window pops up saying Doom is launching, and then nothing happens. After turning on Proton logging, I get a pop-up saying my video driver is too old, but I am running the latest NVIDIA driver 460.39. Attaching the logs. Thanks.

Well that might explain a lot. You've goofed hard.

You're only supposed to have ONE %command%. One.

All envvars and linux options/commands go before the %command%, Windows/game launch options go after.

Also just try with Proton 5.13 or Proton Experimental first, instead of trying with unofficial Protons. The game should work with GE but this is the official Proton bug tracker and the game does work with official proton, so you should be trying that first.

Removing the extra %command% didn't help but using the older Proton 5.13 did. FWIW I did also try Experimental before posting. Thanks.

Okay well both of those (Experimental and GE) do work, so there's something going on. Try switching back to Experimental (not GE yet) and see if that will work. Make sure to completely exit the game and all that first.

If it doesn't, you need to go to the Proton Experimental thread and report the issue.

FWIW, I just checked Experimental and it launched fine.

@kisak-valve, there is one problem, I thought it had gone away but I guess I just hadn't played long enough.

No matter which Proton I use, the game will freeze and then crash after about an hour or two of playtime. I've had it happen 3 times just tonight. Thing is, this last time I ran Steam from the terminal, and there wasn't much of anything right before the crash.

This is all I got:

WARNING: loot droop angular velocity higher than 12.50
WARNING: loot droop angular velocity higher than 12.50
WARNING: idWeaponEntity being deleted from idWeapon destructor: [weapon_ent/ai/soldier/plasma_6718]
WARNING: Alias handle for 'combat/idle_not_aiming_additive' not found in decl 'md6def/characters/monsters/soldier_shield/base/soldier_shield.md6'
WARNING: Alias handle for 'combat/idle_not_aiming_additive' not found in decl 'md6def/characters/monsters/soldier_shield/base/soldier_shield.md6'
WARNING: idWeaponEntity being deleted from idWeapon destructor: [weapon_ent/ai/soldier/plasma_6934]
WARNING: Alias handle for 'combat/idle_not_aiming_additive' not found in decl 'md6def/characters/monsters/soldier_shield/base/soldier_shield.md6'
WARNING: Alias handle for 'combat/idle_not_aiming_additive' not found in decl 'md6def/characters/monsters/soldier_shield/base/soldier_shield.md6'
WARNING: ai/heavy/bloodangel/javelin_hazard_682 has an invalid envDamageType
WARNING: ai/heavy/bloodangel/javelin_hazard_480 has an invalid envDamageType
WARNING: ai/heavy/bloodangel/javelin_hazard_486 has an invalid envDamageType
WARNING: max linear velocity exceeded and clamped, attempted velocity was 1289.43 -1917.95 2244.27
WARNING: idWeaponEntity being deleted from idWeapon destructor: [weapon_ent/ai/soldier/plasma_6748]
WARNING: ai/heavy/bloodangel/javelin_hazard_6677 has an invalid envDamageType
ERROR: ld.so: object '/home/matt/nvme/steamroot/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
wine: enabling seccomp syscall filters.
>>> Adding process 83236 for game ID 782330
Unable to read VR Path Registry from C:\users\steamuser\Local Settings\Application Data\openvr\openvrpaths.vrpath
skipping config: /home/matt/.config/MangoHud/wine-dxdcf13.conf [ not found ]
skipping config: /home/matt/nvme/steamroot/compatibilitytools.d/proton_tkg_5.19.r7.g6a87f0a4.dxvk-dxgi-false/dist/bin/MangoHud.conf [ not found ]
skipping config: /home/matt/.config/MangoHud/wine64-preloader.conf [ not found ]
parsing config: /home/matt/.config/MangoHud/MangoHud.conf [ ok ]
pid 80226 != 80225, skipping destruction (fork without exec?)
Game removed: AppID 782330 "", ProcID 80286
Game 782330 created interface STEAMAPPS_INTERFACE_VERSION006 / Apps
Game 782330 created interface STEAMAPPS_INTERFACE_VERSION008 /
Game 782330 created interface STEAMREMOTESTORAGE_INTERFACE_VERSION014 /
Game 782330 created interface STEAMUSERSTATS_INTERFACE_VERSION011 /
Game 782330 created interface SteamController007 /
Game 782330 created interface SteamController007 / Controller
Game 782330 created interface SteamFriends017 /
Game 782330 created interface SteamInput001 / Controller
Game 782330 created interface SteamUser017 / User
Game 782330 created interface SteamUser020 /
Game 782330 created interface SteamUser020 / User
Game 782330 created interface SteamUtils009 /
Game 782330 created interface SteamUtils009 / Utils
Game 782330 method call count for IClientUser::CancelAuthTicket : 2
Game 782330 method call count for IClientUser::BLoggedOn : 9
Game 782330 method call count for IClientUser::BIsSubscribedApp : 3
Game 782330 method call count for IClientUser::RequestEncryptedAppTicket : 6
Game 782330 method call count for IClientUser::GetAuthSessionTicket : 2
Game 782330 method call count for IClientUser::GetEncryptedAppTicket : 6
Game 782330 method call count for IClientUser::GetSteamID : 5
Game 782330 method call count for IClientFriends::GetFriendCount : 1
Game 782330 method call count for IClientFriends::RequestUserInformation : 9
Game 782330 method call count for IClientFriends::GetFriendPersonaState : 9
Game 782330 method call count for IClientFriends::GetFriendGamePlayed : 9
Game 782330 method call count for IClientFriends::SetRichPresence : 34
Game 782330 method call count for IClientFriends::GetPersonaName : 21
Game 782330 method call count for IClientFriends::GetFriendPersonaName_Public : 9
Game 782330 method call count for IClientUtils::GetAppID : 25
Game 782330 method call count for IClientUtils::GetAPICallResult : 68
Game 782330 method call count for IClientUtils::RecordSteamInterfaceCreation : 14
Game 782330 method call count for IClientUtils::GetIPCountry : 1
Game 782330 method call count for IClientAppManager::BIsDlcEnabled : 3
Game 782330 method call count for IClientAppManager::GetCurrentLanguage : 2
Game 782330 method call count for IClientUserStats::RequestUserStats : 1
Game 782330 method call count for IClientUserStats::RequestCurrentStats : 1
Game 782330 method call count for IClientUserStats::GetAchievement : 41
Game 782330 method call count for IClientRemoteStorage::GetQuota : 37
Game 782330 method call count for IClientRemoteStorage::GetFileCount : 2
Game 782330 method call count for IClientRemoteStorage::FileReadAsyncComplete : 7
Game 782330 method call count for IClientRemoteStorage::FileReadAsync : 7
Game 782330 method call count for IClientRemoteStorage::GetFileSize : 5
Game 782330 method call count for IClientRemoteStorage::GetFileTimestamp : 2
Game 782330 method call count for IClientRemoteStorage::FileWriteAsync : 54
Game 782330 method call count for IClientRemoteStorage::GetFileNameAndSize : 18
Uploaded AppInterfaceStats to Steam
Exiting app 782330

The freeze happened right around the ELFCLASS32 error and the wine: enabling seccomp syscall filters message.

I've tried with both 5.13 and Experimental, as well as numerous GE and TKG versions.

I'm about to launch it again, and when it inevitably crashes I'll look and see if there's anything in common.

Well dammit, I got a 24-hour cooldown. Ugh.

I have just tried DOOM Eternal with default Proton settings and I have random crashes. All the crashes I have seen seem to be related to GnuTLS:

>>> Adding process 1720788 for game ID 782330
Game update: AppID 782330 "", ProcID 1720788, IP 0.0.0.0:0
RecordSteamInterfaceCreation (PID 1720788): SteamUtils009 / Utils
Setting breakpad minidump AppID = 782330
RecordSteamInterfaceCreation (PID 1720788): SteamUser020 / User
Steam_SetMinidumpSteamID:  Caching Steam ID:  76561199014623273 [API loaded no]
RecordSteamInterfaceCreation (PID 1720788): SteamUser017 / User
RecordSteamInterfaceCreation (PID 1720788): STEAMAPPS_INTERFACE_VERSION006 / Apps
Terminal support disabled. Enable with in_terminal
RecordSteamInterfaceCreation (PID 1720788): SteamFriends017 / 
RecordSteamInterfaceCreation (PID 1720788): STEAMUSERSTATS_INTERFACE_VERSION011 / 
RecordSteamInterfaceCreation (PID 1720788): SteamController007 / 
WARNING: radv is not a conformant vulkan implementation, testing use only.
Fossilize INFO: Overriding serialization path: "/mnt/ssd-unencrypted/games/steam/steamapps/shadercache/782330/fozpipelinesv5/steamapprun_pipeline_cache".
RecordSteamInterfaceCreation (PID 1720788): STEAMAPPS_INTERFACE_VERSION008 / 
RecordSteamInterfaceCreation (PID 1720788): SteamUser020 / 
RecordSteamInterfaceCreation (PID 1720788): SteamUtils009 / Utils
RecordSteamInterfaceCreation (PID 1720788): SteamController007 / Controller
RecordSteamInterfaceCreation (PID 1720788): SteamInput001 / Controller
RecordSteamInterfaceCreation (PID 1720788): SteamUtils009 / 
RecordSteamInterfaceCreation (PID 1720788): STEAMREMOTESTORAGE_INTERFACE_VERSION014 / 
Installing breakpad exception handler for appid(steam)/version(1613176728)
GnuTLS error: An unexpected TLS handshake packet was received.
ERROR: ld.so: object '/home/claire/.steam/debian-installation/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
>>> Adding process 1721091 for game ID 782330
Unable to read VR Path Registry from C:\users\steamuser\Local Settings\Application Data\openvr\openvrpaths.vrpath
Unable to read VR Path Registry from C:\users\steamuser\Local Settings\Application Data\openvr\openvrpaths.vrpath
WARNING: radv is not a conformant vulkan implementation, testing use only.
Unable to read VR Path Registry from C:\users\steamuser\Local Settings\Application Data\openvr\openvrpaths.vrpath
pid 1720605 != 1720604, skipping destruction (fork without exec?)
Game removed: AppID 782330 "", ProcID 1720788 

WARNING: radv is not a conformant vulkan implementation, testing use only.
Fossilize INFO: Overriding serialization path: "/mnt/ssd-unencrypted/games/steam/steamapps/shadercache/782330/fozpipelinesv5/steamapprun_pipeline_cache".
RecordSteamInterfaceCreation (PID 1730953): STEAMAPPS_INTERFACE_VERSION008 / 
RecordSteamInterfaceCreation (PID 1730953): SteamUser020 / 
RecordSteamInterfaceCreation (PID 1730953): SteamUtils009 / Utils
RecordSteamInterfaceCreation (PID 1730953): SteamController007 / Controller
RecordSteamInterfaceCreation (PID 1730953): SteamInput001 / Controller
RecordSteamInterfaceCreation (PID 1730953): SteamUtils009 / 
RecordSteamInterfaceCreation (PID 1730953): STEAMREMOTESTORAGE_INTERFACE_VERSION014 / 
GnuTLS error: An unexpected TLS packet was received.
GnuTLS error: The specified session has been invalidated for some reason.
ERROR: ld.so: object '/home/claire/.steam/debian-installation/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
>>> Adding process 1731542 for game ID 782330
Unable to read VR Path Registry from C:\users\steamuser\Local Settings\Application Data\openvr\openvrpaths.vrpath
Unable to read VR Path Registry from C:\users\steamuser\Local Settings\Application Data\openvr\openvrpaths.vrpath
WARNING: radv is not a conformant vulkan implementation, testing use only.
Unable to read VR Path Registry from C:\users\steamuser\Local Settings\Application Data\openvr\openvrpaths.vrpath
pid 1730810 != 1730809, skipping destruction (fork without exec?)

The crashes are sudden and I have seen no other issue whatsoever except occasional connection issues to the Bethesda account / Game server thing (only played the campaign so far), but this may actually be due to poor network conditions.

I am currently running Steam on up-to-date Debian testing.

(Sorry, it's my first time reporting an issue with Steam/Proton and I am not too sure where to look for logs, I simply launched steam from a console and copied relevant excerpts of the console output)

Hey Claire, make sure you always give more relevant information like CPU, GPU, distro, etc. But anyways, yeah I've been getting those too. I've actually gotten them to stop by rolling back to a custom proton 5.22 build I had, but anything after about that time will crash periodically (after about an hour or so), regardless of whether it's official Proton, Proton-GE, or Proton-TKG.

Hey Claire, make sure you always give more relevant information like CPU, GPU, distro, etc. But anyways, yeah I've been getting those too. I've actually gotten them to stop by rolling back to a custom proton 5.22 build I had, but anything after about that time will crash periodically (after about an hour or so), regardless of whether it's official Proton, Proton-GE, or Proton-TKG.

Thank you. I can confirm that after downgrading to Proton 5.13-6, I haven't experienced any crash whatsoever.

Posting here for anyone else investigating poor performance: there seems to be having some sort of regression related to the game using RAM instead of VRAM with the nvidia driver. Going off these two threads on the Nvidia forums this seems to be as early as the 440 drivers which supposedly fixed the issue. On my 2070 Super I've tried on 460 & 450 drivers, several proton & kernel versions, different nvidia settings (flipping, vblank, etc.).

My FPS stays within the 25-45 range no matter what I do across the graphics settings. nvidia-smi shows ~850mb usage despite the game stating 6GB used and system monitor reporting ~2GB used in total.

Replying to https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-798914470

Yup the issue definitely still exists - have posted multiple times about it; 2080 super max-q here.

Hi @kisak-valve,

Unless users are is still reporting being affected by the rainbow particles on Mesa, I believe the RADV / Mesa labels can be removed. The issue was reported (https://gitlab.freedesktop.org/mesa/mesa/-/issues/3064) several months back and fixed (https://gitlab.freedesktop.org/mesa/mesa/-/commit/fd5ffd3a83e178f14fcc69806d3a52724f05b56c). I've confirmed the fixed should have been included in the version reported here: https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-744061602.

I've confirmed the issue is not occuring on the latest mesa-git on both an RX 590 and RX 5700 XT. I however have confirmed that the issue is still present on AMDGPU-PRO, which might explain why some users are still experiencing the issue:

Mesa 21.0-git	AMDGPU-PRO 20.45

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

Yup the issue definitely still exists - have posted multiple times about it; 2080 super max-q here.

I checked back on the nvidia forums thread for any updates and noticed a suggestion that setting __GLX_VENDOR_LIBRARY_NAME=bla instead of __GLX_VENDOR_LIBRARY_NAME=nvidia fixed the issue for me, so that should help others having the VRAM issue.

Just glad it's not a Proton issue :)

Game is still broken with Nvidia and Gnome 40. Just freezes on the first intro video.

Game is still broken with Nvidia and Gnome 40. Just freezes on the first intro video.

You can get past this with the "Unredirect Fullscreen Windows" GNOME extension.

https://github.com/kazysmaster/gnome-shell-extension-disable-unredirect

The actual bug causing this is ticketed here:

https://gitlab.gnome.org/GNOME/mutter/-/issues/1522

It's unique to the NVIDIA/GNOME combination.

Does that extension harm performance?

Does that extension harm performance?

Yes, greatly, it disables Gnome's fullscreen window unredirection causing games to have to go through the compositor. For a proper fix we will need something from either the mutter or Nvidia devs I think.

Battlemode isn't working on my system. It fails to create a party, whether attempting to join/create a private match or queueing for public matches. Windows on the same system has no such issues. Happens with both 5.13 and 6.3.

When is the battlemode problem going to be fixed? Bethesda support clearly stated to me that it's not account issue, it's something with Proton.

When is the battlemode problem going to be fixed? Bethesda support clearly stated to me that it's not account issue, it's something with Proton.

@serebit @warriormaster12 I'm guessing they've added back some sort of anti-cheat or something that's blocking Proton. Because Battlemode absolutely used to work with Proton, and if @serebit is saying that it's not even working with 5.13 (which I'm pretty sure is the Proton version it used to work with), then it looks like Battlemode is finished for Proton users.

EDIT: Actually it was 5.0, so you'll wanna try that. If it doesn't work even then, then there was an update to the game that either broke compatibility, or blocked us.

@gardotd426 denuvo anti-cheat was removed after doom community's negative reception. My only issue is that the game that my account is unverified which was proven falls by Bethesda support.

@warriormaster12 Denuvo anti-cheat was removed, but Id said they would institute a different anti-cheat solution later on down the line.

And my account is absolutely verified, I have played Battlemode before (back when it was working in Proton), and it doesn't work for me now either. So something is clearly wrong.

@gardotd426 in my case it has been always like this since launch. They might have indeed added another anti-cheat solution by now but wouldn't it be easier to implement some kind of a support for it since it's not compatibility braking?

It worked near launch for me, for a while, and broke a few months back. So it's likely a change they made to the system, if others report the same thing.

Is anyone's game freezing at connecting to bethesa.net?

Is anyone's game freezing at connecting to bethesa.net?

If you're using an older proton-ge version (between 6.5 to 6.9-GE-1) please try changing to 6.9-GE-2. The staging ntdll-NtAlertThreadByThreadId was found to cause a lot of issues. My previous builds had this. TKG's and proton/proton experimental do not.

I was using standard proton 6.3.

While attempting to launch DOOM Eternal I would get a prompt telling me that my Nvidia graphics drivers were out of date.

It's always been like that. You just click play.

@gardotd426 I build my own SteamOS. In doing so, I use the steamos-compositor-plus package. Maybe it's just me, but that does not seem to be an option.

I mean there's a play button on the Window. Yeah if you can't click the play button somehow, then you'll have to figure something else out (as in, add a real desktop environment and use that to play Doom Eternal)

Is anyone's game freezing at connecting to bethesda.net?

If you're using an older proton-ge version (between 6.5 to 6.9-GE-1) please try changing to 6.9-GE-2. The staging ntdll-NtAlertThreadByThreadId was found to cause a lot of issues. My previous builds had this. TKG's and proton/proton experimental do not.

@TheGreatestJannet @GloriousEggroll I've been having this issue a lot and now I'm locked out of the game for 24 hours because of DRM. Tried it with 6.3-4, Experimental and 6.10-GE, same result. It crashes mostly at "Connecting to Bethesda.net", sometimes in the main menu.
gist

Game is still broken with Nvidia and Gnome 40. Just freezes on the first intro video.

You can get past this with the "Unredirect Fullscreen Windows" GNOME extension.

https://github.com/kazysmaster/gnome-shell-extension-disable-unredirect

The actual bug causing this is ticketed here:

https://gitlab.gnome.org/GNOME/mutter/-/issues/1522

It's unique to the NVIDIA/GNOME combination.

Did someone also reported the issue to Nvidia ? Beside the performance hit, the extension workaround isn't really a good solution as it also breaks G-SYNC

It’s a Gnome issue though as it only happens on Gnome it seems.

It’s a Gnome issue though as it only happens on Gnome it seems.

But it also looks like it only happens with Nvidia, so maybe we should reports the issue to them too ?

Game is still broken with Nvidia and Gnome 40. Just freezes on the first intro video.

Did someone also reported the issue to Nvidia ? Beside the performance hit, the extension workaround isn't really a good solution as it also breaks G-SYNC

But it also looks like it only happens with Nvidia, so maybe we should reports the issue to them too ?

@koplo199 @TheGreatestJannet I'm sorry but you guys seem to be mistaken, maybe you're trying to run the game on Wayland?

Because Doom Eternal works perfectly on GNOME 40 with Nvidia. I've played it numerous times over the past weeks, and just tested it again today. So it sounds like an individual setup problem.

Nope I’m using Xorg. What driver and graphics card do you have? Also what extension have you installed? Finally are you playing in Windowed or Fullscreen mode?

What driver and graphics card do you have?

RTX 3090, Multiple drivers. 465, 455 (Vulkan Beta), etc.

Also what extension have you installed?

None

Finally are you playing in Windowed or Fullscreen mode?

Both work, and always have.

Hmm I have a GTX 1060 so maybe it affects some cards and not others. Regardless it seems more than just me are affected by it and thus it must be a bug somewhere in Gnome or the Nvidia Driver.

It's more than likely a bug in some extension or some nonsense like that, because Doom Eternal has worked on Nvidia since like 3 days after launch (before it even worked on AMD at all), and that included GNOME.

I only have one extension and disabling it doesn’t change anything. The game still freezes as soon as mutter disables compositing for it. There is an extension that resolves the issue but it comes with a huge performance penalty.

Game is still broken with Nvidia and Gnome 40. Just freezes on the first intro video.

Did someone also reported the issue to Nvidia ? Beside the performance hit, the extension workaround isn't really a good solution as it also breaks G-SYNC

But it also looks like it only happens with Nvidia, so maybe we should reports the issue to them too ?

@koplo199 @TheGreatestJannet I'm sorry but you guys seem to be mistaken, maybe you're trying to run the game on Wayland?

Because Doom Eternal works perfectly on GNOME 40 with Nvidia. I've played it numerous times over the past weeks, and just tested it again today. So it sounds like an individual setup problem.

Wow thanks for your feedback, I don't have any custom extension enabled and I'm on Ubuntu 21.04 (Gnome 3.38.4). May I ask what is your distribution, and if you have any particular settings/config for Nvidia or for Xorg ? Do you have G-SYNC enabled ? If you play nearly since launch, I guess it was also working for you on 3.38.X at that time, would be interesting to see what are the differences on our systems, as I have a RTX 3080 and it's not working on mine, it freeze immediatley after the game window is focused.

EDIT: No more luck after manually disabling preinstalled ubuntu gnome extensions.

I only have one extension and disabling it doesn’t change anything. The game still freezes as soon as mutter disables compositing for it. There is an extension that resolves the issue but it comes with a huge performance penalty.

I'm a little confused.... Mutter doesn't disable compositing. There's actually no way for you to disable compositing in GNOME. I guess maybe you mean fullscreen unredirect but you wouldn't be able to "see" it happening so idk how you know that's when it freezes. Anyway, with unredirect enabled and disabled (using the extension) the game launches perfectly fine. I just tested again, and earlier I played for like 4 hours straight.

Have you not bothered enabling Proton logging and checking and seeing what happens?

Do you have any weird settings in your nvidia-settings?

Wow thanks for your feedback, I don't have any custom extension enabled and I'm on Ubuntu 21.04 (Gnome 3.38.4). May I ask what is your distribution, and if you have any particular settings/config for Nvidia or for Xorg ? Do you have G-SYNC enabled ? If you play nearly since launch, I guess it was also working for you on 3.38.X at that time, would be interesting to see what are the differences on our systems, as I have a RTX 3080 and it's not working on mine, it freeze immediatley after the game window is focused.

I'm on Arch, and have no special settings. Both my monitors are GSync compatible, but since I run two monitors, obviously GSync can't run, so I don't use it (I don't need it, I have a 3090 and Doom Eternal runs at well over 165 fps which is my refresh rate at 1440p). Yes, it was working for me on 3.38 and works on 40 as well.

But when you say it freezes as soon as the window is focused, are you saying that this is after alt-tabbing or something? Or are you saying the game doesn't even work at all? Because Doom Eternal freezes if you alt-tab, it's been an issue since launch. You can't alt-tab once you launch the game. But if you're saying you can't even get the game to launch at all, then that's a problem. And like I asked @TheGreatestJannet, have you bothered actually using Proton logging or at least running Steam from a terminal?

Yes I do mean fullscreen unredirect and I know it is this as it doesn't crash when the extension to disable it is active and when ran in windowed mode. I have bothered to run steam in a terminal and there isn't much useful information here. At best I get this:

Jun 09 11:44:55 GamingPC kernel: snd_hda_intel 0000:00:1f.3: Unstable LPIB (352800 >= 176400); disabling LPIB delay counting
Jun 09 11:44:58 GamingPC com.valvesoftware.Steam.desktop[9110]: Game update: AppID 782330 "", ProcID 2762, IP 0.0.0.0:0
Jun 09 11:44:58 GamingPC com.valvesoftware.Steam.desktop[9110]: RecordSteamInterfaceCreation (PID 2762): SteamUtils009 / Utils
Jun 09 11:44:58 GamingPC com.valvesoftware.Steam.desktop[9110]: RecordSteamInterfaceCreation (PID 2762): SteamUser020 / User
Jun 09 11:44:58 GamingPC com.valvesoftware.Steam.desktop[9110]: RecordSteamInterfaceCreation (PID 2762): SteamUser017 / User
Jun 09 11:44:58 GamingPC com.valvesoftware.Steam.desktop[9110]: RecordSteamInterfaceCreation (PID 2762): STEAMAPPS_INTERFACE_VERSION006 / Apps
Jun 09 11:44:59 GamingPC com.valvesoftware.Steam.desktop[9110]: RecordSteamInterfaceCreation (PID 2762): SteamUtils009 / Utils
Jun 09 11:44:59 GamingPC com.valvesoftware.Steam.desktop[9110]: RecordSteamInterfaceCreation (PID 2762): SteamController007 / Controller
Jun 09 11:44:59 GamingPC com.valvesoftware.Steam.desktop[9110]: RecordSteamInterfaceCreation (PID 2762): SteamInput001 / Controller
Jun 09 11:45:05 GamingPC com.valvesoftware.Steam.desktop[14057]: Terminal support disabled. Enable with in_terminal
Jun 09 11:45:09 GamingPC com.valvesoftware.Steam.desktop[9110]: RecordSteamInterfaceCreation (PID 2762): SteamFriends017 /
Jun 09 11:45:09 GamingPC com.valvesoftware.Steam.desktop[9110]: RecordSteamInterfaceCreation (PID 2762): STEAMUSERSTATS_INTERFACE_VERSION011 /
Jun 09 11:45:09 GamingPC com.valvesoftware.Steam.desktop[9110]: RecordSteamInterfaceCreation (PID 2762): SteamController007 /
Jun 09 11:45:16 GamingPC com.valvesoftware.Steam.desktop[14057]: Fossilize INFO: Overriding serialization path: "/mnt/sdb1/Steam_Games_Linux/steamapps/shadercache/782330/fozpipelinesv5/steamapprun_pipeline_cache".
Jun 09 11:45:17 GamingPC com.valvesoftware.Steam.desktop[14057]: Fossilize WARN: pNext in VkSamplerCreateInfo not supported. (pNext->sType chain: [1000130001])
Jun 09 11:45:17 GamingPC com.valvesoftware.Steam.desktop[14057]: Fossilize WARN: Failed to record sampler, usually caused by unsupported pNext.
Jun 09 11:45:17 GamingPC com.valvesoftware.Steam.desktop[14057]: Fossilize WARN: pNext in VkSamplerCreateInfo not supported. (pNext->sType chain: [1000130001])
Jun 09 11:45:17 GamingPC com.valvesoftware.Steam.desktop[14057]: Fossilize WARN: Failed to record sampler, usually caused by unsupported pNext.
Jun 09 11:45:17 GamingPC com.valvesoftware.Steam.desktop[14057]: Fossilize WARN: pNext in VkSamplerCreateInfo not supported. (pNext->sType chain: [1000130001])
Jun 09 11:45:17 GamingPC com.valvesoftware.Steam.desktop[14057]: Fossilize WARN: Failed to record sampler, usually caused by unsupported pNext.
Jun 09 11:45:17 GamingPC com.valvesoftware.Steam.desktop[14057]: Fossilize WARN: pNext in VkSamplerCreateInfo not supported. (pNext->sType chain: [1000130001])
Jun 09 11:45:17 GamingPC com.valvesoftware.Steam.desktop[14057]: Fossilize WARN: Failed to record sampler, usually caused by unsupported pNext.
Jun 09 11:45:18 GamingPC com.valvesoftware.Steam.desktop[9110]: RecordSteamInterfaceCreation (PID 2762): STEAMAPPS_INTERFACE_VERSION008 /
Jun 09 11:45:22 GamingPC com.valvesoftware.Steam.desktop[9110]: RecordSteamInterfaceCreation (PID 2762): SteamUser020 /
Jun 09 11:45:24 GamingPC com.valvesoftware.Steam.desktop[14113]: Installing breakpad exception handler for appid(gameoverlayui)/version(20210608222338)
Jun 09 11:45:24 GamingPC com.valvesoftware.Steam.desktop[14113]: Installing breakpad exception handler for appid(gameoverlayui)/version(1.0)
Jun 09 11:45:24 GamingPC com.valvesoftware.Steam.desktop[14113]: Installing breakpad exception handler for appid(gameoverlayui)/version(1.0)
Jun 09 11:45:25 GamingPC com.valvesoftware.Steam.desktop[14115]: [0609/114525.661865:INFO:crash_reporting.cc(270)] Crash reporting enabled for process: renderer
Jun 09 11:45:25 GamingPC com.valvesoftware.Steam.desktop[14113]: Installing breakpad exception handler for appid(gameoverlayui)/version(1.0)
Jun 09 11:45:25 GamingPC com.valvesoftware.Steam.desktop[9137]: [0609/114525.896346:ERROR:frame_sink_video_capturer_impl.cc(206)] Invalid resolutions constraints: 0x0 must not be greater than 0x0; and also within media::limits.
Jun 09 11:45:25 GamingPC com.valvesoftware.Steam.desktop[9137]: [0609/114525.933084:ERROR:frame_sink_video_capturer_impl.cc(206)] Invalid resolutions constraints: 0x0 must not be greater than 0x0; and also within media::limits.
Jun 09 11:45:26 GamingPC com.valvesoftware.Steam.desktop[9110]: OnFocusWindowChanged to game window type: AppID 782330, 782330
Jun 09 11:45:26 GamingPC com.valvesoftware.Steam.desktop[9110]: Controller 0 mapping uses xinput : false
Jun 09 11:45:26 GamingPC com.valvesoftware.Steam.desktop[9110]: Loaded Config for Local Override Path for App ID 782330, Controller 0: /home/maxime/.local/share/Steam//controller_base/empty.vdf
Jun 09 11:45:26 GamingPC com.valvesoftware.Steam.desktop[9110]: Controller 0 mapping uses xinput : false
Jun 09 11:45:30 GamingPC com.valvesoftware.Steam.desktop[9110]: OnFocusWindowChanged to window type: k_nGameIDControllerConfigs_Desktop, AppID 413080
Jun 09 11:45:30 GamingPC com.valvesoftware.Steam.desktop[9110]: Controller 0 mapping uses xinput : false
Jun 09 11:45:30 GamingPC com.valvesoftware.Steam.desktop[9110]: Loaded Config for Local Override Path for App ID 413080, Controller 0: /home/maxime/.local/share/Steam//controller_base/empty.vdf
Jun 09 11:45:30 GamingPC com.valvesoftware.Steam.desktop[9110]: [413080]Non-Steam Controller Configs Enabled: 1
Jun 09 11:45:30 GamingPC com.valvesoftware.Steam.desktop[9110]: Controller 0 mapping uses xinput : false
Jun 09 11:45:38 GamingPC gnome-shell[3102]: Can't update stage views actor MetaWindowGroup is on because it needs an allocation.
Jun 09 11:45:38 GamingPC gnome-shell[3102]: Can't update stage views actor MetaWindowActorX11 is on because it needs an allocation.
Jun 09 11:45:38 GamingPC gnome-shell[3102]: Can't update stage views actor MetaSurfaceActorX11 is on because it needs an allocation.
Jun 09 11:46:09 GamingPC com.valvesoftware.Steam.desktop[13987]: pid 2697 != 2696, skipping destruction (fork without exec?)
Jun 09 11:46:17 GamingPC com.valvesoftware.Steam.desktop[9110]: Game removed: AppID 782330 "", ProcID 2762

Like I said, I just tried it with the extension enabled and disabled, and they both worked.

This looks relevant:

Jun 09 11:45:38 GamingPC gnome-shell[3102]: Can't update stage views actor MetaWindowGroup is on because it needs an allocation.
Jun 09 11:45:38 GamingPC gnome-shell[3102]: Can't update stage views actor MetaWindowActorX11 is on because it needs an allocation.
Jun 09 11:45:38 GamingPC gnome-shell[3102]: Can't update stage views actor MetaSurfaceActorX11 is on because it needs an allocation.
Jun 09 11:46:09 GamingPC com.valvesoftware.Steam.desktop[13987]: pid 2697 != 2696, skipping destruction (fork without exec?)

Which GPU and driver version and distro?

I have a GTX 1060 6GB running the 465.31 driver on Arch Linux. I'm not sure why it is working for you but there are multiple people with this issue who can't play the game without workarounds that harm performance.

Have you tried disabling one of your monitors? I wonder if having two monitors might mess with fullscreen unredirect.

That's super bizarre.

The only thing that even rings a bell is that Pascal doesn't support bindless UBO on an architectural level, which means that it can never run vkd3d-proton well and will always have horrible performance in vkd3d-proton titles, but Doom Eternal is native Vulkan, and if anything it would just cause poor performance (I would think), so that's not it.

I'll disable the other monitor and try real quick, and report back.

Yes I am well aware of the abysmal performance in VKD3D and have even experienced it myself (although that didn't stop me from beating Death Stranding on VKD3D). However I don't think this is related to this issue at all as Doom 2016 and Red Dead Redemption 2 both Vulkan games run just fine on my PC.

So the multimonitor thing was it.

I disabled my second monitor, and now with the extension disabled I too get the black window (and not only that, but the game freezes, because MangoHud doesn't update and there's no audio). The second I enabled the extension, it worked, and with two monitors I can run the game regardless of whether it's enabled or disabled.

This is likely a GNOME or X11 bug, but we can report it to Nvidia too. But I'm guessing GNOME.

But there's an easy workaround, just enable the extension for now. Or maybe try and create a virtual display and see if that makes a difference.

So fullscreen unredirect doesn't work with two monitors. Additionally, while the extension does work it harms performance and breaks G-Sync so a fix would be the best solution. You might want to comment on this thread https://gitlab.gnome.org/GNOME/mutter/-/issues/1522 and see if you can get anything from gdb if you know how.

So fullscreen unredirect doesn't work with two monitors.

We could check that easily, if other games work then that's not it.

And yeah I know it's just a temporary workaround.

I'll check out that thread and see what I can do.

I have had other games that freeze at the start too but work fine in borderless windowed mode which bypasses fullscreen unredirect (Doom Eternal borderless windowed mode works differently and doesn't bypass fullscreen unredirect). I'm 99% sure it has something to do with fullscreen unredirect because disabling it solves the freezing.

I have had other games that freeze at the start too but work fine in borderless windowed mode which bypasses fullscreen unredirect (Doom Eternal borderless windowed mode works differently and doesn't bypass fullscreen unredirect). I'm 99% sure it has something to do with fullscreen unredirect because disabling it solves the freezing.

So, it's not fullscreen unredirect. At least it's not only fullscreen unredirect.

I just disabled the second monitor again, and ran 4 games. A native Vulkan game (SoTTR), A native OpenGL game (Dying Light), a NON-STEAM Windows game using DXVK (Star Wars Jedi Fallen Order, Origin version), and a non-Steam DX12 game using vkd3d-proton (Control, Epic Games Store version). All 4 worked fine with fullscreen unredirect enabled and only one monitor.

Yes I know this. Some games work fine but others freeze when unredirecting. It's on a case by case basis but it definitely has something to do with fullscreen unredirect.

I've found another workaround for GNOME + Nvidia, and I may have more informations regarding the source of the bug.

I compile mutter with a change here from :
return window->override_redirect;
to
return TRUE;

With this patch Doom Eternal works just fine, and there is no more performance penalty (and in my case, I can finally use G-SYNC).

I believe the bug is caused because Mutter/Gnome doesn't immediatly unredirect the Doom Window, I read that it use some kind of heuristic to determine which window should be unredirected, but it's not applied immediatly. Doom Eternal (at least) window apparently doesn't like being redirected then unredirected. The patch force the unredirection since the beginning.

Warning: I'm 99% sure this patch will break other things so you may not want to apply it. In my case I just don't really care because I didn't yet see any of my other applications to crash.

Please post this on the mutter gitlab issue!

Done

Replying to https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-858860707

This sounds extremely promising. Does it survive an alt tab and back?

It does if the game is on (full-screen) borderless window mode. If it's on plain full-screen mode it doesn't, I was already observing this behaviour when using the extension, so no change there.

Not sure what's happening here, is this a known issue?
I don't have this artifacts in other games (Proton or Native).

OS: Manjaro 21.1.0 Pahvo
Kernel: x86_64 Linux 5.13.1-3-MANJARO
Uptime: 3h 34m
Packages: 1262
Shell: bash 5.1.8
Resolution: 1920x1080
DE: KDE 5.84.0 / Plasma 5.22.3
WM: KWin
GTK Theme: Breath [GTK2/3]
Icon Theme: breeze-dark
Disk: 2.1T / 5.9T (37%)
CPU: AMD Ryzen 3 3100 4-Core @ 8x 3.6GHz
GPU: Radeon RX 5500 XT (NAVI14, DRM 3.41.0, 5.13.1-3-MANJARO, LLVM 12.0.0)
RAM: 5925MiB / 15925MiB

I was using earlier this week KDE Neon (Ubuntu based) and was having the exact same issue.
Tried verifying game's files and deleting the game's shader cache folder.
Also tried changing some graphics settings (Low to High, Windowed, Fullscreen)

Any help?
Thanks

The detail I was interested in double checking was if the game was using the video driver you expected, but that's completely obvious in the screenshot.

Ah yes sorry for not including the mesa version, but yes it's 21.1.4.
On KDE Neon I was using mesa drivers PPA and had version 21.3 installed, but having the same issue.

Not sure what's happening here, is this a known issue?
I don't have this artifacts in other games (Proton or Native).

Make sure you're using RADV and not AMDVLK

@shigutso I know you're using AMD, but I can tell you that on NVidia, I've seen this happen in some games when I used the NVidia Control Panel to force AA or AF on.

Other things I tried:
RADV_PERFTEST=aco = same issue
RADV_PERFTEST=llvm = game doesn't open anymore (doesn't crash either, I have to click Stop from the Steam client)
Proton GE = same issue
Proton Experimental = same issue
Proton 5.13 = same issue
Proton 5.10 = same issue
Disable Steam overlay = same issue

And then... I just locked myself out for 24h due to Denuvo thinking every Proton version is a new Windows install.
Wrill try again tomorrow...

@shigutso I know you're using AMD, but I can tell you that on NVidia, I've seen this happen in some games when I used the NVidia Control Panel to force AA or AF on.

I don't know where I can change this in amdgpu drivers, and this game doesn't seem to have AA options.

Reinstalled the game (and made sure all related folders were deleted) = same issue
Tested different kernels (currently using 5.13):
Kernel 5.10 = same issue
Kernel 5.4 = same issue

Ok... just giving a last update.
I was able to find a workaround for my glitchy artifacts issue.
First, disable the option "Present From Compute". This may be already enough. If not, start changing resolutions until you find one that doesn't have the glitch particles. In my case, the highest I could go was 1600x900 (my monitor is 1920x1080). I can't play windowed, otherwise the glitch comes back. Also, alt-tabbing leaves the game on a black screen, but that might be another or known issue.

Not sure if it's a driver issue, shaders, KDE, GPU, monitor, or a combination of everything.
Hopefully this helps someone else.

@shigutso This is interesting. For your present from compute issue, could you try upgrading to mesa 21.1.5 and mesa-git to see if it was fixed? If it's still broken that sounds worth reporting directly to mesa (https://gitlab.freedesktop.org/mesa/mesa/)

The black screen issue sounds the same as the one Nvidia just worked around. It's a problem on id Software's side, maybe you could try a similar workaround such as disabling KDE's compositor before launching the game.

The nVidia 470.57.02 driver release notes includes "Added a workaround for DOOM Eternal, which avoids an application bug where Vulkan swapchain recreation events are not properly handled. On desktops like GNOME where the window is initially redirected to the compositor, this may prevent the game from flipping (and thus enabling G-SYNC)."

Have you tried it yet?

I'm still getting a crash to desktop at the "connecting to Bethesda.net" screen, before the main menu, when using Proton Experimental, Proton 6.3-5 or Proton-6.12-GE-1. Only Proton 6.1-GE-2 gets me into the main menu. RTX 2080 with 470.57.02 drivers.
Has anyone else encountered this issue?
steam-782330.log.zip

The nVidia 470.57.02 driver release notes includes "Added a workaround for DOOM Eternal, which avoids an application bug where Vulkan swapchain recreation events are not properly handled. On desktops like GNOME where the window is initially redirected to the compositor, this may prevent the game from flipping (and thus enabling G-SYNC)."

Have you tried it yet?

I have installed the newest nvidia driver and doom eternal now plays on ubuntu 20.10 with Gnome 3.8

My game is now working with the 470 driver but it is crashing at connecting to Bethesda.net.

My game is now working with the 470 driver but it is crashing at connecting to Bethesda.net.

Have you tried Proton 6.1-GE-2? It gets me past the "connecting..." error.
However DLSS doesn't work and if I try to load a level with ray tracing on and settings above low, it crashes with a video memory allocation error. Also changing settings sometimes causes the framerate to tank into the 20s for no reason.

Game causes a full system lockup with Renoir 4700U APU; built-in laptop display and external connected display turns off completely. The system is completely unresponsive and I have to restart to get back to my PC. Tested with 6.3-5 and Proton Experimental.

System specs:

• Arch Linux w/ KDE Plasma
• AMD Ryzen 4700U with Renoir GPU
• Kernal 5.13.4, but it happened on the latest 5.12 kernel I upgraded from recently
• Mesa 21.1.5
• 16GB RAM

Someone on ProtonDB mentioned it's a "kernel null pointer dereference", calling out amdgpu bo_move and ttm_copy_mem_to_mem. Not sure if it's of any help. They also mention that the game works fine on Windows and indeed I've seen people run this game on Windows on the same hardware. Likely an edge case for running this game with Proton though.

System Information gist.

I'd be happy to report this elsewhere too, it seems like these particular errors around bo_move and ttm_copy_mem_to_mem were mentioned in closed ticket on the AMD DRM issue tracker. It seems to relate to a different case. Perhaps it would be worthwhile opening a ticket there detailing the hang.

My game is now working with the 470 driver but it is crashing at connecting to Bethesda.net.

Have you tried Proton 6.1-GE-2? It gets me past the "connecting..." error.
However DLSS doesn't work and if I try to load a level with ray tracing on and settings above low, it crashes with a video memory allocation error. Also changing settings sometimes causes the framerate to tank into the 20s for no reason.

Just block api.bethesda.net and the game works fine. No more crashes.

@jalabb are you using flatpak steam?

@jalabb are you using flatpak steam?

No.
Thanks for the tip about blocking the API, I'll try it tomorrow and report back.

What about pipewire? I see pipewire errors in my journal when running Doom Eternal but sound still works so not sure if they are related.

Here is my log: steam-782330.log
There doesn't seem to be a lot of useful information in it though. It crashes on "connecting to Bethesda.net" pretty much every time.

@jalabb are you using flatpak steam?

No.
Thanks for the tip about blocking the API, I'll try it tomorrow and report back.

@jalabb Don't bother it doesn't seem to have changed anything. Sometimes it works but most of the time it crashes.

@jalabb Steam offline mode works but you can't access your friend list if you do that... and features in the game are disabled...

@jalabb Steam offline mode works but you can't access your friend list if you do that... and features in the game are disabled...

That doesn't work for me either, instead of crashing at "connecting" it crashes at "failed to connect" :/
I'll just keep using Proton-6.1-GE-2 for now

Hey all, picked up the game for the first time in a few months and suddenly am facing absolutely abysmal performance on UN settings. The game used to almost never drop below 70 in this area. I've tried multiple versions of Proton, both mesa and mesa-tkg, and have verified radv is in use. Changing the resolution does absolutely nothing and setting quality to low gives a very low increase in framerate.

CPU: AMD Ryzen 5 2600 @ 3.6 GHz
GPU: XFX Radeon RX 580 8 GB
RAM: 32 GB DDR4
Distro: Arch Linux
Kernel: 5.13.8.zen1-1

System Information Gist.
steam-782330.log.tar.gz

I had a lot of problems, like black screen startup and lower than expected FPS, using a GTX 770.
Switching to a 2060 super seemed to have solved all issues.

So I see that you guys are having the same issue, uhhh have we found out why it doesnt work after alt-tabbing out?

@MilkJug1 This happens with a lot of games, the workaround that I use is to set wine to show the virtual desktop. So far it works with every game that has this issue.

Do you know how to set the game to use wine's virtual desktop?

Thanks for responding to me @indeedwatson I know how to show the virtual desktop in wine, but not with proton. Is there a way we can do it on proton?

Try protontricks, might help.

ah okay, I will have to check it out when I get back on my pc. Thanks @pztrn

I am having issues with colored static all over the screen in the menu and in game (see screenshot below). This is on Fedora 34 with AMD RX 5500 XT. It sounds similar to what @shigutso described above, except for me, disabling "Present from Compute" clears up the display but immediately freezes up the menu, and causes the game to hang before displaying the menu after a restart until the r_presentFromAsync option is removed from the config file.

I also made a bug report under Mesa: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5265

Follow-up from the above: it appears that RADV_DEBUG=nodisplaydcc as a launch option fixes the issue. This seems to only affect Navi 14 (RX 5500/5500 XT) cards .

Doom Eternal is crashing every time when launched at second time. Video mode (fullscreen, windowed, windowed borderless) and other video settings does not matter. GPU: RTX 2060 Super., Linux: Mint 20.2:

At first launch it is possible to configure video settings as desired on native monitor resolution and nothing noticeably weird happens in game. Even ray tracing works.

At second launch game crashes after logging into Bethesda. Continuing game progress further is possible only after removing saved game configuration files under game Steam/Proton pfx user directory. Eq. game must be configured again at each launch.

On every launch game ask for Nvidia driver update to 471.11 or above. Which is not possible directly because Ubuntu/Mint repositories contain only 470.57 driver. Though I believe it is not the real reason why crashes happen.

System Information

• GPU: RTX 2070
• Driver/LLVM version: Nvidia 470.63.01
• Kernel version: 5.4.0-81-generic
• Link to full system information report as Gist: https://gist.github.com/Johnnii360/e970bbf3e0930af31e21272c408966ba
• Proton version: 6.16-GE1

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.

steam-782330.log

Symptoms

When I want to continue an campaign the game crash with a video memory allocation error.

Continue an campaign in Ultra settings runs without any issue because ~6,5GB of 8GB can be allocated but Nightmare settings with ~7,4GB not. But when I change in game while playing from Ultra to Nightmare there is no issue. Strange!

Game Graphic Settings

• Resolution: 1920x1080px @ 144Hz
• Vsync: Off
• Async Compute: Off
• Raytracing: On
• DLSS: Off because it's greyed out for no reason
• Motion blur: High
• Render Mode: Off
• Quality Settings: Nightmare

Edit

Okay I think I found a workaround. I think the issue in this case or in case of all RTX with 6 and 8GB VRAM is the Texture Pool Size. To set it to Ultra fixed it for me so I can also play in Ultra Nightmare. :) Ray Tracing alone need 1,3GB of VRAM. So if you you the same Texture Pool Size level like all other detail settings the game crash and brings the video memory allocation error.

Description: The Texture Pool Size guarantees max. surface details in fast scene changes or fast movements.

DLSS: Off because it's greyed out for no reason

You have to enable DLSS with an environment variable in the launch options in Steam.

PROTON_ENABLE_NVAPI=1

set Texture Pool Size to Ultra

Thank you that did it for me! RTX 2080, Ultra Nightmare except Texture Pool Size on High.

PROTON_ENABLE_NVAPI=1

That doesn't do anything but maybe because I'm using Proton-6.1-GE-2? Anything newer and I still get a crash on the "Connecting to Bethesda.net" screen.

Got a new machine and this was the first thing I tried, but alas it doesn't work at all. Getting past connecting to bethesda.net is a dice roll and it'll still crash after that with a video memory allocation error. I've gotten in game only once and had rtx and dlss working and it ran beautifully.
I've already got other proton games running and all, Doom 2016 is flawless for example.
I've tried 6.3-6, experimental (mostly this), and 6.16-GE-1, all with the same results. I was originally on the 470.63.01 (shipped with mint 20.2) before installing the vulkan beta 470.62.02, the only difference being that the vulkan beta made dlss work.
Of course the game complains that I need 471.11 before each launch, but it doesn't look like such a version is available for linux yet.

Also, the game floods dmesg with thousands of "x86/split lock detection: #AC: DOOMEternalx64v/178871 took a split_lock trap at address: 0x14bf355cd" with various addresses, and an occasional message of how many split_lock commands it has suppressed.

Proton_Log: steam-782330.log
System Info: sysInfo.txt

Of course the game complains that I need 471.11 before each launch, but it doesn't look like such a version is available for linux yet.

Ignore that message. It's showed that message since the game released.

Also, please upload your system info and logs to (separate) gists rather than a zip file that people have to download.

Shooting in the dark here, but is anyone able to get Doom Eternal (Bethesda Launcher version) to launch at all via Lutris/Wine? Ever since update 6.4, it just all of a sudden quit working, no matter what settings I throw at it. I get the out of date driver error, click Play and no dice, no logs, nothing. Any help?

OS: Manjaro Linux
WM: Gnome
GPU: NVIDIA 2060
Lutris and Latest GE Wine Runner

It seems like it causes a full system lockup when running it on a ryzen 4th gen mobile iGPU (Ryzen 5 4500U/Vega 6 in my case). There was a report on protondb reporting a null-pointer dereference error in the kernel logs.

OS: Arch Linux
WM: AwesomeWM
GPU: Vega 6
CPU: Ryzen 5 4500U

So is anyone at all able to play Battlemode? Seems like that might be something that should be worked out before the launch of the Steam Deck. I know it worked about a year ago, but as far as I know it hasn't worked for like 10 months.

When trying to create a party, it just sits there for a few minutes and then errors out with "Unknown Error occured. Please try again later."

steam-782330.log shows some related messages:

29527.675:0114:0150:warn:debugstr:OutputDebugStringA "WARNING: NET: PartyManager::JoinNetwork: Retrying to create local endpoint in 10.00 s\n"
29527.675:0114:0150:trace:seh:dispatch_exception code=40010006 flags=0 addr=000000007B01235E ip=000000007B01235E tid=0150
29527.675:0114:0150:warn:seh:dispatch_exception "WARNING: NET: PartyManager::JoinNetwork: Retrying to create local endpoint in 10.00 s\n"

Those will show up several times, and then finally this:

29583.358:0114:0148:warn:debugstr:OutputDebugStringA "WARNING: NET: PartyManager::JoinNetwork: Time out trying to create local endpoint\n"
29583.358:0114:0148:trace:seh:dispatch_exception code=40010006 flags=0 addr=000000007B01235E ip=000000007B01235E tid=0148
29583.358:0114:0148:warn:seh:dispatch_exception "WARNING: NET: PartyManager::JoinNetwork: Time out trying to create local endpoint\n"

steam-782330.log.tar.gz

Battlemode worked early on, not sure what changed. However, I think the underlying issue is already known.

https://github.com/ValveSoftware/Proton/issues/4961#issuecomment-878339630

So is anyone at all able to play Battlemode? Seems like that might be something that should be worked out before the launch of the Steam Deck. I know it worked about a year ago, but as far as I know it hasn't worked for like 10 months.

One hack I picked up from someone on ProtonDB, is to replace PartyWin.dll with PartyWin7.dll - both files reside in DOOMEternal directory.
I have successfully played about 15-20 matches this way... while the game still wanted to run...

As for me - I keep running into "opens wine tray, closes without error after 4 seconds".
It would work fine on fresh reboot. If I'd put my laptop to sleep, it'd stop working, but restarting X or the machine, would make it work.
Right now, no tricks are getting it up & running. I've searched through this thread and the "initial month of feedback", but while I've noticed many people having the tray issue - it seemed to be resolved with vulcan-icd-loader version and newer proton versions.

I tested with both newest Arch kernel, and LTS version (5.10) - no dice.

Any tips?

Thanks @machinedgod! I haven't played DOOM Eternal in a bit, but I just tried out replacing PartyWin.dll with PartyWin7.dll and it seems to work!

With the recent update I gave it another shot, now on 495.44 stable driver. The only differences being that bethesda.net no longer gives me an issue (yay), and the "Failed to allocate video memory." crash happens a LOT easier now: launching campaign, changing window/fullscreen, or frequently immediately at startup. Still guaranteed to crash for me before getting into the actual game.

Edit: After a couple dozen failed attempts I finally got it working right after opening my big mouth. If I turn off ray tracing it seems stable though I didn't play but a few minutes. It did get into the campaign multiple times. So if ray tracing is on when the game launches it may or may not crash, if it's still on when I try to load a save it will crash. If it's off I can load a save and turn it back on again.

Edit 2: Disabled resizable BAR in my bios, and it seems to be working.
Edit 3: Worked great at first, but from super gore nest on, ray tracing started crashing with vram allocation errors again.

For some reason Proton Experimental is having a very bad performance compared with Proton 6.3-7 .

Internal performance metrics show that the game is bottlenecked by the CPU, no matter the graphics options I set, but in reality the actual CPU usage of all cores is about 25%.

I have an overclocked 3770k and a 2060 super, Proton stable would normally make more than 100FPS but Proton Experimental will make less than 72FPS (dipping into the 40s).

It's almost as if the game didn't see the correct core count.

I'm on an Ubuntu 20.04 and drivers 470.82.00

@sancheztavo hi, are you using kernel with futex2 patches by any chance?

New version of the kernel patchset recently got accepted upstream and the support for the downstream version was dropped from Experimental. This may cause Experimental to default to wine server sync on such kernels, which would explain the slowdown you are seeing.

Can you enable logging for the game and look for fsync: up and running., esync: up and running. or wineserver: using server-side synchronization. near the top of the log?

@ivyl Sorry I forgot to mention that I was using kernel 5.14.0-17.1-liquorix-amd64

I checked at the logs and I only saw fsync: up and running.

Edit: I've also tried the official Ubuntu 20.04 kernel 5.4.0-90-generic and performance shows the exact same behavior, even when the logs show esync: up and running. this time

Sorry I forgot to mention that I was using kernel 5.14.0-17.1-liquorix-amd64

As far as I am aware liquorix ~= linux-zen, so it should have the fsync patches and you seeing fsync: up and running. confirms that.

What's odd is that you should see this line only with one of the Protons depending on which version of the kernel patches it is using (old downstream futex2 vs the upstreamed futex_waitv()).

I've also tried the official Ubuntu 20.04 kernel 5.4.0-90-generic and performance shows the exact same behavior, even when the logs show esync: up and running. this time

Ok, that's good to know. I don't have exact same setup but I've tried with RTX 3060, i5-4690k and esync only on Linux 5.10.78 with Nvidia drivers 495.44 and I don't see any difference between 6.3-7 and current experimental. @alasky17 also did not see any performance difference.

Can you run sudo perf top while the game is running? Preferably you should start it over SSH while you are already in the game in a place that has the noticable FPS difference. You may need to compile a newer version than your distribution ships (https://github.com/torvalds/linux/tree/master/tools/perf) for PE symbol parsing. There may be something that takes significantly more time on your particular system.

One other thing worth trying is echo hpet | sudo tee /sys/bus/clocksource/devices/clocksource0/current_clocksource and check if you see any difference after it.

@ivyl Well, while I was trying to screenshot a windowed instance of Doom and perf top output I found out that this slowdown only happens when Vsync is set to on the FPS would be 72 in the main menu, if it's set to anything else I'd get ~130 FPS.

Apart from this, I have GSync enabled in a 1440p 144Hz monitor that supports FreeSync and this drop to 72 FPS only occurs when setting it to 1440p (when I can't hit 144Hz if Vsync is not on)

It seems that with Proton Experimental VSync on really forces true VSync, so since it can't achieve to 144FPS it falls back to 144FPS / 2 = 72FPS . This behavior might even be a "feature", given that this game actually has the adaptive option. But I don't know if this can affect other games where it's either on or off, I'll test others in my library.

Edit: This doesn't happen with DXVK games (I tried Witcher 3 and Cyberpunk 2077), I'm redownloading RDR2 since that one is the only other Vulkan game I have, but I won't be able to test it until tomorrow

Does anyone have a fix for the Failed to allocate video memory error for the latest Nvidia 495.44 drivers, other than downgrading to 470?

I understand this is not a Proton issue, but since it's a common issue now for those running the game with Proton, I guess it won't be a bad thing to ask here.

Does anyone have a fix for the Failed to allocate video memory error for the latest Nvidia 495.44 drivers, other than downgrading to 470?

I understand this is not a Proton issue, but since it's a common issue now for those running the game with Proton, I guess it won't be a bad thing to ask here.

I can't reproduce this. Using 495.44:

What Proton version are you using?

EDIT: You say it's a common issue but I've not seen it reported anywhere. What makes you say it's common?

@gardotd426 a lot of recent reports on Proton DB's page are about this error from those using Nvidia, so thought it's quite common. I'm using Proton GE 6.20 (but the same is for 'native' Proton).

My full related specs:

• Ubuntu 21.10
• GNOME 3.40 on Xorg
• GeForce GTX 1650 Ti Mobile with 495.44 drivers

On Ubuntu 21.04 with 470 drivers, everything was running perfectly.

On the internet, it's advised to lower some graphical settings if you face this error but I have no idea how to do it since I even cannot load to the settings phase, it throws right after the Bethesda logo.

UPD: Now I see some reports from those using pre-495 drivers, so it may be due to the latest Doom (patch?) update that broke the game for some (including me). The 6.66 update itself was working good though.

@gardotd426 a lot of recent reports on Proton DB's page are about this error from those using Nvidia, so thought it's quite common. I'm using Proton GE 6.20 (but the same is for 'native' Proton).

UPD: Now I see some reports from those using pre-495 drivers, so it may be due to the latest Doom (patch?) update that broke the game for some (including me). The 6.66 update itself was working good though.

Latest update? Hm, I just launched it, still can't reproduce.

@liam-middlebrook I suppose you'd be the person to contact about that?

Can confirm downgrading to 470 Nvidia drivers helped, the game now starts without issues.

I can confirm the Failed to allocate video memory error with the latest nvidia driver.

Arch with 5.15.2 kernel
i7 4710 HQ
16Go RAM
Nvidia GTX 970m, 3Go vram, with latest 495.44 drivers

I was able to play the game with the 6.66 update version, then updated my drivers from 470.74 to 495.44, and now I have the error.
I tried some proton versions: 6.21-GE-1, experimental, 6.3-7

Here are the proton logs: https://pastebin.com/DDXgAUDv
According to the logs, the game is trying to allocate more video memory than available.
If I close Firefox, the game can load 1 more chunk but I still get the allocation error.

I have no options related to the video memory size in the config file steam/steamapps/compatdata/782330/pfx/drive_c/users/steamuser/Saved Games/id Software/DOOMEternal/base/DOOMEternalConfig.local
But looks like it only store the modified values.

I tried to take a look at the console commands found on the internet, no video memory related commands:
https://pastebin.com/Vga4B4NA
https://pastebin.com/cgqQfvLr
https://pastebin.com/trb8JPBw

Does anyone knows how to limit the vram allocation ?
Is there an option on the game menu ? (which I can not see because the game crashes at launch time...)

This might actually be a problem on Windows too. When you launch the game with 495, unless you specify a reported driver version with DXVK_NVAPI_DRIVER_VERSION, then it throws a warning window saying that there are issues on drivers later than 470.whateverversionwindows had, and that a fix was being worked on.

Since the game is native Vulkan, it's obviously not a DXVK or VKD3D-Proton error, and it might not even be a Wine error.

@nmenetrier I tried to modify DOOMEternalConfig.local with different configs found on the internet (and in related game topics saying these configs will fix the error), but so far the only thing that helped is downgrading to 470.

The game just updated. Battlemode no longer works, even with replacing the PartyWin.dll with PartyWin7.dll. So RIP Battlemode on Linux. Maybe Valve can talk with id and see what's up.

I still can't reproduce this VRAM issue. I thought maybe it was because I have a 3090 and 24GB of VRAM, but I checked and the game doesn't even try to allocate more than like 4GB of VRAM at the splash screen, and that's at 1440p. So anyone with more than 5GB of VRAM shouldn't be running into this issue (the DE usually takes up about 1GB).

Can anyone check and see if it persists with the game update that hit this morning?

Can anyone check and see if it persists with the game update that hit this morning?

Yup, still run into it on my 4GB 1650 Super.

I still can't reproduce this VRAM issue. I thought maybe it was because I have a 3090 and 24GB of VRAM, but I checked and the game doesn't even try to allocate more than like 4GB of VRAM at the splash screen, and that's at 1440p. So anyone with more than 5GB of VRAM shouldn't be running into this issue (the DE usually takes up about 1GB).

Looks like it. Some people on Windows have the same issue with 4GB cards (link).

Seems Battlemode is back online. Was just able to play. Requires replacing PartyWin.dll with PartyWin7.dll again.

@sancheztavo With the extra details you have provided (vsync, gsync) I was able to reproduce the problem locally and fix it.

https://github.com/ValveSoftware/wine/commit/3c78d21cee10312d63806594c7ecde4c2b000830

This should be included in the next experimental update. Thanks for the report!

For anyone who is experiencing the game crashing.

If you set the Texture Pool to Ultra, does it fix the problem?

If I use anything other than Ultra it get the below message.

This is with Ray Tracing enabled with a RTX 3060ti using Ubuntu 21.10 with the 495 drivers.

In contrast, the same happens on Windows, except it does not crash, just drops the FPS to 30.

@intelligentgaming this works if you're able to load the game, but for those having 4 GB of VRAM or less, the game won't even start. Thus, the only viable option so far is to downgrade the drivers.

Hi all,

I've been doing some digging on the "Failed to allocate video memory" issue, since I didn't see any answers and I've been going through that myself. Yesterday, I had a thought: maybe we need to take the error message at face value and look at video memory utilization!

I ran nvidia-smiand found that other processes were using a sizable chunk of video memory, around 500-600MB in total. So in my case, when Doom Eternal tried to reserve the 7.3GB it needed to run, the GPU really didn't have available memory for it. I think that also explains why people could get the game to run after a few tries: as video memory usage by other programs went up and down, eventually the game will be able to reserve all the memory it needs.

Here's some of the things I tried (or I want to try):

• Close other programs that are using big chunks of video memory
• Disable hardware acceleration on processes you need to stay open - in my case, Steam and Firefox were eating up memory
• Switch to a lighter desktop environment - I've compared Gnome3 versus LXQt and it frees up a bunch of memory
• Lower the game's texture and shadow quality
• Get a GPU with more memory (if you're rich or lucky)

Tested on Pop!_OS 21.04, on a laptop with an RTX 2080 Super (7,982MB). No idea what the equivalent command is on AMD systems.

@intelligentgaming tracked down the root cause - it's texture pool size. If you are able to get in game (or edit it in a config file, not sure if texture pool is exposed in any .ini or anything), lower the texture pool size and you should be fine.

If you only have 4GB of VRAM, though, there probably isn't much that can be done.

Nice, I missed that message when looking around. I'm still pretty confident on my own findings though, the game's been running with no issues after I cut down on video memory usage from other programs. I guess somebody who's on the verge of getting it running could do both.

Unfortunately I spoke too soon, as I'm having crashes again on the 495 drivers.

Only using the 470 drivers and texture pool to set to ultra seems to allows a playable experience.

I have a laptop with an AMD iGPU and Nvidia dGPU that has 6GB of VRAM but Doom Eternal still can't assign more than 5300 MB. I don't think the issue is regards other applications running because without Doom Eternal running the VRAM usage on the dGPU is just 11 MB.

Also for people that get the "Failed to allocate video memory" and can't get into the game to reduce the VRAM usage add the -safe flag after %command% and it should set it the game quality low enough to launch the game so you can edit the settings.

Also for people that get the "Failed to allocate video memory" and can't get into the game to reduce the VRAM usage add the -safe flag after %command% and it should set it the game quality low enough to launch the game so you can edit the settings.

Thanks for the tips, sadly, it didn't fix the issue with my 3 GB GPU.

I haven't been able to play since Ubuntu 21.04 :(
AMD Ryzen 3 2200g, just launches into a black screen and either freezes my entire system requiring a reboot or just gets stuck at black screen and process refuses to terminate even with root priveleges

@yupyup0666 Well you don't even remotely meet the minimum requirements for the game (neither in VRAM size or GPU power). When you don't meet a game's minimum requirements, you should basically expect it not to work.

Your only other option would be to try amdvlk, but it's important to note that when you install AMDVLK it makes itself the default and so you'd have to put VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_i686.json:/usr/share/vulkan/icd.d/radeon_x86_64.json in your /etc/environment.

But for a long time, like a year after launch, vulkan-amdgpu-pro outperformed RADV in Doom Eternal by like literally almost double, and AMDVLK outperformed it by like 60%. RADV eventually mostly caught up, but it's still worth a shot since you don't even meet the minimum requirements.

Replying to https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-1001226928

But it did work, and quite well, and it turns out this was due to an update that broke compat specifically with Ryzen iGPUs.

@yupyup0666
I am not quite sure which kernel is Ubuntu 21 running. I had no luck running DoomEternal with 5.14 versions at all - but 5.10 seemed to work well.
There is/was an odd behaviour where I could not relaunch the game after I suspended and then awoke my machine -which was reproducible- but a full reset would work without issues.

If you can install 5.10 LTS kernel somehow and boot with it - its worth a shot I suppose?

My laptop is a Dell XPS 15 (9500) with a NVIDIA GTX 1650Ti GPU (4GB VRAM).
The game "failed to allocate video memory" with 495 driver series, but I confirm downgrading to 470 fixes it.

Yes, this is a confirmed issue, it's to do with texture pool size. If you have enough VRAM, you don't get the issue. For example, I have an RTX 3090 and I can play Doom Eternal just fine on the 495 drivers, I've never seen the "failed to allocate video memory" error one time. But I have 24GB of VRAM. But what's weird, is at 1440p when I launch the game it only allocates 6GB of VRAM, but people with 8GB are reporting the issue. 12GB GPUs with their texture pool size set to High or lower can play on 495.

If you have 8, 10, or 12GB of VRAM, you can probably launch the game with 470, change your texture pool size to low, then upgrade to 495 and the game will likely launch and work.

This was an issue on Windows as well, but they fixed it with a driver update. We haven't had a 495 driver update since long before then, so hopefully the next update will address the issue (@liam-middlebrook ?)

FWIW, it still doesn't work when you (like me) have e.g. GeForce GTX 1650 Ti Mobile with 4 GB memory onboard. I've set texture pool size to low, upgraded to 495, and getting the same error (but now on loading screen instead of the very beginning):

This needs to be reported en masse to Nvidia or it won't get fixed. They released a driver fix for Windows for this issue and the issue is gone (on Windows). Since the game uses Vulkan (and AFAIU the Linux drivers actually share a lot of codebase with the Windows ones), the next 495 release should hopefully include a fix, but people have to actually report it.

Send logs and the output of sudo nvidia-bug-report.sh (it'll be a nvidia-bug-report.log.gz file in your user's home directory) and an explanation of the issue to [email protected], and also report it here at the Nvidia developer forums Linux section. I've seen bugs get fixed through both methods, and Nvidia accepts bug reports through both avenues.

also report it here at the Nvidia developer forums

I've done so: https://forums.developer.nvidia.com/t/doom-eternal-crashes-with-495-46-on-high-vram-usage/199961

I too have same problem on Kubuntu 21.10
I use GTX 1050 which has smaller VRAM size, but it used to work on 470 driver. It was already on lowest setting back then and now it crashes immediately I start up the game.
I hope this issue get patched soon, as I don't think I can downgrade to 470 anymore. I recently installed cuda on my pc and it installed 510 driver, which seems it's required by cuda

Still the same situation with driver 510.47.03.

I can't figure out how to switch to mesa/RADV, if I do pacman -R amdvlk I get a dependency error saying that steam needs it for vulkan-driver.

I can't figure out how to switch to mesa/RADV

https://wiki.archlinux.org/title/Vulkan#Selecting_Vulkan_driver

Basically AMD_VULKAN_ICD=RADV steam. You will also need to install vulkan-radeon.

Works fine with mesa, thank you.

Works fine with mesa, thank you.

You still need to get rid of amdvlk. It will force itself to be the Vulkan driver by default for every game where you don't specify RADV, and there's no reason to have it.

sudo pacman -S vulkan-radeon lib32-vulkan-radeon && sudo pacman -Rn $(pacman -Qq | grep amdvlk)

vulkan-radeon and lib32-vulkan-radeonalso providevulkan-driverso you will get no such error trying to remove the amdvlk drivers once you have bothvulkan-radeon` drivers.

Yeah I've removed amdvlk now, I'm also getting slightly better performance in games since uninstalling it which is cool.

Still the same situation with driver 510.47.03.

Still have the issue with 510.54 driver

The problem with NVIDIA GPUs related to low VRAM still happens in the latest version of the driver, 510.60.02.

This issue is still not fixed. Nvidia 510.60.02. Most of the time it crashes on the Bethesda screen. Sometimes gets past it but always crashes before getting to the main menu. Is there not a way to limit VRAM?

The game seems to be running again on Nvidia 515.43.04, i'm on a GTX1050 with 2GB of VRAM. I think the performance is not as good as it was with the 470 drivers, but i'm not sure.

515.43.04 has indeed improved the performance and allowed for a much larger VRAM usage. However, the game still tries to use too much VRAM if you go all-out in the settings and crashes on level-load (Failed to allocate video memory) without showing any VRAM-warnings in the settings menu.

That said, the game now runs fine on a 3070 with 8GB of VRAM with everything maxed out besides the texture pool (which should be kept at Ultra).

The game seems to be running again on Nvidia 515.43.04, i'm on a GTX1050 with 2GB of VRAM. I think the performance is not as good as it was with the 470 drivers, but i'm not sure.

I can confirm, it's working again with my 970m :)

Nice to know. I have a RTX 3060 laptop GPU and the problem happens to me. I will wait the driver to be officially available to Ubuntu to test that, but if worked with 2GB with my 6GB VRAM problably will work. :)

Yee-haw! The new driver works wonders! The game runs fine on my machine that crashed on start up before. No more popup window with that VRAM allocation failure message.
My machine has a 1650 in it. This graphics card does not support DLSS or have tensor cores built in, though it is built on the Turing architecture. DLSS is enabled by default. I don't know how that is possible. If anyone has any insight please share.

With NVIDIA 515 series driver, I'm able to go to the settings menu and select options that don't overuse my VRAM. I'm unable to use Ray Tracing, for instance, but that's because it consumes too much VRAM. I also need to put the graphics settings on medium to not consume all the VRAM, but before I even couldn't start the game. I have a NVIDIA Geforce RTX 3060 laptop GPU with 6GB of VRAM, which I found that's not a lot.

515.43.04 has indeed improved the performance and allowed for a much larger VRAM usage. However, the game still tries to use too much VRAM if you go all-out in the settings and crashes on level-load (Failed to allocate video memory) without showing any VRAM-warnings in the settings menu.

That said, the game now runs fine on a 3070 with 8GB of VRAM with everything maxed out besides the texture pool (which should be kept at Ultra).

I found the exactly same problem. The graphics settings menu has an indicator of how much VRAM do you have and how much VRAM will be used by the current settings, but I think it's not considering the VRAM necessary to load the levels assets, so I have 6GB, but I disabled Ray Tracing (who needs real lighting anyway?) and kept the graphics in medium (but maybe I could get high or even ultra. Didn't test enough).

If you have a 3060, you can use DLSS to lower the amount of VRAM used.
This, depending on the other settings, primarily the texture pool (can be
set all the way to lowest without much impact) and the shadow quality, may
decrease it enough to allow you to re-enable RayTracing, but you may need
to put it all the way down to ultra-performance. Is it worth it, though?
Tastes differ.

On Mon, Jun 6, 2022 at 10:14 PM Marcos Alano @.***>
wrote:

515.43.04 has indeed improved the performance and allowed for a much
larger VRAM usage. However, the game still tries to use too much VRAM if
you go all-out in the settings and crashes on level-load (Failed to
allocate video memory) without showing any VRAM-warnings in the settings
menu.

That said, the game now runs fine on a 3070 with 8GB of VRAM with
everything maxed out besides the texture pool (which should be kept at
Ultra).

I found the exactly same problem. The graphics settings menu has an
indicator of how much VRAM do you have and how much VRAM will be used by
the current settings, but I think it's not considering the VRAM necessary
to load the levels assets, so I have 6GB, but I disabled Ray Tracing (who
needs real lighting anyway?) and kept the graphics in medium (but maybe I
could get high or even ultra. Didn't test enough).

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

Surround sound does not work. Game plays in stereo.

Proton-experimental
Linux Mint 21, Kernel 5.17
Nvidia driver 515.65.01
Surround set-up: HDMI cable from GeForce 1080Ti to AVR.
Everything about my system, steam and the game is up-to-date

Full Steam system report
https://gist.github.com/mrmatteastwood/6590914dd0cf7d3fba6a31be4a3b396c

Proton Log:
steam-782330.log

This is the second one today. Tried Dishonored earlier and no surround there either. Both games seem to use wwise, so perhaps wwise and Proton aren't exactly on friendly terms?

Any workaround? Any fix for this? I was really looking forward to playing this game... :-/ Any help would be greatly appreciated.

Doom Eternal barely runs on a machine with a Ryzen 3800X CPU and a GeForce GTX 1050 Ti with 4 GB GDDR5. The distribution is Arch Linux. The Nvidia driver is 515.65.01 (installed from the official distribution packages). The GPU is running in PCI-E x16 v3.0. The Nvidia driver is the one in use, not nouveau. This was confirmed with nvidia-smi.

The graphics options are all set to low or off, the resolution was set to 960x540 with scaling to 50%. The game is barely able to reach 30 fps with these settings. Turning on the in-game performance overlay has revealed that this issue persists across a large range of resolutions. The frames need about 3-5 ms of processing on the CPU side. The GPU seems to not be able to stay under 16.6ms at any resolution. The GPU time is usually in the range ~16 ms and ~35-40ms. It goes to 60 FPS only when looking at some walls which are very close. The time taken by the game's code to run on the CPU is always almost the same. The GPU processing time is almost identical, regardless of the chosen resolution (960x540 @ 50% to 1920x1080 @ 100% scaling). This suggests that it's a GPU driver bug.

I've tried a few things to work around these performance issues:

• gamemode didn't make any difference
• various configuration options for fsync and esync
• linux-lts and nvidia-lts Arch packages, linux and nvidia Arch packages (the latter has better overall performance)
• closing the Steam UI to free up more VRAM didn't help

Other games don't have such problems. Even Elden Ring is playable at 1920x1080.

The Nvidia Linux drivers have very poor quality. Does anyone test these drivers? Do they have QA at all? To those who are looking to buy a GPU to play games on Linux, it's wise to stay away from Nvidia GPUs because of their extremely bad and closed source Linux drivers. Their new drivers still have the closed source blobs and the closed source user space component.

The game has now locked me out after attempting to change the Proton version in steam a few times (experimental, 7.0, latest GE). It states that I must wait 24 hours to be allowed to run the game. This seems to be the DENUVO DRM's fault. I wanted to find out if there's a regression in one of these proton versions.

Running the game on Steam Deck with SteamOS stable 3.3 is a better experience. The game runs at the configured desired frame rate with the medium settings. The game was closed unexpectedly, a shader update was installed and it happily said that it's ready to run again without explaining what happened.

The connection with the Zenimax servers was broken while playing the game. My game was interrupted. I had to confirm that I want it to reconnect. It failed a few times. It allowed me to resume the game after it was connected. This isn't a great experience on the Steam Deck, even though the performance was a lot better than with the Nvidia GPU on the other computer.

Tagging @ColdPie1, who was able to solve surround sound issues back in 2020 and mentioned over in the "No surround support?" thread he might be able to help. Are you still around?

Replying to https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-1214132268

For what it's worth, I have an i7-4790K and GTX 1080 Ti, 32 GB RAM, running from SSD. Getting perfect 60 FPS at all times @ 1440p and all graphics settings maxed out ("Ultra Nightmare").

Re0plying to https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-1213417973

So, I have no idea what happened or if it's something I did, but surround sound works now!

Since I last posted, I have deleted the Proton prefix and switched from Proton-GE (which I was using at first) to Proton Experimental. I am not hearing much from the center speaker, but at the beginning of the game, there's click-clacking of chains in the rears, for instance, and a bunch of other atmospheric sounds. Full 7.1 sound, too.

I can tell from the log that it crashes in vkCreateComputePipelines() (in host native Mesa code). Given this is Vulkan game this is likely between the game and Linux Vulkan driver (also maybe it misses something on Integrated Intel XE).

Just came to report the exact issue on Intel. Intel Arc A750 dGPU crashes on open during Bethesda logo. Tried Experimental and 7.0-4. Running on the latest mesa commit compiled as of a few days ago, Kernel 6.0.2.
steam-782330_7.0-4.log
steam-782330_experimental.log

Crashes on Intel are a driver bug: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6847

I am getting ~40fps average with all settings low, 1080p resolution, on an RTX 3080, with drivers 515 and 520. I am not maxing out VRAM usage on the card. The in-game performance meters show it's a problem with the GPU.