[Linux] Unusually long startup time #608
Comments
|
This has been bothering me too. It's not using a lot of cpu time and it's not reading from the hard disk. What is it doing? Maybe a failing network connection timing out? |
|
I too am getting this with a similar setup. System Info: https://gist.github.com/anonymous/2d9526841e33438f30df0919239727b8 |
|
I have the same problem on Fedora 23 |
|
I can confirm this on Manjaro. |
|
still relevant, same behavior on arch i really hope this get fixed, since i lost/abandon a competitive game because of it a month ago |
|
Same issue here with arch, with steam_runtime enabled and disbaled. my system info: https://gist.github.com/markitoxs/f19e4477dd1c573ad192009e910c4242 |
|
It's 2017 and this issue is still present on Fedora 25, Debian Testing, and Ubuntu 16.10/16.04. |
|
I've just discovered that this problem has been a known issue even longer than I realised: Issue #383 I know this bug must be low priority as we can still play the game (eventually), but June 2015 to January 2017 is 18 months. With no end in sight. @davidw-valve: what can we do to help you help us? Looking back even further I see this: Client takes 70 seconds to load #119
But
So, is it possible this is related? |
|
still an issue. amdgpu-pro driver on fedora-25 with Radeon RX 480 following the output of the csgo startup script: |
|
@mnlhfr I have exact the same log as you idk why csgo doesn't work as normally even on windows its have fps lag that wasn't before like that i had smooth performance on highest settings 2560x1440p while now on lowest settings and lowest resolution 640x its lagging insane (LINUX) AND (WINDOWS). |
|
I hava same problem on ArchLinux! |
|
For me it takes a full minute to start. Testing the in-development Mesa/RadeonSI binary shader cache did not noticeably improve startup time. |
|
I'm getting this as well. In fact, I didn't even realize this wasn't how it was supposed to be; I recently disabled STEAM_RUNTIME and was floored by the fact that this dropped the game's start time to a mere 50 seconds…and then I found out that the Windows copy starts up in a fraction of that. I'm actually getting significantly better startup times running this through Wine than the native version. Seems like there is a lot of room for optimization or something here. |
|
I cannot start game on my Macbook Pro 2016 15", even switching to high-performance VGA |
|
Hello @nhducit, your issue does not sound related to this issue. Please open a new issue report. |
|
also experiencing long launch times on ubuntu 14.04 |
|
My Insurgency has the same problem on Arch. Source Engine is the thing to look. |
|
ArchLinux. This happens only with csgo. If i press any key atm, game will be closed after some time(20-30 seconds) |
|
This issue is still persistent. I recently moved to Ubuntu 16.04 LTS and I'm running CSGO through the steam option. The maps takes more than 2 minutes to load and I even get cooldowns in competitive matches because of that. Even while selecting teams is takes up a while to render the screen. |
|
I can confirm this is still an issue. it doesn't happen every time. it could be related to higher graphics settings, wrong permissions on steam library folder, and/or use of a library in another disk/folder |
|
To bring some numbers here: Directly on startup the game freezes for ~40 seconds. There's no unusally high CPU or GPU activity, but ~1000 shaders are compiled / ~2000 shaders are created: csgo startup When loading a map it freezes for ~20 seconds, often longer. In this image you see 30 shaders compiled but that is distinctly after the freeze, the only real activity is 80 mb being moved to or from VRAM: csgo map load The windows version in wine starts up much faster and loads maps much faster. Sure we could try to perf profile it further but this is something the csgo developers who have the source code absolutely need to profile and fix, together with the actual game running much less smoothly/with worse frame pacing than the windows version in wine. |
|
This affects Insurgency in the same way.
Obviously not a CS GO issue, but a spurce engine issue.
Gnome 3 freeze protection asks if I want to force quit or wait... Every
hard loading on CS GO or Insurgency.
|
|
I got huge improvements after enabling the mesa shader cache on mesa 18.0.0 (intel graphics). |
|
Same issue happening with me and it really takes around 20 seconds to start the game and on start of each round it takes 3 minutes. Still there is no fix ? |
This ended up working for me as well. Shader pre-cache disabled: 25s +rep @turrini |
|
It's a shame, because I would really like it if shader pre-caching worked on Linux, but it seems so broken (and has been, for a long time). |
|
For me disabling shader pre-cache was not enough, I also had to explicitly remove/rename $HOME/.steam/debian-installation/steamapps/shadercache/730 directory to get sub-minute CS GO startup. i5 3500K, NVIDIA GTX 670, driver 450.66, Debian Buster, kernel 5.4.106-1-pve |
I guess we can close the issue, as this worked perfectly fine in most of the cases. |
|
I have had this bug for years. Shader pre-caching disabled, .steam/steamapps/shadercache/730 is nonexistent. I have an AMD RX Vega 56, on Fedora 34. CS:GO takes several minutes to start up, and by the time it finally starts, it will be taking >5GB of RAM. |
|
confirm this on Ubuntu 20.04 with Nvidia 390.144 drivers, only disabling the shader pre-cache nothing changed, with remove $HOME/.steam/debian-installation/steamapps/shadercache/730 improves it a lot. |
|
Hello, https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18484 looks like something worth testing for Intel (GPU) and AMD (GPU) players. Does not affect NVIDIA players. |
|
Interestingly there was a update that should improve startup performance released today also: |
|
time reduced from 45 seconds to 2-3 |
Tried it, it does work. Now just waiting for it to end up in a stable release. Mesa v22.2 doesn't have it and you have to build from git. |
Make sure you remove $HOME/.nv/GLCache/ as well if it exists. Mine was using the files in there instead of the ones from steam's shadercache |
|
Can confirm this on multiple devices: All of them are running on my external TOSHIBA HDD, formatted as ExFAT, with NO issues on Windows 10 Pro. (should be a software issue since CS:S works perfectly) SS: |
|
This is still happening to me on Manjaro w/ Nvidia (started about a week or two ago)... wouldn't be a big problem if the game didn't also crash when I open the damn Steam overlay. EDIT: Also happens with cache deleted from both steam and nvidia directories and the shader pre-cache disabled... |
|
For me, However, since the dxvk version in csgo is quite old, it was pretty stuttery until I updated it with the latest |
|
@eiglow Thanks for the tip! Last time I tried, Vulkan was stuttery for me too. Does updating with the latest dxvk completely remove the stuttering? Do I have to do it every time csgo receives an update? Can I get VAC banned? |
It completely removed the stuttering for me. The only downside is that I was unable to change my resolution. This isn't a problem for me on my desktop, but on my laptop with a very high-DPI display and integrated graphics, its a bit more of an issue.
I don't think so unless the update involves that specific file. I've had my game updated a few times since doing it and it seems to still work.
No, VAC bans only target cheats. If you're not trying to install a cheat, you won't get VAC banned. The worst that will happen if your files aren't in a consistent state is you can get errors like "VAC was unable to verify your game session", which is fixed either by restarting the game or verifying the files. But I haven't encountered this as a result of upgrading dxvk. |
|
This seems to come and go over the years and this is another round. The best/fastest/easiest thing to test would be older gpu drivers (and kernel versions if needed to build). If I find time over the next few weeks I'll test for a solution. |
|
I forgot to say, Vulkan worked for me for like half a match and then become a 5fps slideshow, although 75fps was shown by cl_showfps 1 at all times. So I turned back to OpenGL... but surprisingly the game launched as fast as it did with Vulkan and kinda stayed that way since... @ipaqmaster I haven't reverted to an older kernel or GPU driver so I doubt the version is what matters. Maybe after the update some cache or files that were meant for the old versions were not properly cleared or updated, and that triggers this pathological case. |
This is unfortunately a known problem (#2901) making
My intention without context was to try downgrading to previous month versions to see if the issue goes away.
With that theory I could certainly try pacstrapping to a new zfs root, boot into that and try installing some boring base minimal base packages plus Steam like a brand new Arch user just to confirm whether or not the problem goes away in an environment without historical files laying around. I'll add this to the list. |
|
[Findings for my case and TL;DR at bottom] Testing a new rootfsI created a new rootfs dataset with ZFS and bootstrapped packages to it with Steam processed shaders first (!) and after 5 minutes of waiting for that, the game launched in this fresh and lightweight Archlinux installation immediately. Like under a second after the window appeared. I must comment - Steam spent 3-5 minutes processing shaders before opening the game. This is probably the issue many are experiencing as my computer's Steam client hasn't been offering to pre-process shaders at all lately despite the option being enabled in my host's Steam Beta client. This confirms that a brand new install with the latest drivers, kernel and packages have no problem opening running CS;GO. Which is what my real rootfs install is running too. Next I'll poke at my desktop's filesystems to see if I can magically cure this problem by deleting something, or otherwise. Continued troubleshootingNext up in this troubleshooting session I noticed CS;GO would launch faster on my PC after reaching the menu at least once despite this slow startup problem persisting whenever I go to play with my friends every evening or so. Block level diffing to find a lead as quickly as possibleRolling back my /data dataset to the previous day featured the 60s CS;GO startup delay again which gave me an interesting troubleshooting idea. I rolled it back again and took a zfs-snapshot for every 10 seconds that CS;GO was stalling to reach the main menu then diffed them. Comparing the zfs-diff's it turns out my CS;GO is building its own shadercache this entire time... and with only a single cpu thread that's where the startup delay is coming from. [Click to reveal growing shadercache file between diffs while the game launches]Once the game is able to reach the main menu those files merge becoming This unusually long startup time issue can be reproduced by dropping all shadercaching efforts for appid 730 (CSGO) with In my case, Steam hasn't been processesing shaders for CS;GO all month and I imagine that's the root cause of this problem. To reproduce the issue feel free to click 'skip' on Steam's shadercache generation to truly reproduce the issue (if yours still works). The game's black screen delay will be a variable time based on a computer's max single core boost clock speed assuming no other load I suppose. You can Why isn't my Steam offering to process the vulkan shaders before starting the game?The new rootfs installation test processed them and after that 5 minute processing wait; the game opened up immediately (presumably as a result). My installation doesn't seem to offer this when I launch CS;GO and I remember how badly To try and fix this I went via the top left Steam menu otions into Peeking inside With the above paragraph the game launched in about 6 seconds for me. Still not quite as snappy as that fresh install rootfs was able to pull off but still, this fixed the problem for me. This ginormous file size makes me wonder if a lot of my stuttering this year has come from this exact same problem. I deleted CS;GO's GLCache again and opened it, waiting 60 seconds and ran I have a gut feeling I've just accidentally discovered the source of my stutters when peaking enemies in MM during the months this bug resurfaces for me every so often (Months/Years in-between) while thinking it couldn't possibly be shader related given the vulkan shader processing steam is supposed to be doing... I deleted the CS;GO GLCache directory again but Steam did not offer to regenerate it with fossilize_replay when I launched CS;GO again, causing the 60s black-screen launch delay. Next I tried exiting Steam and deleting the appid's entire cache path with: Finally I tried deleting the homedir cache with GLCache and its UUID subdir system?All those GLCache subdirectories seem to be hypenless uuid's and don't seem to tie to anything on the system. I assume they're randomly generated and Steam is starting the game without checking if it needs to generate a new shadercache .bin for CSGO before each run. This is probably where it's up to Valve to permanently fix. Given my csgo appid has a few uuids in its GLCache shadercache directory all dated different months I suspect the UUID is rolling over every so often and Steam doesn't check if it needs to generate a new shadercache.bin for CS;GO. The UUID may be influenced by new package versions, steam versions, driver versions, randomly or otherwise - causing CS;GO to look in a new/empty This theory tracks the real issue here: Steam not offering to build a shadercache as-needed nor on-demand when I deleted the CS;GO's shadercahce directory. The problem is reproducible if you delete appid 730's shadercache directory. The real issue is that my Steam is not checking if it needs to build a shadercache with the Steam for one reason or another is not rebuilding the cache when there is none leaving it up to the game, slowly, at startup. The game's self-generated shader-cache is only a 52MB.bin compared to Steam's 1.1GB.bin and is probably where my stutters came from around the same time the game started taking a long time to open. I'm glad to have a lead on the cause of this at least in my case. The game is generating a new 52MB shadercache for itself because Steam isn't generating the full one for the game. every evening I open it to play with friends. This file is significantly smaller than the 1GB shadercache Steam should be generating (And with multiple threads). So I expect this same issue is also the cause of the stuttering I've experienced lately right as this slow launch problem popped up. Findings and SummaryIn my case Steam isn't generating the complete shadercache for CS;GO and the game is launching, seeing no shaders and generating its own incomplete shadercache file which is the reason the game takes 60 seconds for my PC to open and pins a cpu core to 100% for that duration. I suspect given the nature shaders, this is also why my initial peak's and fights with an enemy on a map causes the game to microstutter/pause briefly while it handles more shaders. TL;DR & Potential workarounds / What worked for me
|
|
Its been a few days now and CS;GO/Steam have been doing well with a consistent 6-10 second launch time after a few additional seconds of Steam doing vulkan shader preparation against the 1GB worth it already prepared. The game consistently opens in ~6-10 seconds when the game is launched from my steam library and as an added bonus, the game doesn't stutter at all anymore given the 1GB shader cache Steam generates vs the 50MB one the game usually does on its own for 60 seconds every launch. Something that's probably noteworth is that I deleted my steam-made csgo.desktop shortcut just in case it were causing Steam to skip its multi-threaded vulkan shader generation solution. I've been launching the game directly from the Steam library, though I don't explicitly recall shaders being generated by Steam when launched this way in the past. TBD. Overall, dropping my Steam's 4GB of Steam's shadercaching efforts by going to Again though, I also no longer using the steam-generated csgo.desktop shortcut to open the game - It is theoretically possible that the Steam Browser Protocol that steam game shortcuts invoke with could've been causing the any% Steam multithread shader skip as well. I haven't tested for that case so it has to be kept in mind until eliminated. If anyone feels like trying the above shader-dropping trickery this please let me know if it fixes the problem for you. Even if transiently. Further testing/evidence could provide a huge bump for Valve officially solving why Steam silently skips shader generation before the game launches. |
|
-vulkan |
|
Its been a while since my last comment but since the above actions in my larger comment the game has been consistently launching in ~6 seconds. Some nights I catch steam preparing with all 24 of my cpu threads. I don't know why Steam stopped preparing shaders before gameplay a few times this decade but that whole reset shader-cache download procedure did the trick. At least until the bug happens again. It should've clicked for me earlier but is still just a guess - csgo_linux64 was probably synchronously generating the shaders it needed to render everything involved for the main menu - causing the pause. Avoided by letting Steam generate a full 1.1GB shadercache file (Plus any in-game stuttering). I wonder if something trivial like temporarily running out of disk space causes Steam to stop generating them right before game launch. Will check that later in case its relevant. Unfortunately I still can't use E: It's 1w6d since this comment and as I opened CS;GO tonight; Steam spent about 4 minutes making new shaders for the game. Then it sat on 100% for 30 seconds while it merged them. The game took over a minute to launch. I ran I then went to Not sure why this is still an ongoing problem and I'm disappointed this happened again. But the workaround of regenerating seems to be consistent. |
and others
This isn't a major issue by any means, but it would be really nice if it could get looked into. Ever since moving over to linux full time, I've had an issue with CS:GO taking an unusually long time to launch.
I've just timed it, and when I launch the game from Steam, it takes a full 10 seconds before the system enters fullscreen mode, and then there is a solid black screen (I have -nosplash -novid set) for another 13 seconds. I don't recall having any sort of delay like this on Windows.. a few seconds at most.
So from launching the game to actually getting to the main menu, there is a total of a 23 second wait time. Here is a screen recording: https://www.youtube.com/watch?v=L5yuYx0zxp4
I'm running the game on a 2.5GB/s Samsung 950 Pro NVMe SSD.. it should be firing up pretty fast.
CS:GO is the only game I own that has this issue.
I would appreciate if someone could take a look. Thanks!
The text was updated successfully, but these errors were encountered: