THE JESUS

yeah, if you use the mask, the policy is unnecessary. It still seemed to provide minor benefits in 1% in some scenarios based on my testing because it probably decreased the statistical likelihood of the behavior explained in the original post (overcrowding one core with unrelated things, so having the game thread + say, your audio dpc's, etc.). Ultimately, the real fps killer happens when your game threads keep getting quanti scheduled on the core 0 and then have to wait or be preempted by other things. The policy is basically a "mini 0/1 affinity" in some cases because it makes it so that the scheduler is willing to schedule the game thread even on a core that CPPC is not reporting as "performant". For example - you should try ARC Raiders, where there is no way to enforce core 0/1. In that game, the policy has an absurdly large effect, check the screenshot. Since you can't prevent the scheduling issue directly, the thread scheduling policy in that case is the next best thing. The reality is that Microsoft and AMD have to work together to define the semantics of CPPC, and what should happen when a core is marked as performant or efficient in the context of games. Remember lower stdev = better! And you can see in the frametime percentile curves how it has a disproportionate effect on high percentile frametimes - basically, it makes it WAY less likely for a frame to last VERY long versus the default behavior, which matches what you'd expect to happen if the game has a high chance of being preempted and/or its L1/L2 cache being flushed of what it needs because of other threads being scheduled on the same core. I think this issue has gone unnoticed for so long because people wrote it off as some "quirk" of specific systems, and "the core 0/1 trick". The issue is larger. The issue is that CPPC is actively informing the scheduler to do something that harms game performance, and in general, the scheduler seems to be too game agnostic even when things like Windows' "Game Mode" are turned on, which you'd expect would make the scheduler be a bit smarter than this. Also, I think no one had realized that the whole concept of "heterogeneous" was actually being applied even on AMD systems. I think most people kept thinking heterogeneous == "P and E cores" only. But clearly, the semantics there are overloaded and CPPC is a way to "soft" classify cores in a way that ends up matching the behavior of Intel's P/E on Windows.

Did I just wake up in 2017 or what because this is CRAZY