Blizzard-Spiele bremsen AMD-Prozessoren bewußt (?) aus

[pilzsammler2002]

Es ist zwar schon etwas her aber es gab damals ja häufiger mal Threads im battlenet bezüglich VMs mit AMD CPUs und deren Leistung in Games wie WOW und SC2...

Zum Bsp.:
https://us.battle.net/forums/en/sc2/topic/16203380383

https://us.battle.net/forums/en/wow/topic/4079871855

https://www.reddit.com/r/Amd/comments/6lej62/amd_benchmarks_being_alternated_shown_by_spoofing/

Gibt es da jetzt auch mal richtige Tests zu oder hat jemand sowas selber mal getestet?
Oder ist das nur nen Mythos gewesen? :freak:

[Leonidas]

Selbst der allgemeine Performance-Rückstand von AMD in Blizzard-Spielen wurde bislang noch nicht so richtig thematisiert - weil eben nur dort anzutreffen.

Das es nun an einer Hardware-ID hängt, macht die Sache allerdings fetter. Blizzard musste sich vorher schon fragen lassen, was sie für einen Mist programmieren - und nun, ob sie hier nicht gerade in wettbewerbsrechtliche Verwicklungen hereinrennen. Wenn AMD mal wenigstens einen Teil des (sowieso nutzlos verschwendeten) PR-Budgets in Untersuchungen solcher Sachverhalten stecken würde ... Allein die Presseberichterstattung über den Fall selber wäre Gold für AMD wert.

[uweskw]

Das wär doch mal eine Aufgabe für ein engagierte Online Magazin.
Aber die meisten kauen lieber die gleichen Benchmarks zum 27ten mal durch, und heben die Marktführer in den Himmel.
Da kann man halt nichts falsch machen.

Greetz
US

[dildo4u]

Das sind alles Asbach Engines,es machte damals Sinn auf wenige Thread's mit hohem Takt zu optimieren da es sich um reine PC Game's handelt.Erst bei Overwatch mussten sie wirklich Arbeit reinstecken,da das mit 60fps auf Jaguar Core's laufen musste.

200fps auf Ryzen 1600:

https://youtu.be/qXuHt20bwSU?t=5m26s

[Exxtreme]

Hier ist anzumerken, dass die Spiele in einer VM gelaufen sind. Kann gut sein, dass diese VM das Verhalten auslöst. Und ich bin mir sogar sicher, dass VMs CPU-spezifischen Code enthalten.

Da müsste man evtl. andere VMs probieren.

[Birdman]

Hier ist anzumerken, dass die Spiele in einer VM gelaufen sind. Kann gut sein, dass diese VM das Verhalten auslöst. Und ich bin mir sogar sicher, dass VMs CPU-spezifischen Code enthalten.

Da müsste man evtl. andere VMs probieren.
Interessant wäre ja gewesen, wenn man die Performance der AMD CPU auch ohne den virtualization Layer gesehen hätte.
Nur wenn diese schlechter wäre als in einer VM mit Intel CPU IDs, dann würde ich auch meine Augsbrauen runzeln.

Wenn man durch die VM aber einfach mit emulierter Intel CPU weniger Performance verliert als mit AMD, dann deutet das eher darauf hin dass entweder die VX Unterstützung von Architektur A schlechter ist oder dass die Virtualisierungssoftware nicht auf beiden Architekturen gleich gut läuft.

Trotzdem finde ich das ganze ein hochinteressantes Thema - mangels IGP oder zweiter Grafikkarte kann ich das an meinem PC aber selber nicht durchspielen.
Zudem habe ich nur ne Intel CPU und keine von AMD, was im vorliegenden Falle aber interessanter wäre.

[Jasch]

Wenn ich das richtig verstanden habe ist es wirklich so,
das Amd native langsamer ist als Amd mit intel ID in VM.

[ottoman]

Genau so ist es. Hier ist der Link zu dem Test: http://realmofespionage.blogspot.de/2015/01/starcraft-ii-cpu-benchmarking-with-amd.html

