Open HolySoap opened 9 months ago
Note: This game seems to always use GPU#0 instead of the one driving the current display. I had issues with even getting into the game because of sub-1-FPS performance until I turned off the CPUs iGPU.
Thank you! Disabling the iGPU fixed the problem for me.
Note: This game seems to always use GPU#0 instead of the one driving the current display. I had issues with even getting into the game because of sub-1-FPS performance until I turned off the CPUs iGPU.
The AMD 3900X doesn't have an iGPU, and all cores are used.
I set the graphics back to Ultra (from the video showing it with Low) with FSR Quality preset, I forgot to remove the Mangohud frame-cap but that shouldn't matter.
@HolySoap this seems to be a RADV issue, I'm getting the same framedrops with a 7900xtx using RADV, swapping to AMDVLKand the framedrops are gone
I reproduced the stuttering with an RX 7600 with the Mesa version mentioned above, and the issue is gone in Mesa main. It appears to have been fixed here: https://github.com/Mesa3D/mesa/commit/f30bd0074e229744b0c0ccf03d5979e3cbdc9835
I reproduced the stuttering with an RX 7600 with the Mesa version mentioned above, and the issue is gone in Mesa main. It appears to have been fixed here: Mesa3D/mesa@f30bd00
Can also confirm that its fixed in Mesa git (snapshot 20231113). Anyway, now the game just needs to save my settings, but that's a game issue I think.
I can confirm this picks up the iGPU incorrectly (confirmed with amdgpu_top) even if the dGPU is marked as card #0.
Disabling the iGPU in BIOS settings, the game finally starts fine with a recent enough mesa version. A bonus question though, is this incorrect pick of GPU a game/UE5 bug, or a wine/proton one?
Processor: AMD 7950X3D (with iGPU) Discrete GPU: AMD RX 7900 XT Motherboard: ASUS TUF GAMING X670E-PLUS WIFI (disable dGPU in Advanced -> NB Configuration -> Integrated) Kernel: 6.6.1 Mesa: 23.3.0_rc4 (includes the mentioned fix)
Talos Principle 2 does not start
Issue transferred from https://github.com/ValveSoftware/Proton/issues/7275. @Leminski posted on 2023-11-21T23:29:36:
(Attached steam-835960.zip)
I can't get the game to run. I've tried different Proton versions, and the various commands listed on ProtonDB. It does not run. Simply a quick flash and then dies. I can't even screenshot it. I'm using X11 and once got sound using Wayland, but Wayland does not open Steam, and really that was only once.
Running Steam via command line, then running the game gives the following: https://gist.github.com/Leminski/08cd5c7084411291c1a6a4eecc10b1f6
I'm using Pop!_OS and an RTX3080. I've contacted Steam Support for help, who directed me here.
LSHW: https://gist.github.com/Leminski/1f171bc98f075e85dc5d4f39da2562a8
Thanks.
With Proton-Experimental as of 14.12.2023 is does run very well. The only graphical glitch is that foliage and trees "expand" to gargantuan size when standing still for 1-2 seconds, but all puzzles are completable. (The trees return to "normal" size when moving around).
https://gist.github.com/mlauss2/b1fe6d632110b2bb054c3e12d759ef7e
RX7900XTX w. mesa snapshot from 2023-DEC-14.
Hello @mlauss2, 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.
Hello @mlauss2, 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.
Done. (https://gist.github.com/mlauss2/b1fe6d632110b2bb054c3e12d759ef7e)
It's seems to be completely fixed with a fresh mesa checkout (running mesa.git 4d93aac74df68fad9b2ca5a9c653b913874f383d at the moment with zero issues).
Setting DRI_PRIME with an exclamation mark at the end will hide other GPUs and force the game to use what you tell it to.
See: https://docs.mesa3d.org/envvars.html#envvar-DRI_PRIME
For example, if you want to force it to use the second GPU (typical in a laptop with hybrid graphics) use this as the game's launch options:
DRI_PRIME=1! %command%
This format doesn't work to force the first GPU, though. If you need that, you will have to specify it using its PCIe bus or device id, as described in the documentation I linked.
If you have vulkaninfo installed, you can just run this command:
printf 'DRI_PRIME=%s:%s! %%command%%\n' "$(vulkaninfo --summary | grep -oPm 1 'vendorID\s*=\s*0x\K....')" "$(vulkaninfo --summary | grep -oPm 1 'deviceID\s*=\s*0x\K....')"
And it will print something like:
DRI_PRIME=1002:1638! %command%
Which you can just copy and paste into the game's launch options.
Without vulkaninfo, you can find the right device ID with this command:
lspci -nnd ::380 | grep -E --color '[[:xdigit:]]{4}:[[:xdigit:]]{4}'
If that doesn't show anything, try this instead:
lspci -nnd ::3xx | grep -E --color '[[:xdigit:]]{4}:[[:xdigit:]]{4}'
The ID you need to copy will be highlighted. If there are multiple IDs, you'll need to pick the right one.
For example:
Then set the game's launch options to:
DRI_PRIME=xxxx:xxxx! %command%
Replacing xxxx:xxxx
with the ID you copied earlier.
It's come to my attention that the advice I gave above won't work with proprietary Nvidia drivers, which work differently. It's probably not even an issue on those, since I don't see Nvidia users complaining.
NVIDIA user here. Didn't test the above DRI_Prime setting, my solution was to disable the iGPU on my board, which put the RTX3080 next in line. I can re-enable and test if you have a NVIDIA proprietary driver variable that'll be used here.
NVIDIA user here. Didn't test the above DRI_Prime setting, my solution was to disable the iGPU on my board, which put the RTX3080 next in line. I can re-enable and test if you have a NVIDIA proprietary driver variable that'll be used here.
Ah, so it does affect Nvidia users sometimes.
You could try with the iGPU enabled in the bios and these launch options for the game:
VK_DRIVER_FILES=/etc/vulkan/icd.d/nvidia_icd.json:/usr/share/vulkan/icd.d/nvidia_icd.json:/usr/share/vulkan/icd.d/nvidia_icd.x86_64.json %command%
It's long because I don't know where the file is in your system, so I included all the paths I know about.
I think that would stop it from trying to use any non-Nvidia GPUs.
VK_DRIVER_FILES=/etc/vulkan/icd.d/nvidia_icd.json:/usr/share/vulkan/icd.d/nvidia_icd.json:/usr/share/vulkan/icd.d/nvidia_icd.x86_64.json %command%
Hey! Yep that works. Game boots now, with integrated graphics enabled. This would have been great at launch (didn't know what the issue was).
I'm using Pop!_OS 22.04, so the json file is in "/usr/share/vulkan/icd.d/nvidia_icd.json", and retesting with just that command also just works.
@Leminski @major-gnuisance @voyageur
You can use this option to hide integrated GPU and force the game to select distrete GPU:
DXVK_CONFIG="dxvk.hideIntegratedGraphics = True" %command%
This option is easier and this is an universal option for Nvidia, AMD, Intel.
Seems that there's a regression in Wine\Proton 9.x which affects T2: https://github.com/HansKristian-Work/vkd3d-proton/issues/2065
TLDR: when the player's avatar passes through force field (violet field), or force field animation is being played (blue fields), the game stutters with very noticeable frame drops (see the issue above for video clip depicting the situation)
GPU: RX 7900 XTX Driver: Mesa 24.1.5-manjaro1.1
Log file: steam-835960.log.zip
Additionally to what I've described there, I've tested the game with Proton 8.0-5 available in Steam and I also built a 8.0 frankenstein without VKD3D and other stuff baked in, so I've tested different versions of VKD3D-Proton as well.
On these versions, there's NO such stutter of frame drop when interacting with force field objects - meaning that I've been able to repro that issue only on 9.0 branches of Proton, regardless of VKD3D-Proton version.
Compatibility Report
System Information
I confirm:
steam-835960.tar.gz
Symptoms
Heavy frame drops even on the lowest graphical settings (I uploaded a video for reference, sadly YouTube caps it at 60fps, the original has 144fps). It gets worse and way more frequent (basically with every mouse movement) with the increase of graphical fidelity. Game is installed on an SSD and the CPU is handled via AMD P-State Guided. No launch options were used besides Proton log and gamescope, mangohud is globally enabled.
Reproduction
Starting the game should be enough, even the intro video has a frame drop that is also seen in the video.
There is another reported issue for this game but its a false report do due wrongly handled/buggy hardware that has nothing to do with the game, it is also closed and should stay this way.