Open frozen-sea opened 8 months ago
For me it's crashing a lot when opening the game menu
Proton Experimental AMD 7800XT Mesa Git
For folks tinkering, please just be aware of the Denuvo anti-tamper. If you change Proton versions a few times it will lock you out of the game for 24 hours like the well-respected customer you are.
I remember re4 blocking rt if it detect it is running on wine, may be this is also true for dd2. and need to promote to dxr ultimate like the reset of the re engine game.
Also disable sam(system access memory) for vkd3d seem to improve performance when cpu bound, at least on main menu.https://github.com/HansKristian-Work/vkd3d-proton/issues/1406#issuecomment-2014752410
I remember re4 blocking rt if it detect it is running on wine, may be this is also true for dd2. and need to promote to dxr ultimate like the reset of the re engine game. Also disable sam(system access memory) for vkd3d seem to improve performance when cpu bound, at least on main menu.HansKristian-Work/vkd3d-proton#1406 (comment)
I did hidewineexports=enable
via Protontricks and added VKD3D_FEATURE_LEVEL=12_2 VKD3D_SHADER_MODEL=6_7
, but still no dice. Anything I'm missing?
Setting no_upload_hvv
looks to be a good call, that takes me from being stuck at 50% GPU usage and barely hitting 60 fps to peaking at 80% sometimes!
I remember re4 blocking rt if it detect it is running on wine, may be this is also true for dd2. and need to promote to dxr ultimate like the reset of the re engine game. Also disable sam(system access memory) for vkd3d seem to improve performance when cpu bound, at least on main menu.HansKristian-Work/vkd3d-proton#1406 (comment)
Tried the no_upload_hvv, with an 7800XT, also getting better GPU utilization and performance :D
For folks tinkering, please just be aware of the Denuvo anti-tamper. If you change Proton versions a few times it will lock you out of the game for 24 hours like the well-respected customer you are.
It locked me out without having to change versions much. I've only changed versions ONCE when experimental didn't work back to 8.
When accessing the options menu from the title screen or in-game, the cursor movement sound starts looping and it becomes impossible to exit the menu or change any options. It's not a total freeze, though, as the option categories can still be navigated. This happens on both Proton 9 and experimental.
GPU: AMD Radeon RX 7900 XTX Kernel version: 6.7.9 Link to full system information report as Gist: System Information, System Runtime Diagnostics
Log from launching the game, navigating to the options menu to trigger the bug, and closing the game using window controls: steam-2054970.zip
Replying to https://github.com/ValveSoftware/Proton/issues/7595#issuecomment-2016072761
I had the same problem fixed it by using amdvlk instead of radv.
Replying to https://github.com/ValveSoftware/Proton/issues/7595#issuecomment-2016252055
how did you go about launching with amdvlk instead of the default? I think I'm too stupid and tired after trying to get this working for 20+ hours using 5 accounts
EDIT: Figured out how to do it and yeah, this is the answer; AMDVLK get's it to work; average 60+ frames and no more crashes! "mangohud gamemoderun vk_amdvlk %command%"
Replying to https://github.com/ValveSoftware/Proton/issues/7595#issuecomment-2016301950
I had the same problem but the driver was the opposite of LordJakki, the default for me was amdvlk
, using radv
instead fixed the problem.
I used the AMD Vulkan Prefixes script from the Arch wiki. https://wiki.archlinux.org/title/Vulkan#Selecting_via_AMD_Vulkan_Prefixes
AMD_VULKAN_ICD=RADV
didn't seem to work.
Replying to https://github.com/ValveSoftware/Proton/issues/7595#issuecomment-2016301950
I have amd-vulkan-prefixes package installed from AUR. https://aur.archlinux.org/packages/amd-vulkan-prefixes/ This allows me to easily chose if I want to use RADV or AMDVLK. I only needed to add vk_amdvlk %command% as a launch option in a steam.
When accessing the options menu from the title screen or in-game, the cursor movement sound starts looping and it becomes impossible to exit the menu or change any options. It's not a total freeze, though, as the option categories can still be navigated. This happens on both Proton 9 and experimental.
I ran in to the same issue on Nvidia and was able to make it go away by disconnecting my HDMI capture card before starting the game.
So this is going to be a curveball because my report will be different from everyone else. Using an Intel Arc A770 and Proton Experimental (although I tried it with a couple of Proton versions and they all have the same issue), the shader precompilation step never completes. I will get roughly 60% of the way before crashing with this popup. Clicking cancel or ok makes no difference, they both close the program afterwards. It is also impossible to generate a Proton log because while it will compile the shaders as expected, it will get stuck instead of crashing generating the logs and I waited until the log bloated up to around 10GB before calling it quits because it just seemed too abnormal for a log file to grow that big if it was doing actual work. Looking at a portion of the file, the last line of useful work done was this line in precompiling a certain graphics shader pipeline before a backtrace gets generated.
Is this a Proton issue or as the crash implies, is Intel's Vulkan driver is at fault and I should file a Mesa bug report?
Not sure if this is the best place to report this, but I'm getting crashes from time to time:
Also had multiple crashes with what looks like the same message, usually when opening map or menu. Started turning everything but steam off, including 2nd display, ran with gamemode and RADV_PERFTEST=nosam VKD3D_CONFIG=no_upload_hvv
env variables, had 2 about 2 hours long crash-free sessions, so fingers crossed it's not coincidence/random stroke of luck.
Not sure if this is the best place to report this, but I'm getting crashes from time to time:
Also had multiple crashes with what looks like the same message, usually when opening map or menu. Started turning everything but steam off, including 2nd display, ran with gamemode and
RADV_PERFTEST=nosam VKD3D_CONFIG=no_upload_hvv
env variables, had 2 about 2 hours long crash-free sessions, so fingers crossed it's not coincidence/random stroke of luck.
Even with that, I get random freezes where I get kick to the GDM login screen
@alosarjos please add PROTON_LOG=1 %command%
to the launch parameters and upload the resulting steam-2054970.log (it will be in your home folder) after the game crashes, if the log is too big then compress as a .zip before uploading it. It would also be helpful to say how many crashes you've had and how long they have taken to occur.
@simifor Hope this helps:
I have had lots of crashes, nothing in particular triggers them, could be 5 minutes of gameplay or 20....
But some of those times happened to be when opening the menu (But other times I opened it and worked just fine)
EDIT: Another log, this ime loading the game, didn't even get into gameplay: steam-2054970.log
Replying to #7595 (comment)
I have amd-vulkan-prefixes package installed from AUR. https://aur.archlinux.org/packages/amd-vulkan-prefixes/ This allows me to easily chose if I want to use RADV or AMDVLK. I only needed to add vk_amdvlk %command% as a launch option in a steam.
Okay I made few more tests and it's kinda weird. If I don't use any launch options then options menu bugs out. If I use vk_amdvlk or vk_radv then everything works. What makes no sense to me is why vk_radv is working when it is just suppose to be same as if I don't specify any driver. I have set radv as a default driver to be used if not otherwise specified with AMD_VULKAN_ICD=RADV variable.
So, I never really had any issues launching the game, though certain proton versions cause it to crash on start up.
I can get 40-50fps in cities and 80-90fps in the countryside after starting the game, but every single time, after about 5-30 minutes the framerate will drop to 20-30fps and stay there no matter what area i'm in. Restarting the game fixes it but only for another 5-30 minutes.
I'm not really sure if this is a linux configuration issue or an issue with the game itself though.
Replying to https://github.com/ValveSoftware/Proton/issues/7595#issuecomment-2016561825
I experience the same thing. I am on an RTX 3060Ti with a Ryzen 5 3600, so for me that slowdown means going from just barely playable to completely useless.
Replying to https://github.com/ValveSoftware/Proton/issues/7595#issuecomment-2016563062
I'm starting to think that there's a memory leak that's causing it. How much memory does the game use on average for you? It typically uses around 12-13gb for me.
I've been trying all the various launch commands suggested on my RX6950XT in this thread, but never got the fps higher than 25. Kept trying to change Proton versions without getting locked out and had nvtop on the other monitor and only got 5% gpu utilization. What I found maddening was when I open the System menu I get 60 fps and the gpu jumps up to 11%. Under all the tests the CPU has been at 20% except for when compiling shaders, then almost all are at 100.
Is there any possible way to make the game use more of the GPU or is entirely on the application itself.
I've been trying all the various launch commands suggested on my RX6950XT in this thread, but never got the fps higher than 25. Kept trying to change Proton versions without getting locked out and had nvtop on the other monitor and only got 5% gpu utilization. What I found maddening was when I open the System menu I get 60 fps and the gpu jumps up to 11%. Under all the tests the CPU has been at 20% except for when compiling shaders, then almost all are at 100.
Is there any possible way to make the game use more of the GPU or is entirely on the application itself.
That's how the game works, and the complain everyone has. How much CPU bottlenecked it is
When people say crash are your games actually crashing or is your driver timing out?
I didnt have a single crash but amdgpu kept timing out. On the 1st day i had really good performance around 50-100fps with RADV_PERFTEST=nosam
command but then randomly it stopped doing anything and no matter what i did it never got past 20-50fps. At this point im on my 2nd 24h ban (i dont think its only the proton switching triggering it) and im refunding it and waiting for cracked version without denuvo or when they actually fix this because this is ridiculous. You literally cant troubleshoot anything because you just get banned.
Replying to https://github.com/ValveSoftware/Proton/issues/7595#issuecomment-2016489633
I have the same exact issue but I have an Nvidia 1070, which doesn't use Mesa. I think the problem is not Mesa related. I am on ArchLinux, stable kernel.
On the 1st day i had really good performance around 50-100fps with
RADV_PERFTEST=nosam
command but then randomly it stopped doing anything and no matter what i did it never got past 20-50fps. At this point im on my 2nd 24h ban
Same thing happened to me. I had the game running decently, changed literally nothing, and then it would never start up with good performance again. For some reason it also started resetting all options every startup and going through the initial options/EULA step every time when going to main menu, even when quitting from gameplay. I tried deleting the prefix, deleting shader cache, uninstalled and redownloaded the game, no change to either issue. Also on my 2nd ban by now.
Game has a weird behaviour where it seems to not utilize CPU completely. Straight from the main menu CPU usage is capped around 35%(pic 1) and doesn't change throughout gameplay. When it does launch "properly"(pic 2) both resource usage and performance is comparable to Windows.
Disabling SAM has no impact on this, and whether the game launches with a good CPU utilization is seemingly random. Here's proton logs for both launches on Proton 9 Beta. Proton 8.0-5 behaves the same, however I wasn't able to reproduce this on either Experimental or Bleeding Edge, where it seems to always get reduced CPU usage. Low cpu usage log: steam-2054970.log Expected cpu usage log: steam-2054970.log
And then there's also crashes as per comment above, although at least some of them are on game's side, since one of the common crashes on opening menu is widely reported on Windows as well. There's definitely some Linux crashes, but I guess that's better left for mesa folks.
EDIT: Thinking about it, not sure why I pegged it as a CPU usage issue, since it might also be the same deal but with GPU, and one just bottlenecks the other. But there's definitely something wrong in regard to resource usage.
Something about the very first time you run the game after a fresh install makes it run good and this can't be replicated neither by deleting the prefix nor the save data. Here are some findings that might be useful to someone.
On the first run the game does a long shader pre-compile which creates a file called shader.cache2 in the game directory. It looks like the game doesn't load it on subsequent runs, since deleting it will make the game pretend to do the pre-compile (much faster than the real one), but it either doesn't create the file at all or it's 24 MB instead of the real 2 GB. Performance with the fake cache is the same as subsequent launches with the real one.
You can make the game always do a real pre-compile by deleting the cache file and running with VKD3D_SHADER_CACHE_PATH=0, but you still get the bad performance.
So, what else does uninstalling the game through Steam remove that I might have missed? Because looking at the timestamps of the game files, they didn't get modified when I ran it the first time.
Replying to https://github.com/ValveSoftware/Proton/issues/7595#issuecomment-2016940237
Thanks for the idea. After reading everyone's trial and error, and other things externally like docs I managed to put my game from 15-25fps to 100+ fps (still pending to reach vernworth, I reset my game for tests).
This only works for AMD GPU, I am sorry NVIDIA. But I will also thanks NVIDIA for giving the same idea, Shaders were my problem. NVIDIA solution was (in windows) to put shader cache limit to infinite.
Here's what I did.
vk_amdvlk %command%
The important part is deleting the old shader and using amd vulkan prefixes. I tried the default way, my default drivers are RADV and the game wouldn't stop crashing, low performance and menu looping as some people said it happened. I did the AMD_VULKAN_ICD= and AMD_VULKAN_ICD=AMDVLK and nothing changed, but after trying to manually load the AMDVLK Vulkan drivers via ICD Path it finally worked after deleting the shaders (that took a LOT of time), no crash so far and very stable and high FPS.
It seems we have a problem with RADV Shaders and loading correctly Vulkan Drivers with this game in specific. Other games behave normally without the need to use amd vulkan prefix. On them AMD_VULKAN_ICD works nicely, I know because I tested.
Replying to https://github.com/ValveSoftware/Proton/issues/7595#issuecomment-2017119513
I initially launched the game without any launch options (so using AMDVLK by default I assume?) and had the options menu bug described above with the looping cursor noise.
Based on above suggestion I launched with vk_amdvlk
and that fixed the options problem and let me start the game. Worth noting it didn't rebuild the shader cache. However after closing the game, it would no longer get past the splash screens and got stuck on a black screen instead of the main menu. I've attached the log file from when this happened:
Edit: I wonder if following your instructions and rebuilding the shader cache after setting vk_amdvlk
would've got beyond the black screen issue.
I then switched to vk_radv
. It rebuilt the shader cache and launched fine and the options menu bug was gone. I was able to play till after the tutorial (with decent performance) but then stopped as it was crashing pretty frequently.
It seems to work with either driver (although AMDVLK not so well for me) but what seemed to matter more was whatever the amd-vulkan-prefixes
script is doing.
As far as I know it is only doing simple env setting to load vulkan drivers. Nothing more nothing less.
It makes the system to use the old method of finding drivers and set 32bits then 64bits into the env. Vulkan Arch Wiki
This only works for AMD GPU, I am sorry NVIDIA. But I will also thanks NVIDIA for giving the same idea, Shaders were my problem. NVIDIA solution was (in windows) to put shader cache limit to infinite.
I'm reading on the Steam forums that putting the shader cache limit to infinite has been consistently making performance better on Windows. Does anyone know how to do the same on Linux with an NVIDIA GPU? I get good results using the other launch params people are sharing, but unfortunately, I get nasty graphical glitches after playing for some time.
Hello @LordJakki, @brenmous, there's not a lot of components to https://gitlab.com/AndrewShark/amd-vulkan-prefixes/-/raw/main/amd_vulkan_prefixes.sh. I'm mildly curious if one of you can reproduce the misrendering, then try running the game with DISABLE_LAYER_AMD_SWITCHABLE_GRAPHICS_1=1 %command%
and see if that has any effect. I suspect it's not going to make a difference, but there's nothing else in that helper script besides forcing the game to see a single video driver vendor.
Hello @LordJakki, @brenmous, there's not a lot of components to https://gitlab.com/AndrewShark/amd-vulkan-prefixes/-/raw/main/amd_vulkan_prefixes.sh. I'm mildly curious if one of you can reproduce the misrendering, then try running the game with
DISABLE_LAYER_AMD_SWITCHABLE_GRAPHICS_1=1 %command%
and see if that has any effect. I suspect it's not going to make a difference, but there's nothing else in that helper script besides forcing the game to see a single video driver vendor.
I removed vk_amdvlk
, and I was able to reproduce the looping frozen options menu bug. I also get flickering black bars at the top and bottom of the screen.
Adding DISABLE_LAYER_AMD_SWITCHABLE_GRAPHICS_1=1
has the same result.
Going back to vk_amdvlk
fixes the issue.
Removing vk_amdvlk
and instead trying AMD_VULKAN_ICD=amdvlk
results in the options menu bug and flickering bars.
Pretty sure my previous issue of the black screen with amdvlk was because I was trying to launch with gamescope as well, so ignore that.
I can see that script is just setting variables so I understand it seems weird.
Hello @LordJakki, @brenmous, there's not a lot of components to https://gitlab.com/AndrewShark/amd-vulkan-prefixes/-/raw/main/amd_vulkan_prefixes.sh. I'm mildly curious if one of you can reproduce the misrendering, then try running the game with
DISABLE_LAYER_AMD_SWITCHABLE_GRAPHICS_1=1 %command%
and see if that has any effect. I suspect it's not going to make a difference, but there's nothing else in that helper script besides forcing the game to see a single video driver vendor.
Replacing vk_amdvlk %command% with DISABLE_LAYER_AMD_SWITCHABLE_GRAPHICS_1=1 %command% caused the options menu to bug out again and monitor to flicker between game and desktop like it was trying to render both at the same time.
The method given by @brenmous is working for me, while the performance of amdvlk is inferior compared to the case when radv can work "normally"... The problem with radv is much more severe, it will usually freeze my wm (by the way, I use hyprland) either when loading in menu or exiting the game, and the performance is usually bad... By "normal" I mean that I could try multiple times rebooting my pc to exit the game once I see the frame is bad or it just freeze on menu... (for reference, it is usually 30~ fps on menu, but when this game can work "normally", then the frame will be 80+, my gpu is 7800xt) The regular freezing is really a pain in the neck...
Replying to https://github.com/ValveSoftware/Proton/issues/7595#issuecomment-2020864264
I have a RX 7900 XT and the driver crashes were also forcing me to reboot the computer. After updating to the latest Mesa main branch and disabling bar in vkd3d through no_upload_hvv
I was able to play for a few hours without the driver crashing. I will do more tests today to see if I was just lucky.
For folks tinkering, please just be aware of the Denuvo anti-tamper. If you change Proton versions a few times it will lock you out of the game for 24 hours like the well-respected customer you are.
I have suggested to Valve customer service to add a warning something similar to "If the program you are changing versions of Proton on has anti-tamer DRM with a limited number of installs per day, changing this may count as a separate install and may lock you out of your software for a limited time". My first result seemed to be an automated reply stating the software isn't guaranteed to work and sent me to github for "troubleshooting". The game runs fine...we just need warnings against this kind of stuff. I understand it's new to Valve and their support team but this is something that does need addressed.
Replying to #7595 (comment)
Currently in a almost two hour session myself without crashes, using
VKD3D_CONFIG=no_upload_hvv gamemoderun gamescope -e -f -r 165 -h 2160 -H 2160 --hdr-enabled -- %command%
Plasma 6 with HDR on Arch with mesa from repositories, not mesa-git
HDR actually works better than on Windows. Performance right now is also good somehow, but I've also not been in the city for a while
https://github.com/ValveSoftware/Proton/issues/7595#issuecomment-2020864264 basically this. As much as I prefer RADV and their performance, in this game specifically I will say its impossible to play, low fps, menu looping (bug referenced earlier in comments), crashes every so often. AMDVLK is not crashing and the FPS is stable and high enough to enjoy the game so far.
My Mesa Drivers are package managed, maybe I should look into git and bite the bullet.
#7595 (comment) basically this. As much as I prefer RADV and their performance, in this game specifically I will say its impossible to play, low fps, menu looping (bug referenced earlier in comments), crashes every so often. AMDVLK is not crashing and the FPS is stable and high enough to enjoy the game so far.
My Mesa Drivers are package managed, maybe I should look into git and bite the bullet.
I can confirm it's not crashing on my machine as well. FPS is stable, but the frametime is still all over the place making it stuttery. From what I've heard, this is an issue with the game itself.
Today i installed Pop!_OS and when launching the game it gives me this error after the RE Engine logo, before the start menù. Anyone has any idea on what is it? I'm on NVIDIA GPU
Today i installed Pop!_OS and when launching the game it gives me this error after the RE Engine logo, before the start menù. Anyone has any idea on what is it? I'm on NVIDIA GPU
Add VKD3D_DISABLE_EXTENSIONS=VK_NV_low_latency2
to launch parameters
It doesn't change anything, sadly. BTW Capcom Crash report is unable to provide a log, apparently, as it is abruptly ended. Error code 0x2000000.
Something I did today and got great results with my machine. I added 2 things so I can't say which one helped or both, but I am having great results.
PROTON_NO_FSYNC=1
and gamemoderun
to Steam Paramters Launch.Something is telling me gamemoderun and NO_FSYNC=1 made the difference for the stability of game.
Replying to https://github.com/ValveSoftware/Proton/issues/7595#issuecomment-2027872648
Can you at least define "great results"? How is it different than it was for you before? More FPS? More stable? What changed?
https://github.com/ValveSoftware/Proton/issues/7595#issuecomment-2027887172 I wasn't monitoring before since it was always low FPS (below FSYNC minimum, which means 30 or less, even less in cities).
The great result for me came the stability and actually smooth fps with freesync. Still not 60 fps dream, but I take a smooth above 30 fps for this game for now. Good enough.
I also tried running the game with PROTON_NO_FSYNC=1
set and managed to play for a noticeably longer time without the game crashing. Usually the game crashes anywhere between 5 to 120 minutes from launch and completely resets the session back to login screen.
I will do more testing later today to see if this indeed does effect the stability when compared to FSYNC being enabled.
I observed noticeably worse performance when FSYNC is disabled which I think is to be expected. Without exact measurements, I estimate the performance hit to be around 20% less in FPS at least on my system. For me the priority would be to have the game run stable even by sacrificing some performance.
I'm running the game on a rig with the following:
Compatibility Report
System Information
I confirm:
Symptoms
Not possible to enable ray tracing in the options menu. DLSS can be enabled. Tried with launch options: PROTON_LOG=1 PROTON_ENABLE_NVAPI=1 VKD3D_CONFIG=dxr %command%
Log from starting to menu and quitting: steam-2054970.log
Also tried on Experimental bleeding-edge, which crashes immediately at the main menu if you run without PROTON_LOG and hangs on black screen at the same point when logging is enabled. Log after killing the process:
steam-2054970.zip
Reproduction
Start the game, check the graphics options