Dort wurde StarCraft 2 in einer VM getestet. Geändert wurde nur die CPUID in der VM, also die Kennung mit welcher der Prozessor identifiziert wird. Das heißt es ist eine AMD CPU, die sich in der VM als Intel CPU ausgibt. Und damit waren die FPS in SC2 höher.

Ich werde das selbst mal heute Abend testen und noch ein paar Infos posten, wie man das nachstellen kann, zumindest in VMWare. Ich habe aber nur eine Intel CPU.

[BigKid]

Es könnte ja auch daran liegen, dass Intel spezifische Optimierungen dem Ryzen (teilweise) besser schmecken als die "alten" AMD Optimierungen... Nur weiss das manche Engine noch nicht...
Oder ?

[ottoman]

Der getestete Prozessor war kein Ryzen sondern ein AMD FX-8350. Der Test ist auch von 2015.

[Ganon]

Intel-spezifische Optimierungen wären aber reichlich dämlich. Normalerweise fragt man spezifische CPU-Features ab (SSE4, AVX, ...) und nicht schlicht "if CPUID = Intel then runBetterCode()".

Ansonsten müsste man alles über Kreuz testen, aka:
- Spiel nativ auf Intel
- Spiel nativ auf AMD
- Spiel in VM auf Intel
- Spiel in VM auf AMD
- das alles noch mal mit unterschiedlicher CPUID (AMD auf Intel, Intel auf AMD)

Es gibt durchaus Fälle wo in Benchmarks die Ergebnisse in einer VM besser ausfallen, weil die VM schlicht diverse Dinge nicht tut. Beispielsweise ignoriert VMWare oder VirtualBox (weiß nicht mehr wer) einen fsync. Somit sind z.B. alle Filesystembenchmarks in diesen VMs wertlos.

[ottoman]

Hier ist ein Blog Post, der das noch umfangreicher beschreibt: http://www.agner.org/optimize/blog/read.php?i=49

Will man seine Intel CPU zu AMD machen (GenuineIntel => AuthenticAMD), muss man folgende Zeilen in die Konfiguration der VMWare VM schreiben:

cpuid.0.ebx = "0110:1000:0111:0100:0111:0101:0100:0001"
cpuid.0.ecx = "0100:0100:0100:1101:0100:0001:0110:0011"
cpuid.0.edx = "0110:1001:0111:0100:0110:1110:0110:0101"


Anders herum geht es wohl auch, das kann ich aber nicht verifizieren. Hier ist der Beitrag aus dem verlinkten Blog:

By analogy to Andrew's code, I assume that you can make an AMD processor spoof to be "GenuineIntel" with these lines:
cpuid.0.ebx = "0111:0101:0110:1110:0110:0101:0100:0111"
cpuid.0.edx = "0100:1001:0110:0101:0110:1110:0110:1001"
cpuid.0.ecx = "0110:1100:0110:0101:0111:0100:0110:1110"

The Intel software also checks the family number, which should be set to 6:
cpuid.1.eax = "0000:0000:0000:0001:0000:0110:0111:0001"



Falls man eine Fehlermeldung beim Start der VM erhält, muss man noch die folgende Zeile hinzufügen:
featureCompat.enable = FALSE

[ottoman]

@Ganon
Es geht um den Intel Compiler. Die damit generierten Programme führen unterschiedlichen Code aus, je nachdem welche CPU verwendet wird.
The system includes a function that detects which type of CPU it is running on and chooses the optimal code path for that CPU. This is called a CPU dispatcher. However, the Intel CPU dispatcher does not only check which instruction set is supported by the CPU, it also checks the vendor ID string. If the vendor string says "GenuineIntel" then it uses the optimal code path. If the CPU is not from Intel then, in most cases, it will run the slowest possible version of the code, even if the CPU is fully compatible with a better version.
siehe http://www.agner.org/optimize/blog/read.php?i=49

[Ganon]

Wie da aber auch steht hat Intel das Verfahren damit abgeschlossen, dass der Intel Compiler dies nicht mehr tut. D.h. es gibt u.a. folgende Möglichkeiten:

