Open Patola opened 1 year ago
Hello @Patola, please copy the contents of Steam Runtime Diagnostics from Steam (Steam
-> Help
-> Steam Runtime Diagnostics
) and put it in a gist, then include a link to the gist in this issue report.
Sorry for the delay, here it is: https://gist.github.com/Patola/225fdf5f50c3b227f33092a19ee18b1a
Thanks, this looks like the section to focus on https://gist.github.com/Patola/225fdf5f50c3b227f33092a19ee18b1a#file-steam-runtime-diagnostics-patola-txt-L6518-L6528. As a quick test, can you go to the per-game properties of Steam Linux Runtime 3.0 (sniper)
in your Steam library, and switch to the client_beta
beta branch and test if that has any effect?
Found the Steam Linux Runtime 3.0 (sniper), on the properties windows, betas tab, changed it to client_beta, waited for it to update and ran Demonicon again. Same thing, the game doesn't start, sending the proton log.
On my Steam Runtime Diagnostics, what was specially relevant on the part you marked? The double-free part is sort of a driver bug or something?
I've completely removed amdgpu-pro from my system, unset VK_ICD_FILENAMES (removed from /etc/environment) and rebooted. Game still does not start, generated a new gist: https://gist.github.com/Patola/5de85bdf2523ab4a1b89279e56f78fac
This is looking more like a your-computer-specific issue than a game-specific issue. Do other Vulkan or DXVK games work? It's often useful to try other games as a way to check whether something is game-specific, especially free-to-play games which are equally accessible to all users. Some good ones to try here might be:
I see you have MangoHud installed. Conveniently, that will tell you whether a game is using DXVK.
amdgpu-pro is known to be problematic, so it's good to have removed it completely to rule out it being part of the problem.
I also notice that you have something called VK_LAYER_ALVR_capture
installed, which is unusual. It might be worthwhile to make sure that's disabled during testing.
"free(): double free detected in tcache 2", "timeout: the monitored command dumped core"
This specific issue was (probably) a bug in the diagnostic tool that is generating the report, nothing to do with your specific driver. This specific issue is fixed in the client_beta
, which is part of why Kisak asked you to try that.
Looking at your latest report, the "double free" bug is fixed for sniper there, as expected (it's still present for soldier, presumably because you didn't switch soldier to its equivalent beta).
Is it intentional that you have the Nvidia proprietary driver installed on a machine that doesn't appear to have an Nvidia GPU? That seems odd to me. If DXVK is somehow selecting that driver, then that could be causing problems for you. DXVK has its own logic for choosing which Vulkan rendering device to use, and does not necessarily use devices in the order in which they are provided to it by lower layers.
Non-DXVK Vulkan seems to be working fine in your sniper container: both the 32- and 64-bit versions of the diagnostic tool (which is a simple Vulkan program that draws one triangle) can render successfully either on your GPU or in software.
Outside the sniper container, 32-bit Vulkan is fine, but the diagnostic tool is finding that something is not right with 64-bit Vulkan: it has taken longer than a few seconds to start up the renderer:
"graphics-details" : { "x11/vulkan" : { "renderer" : null, "version" : null, "issues" : [ "cannot-load", "timeout", "cannot-draw" ], "exit-status" : 124,
This is looking more like a your-computer-specific issue than a game-specific issue. Do other Vulkan or DXVK games work? It's often useful to try other games as a way to check whether something is game-specific, especially free-to-play games which are equally accessible to all users. Some good ones to try here might be:
* Ghostrunner (free demo) via Proton 8.0 - uses DXVK in the sniper container * Counter-Strike 2 - free, native Linux game, runs in the sniper container * Dota 2 - technologically similar to CS2
Just to make things clear, after these tests I reinstalled the amdgpu-pro packages (making the default be the vk_radv via /etc/environment) because these are the only packages that provide amdgpu_dri.so
. And also, without the amdgpu-pro packages installed, this steam diagnostic that I was asked to run had some odd error messages like in x11/vdpau libGL saying that it can't open .drirc and renderer being null, and graphics-details-x11/vulkan with null renderer (with amdgpu-pro installed (but not being the default) this section has "AMD Radeon RX 7900 XTX (RADV GFX1100)" as renderer and version is "Mesa 23.2.1-arch1.2" as expected).
All of these games you mentioned worked without a hitch, just tested them. In fact on this machine I usually run about 10 different Steam games each and every day, it's the odd ones that don't run that I report. So it's got an excellent compatibility track record. I've also got other machines that work as control, my nvidia rtx 3070 laptop (where Demonicon started the launcher, but got stuck anyway -- I was just going to add that), my Steam Deck and my wife's PC with Ubuntu and RTX 2070 Super (that she's upgrading to a RX 6800 XT). Please let me know if you want proton logs and machine details from each of them and I will run the game there.
I see you have MangoHud installed. Conveniently, that will tell you whether a game is using DXVK.
It tells when a screen appear, which is not the case for this game. Maybe I can make it show something by turning on logging?
amdgpu-pro is known to be problematic, so it's good to have removed it completely to rule out it being part of the problem.
Unfortunately due to the oddities I mentioned I prefer to have it installed. There are a few games that I prefer to run with amdgpu-pro too, although this thing that happened that I had to specify RADV instead is a recent development, some arch update might have changed some default or something.
I also notice that you have something called
VK_LAYER_ALVR_capture
installed, which is unusual. It might be worthwhile to make sure that's disabled during testing.
ALVR is a steamvr streaming software for the Oculus Quest 2 and Pico VR headsets. I have it installed there but inactive, apparently this comes from /usr/share/vulkan/explicit_layer.d/alvr_x86_64.json, but as I only use this machine with the Valve Index I can remove it to test, of course.
"free(): double free detected in tcache 2", "timeout: the monitored command dumped core"
This specific issue was (probably) a bug in the diagnostic tool that is generating the report, nothing to do with your specific driver. This specific issue is fixed in the
client_beta
, which is part of why Kisak asked you to try that.
Ah, understood.
Looking at your latest report, the "double free" bug is fixed for sniper there, as expected (it's still present for soldier, presumably because you didn't switch soldier to its equivalent beta).
Should I switch soldier to beta? Will it help in this case, or just other general cases?
Is it intentional that you have the Nvidia proprietary driver installed on a machine that doesn't appear to have an Nvidia GPU? That seems odd to me. If DXVK is somehow selecting that driver, then that could be causing problems for you. DXVK has its own logic for choosing which Vulkan rendering device to use, and does not necessarily use devices in the order in which they are provided to it by lower layers.
I didn't like this but it's also recent, ffmpeg-full-git required me to have cuda installed which by its turns pulls nvidia-utils and opencl-nvidia. Having said that I instead installed ffmpeg-amd-full-git
and I was then able to remove these pesky three packages.
Non-DXVK Vulkan seems to be working fine in your sniper container: both the 32- and 64-bit versions of the diagnostic tool (which is a simple Vulkan program that draws one triangle) can render successfully either on your GPU or in software.
Outside the sniper container, 32-bit Vulkan is fine, but the diagnostic tool is finding that something is not right with 64-bit Vulkan: it has taken longer than a few seconds to start up the renderer:
"graphics-details" : { "x11/vulkan" : { "renderer" : null, "version" : null, "issues" : [ "cannot-load", "timeout", "cannot-draw" ], "exit-status" : 124,
I don't know what to make of it. However, games that are supposed to work via radv do it ok. Starfield, for example, would not work via amdgpu-pro, but works with RADV, and this is still the case with amdgpu-pro installed.
steamdiag-3.json
steamdiag-1.json
steamdiag-2.json
Maybe this helps figuring out what's going on? steamdiag-1 is pior to uninstalling amdgpu-pro (although I also uninstalled amdgpu-core-meta
which I can't find again, there's been some renaming of packages), steamdiag-2 is after having uninstalled amdgpu-pro, and steamdiag-3 is after I have reinstalled amdgpu-pro (paru -S amdgpu-pro-oglp amf-amdgpu-pro lib32-amdgpu-pro-oglp lib32-vulkan-amdgpu-pro vulkan-amdgpu-pro
). Please understand that I'm not asking for help to get my machine "fixed", I am doing that because I think it might be a point of contention for this case and others, and it's important to know that if there's an issue, it's better for everyone to know where it comes from.
Ok, I just tested Demonicon on my gaming laptop, running Arch Linux with proprietary nvidia drivers for the Mobile RTX 3070 GPU. system information of the laptop -- https://gist.github.com/Patola/59b59f9e71a2f085a42d3d574bf57810 systeam diagnostics of the laptop -- https://gist.github.com/Patola/74667b8a30c91c71d5f187ed8330c046
So, what happens on this case? I press play and this window appears: I then press "install update" and the window disappears and the game keeps running forever with nothing happening (waited 13h then pressed stop on Steam). This is the proton log: steam-215630.log
So... it's quite different from what is happening on my desktop, where even this initial launcher screen does not appear.
...ok, this is creepy. Demonicon just started working in that gaming laptop with NVIDIA. It goes to a launcher first, then I can press a button to play the game. First time it didn't work but now it does, and apparently everything is working perfectly now on that laptop. I had no updates in between the tests, I hadn't even rebooted the laptop. Sending an updated proton log if that helps comparing. steam-215630.log The game still doesn't work on my AMD desktop, though.
@smcv this weird error about VK_KHR_surface also appears on the Steam Deck, the game behaves the same as on my AMD desktop (in other words, it doesn't even launch). I swear I do not do any modification on my Deck, it's vanilla (except for maybe a few application flatpaks installed via discover), so I don't think it's a driver issue from my having AMDGPU and AMDGPU-PRO installed simultaneously on my desktop.
Attached the proton log of Demonicon in my Steam Deck. steam-215630-steam-deck.log
Compatibility Report
System Information
I confirm:
Symptoms
Game doesn't start
Reproduction
Press PLAY.
steam-215630.log
Note: previously I had a problem with various games where I couldn't start games because of amdgpu-pro and amdgpu installed at the same time, which I resolved by settings the VK_ICD_FILENAMES variable to point only to amdgpu. I find it odd that proton.log has these lines:
even though
vulkaninfo
tells me that my GPU supports this vulkan extension.