ValveSoftware
Excessive CPU Usage when no game is running
I'm noting an issue with fossilize_replay doesn't properly exit after a game has closed down, it'll peg the CPU usage to 100% on 2 cores on Linux, I'll have played a game for a couple hours maybe and quit the game, only to come back later to find CPU usage is still excessively high, because I can hear the fans ramped up more than they should be when not running a game or running any computationally intensive applications. I can see it's usage in htop having CPU utilization being at 100%, I can see it has 2 threads running the same thing with shadow processes, that even if you kill one of them, it doesn't kill the other and has to be killed separately. I feel this might need a kill script after a game has exited that looks for fossilize_replay running to kill it.
Possible related issues: #247 , #84
Computer Information:
Manufacturer: ASUSTeK COMPUTER INC.
Model: PRIME Z270-A
Form Factor: Desktop
No Touch Input Detected
Processor Information:
CPU Vendor: GenuineIntel
CPU Brand: Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz
CPU Family: 0x6
CPU Model: 0x9e
CPU Stepping: 0x9
CPU Type: 0x0
Speed: 4500 MHz
8 logical processors
4 physical processors
Hyper-threading: Supported
FCMOV: Supported
SSE2: Supported
SSE3: Supported
SSSE3: Supported
SSE4a: Unsupported
SSE41: Supported
SSE42: Supported
AES: Supported
AVX: Supported
AVX2: Supported
AVX512F: Unsupported
AVX512PF: Unsupported
AVX512ER: Unsupported
AVX512CD: Unsupported
AVX512VNNI: Unsupported
SHA: Unsupported
CMPXCHG16B: Supported
LAHF/SAHF: Supported
PrefetchW: Unsupported
BMI1: Supported
BMI2: Supported
F16C: Supported
FMA: Supported
Operating System Version:
"Manjaro Linux" (64 bit)
Kernel Name: Linux
Kernel Version: 6.15.9-2-MANJARO
X Server Vendor: The X.Org Foundation
X Server Release: 12401008
X Window Manager: KWin
Steam Runtime Version: steam-runtime_1.0.20250519.130917
Client Information:
Version: 1751405894
Browser GPU Acceleration Status: Enabled
Browser Canvas: Enabled
Browser Canvas out-of-process rasterization: Enabled
Browser Direct Rendering Display Compositor: Disabled
Browser Compositing: Enabled
Browser Multiple Raster Threads: Enabled
Browser OpenGL: Enabled
Browser Rasterization: Enabled
Browser Raw Draw: Disabled
Browser Skia Graphite: Disabled
Browser Video Decode: Enabled
Browser Video Encode: Disabled
Browser Vulkan: Disabled
Browser WebGL: Enabled
Browser WebGL2: Enabled
Browser WebGPU: Disabled
Browser WebNN: Disabled
Video Card:
Driver: NVIDIA Corporation NVIDIA GeForce RTX 3070/PCIe/SSE2
Driver Version: 4.6.0 NVIDIA 575.64.05
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 143 Hz
VendorID: 0x10de
DeviceID: 0x2488
Revision Not Detected
Number of Monitors: 1
Number of Logical Video Cards: 1
Primary Display Resolution: 2560 x 1440
Desktop Resolution: 2560 x 1440
Primary Display Size: 23.50" x 13.23" (26.97" diag), 59.7cm x 33.6cm (68.5cm diag)
Primary VRAM: 8192 MB
Sound card:
Audio device: Realtek ALC1220
Memory:
RAM: 31773 Mb
VR Hardware:
VR Headset: None detected
Miscellaneous:
UI Language: English
LANG: en_AU.UTF-8
Total Hard Disk Space Available: 1876389 MB
Largest Free Hard Disk Block: 981510 MB
Storage:
Number of SSDs: 4
SSD sizes: 4000G,2000G,2000G,525G
Number of HDDs: 0
Number of removable drives: 0
fossilize_replay is meant to run when the game is not running, so the behavior of it running 100% on some cores after the game exited is expected. If you start the game again, it should ramp up to more cores and Steam should show that it is pre-compiling Vulkan shaders. This may be one way to finish it faster.
But I'm pretty sure that it is still not normal to run for multiple hours. If your CPU-integrated GPU is enabled, fossilize may run for both GPUs although the game will ever only use your dGPU. You can try disabling integrated graphics in the BIOS.
Also, your shader cache may contain very old shaders, especially for some games this extents the runtime of fossilize a lot. Try something like this (while the Steam client is completly closed):
# find shader caches older than 180 days
find $HOME/.steam/steam/steamapps/shadercache/*/ -type f -mtime +180
# delete those files
find $HOME/.steam/steam/steamapps/shadercache/*/ -type f -mtime +180 -delete
I run that once in a while to purge old and stale data, and it helped my system.
Why is it like this? I don't want this running after a game has closed pegging cores at 100% like that. That's not normal behavior for apps, in fact I'd call that malicious software if it's running like that in the background. Major red flags right there. If the purpose is to Pre-Compile Shaders for games, it should only do it when a game is about to be run, and exit immediately after it's complete, but should NOT stay running after a game has exited when there are no shaders to pre-compile for the shader cache. Having to run a separate command to clear old shader cache is not something people will casually do every so often.
It cannot and does not run while the game is running - for maybe not so obvious reasons. But I think you can adjust Steam to not do background compilation of shaders. It should then only run before you start a game.
The reason you're seeing that behavior is most likely that you're having a secondary GPU, and after the game existed, fossilize finds that all the collected shaders are missing compilation for that other GPU.
Hello this is an interesting find, my workaround to this, is to just rather close off steam, as i think is more time saving leaving pre-shaders on then to do while game bootup. Regarding steam not knowing targeting a GPU for the specific shaders, would it be possible if steam had a select box for fossilize to target a selected GPU? For me thats a more viable option as i too need the iGPU for things, and is more power efficient in light use.