- Intel tut's trotzdem (die Abfrage müsste sich ja im Binary finden lassen (?)), dann müsste AMD einschreiten
- Blizzard nutzt einen uralten Intel Compiler, dann müsste Blizzard tätig werden
- eine von Blizzard benutzte Middleware ist veraltet/noch mit altem Compiler erstellt

Aber die ganzen Ergebnisse sind teilweise uralt, d.h. es müsste erst mal jemand testen, ob es auch heute noch der Fall ist. Also im Fall von Blizzard-Spielen.

Andere Benchmarks müssten wieder anders bewertet werden. Der im Startpost verlinkte OpenCL-Test da auf Reddit ist halt ganz was anderes. OpenCL-Code wird in der Regel on-the-fly für die genutzte CPU optimiert und so ist es durchaus logisch, dass besserer Code für eine AMD CPU rauskommt, wenn man diese für eine andere Intel-CPU kompiliert. Ein Compiler muss eine CPU auch kennen, um für sie zu optimieren. Das muss nicht mal ein übler Vorsatz sein.

[gravitationsfeld]

Hier ist anzumerken, dass die Spiele in einer VM gelaufen sind. Kann gut sein, dass diese VM das Verhalten auslöst. Und ich bin mir sogar sicher, dass VMs CPU-spezifischen Code enthalten.

Da müsste man evtl. andere VMs probieren.
Nein, kann es nicht. Wenn die CPU-ID wirklich die Performance aendert, dann ist da was im Busch.

Vielleicht benutzt Blizzard wirklich den Intel-Compiler oder deren Math-Library.

[Exxtreme]

Nein, kann es nicht. Wenn die CPU-ID wirklich die Performance aendert, dann ist da was im Busch.

Vielleicht benutzt Blizzard wirklich den Intel-Compiler oder deren Math-Library.
Es kann auch sein, dass die VM die CPU-ID ausliest und dann schneller läuft weil sie herstellerspezifische Dinge nutzt.

Ich glaube zwar durchaus, dass das an den Spielen liegt aber die VM ist ein massiver Eingriff in der gesamten Testinfrastruktur. Und man sollte das nicht aus den Augen lassen, IMHO.

[Screemer]

liese sich nicht die cpu-id per biosmod spoofen? opcode cpuid per microcodeupdate verändern vielleicht.t damit könnte man der vm-geschichte auch aus dem weg gehen.

[x-force]

mit ner vm spielen ist wie mit ner knieverletzung 100m laufen.
das macht niemand der vernünftig ist.

[gravitationsfeld]

Es kann auch sein, dass die VM die CPU-ID ausliest und dann schneller läuft weil sie herstellerspezifische Dinge nutzt.
:confused:

Das ergibt keinen Sinn. Die CPU-ID wird entweder durchgereicht oder nicht. In dem Fall wird sie nicht durchgereicht, sondern von der VM geaendert. Was soll da an der VM-Performance aendern?

VMs emulieren auch keinen User-Space-Code. Er wird ganz normal ausgefuehrt, nur Kernel-Calls werden vom Hypervisor abgefangen.

Im Uebrigen hat auf die VM-Performance nur die Virtualisierungs-Extensions eine Auswirkung und wenn die nicht benutzt wird dann laeuft heutzutage eigentlich die VM erst gar nicht.

Ich glaube zwar durchaus, dass das an den Spielen liegt aber die VM ist ein massiver Eingriff in der gesamten Testinfrastruktur. Und man sollte das nicht aus den Augen lassen, IMHO.
Wenn der selbe User-Space-Code nur weil die CPU-ID von der VM ausgetauscht wird auf einmal signifikant schneller laeuft, dann ist es piep egal was da an der "Testinfrastruktur" geaendert wird. Alter.

[senfei]

Wie da aber auch steht hat Intel das Verfahren damit abgeschlossen, dass der Intel Compiler dies nicht mehr tut.
Laut INTEL läuft das aber immer noch so ab:
https://software.intel.com/en-us/articles/optimization-notice/#opt-en

[Exxtreme]

