GTFO
Hello @beardstorm, can you check if the game runs better with mesa 20.0.x or git master from a mesa PPA like oibaf or kisak-mesa and using the RADV/ACO render path?
Support for mesa 19.3.x has ended upstream, and issues with RADV/ACO in the older driver version are not particularly interesting because it is not enabled by default and no more fixes will ship for 19.3.x.
Hello @kisak-valve, thanks for the quick reply.
I have followed the instructions here to install kisak-mesa. If that is what is applied by setting launch options to RADV_PERFTEST=aco then that also seems to work! :+1: I believe I tried this earlier, but I might not have restarted my computer after that installation... Oh well. :sweat_smile:
How come the mesa support for 19.3.x has ended?
Follow-up question. How come RADV/ACO is not mentioned among the Proton runtime configuration options?
How come the mesa support for 19.3.x has ended?
Because 20.0.x is out and 19.3.x has run its course.
I would just like to add that using the system installation of wine (mine was version wine-5.0 (Ubuntu 5.0-3ubuntu1)) does manage to get past the Unity crash handler and into the game.
The game then fails to connect to the internet.
But for myself, then I tried Proton 4.11.13 (earlier used Glorious Eggroll version 5.11-GE-1-MF and 5.8-GE-2-MF)
without PROTON_USE_WINED3D=1 %command% and without any Unity crash handler, the game launched and worked!
PS: Now the game even works with 5.8-GE-2-MF!!! (have not tried 5.11-GE-1-MF)
I think that launching it with the system install of wine did something...
Even though I have lost my own logs from back when the game did not launch, I remember comparing my logs to @beardstorm's and the exception at line 243: 00d8:00e8:trace:seh:raise_exception code=406d1388 flags=0 addr=0x7b00fc3e ip=7b00fc3e tid=00e8 matched mine as well...
System Info
GPU: GeForce GTX 1650/PCIe/SSE2
Driver: nvidia 440.100
Kernel: 5.4.0-7642-generic
Complete system information: Gist
Proton versions: 5.11-GE-1-MF/5.8-GE-2-MF/4.11.13
After applying settings the video freezes (it plays background music, effects when you hover over a button, etc.) and it rarely happens when going into video settings. Is this happening to anyone else ? I used Proton 6.3-7
So, the game before the 1.0 update used to run at 144fps with everything set a very high for me, since it the update dropped two days ago I'm running at ~30fps... I'm wondering what this could be and how I could debug it; does anyone has any tips on how I could debug the root issue?
Also, @kisak-valve could this be considered regression as the game's performance is reasonable if not the same with Proton 5.0-10? Sorry for the mention in advance.
Hello @wizardlink, in general, unwanted behavior introduced by a game update can't be investigated as a regression on Proton's side because a Proton dev can't bisect changes in the game's code.
That said, please add PROTON_LOG=1 %command% to the game's launch options, reproduce the suboptimal performance, and attach the generated $HOME/steam-$APPID.log to this issue report as a file. (Proton logs compress well if needed.) Also, 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.
I'm also experiencing performance problems using Proton compared to windows.
With everything set to high I get 20-50FPS on Linux and 140-160FPS on Windows in the first room of A1.
GTFO seems to be GPU bound.
System Information
- GPU: RTX 2080
- Driver/LLVM version: nvidia 495.46
- Kernel version: 5.15.8-arch1-1
- Link to full system information report as Gist:
- Proton version: 6.3-8
I get very similar logs to @CytexalMika
If I go into a mission it is typically fine, I usually get 60fps and when I use radeontop, I use most GPU utilisation between 50-70% for most things. However, if after that I go into a second mission the fps drops to 30 and the GPU utilisation maxes out to 100%.
System Information
Distro:Manjaro Linux
Kernel:5.15.2-2-MANJARO
RAM:32 GB
GPU Driver:4.6 Mesa 21.2.5
GPU:AMD Radeon RX Vega (VEGA10, DRM 3.42.0, 5.15.2-2-MANJARO, LLVM 13.0.0)
CPU:AMD Ryzen 7 2700 Eight-Core
Issue occurs in both: Proton version: 6.3-8 and Proton Experimental
I have similar issues as @ahtoms and @CytexalMika . Before the update performance was fine, after 1.0 it has degraded significantly. Other people I've played with are on Windows and don't report having the same issues.
System Info:
Disro: Pop!_OS 20.04 LTS (64 bit)
GPU: AMD Radeon RX 5700 XT
CPU: AMD Ryzen 5 3600 6-Core Processor
Ram: 16gb
Hello @wizardlink, in general, unwanted behavior introduced by a game update can't be investigated as a regression on Proton's side because a Proton dev can't bisect changes in the game's code.
That said, please add
PROTON_LOG=1 %command%to the game's launch options, reproduce the suboptimal performance, and attach the generated $HOME/steam-$APPID.log to this issue report as a file. (Proton logs compress well if needed.) Also, 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.
Sorry for my immense delay to answer you @kisak-valve. Yeah, I understand that, I just can't see another label fitting this better and wanted to understand the process; thanks for the clarification!
Report
- Full system information: https://gist.github.com/wizardlink/0f9e7f5fb074481a65cc0ce7680451af
- Proton version: Proton Experimental (@ 0de380d at the time of writing)
- Proton logs: https://drive.google.com/file/d/1jSuTuX5OqkvsCJcme2N9lOcudmH8DpaC/view?usp=sharing
- Didn't knew where to upload to so I defaulted to Google Drive, as the log file is 218MB, GitHub doesn't lets me upload here.
Also, for anyone else having performance issues: Do use Proton 5.0-10 as it's working perfectly with this title.
As a quick test, can you see if disabling MangoHUD and gamemode has a significant influence on the game's performance with newer Proton? I wouldn't be surprised if there's no effect, the request is just to remove them as extra factors.
@kisak-valve I am not using MangoHUD but the ingame FPS counter, I have tried it with and without gamemode and I still get these drops.
As a quick test, can you see if disabling MangoHUD and gamemode has a significant influence on the game's performance with newer Proton? I wouldn't be surprised if there's no effect, the request is just to remove them as extra factors.
Alike @ahtoms, disabling FeralInteractive's gamemode and MangoHud (plus enabling ESYNC again) did not affect in anything noticeable, I can generate a new log if you prefer without the usage of these tools, not sure if it's cleaner for you and the team to analyse.
@wizardlink I had just tried it with Proton 5.0-10, There was no improvement.
Some reports on protondb are starting to corroborate that when reloading from checkpoint/dropping to another mission after trying one before it/or joining midgame, it will trigger a significant FPS drop. https://www.protondb.com/app/493520
I strongly suspect there is some oddities with shaders being sent to the GPU.
@wizardlink I had just tried it with Proton 5.0-10, There was no improvement.
Some reports on protondb are starting to corroborate that when reloading from checkpoint/dropping to another mission after trying one before it/or joining midgame, it will trigger a significant FPS drop. https://www.protondb.com/app/493520
I strongly suspect there is some oddities with shaders being sent to the GPU.
Intriguing, with 5.0-10 I experienced major improvement.
If you do suspect it's shaders you could clean them and try again, perhaps allowing the background processing of the same could help? Though I'm unsure if that setting just means it can download pre-compiled shaders while the game is running.
@wizardlink I had just tried it with Proton 5.0-10, There was no improvement.
Some reports on protondb are starting to corroborate that when reloading from checkpoint/dropping to another mission after trying one before it/or joining midgame, it will trigger a significant FPS drop. https://www.protondb.com/app/493520
I strongly suspect there is some oddities with shaders being sent to the GPU.
I am also getting this issue in GTFO. It seems to be related to an extremely similar problem I get in Battlefront II: https://github.com/ValveSoftware/Proton/issues/3971#issuecomment-774826539
Replying to https://github.com/ValveSoftware/Proton/issues/3834#issuecomment-1003658550
Having also the same issue. Whenever I change a graphic setting or change the window resolution, game drops to 20FPS, happens when I lose and have to restart the game. If I don't have to restart or change any settings, game is 70/80FPS all maxed out on 1440p.
@wizardlink I had just tried it with Proton 5.0-10, There was no improvement.
Some reports on protondb are starting to corroborate that when reloading from checkpoint/dropping to another mission after trying one before it/or joining midgame, it will trigger a significant FPS drop. https://www.protondb.com/app/493520
I strongly suspect there is some oddities with shaders being sent to the GPU.
Can confirm, seeing exact same issue. Framerate gets halved every time I press ESC for the menu or die/reload level.
Specs:
OS: Fedora 35
KERNEL: 5.16.5-200.fc35.x86_64
CPU: Intel Core i9-9900K @ 3.60GHz
GPU: NVIDIA GeForce RTX 2080 SUPER
GPU DRIVER: NVIDIA 510.47.03
RAM: 32 GB
New rundown/update, it's very clear to trigger a slowdown now. You simply just need to start the B3 mission and you'll find that you get between 10-20 FPS. There seems to be something quite intensive being ran on the GPU on this mission that I am uncertain about.
Well... it appears that if I run the game with the following environment flag RADV_PERFTEST=llvm it is completely stable. I'm wondering what the issue is with ACO
Hello @ahtoms, 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. The performance behavior might be something worth reporting directly to your video driver vendor with a renderdoc capture of the game while it's showing degraded performance.
Hi @kisak-valve, you can refer to the following:
https://gist.github.com/ahtoms/f1426d6c10d7a531125bd785b7e12fc9
Well... it appears that if I run the game with the following environment flag
RADV_PERFTEST=llvmit is completely stable. I'm wondering what the issue is with ACO
I'm really considering switching to an AMD GPU. I have a 3070 since Jan 2021 and bought it so cheap but I might sell it and just buy an AMD one.
I didn't test the new update but sometimes it happens on Windows too. I had my FPS drop from reloading the level after a checkpoint door.
Freezes on the Steam Deck while loading, or immediately after loading is complete, on most expeditions. Sometimes it crashes back to the OS, but other times it seems to hard lock the deck and it needs to be forcibly power cycled.
@absolom Are you still able to reproduce this? It seems on Steam Deck Beta on my side.
Yes, I am still having the same issue.
I turned on Steam Deck Beta, validated game cache, and configured it to use Proton Experimental. Same behavior.
This is rundown 7.0 still. The "EVAL" sector of the rundown runs perfectly. The "A1" sector I was able to get through playing with friends with one crash and one near crash. The "B1" sector crashes every time during loading (while dropping down into the level).
I never found a solution for GTFO using 8GB of my VRAM (3070) and dropping FPS like hell whenever I reloaded from a checkpoint but I found that setting the texture size to "half" and limiting my FPS to 70 with DXVK_FRAME_RATE, only takes 4 or 5GB of VRAM and it's super smooth, frametime is a flat line, even comparing the 100FPS I got without setting the frame rate cap and the 70FPS capping (I have a 144hz monitor), 70FPS looks and feel way smoother than 100FPS.
I've come back to trying GTFO again on my Steam Deck. With the latest version of the game, running on lowest settings, I no longer have the issues that I was encountering with rundown 7.0's B1 sector. Seems to be working well now.
I get random system freezes and game crashes with all the logs ending in
warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
Any what this could be?
Solved by the way, I was just running out of memory.
Proton 10/experimental seems to affect the game's strings, rendering them invisible depending where the HUD moves to or when a certain tab is selected in settings menu. This doesn't happens in Proton 9
Hello @matkijahenkilo, please add PROTON_LOG=1 %command% to the game's launch options, reproduce the regression, and attach the generated $HOME/steam-$APPID.log to this issue report as a file. (Proton logs compress well if needed.)
Heya @kisak-valve, here's the log: steam-493520.zip
GTFO (493520)
Issue transferred from https://github.com/ValveSoftware/Proton/issues/9176.
@HubsChromeFreeze posted on 2025-11-03T02:51:27:
Compatibility Report
- GTFO
- 493520
System Information
- GPU: NVIDIA GeForce RTX 3050 Ti Laptop GPU
- Video driver version: 535.247.01
- Kernel version: 6.1.0-40-amd64
- Link to full system information report as [Gist]: https://gist.github.com/HubsChromeFreeze/855b9ba07c74041c69ea19320b5ceace
- NOTE Regarding System Info: Steam (and other programs) do not read system information correctly and won't properly find the NVIDIA card. Games are launched on the system by putting _NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia %command% into the launch options.
- Proton version: Attempted Hotfix, Experimental, 9.0-4, 8.0-5, 7.0-6, 6.3-8, 5.13-6, 10.0-2 (beta), GE-Proton10-25 to varying results; none are functional.
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.
Proton Log:
https://gist.github.com/HubsChromeFreeze/95fa4109fa718ff7637426ba64e8f9e5
Proton logs do not appear in the provided location by the template. This could be because debian-installation has put it in a bad spot where it's hard to find, or it is Proton itself crashing and generates this report and no log.
Symptoms
Using any of the above Proton will yield different results;
For 9.0-4, the game will crash during the startup sequence, right around as the cutscene begins. No menus besides the EULA agreement screen are reached.
For more experimental versions, the game often will not launch at all, or produces an identical result, kicking to the Unity Crash Handler.
For older versions, down to 5.13-6, the game will either crash immediately -- or in the case of Proton 6.3-8, will NOT crash at the described location and will instead cause the game to freeze as the menu cutscene says "Waiting for system assets to initialize.." (exact number of periods too), not loading and not crashing. This is as far as I have been able to reach.
Reproduction
Launch the game with hardware and software as described.
Notes: PROTON_USE_WINED3D=1 causes the game under MOST Proton versions (if it does not crash) to not successfully load (or at least load so slowly my patience ran out -- so about 5-10 minutes). A long list (which I cannot remember, unfortunately) of other launch options have been tried, to no positive effect.
Edit: Fixed links.
Proton versions
ge-proton10-25x1 2025-11proton 6.3-8x1 2025-11proton experimentalx3 2022-09proton 5.0-10x6 2022-02proton 6.3-7x1 2021-10proton 4.11x1 2020-08
Launch options
PROTON_USE_WINED3D=1x3 2025-11PROTON_LOG=1x3 2025-06DXVK_FRAME_RATEx1 2022-09RADV_PERFTEST=llvm`x2 2022-06RADV_PERFTEST=aco`x1 2020-05RADV_PERFTEST=llvm`.x1 2020-05
Launch lines
_NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia %command%x1 2025-11PROTON_USE_WINED3D=1 %command%x2 2020-08
Upstream links
- ValveSoftware/Proton/issues/9176x1 2025-11
- ValveSoftware/Proton/issues/3971x1 2022-01
Compatibility Report
System Information
I confirm:
Symptoms
The game simply will not start using any of the tried Proton versions. The game will briefly show an Unity crash handler and then close.
Reproduction
Launch the game using the hardware and drivers provided in System information.
Proton log
Workarounds
I managed to get around the launch crash with OpenGL-based wined3d renderer by using launch options
PROTON_USE_WINED3D=1 %command%. This did however come with severe rendering issues in the main game. 2D interfaces like the menus and the game HUD worked fine. Would you prefer if I opened a separate issue for using wined3d?I managed to get it working properly with the LLVM compiler framework by using launch options
RADV_PERFTEST=llvm. However, I happened upon this solution at random, and it seems to not be an intended way to use Proton.