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.

  • thingsiplay@beehaw.org
    link
    fedilink
    arrow-up
    4
    ·
    6 hours ago

    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.

    • Quail4789@lemmy.ml
      link
      fedilink
      English
      arrow-up
      2
      ·
      2 hours ago

      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.

      • Commiunism@lemmy.wtf
        link
        fedilink
        arrow-up
        1
        ·
        3 minutes ago

        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

      • thingsiplay@beehaw.org
        link
        fedilink
        arrow-up
        1
        ·
        34 minutes ago

        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.