Wenn der selbe User-Space-Code nur weil die CPU-ID von der VM ausgetauscht wird auf einmal signifikant schneller laeuft, dann ist es piep egal was da an der "Testinfrastruktur" geaendert wird. Alter.
OK, hast recht. Da hatte ich bissl Gehirnverknotung bei der Vorher-nachher-Problematik drin. Das wird doch am Spiel liegen müssen.

[Ganon]

Laut INTEL läuft das aber immer noch so ab:
https://software.intel.com/en-us/articles/optimization-notice/#opt-en

Ich habe die ganze Sache damals nicht bis ins unendliche verfolgt. Aber in dem Text steht nur, dass sie nicht darauf achten, ob erzeugter Code jetzt schlecht für eine Non-Intel CPU wäre.

Das was ich aber meinte war eine künstliche Beschränkung im entstandenen Binärcode, die Optimierungen im Stil von "IF CPU == Intel THEN highPerformanceCode() ELSE slowStandardCode()". D.h. auch wenn die CPU entsprechende CPU-Features hätte, würde der Code nicht ausgeführt werden.

Dieses Vorgehen hat Intel, soweit ich weiß, eingestellt. Er optimiert weiterhin für spezielle Intel-CPUs, aber schließt nicht mehr kategorisch alles andere aus. Man darf mich hier gerne korrigieren. Aber ich sehe das alles weniger kritisch. Wer den Intel Compiler benutzt, um auch Non-Intel CPUs zu unterstützen, der begeht schon mal einen Fehler an sich.

Generell wäre ich aber an einer Prüfung des Ganzen interessiert, die nicht mehrere Jahre alt ist.

[gravitationsfeld]

Ich finde immer noch Intel haette dazu gezwungen werden muessen das Ganze komplett bleiben zu lassen. Sie haben immer noch den Disclaimer auf ihrer Webseite und keine klare Aussage was AMD genau vorenthalten wird.

[Lord Wotan]

Hier ist anzumerken, dass die Spiele in einer VM gelaufen sind. Kann gut sein, dass diese VM das Verhalten auslöst. Und ich bin mir sogar sicher, dass VMs CPU-spezifischen Code enthalten.

Da müsste man evtl. andere VMs probieren.
Wer lässt denn seine aktuellen Spiele in einer VR laufen. Das kostet doch immer Leistung.

[aufkrawall]

Welches Spiel außer WoW von Blizzard ist denn noch so dermaßen "biased", was die Hardware angeht?
Das läuft ja auch auf Radeons im GPU-Limit wie Abfall. Bei SC2 sind die dicken Intel E-CPUs laut PCGH auch komisch langsam.

Ist jetzt halt auch Schnee von gestern, Overwatch ist aktuell und zeigt kein seltsames Verhalten.

[Ganon]

Wer lässt denn seine aktuellen Spiele in einer VR laufen. Das kostet doch immer Leistung.

Wenn du 2-3 Beiträge weiter liest, dann siehst du, dass es darum geht/ging, dass das Spiel in einer VM _besser_ läuft, wenn man vorgibt eine Intel-CPU zu haben.

Welches Spiel außer WoW von Blizzard ist denn noch so dermaßen "biased", was die Hardware angeht?

Das hat vermutlich noch niemand großartig untersucht. Ich weiß aber auch nicht wie viele Spiele überhaupt mit dem Intel Compiler erstellt werden. Mir ist eher so, als wenn die meisten Firmen den Microsoft Compiler nutzen.

[Raff]

Ist jetzt halt auch Schnee von gestern, Overwatch ist aktuell und zeigt kein seltsames Verhalten.

Im Gegenteil, das Spiel läuft hervorragend auf beinahe jeder Grafikkarte, produziert "neutrale" Ergebnisse und weiß Prozessorkerne zu nutzen. Besser geht's kaum – und das mit einer High-Level-API. ;)

MfG,
Raff

[Emperator]

Wer lässt denn seine aktuellen Spiele in einer VR laufen. Das kostet doch immer Leistung. Leute die Linux als Main-OS nutzen und keinen Bock auf Dual-Boot haben.
Und der Leistungsverlust ist vernachlässigbar, bei manchen gibt es keinen Unterschied, manche haben 5-10% schlechtere FPS und es gibt auch Spiele die in einer VM etwas höhere FPS haben, warum auch immer ^^

