Woher stammt eigentlich die Ansicht, dass SMT bei Intel hier genutzt wird? Aus den Screens kann man das so erstmal gar nicht rauslesen. Der Screen von CapFrameX aus Twitter zeigt einen 10900er 10C Intel mit aktivem SMT und dort ist mit im Schnitt 50% auch nur jeweils (gleichzeitig) ein Thread aktiv. Ein paar kleine Peaks bescheinigen mehr wie die 50% Last. Aber das kann wieder alles und nix sein.
Lasst euch nicht vom Taskmanager veralbern. Jeweils Thread 0 und 1, 2 und 3 usw. gehören zusammen. Die Summe beider Diagramme muss mehr wie 100% sein, damit SMT aktiv in Nutzung ist. Der Rest -> regelt der OS Threadscheduler, der seit spätestens Win7 versucht, möglichst nur einen der beiden Hardwarethreads zu belasten, sofern es eben geht und nicht anders erzwungen wird.
Auffällig dabei ist, dass im zweiten Bild mit dem 12C Ryzen die 50% im Schnitt auch nicht gebrochen werden. Beides lässt darauf schließen, dass im Spiel nur jeweils ein Thread pro Core genutzt wird.
Btw. ist das nicht zwingend unnormal, dass der Taskmanager beide Threads mit Last anzeigt, bei meinem Intel System ist das im exakt gleichen Programm mit nachweislich nur einem Thread Last (bspw. via Prime95 simuliert oder anderen) identisch. Auf dem Intel werden beide Threads bei hart Pinnung auf beide eines Cores belastet. Auf dem Ryzen wird das primär nicht gemacht. In Summe läuft aber dennoch nur jeweils einer. Das muss sicher nicht überall so sein - aber als Anhaltspunkt, ist das mMn kein wirkliches Indiz ohne nähere Untersuchung (bspw. via Windows Performance Analyzer)
Spawnt man nun, wie mit dem Trick hier offenbar, einfach mehr Threads und lässt das Spiel in der Form mehr Ressourcen nutzen, dann kann das positive aber auch negative Effekte haben. Negativ wird es dann, wenn ein zweiter Thread auf dem physischen Kern im anderen Thread Ressourcen klaut, wo eben der API Thread zur Bildberechnung läuft. Jedes Frame wird in einer Schleife erzeugt - und im API Limit ist es eben so, dass die Abarbeitungsgeschwindigkeit dieser Schleife limitiert. IdR ist es dort entscheidend, so viel wie möglichst pro Thread Bumms zu haben um dort maximale Performance zu bekommen. Kontraproduktiv ist, im zweiten Thread Ressourcen zu benutzen, die dann die Abarbeitung dieses einen Threads behindern.
In anderen Fällen, bspw. wenn die CPU allgemein schmal ist, und nicht die API limitiert, sondern bspw. Teile des Spielebackends, KI, Physik, whatever, dann bringt das erhöhen des Threadcounts hingegen durchaus Punkte. Die Frage ist eher, was hat sich hier CDP bei gedacht? Single Thread pro Core ist besser für breite CPUs und HighFPS. Double Thread pro Core ist besser für schmale CPUs. Das dynamisch zu regeln halte ich in einer derartigen Spielwelt für unmöglich, dafür ist das zu stark schwankend.
EDIT: in Bildform -> Intel CPU mit nem Single Prime 95 Thread:
AMD CPU mit nem Single Prime95 Thread:
Der Threadscheduler verhält sich einfach anders...