RogueSix wrote on Mar 11, 2025, 22:12:
Again: The problem is not the requirement to install a chipset driver. The issue is keeping the compatibility database "inside" the chipset drivers up to date which you can not even influence because you 100% depend on AMD in that regard (just like you depend 100% on M$ to keep the Shitbox GameBar garbage up to date). *That* is the problem.
This might be less problematic if you never play any new games/releases anyway but if you like playing new games (maybe even lesser known indie games) or if you do really crazy shit like participating in a Steam NextFest then good luck.
There is going to be a 100% chance that neither the GameBar nor your AMD chipset drivers will correctly recognize most of the game demos during a NextFest as a game application, i.e. you will have to do a ton of manual tuning to get the most out of your NextFest demos.
Sure, some people enjoy playing the manual core allocation game but personally I'm weird and I would rather focus my gaming time on the actual demos.
I agree with you that approaches based on a database of known processes is icky. This is unfortunately super prevalent especially in the Windows ecosystem (Windows itself and every GPU driver have massive dbs for apps/games that apply various quirks, sometimes for backward compat, other times for perfomance tuning). Of course every engineer prefers a generic, self-tuning approach, because it makes systems easier to predict and reason about, and is more future-proof in the face of unknown workloads.
The stuff I quoted is about what AMD has in place (on Linux, since I know this better than Windows) for the generic, db-less approach - a HW-driven way to classify threads at runtime based on their behavior, and allow the OS kernel scheduler to make useful decisions where to run them. Along with P-state-related mechanisms to handle core preferences dynamically based on their non-heterogenous characteristics.
Hopefully this is enough to make the system behave well decently. If not, I'd advocate for the other approach I mentioned toward the end, where, when the Steam client (or something else) launches a game into a cgroup (a cgroup is a way to track groups of processes and e.g. set quotas and other properties on them) that entire group just gets pinned on the V-Caches or has scheduler hints set, at launch time (and if they launch child processes into the same group the preference is inherited). This is then basically for all games via the context they get launched in, and doesn't need anything db-based or running permanently.
If this
also still isn't good enough, then it's time for an API that lets games itself announce a preference for whether they believe they can benefit from being distributed over more cores vs. keeping their threads together on performance cores, as an additional hint to either the OS scheduler or a launcher. This is the one part that could be db-augmented for older games that won't see updates, but then those probably aren't perf-critical enough to warrant the complexity.