How fast is KVM host vs virtual machine performance (https://forum.level1techs.com/t/how-fast-is-kvm-host-vs-virtual-machine-performance/110192)

[Daredevil]

Krass, so ein Szenario ist mir ja völlig weltfremd.
Unter Linux eine Windows VM erstellen, um damit Games zu zocken. ;D Klasse.

@Topic
Ich glaub da nicht dran.
Da gibts so viele Faktoren, die da mitspielen können.
Blizzard zu unterstellen, sie würden Intel extre besser laufen lassen ist schon ein wenig frech.

[MikePayne]

Mich würde es nicht wundern.
AMD hat bei SC2 immer seltsam abgestunken und wurde vom Intel-Lager entsprechend ausgeweidet.

Das Szenario ist nicht praxisnah (mit der VM), aber wenn eine AMD CPU mit anderer CPUID schneller läuft, dann sieht das schon nach Vorsatz aus.

[Lord Wotan]

Leute die Linux als Main-OS nutzen und keinen Bock auf Dual-Boot haben.
Und der Leistungsverlust ist vernachlässigbar, bei manchen gibt es keinen Unterschied, manche haben 5-10% schlechtere FPS und es gibt auch Spiele die in einer VM etwas höhere FPS haben, warum auch immer ^^

How fast is KVM host vs virtual machine performance (https://forum.level1techs.com/t/how-fast-is-kvm-host-vs-virtual-machine-performance/110192)
Linux hingt doch bei Spielen von der Leistung auch schon um Welten gegenüber Windows hinterher. Da müsste doch eine Game VR unter Linux noch mehr bremsen. Und so richtig funktioniert ja die DirectX bzw 3D gar nicht richtig bei einer VR oder?

[gravitationsfeld]

Linux hingt doch bei Spielen von der Leistung auch schon um Welten gegenüber Windows hinterher.
Das ist falsch. Linux laeuft in der Regel schneller als Windows wenn die Applikation Vulkan oder OpenGL verwendet.

[Relic]

Linux hingt doch bei Spielen von der Leistung auch schon um Welten gegenüber Windows hinterher. Da müsste doch eine Game VR unter Linux noch mehr bremsen. Und so richtig funktioniert ja die DirectX bzw 3D gar nicht richtig bei einer VR oder?

Dieser Post protzt nur so von Vorurteilen und Halbwissen :)

[Ganon]

Da müsste doch eine Game VR unter Linux noch mehr bremsen.

Informiere dich bitte, wie eine virtuelle Maschine funktioniert. Und VM, nicht VR.

Ein Computer, 7 virtuelle Windows-VMs, zocken alle Crysis 3 (https://www.youtube.com/watch?v=opX-AsJ5Uy8)

[pilzsammler2002]

Wollte es auch gerade kommentieren.

Dank PCIE passthrough wird man den unterschied zwischen VM und "straight metal" nicht wirklich merken :freak:

[BlacKi]

:confused:

Das ergibt keinen Sinn. Die CPU-ID wird entweder durchgereicht oder nicht. In dem Fall wird sie nicht durchgereicht, sondern von der VM geaendert. Was soll da an der VM-Performance aendern?
die vm simuliert eine cpu. was ist, wenn die vm die simulierte cpu in vm langsamer macht?

[Exxtreme]

die vm simuliert eine cpu. was ist, wenn die vm die simulierte cpu in vm langsamer macht?
Das Problem ist, die Spiele laufen in der VM schneller(!) als ohne VM wenn man die CPU-ID von AMD auf Intel ändert. Das ist definitiv nicht mehr koscher.

[Achill]

die vm simuliert eine cpu. was ist, wenn die vm die simulierte cpu in vm langsamer macht?

KVM und auch andere Linux-Hypervisor simulieren nicht - sie virtualisieren. Sprich VMs werden unter Linux zur Isolation eingesetzt, dies passiert sehr hardware nah. Konkret sieht das so aus, dass in der Regel direkter Zugriff oder Zugriff durch einen ganz dünnen SW-Layer erfolgt. Das Programm läuft direkt auf der CPU umgesetzt durch HW-Virtualisierung mit AMD-V oder Intel VT-x (https://de.wikipedia.org/wiki/X86-Virtualisierung).

Die Verluste im Vergleich zu Bare Metal sind sehr gering - solange man den Host nicht überbucht (also z.B. mehr virtuelle CPUs definiert und nutzt als physikalisch Vorhanden).

Es gibt auch Simulatoren wie Bochs (https://en.wikipedia.org/wiki/Bochs) - hier wird ein PC simuliert inkl. CPU und man nutzt - wie bei Wiki ausgeführt - dies um SW-Teile eines Betriebssystem zu entwickeln bzw. Register zu debuggen.

[Birdman]

Die Verluste im Vergleich zu Bare Metal sind sehr gering - solange man den Host nicht überbucht (also z.B. mehr virtuelle CPUs definiert und nutzt als physikalisch Vorhanden).

Achtung! Der Virtualisierungs-Layer macht durchaus mehr, u.a. bestimmt er welche CPU Caps dem Gast Betriebssystem mitgeteilt/durchgereicht werden.
Daher kann die CPU-Performance in einer VM durchaus deutlich tiefer sein, als es im Bare Metal Betrieb wäre.

[BlacKi]

Das Problem ist, die Spiele laufen in der VM schneller(!) als ohne VM wenn man die CPU-ID von AMD auf Intel ändert. Das ist definitiv nicht mehr koscher.
könnte nicht aber auch windows das problem sein? zb. dass das OS nur die VM sieht(also kein spiel und somit keine leistung drosselt oder features deaktiviert) und im OS der VM ja sowieso eine intel id vorhanden ist.

komisch ist das auf jedenfall, nur muss das nicht unbedingt das spiel sein, auch wenn es naheliegt.

[hmmm]

Das ist AMDs Baustelle.
Anders als Früher "optimiert" Intel nicht mehr "einfach" bei einer vorhandenen Intel CPU sondern Intel "optimiert" Modell Bezogen (Core, Core2,...)
Zudem wird nicht für einen Befehlssatz sondern für eine CPU optimiert und dies kann (und will) Intel verständlicherweise nicht für AMD CPUs machen.

Selbst wenn ein Entwickler nun den SSE(,...) Code trennt und auch für AMD optimieren will, womit soll er das machen? Welcher Compiler? GCC ist da (für AMD) zwar besser als der Intel (für AMD) aber selbst der ist eher suboptimal.

[Eldoran]

So 2008 habe ich mal händisch SSE Pfade für ein avisynth Plugin gebaut. Im Endeffekt waren dann allerdings die noch besser optimierte Routinen von x264 besser und dort war es zumindest damals so, dass die eben die jeweilige CPU Modell bestimmt haben, da es bei den SIMD Befehlen oft ein paar gleichwertige Optionen gibt, zB. ist MMX Teil von SSE2, nur war beispielsweise auf Pentium M SSE2 langsamer als MMX. Ein aktuelles Beispiel war die anfänglichen Probleme von Ryzen in Ashes of the Singularity. Das sind so diverse wirklich modellspezifische Eigenheiten.
I.d.R. macht man solche Optimierungen aber nicht von Hand (schreibt also wirklich Assembler), dann liegt es eben an den Optimierungen des Compilers. Und wie schon erwähnt, war (ist?) da intel nicht ganz fair in der Optimierung und per Definition kann ein Compiler bzw. der generierte Code nur begrenzt auf unbekannte CPUs optimieren, da eben viele der Parameter nicht explizit abgefragt werden können. Nur weil etwas das richtige Ergebnis liefert, heißt das nicht, dass es die optimale Performance erzeugt (und manchmal nicht einmal das - known issues...). Allerdings in vielen Fällen, sind die Details der CPU uninteressant, bzw. direkt auslesbar etwa wie die Größe des Caches, oder die Länge der Cachelines...