From time to time, often after I’ve restored from sleep or finished playing a Steam game, one of my CPU cores is pinned at 100% with no indication of what might be doing it. Running htop, btop, or GNOME system monitor all show the same thing: CPU0 at 100% while the rest are doing near-nothing, and no process in particular seems to be using those resources.
If I restart, it’s back to normal, and sometimes I can play a game in Steam or let the computer go to sleep and it doesn’t do this, but it happens often enough that’s annoying/confusing so I’d like to know if there’s a way to either (a) diagnose which processes are using which CPU cores, or (b) somehow “reset” the checking of these values to make sure that something’s not just being misreported.
This is a desktop system running Arch & GNOME.
It’s probably Shader compilation. Funny enough the top result of my websearch is my own post/thread in Reddit 4 years ago. I had this exact same question on my old computer: https://www.reddit.com/r/linux_gaming/comments/kyf1wf/why_is_steam_using_one_core_always_but_doing/ Shader compilation is done from time to time in the background while Steam runs. This prepares games to run better.
Look if there is a process called
fosselize. That was the process name back then doing the Shader compilation.I’d never even heard of shader compilation. Apparently for the Steam Deck, Valve provides pre-compiled shaders for some games. What Is Shader Compilation and Why Does It Make PC Games Stutter?
Yes. That’s the benefit of having a single hardware to target. Same goes for consoles. They obviously know the hardware (like in Steam Deck’s case) and can precompile and ship it. There was plans (or just talks? not sure if this was ever realized) that users can download precompiled Shaders from other users, if its the exact same hardware.
Steam can download precompiled binaries that’s suitable for any system it they exist. If you turn it on, they’ll also collect shaders from you for others to download (not P2P).
It’s often said in r/linux_gaming that you no longer need shader precompilation, though without giving any reason. In my experience turning it off doesn’t have any performance penalty. But games with baked -in shader compilation will take 10 minutes to do it themselves on every launch which is annoying af.
The problem with fosselize is that it’s currently bugged, and happens to precompile way more things than are needed, such as all workshop content that you might not have installed which takes a really long time + bloats up the shader cache in size. On anything that’s not low-end, it’s pretty much a waste of time since shader compilation is easily done on runtime.
Some issues on the things I’ve mentioned that Valve hasn’t seem to have responded yet: bloat, time
Thanks for confirmation. After all, Shaders ARE actually shared; which is a good thing. Maybe for certain games its no longer needed to have Shader pre-compilation enabled. Because games does it themselves or maybe because the download of the compiled shaders from Valve (or collected ones) they come to conclusion the pre-compilation option is no longer needed? It’s hard to say if people do not explain their recommendation. It’s also not a straight forward and easy thing to test, so people can easily end up with wrong conclusions.
As for the annoying factor, every update requires pre-compilation (if enabled and only those games that need it off course). And if you have lot of games installed, it can be really annoying too.
If you have a reasonably up to date mesa and use a Proton version with a new enough DXVK, DXVK can utilise Graphics Pipeline Libraries to link shaders just like a d3d11 driver on Windows would, eliminating stutter.
I believe shader precomp is used for some video codec edge cases though, so YMMV depending on the game.