Gerüchte, Mutmaßungen und warum man die GameStar nicht immer ernstnehmen sollte

Geöffnet als Baustelle! ;) Umbauarbeiten erfolgen noch über einige Bereiche!
Sapphire Radeon HD 5870 by D-Kuru (CC-BY-SA 3.0 at).

Dass ich nicht gerade ein Freund von der GameStar-Hardware Redaktion bin, sollte eigentlich einigen bekannt sein, vor allem weil ich mich früher auch regelmäßig mit den Redakteuren angelegt habe, wenn diese mal wieder ein paar Aussagen getroffen haben, die so in der Regel nicht haltbar sind. Gerade der Herr Klein hat dabei von mir durchaus sein Fett wegbekommen, auch als es damals um die PlayStation 4 ging und dass ja nun alles besser wird für PC Spieler, da die Hardware ja gleich ist. Dass Hardware, besser die ISA - Instruction Set Architecture, also Befehlssatz einer CPU - oft eher eine Nebenrolle spielt und heute die Software-APIs sowie die Programmiermodelle weit mehr Auswirkung, ist jedem bekannt, der zumindest Ansatzweise mal für mehrere Plattformen programmiert hat.


Der GameStar schießt aber eigentlich in regelmäßigen Abständen entsprechende Böcke, bei denen man sich durchaus auch die Frage stellt: Welche IT-Erfahrung haben die Hardware-Redakteure. So wurde bei der Präsentation der GeForce RTX 3000er-Serie - also Ampere - bereits der Abgesang auf AMD gesunden und dass AMD wohl sogar Probleme haben wird die 3070 zu schlagen. Klar, die Ausführungen "Kernzahl * Takt * Operationen pro Takt" sind erst mal nicht falsch, doch zeigt bereits dieser Text, dass Herrn Köpf anscheinend wirklich wichtige Grundlagen im Bereich Informatik fehlen und auch im neusten Text wird das nicht besser, denn hier wird die Leistung der hypothetischen RX 7000 alias RDNA 3 bereits analysiert und Herr Köpf ist sich sicher, dass Sprünge um 15 % bei der Leistung pro Takt realistisch sind. Dabei zeigte doch gerade RDNA2, dass AMD hier zugunsten vom Takt sogar eine Senkung der Leistung pro Takt um 4 - 5 % in Kauf nimmt, wenn man den Takt um bis zu 50 % steigern kann.


Nun gut, zuerst müssen wir aber ein paar Grundlagen klären, entsprechend wird es kurz langweilig, für alle die wissen was *OP/s und IPC ist: Tut mir leid!

Operations per Seconds, Instructions per Cycle und was es damit auf sich hat

Heute gibt es quasi zwei Begriffe, die man in verschiedenen Hardwareartikeln immer wieder findet: FLOPS und IPC. In manchen Bereichen kommen heute auch gerne noch die TOPS dazu, aber dazu gleich mehr. Mit diesen Werten versucht man die Rechenleistung eines Prozessors vergleichbar zu machen, FLOPS sind dabei als Einheit sogar wirklich greifbar, die IPC ist dann schon etwas abstrakter, da sie von der Architektur des Prozessors sowie dem Programm abhängt und damit eher ein Sammelbegriff ist.


Fangen wir mal mit den FLOPS an: FLOPS steht in dem Fall für Floatingpoint Operations per Seconds, ich habe in der Überschrift bereits den Begriff Operations per Seconds eingeführt, da es natürlich nicht nur FLOPS gibt, sondern theoretisch auch IOPS (Interger Operations per Seconds), IOOPS (Input/Output Operations per Seconds) oder TOPS (Tensor Operations per Seconds). Hier wird also angeben, wie viele Operationen ein Prozessor erreicht. Jetzt geht es aber los: FLOPS ist nicht gleich FLOPS. Vor einiger Zeit hatte ich da mit einem User auf GameStar auch eine entsprechende Diskussion, der mir erklären wollte, dass man ja die Rechenleistung steigern kann, ohne die FLOPS z steigern und dass die FLOPS ja ein fester Wert wäre. Die Diskussion mit diesem GameStar-User war sinnlos, weil da einigs an Verständnis fehlte, deswege auch dieser Abschnitt: Wenn man bei einer Grafikkarte oder CPU eine Angabe zu FLOPS oder heute ganz modern TOPS findet, dann meint man damit in der regel das theoretische Maximum, in wissenschaftlichen Texten findet man daher bei diesen Angaben oft im kleinen den Hinweis Max in Klammern: FLOPS(max). Damit wird in diesem Fall die theoretische maximale Rechenleistung angeben, die ein Prozessor erreicht und für dieses Maximum gilt die oben aufgeführte Formel: Anzahl der Kerne (ALUs) * Takt * Operationen pro Takt. Man kann aber mit FLOPS auch die wirklich erreichbare Rechenleistung angeben und da gibt es dann wiederum in der Wissenschaft gerne einen Zusatz, der sich Average sowie Peak nennt, auch wieder gerne in Klammern als Hinweis an FLOPS: FLOPS(PEAK), FLOPS(AVG).


Nimmt man die Werte von FLOPS(PEAK) und FLOPS(AVG) hat man gleichzeitig auch einen Wert mit der man die IPC eines Prozessors bestimmen kann. Wichtig ist dabei, dass die IPC selbst keine feste Einheit hat. Bei Programmen, die primär Berechnungen anstellen, sind die OPS wichtig, bei anderen Programmen die Frames per Seconds oder die Hases pro Sekunde oder die Anfragen pro Sekunde. Aus all diesen Werten kann man eine IPC errechnen, also das, was Herr Klein als "Leistung pro Takt meint, wenn er von 15 % spricht. Wichtig dabei ist, dass man die Werte normiert, und zwar am besten auf Kerne und Takt. So kann man dann rausfinden, wie viel ein Kern leistet. Bei einer CPU ist das relativ einfach: Erreicht eine CPU A bei 3,8 GHz 540 Punkte in einem Programm und die andere CPU bei 4,4 GHz 600, dann teilt man einfach die Punkte durch den Takt und hat so die Punkte pro GHz: Punkte / Takt. Ergibt in dem Beispiel für CPU A 142 Punkte pro GHz, bei CPU B 136 Punkte pro GHZ. Die IPC bei CPU A ist also höher, obwohl sie als ganzes aber weniger Leistet.


Damit sind nun die Begrifflichkeiten geklärt, nun wird es wirklich technisch, da ich euch zeigen möchte, warum Herr Klein mit seinem 15 % bei RDNA 3 vermutlich falsch liegen wird.

GPUS sind keine CPUS

Wir müssen an dieser Stelle nun klären, woher diese 15 % IPC kommen und die Antwort ist ganz einfach: Zen zu Zen 2 zu Zen 3 sowie SkyLake zu nun Rocket Lake und den Nachfolger Alder Lake. AMD und Intel geben hier an, dass sie die Leistung pro Kern normiert auf den Takt um 15 % steigern im Schnitt. Daher auch die Einschätzung von Herrn Klein, dass diese 15 % realistisch sind, nur gibt es hier ein kleines Problem und die Überschrift deutet es schon an: Ein Grafikprozessor ist keine CPU.


Moderne CPUs arbeiten heute nach dem Out-of-Order-Prinzip, das bedeutet, dass sie Befehle umsortieren können. Dazu kommt eine Sprungvorhersage, die passende Befehle bereits in die Pipeline schiebt, bevor diese überhaupt dran wären und eine spekulative Ausführung von Befehlen, wenn Rechenwerke nicht beschäftigt sind. Ein weiterer Punkt ist, dass CPUs ein hohes Maß an Interaktion haben, sei es bei moderner Software innerhalb des Programms - als innerhalb mehrere Threads - als auch mit dem Arbeitsspeicher. Noch ein Punkt ist zu dem, dass auf einem Prozessorkern heute häufig nicht nur ein Thread ausgeführt wird, sondern viele. Ihr könnt euch ja mal den Windows Taskmanager aufrufen und euch ansehen, wie viele Tasks geöffnet sind, denen der Sheduler regelmäßig etwas Rechenzeit zuweisen muss.


Wenn AMD und Intel von 15 % Leistung pro Takt sprechen muss man zudem auch aufpassen, was sie genau damit meinen: Die 15 % mehr Leistung sind nämlich ein Mittelwert über verschiedene Szenarien hinweg und Programme profitieren da auch unterschiedlich. Wenn ein Programm stark abhängig vom Arbeitsspeicher ist, da viele Daten gelesen und geschrieben werden, dann kann eine simple Cache-Erhöhung bereits einiges bringen - Zen+ zu Zen 2 - aber es kann auch etwas bringen die Latenzen zum RAM zu senken - Zen zu Zen+ - und sollte hier auch immer mehr Kommunikation unter den Kernen erforderlich sein, kann es auch etwas bringen die Kommunikation über die Caches zu verbessern - Zen2 zu Zen3. Nur gibt es eben auch Programme in einer CPU, die durch andere Faktoren limitiert werden und daher durch solche Änderungen nicht wirklich schneller laufen.


Bei modernen CPUs gibt es also einige Stellschrauben, die man drehen kann, um mehr Leistung zu bekommen, aber nicht jedes Programm reagiert auf jede dieser Stellschrauben gleich gut. GPUs sind dagegen relativ simpel aufgebaut und fast alle gängigen GPUs arbeiten bis heute noch nach dem Prinzip der In-Order-Execution, die Befehle werden also in der Reihenfolge abgearbeitet, wie sie der Shader (Programm) vorsieht. Die Befehle werden also nicht umsortiert um eventuell nicht ausgelastete ALUs auszulasten und da kommt der nächste Punkt: Die ALUs in einer GPU sind nicht voneinander unabhängig organisiert. Während bei einer CPU die 4 ALUS vollständig voneinander unabhängig arbeiten können, werden bei einer GPU die ALUs pro CU (CudaCore) in Blöcken organisiert und angesprochen und da liegt ein weiterer Knackpunkt aber auch das Geheimnis einer GPU und warum man oft von SIMD spricht: Single Instruction Multiple Data: Ein und derselbe Befehl werden auf viele Daten ausgeführt. In einer RDNA CU befinde sich nominell 64 Shader (ALUs), diese werden aber eben nicht wie die 4 Rechenwerke einer CPU angesprochen, die unabhängigen Befehle parallel ausführen, sondern in 2 Blöcken zu 32 - in den AMD Whitepaper zu RDNA spricht man auch von Vec32 ALUs.


Es müssen also immer 32 Rechenwerke dieselbe Operation ausführen, was bei Bildern aber in der Regel nicht das Problem darstellt, da ein und derselbe Shader auf mehrere Pixel in einem Bild ausgeführt wird. Im Übrigen ist ein Shader im weiteren Verlauf ein Thread auf der GPU um nicht ständig zwischen den Termini zu wechseln und so für Verwirrung zu sorgen.


Während in einer CPU die meisten ALUs voneinander unabhängig sind und die CPU versucht durch Out-Of-Order-Umsortierung der Befehle die meisten Operationen möglichst auf Befehlsebene zu parallelisieren und dafür einen hohen Aufwand betreibt und auch mit Branchprediction versucht die ALUS vorausschauend zu füllen, verzichtet man bei GPUs auf eben diese komplizierte Kontrolllogik um mehr Rechenwerke unterzubringen. Was auf der GPU ausgeführt wird primär durch den Treiber bestimmt, der die entsprechenden Berechnungen vorbereitet und dann an die GPU weiter gibt.

Aber von GCN zu RDNA wurde doch die Rechenleistung pro Kern erhöht!

Richtig und genau hier setzt der vorherige Abschnitt an: Die Rechenleistung von GCN zu RDNA konnte pro Kern erhöht werden, weil die Kerne umstrukturiert wurden und genau das ist der entscheidende Punkt: Eine CU hat seit GCN 64 Rechenwerke, nur hat sich deren Organisation geändert und ebenso wie der Treiber diese anspricht - das Whitepaper habe ich verlinkt. Bei GCN bestand eine CU aus einer speziellen skalaren ALU für bestimmte Operationen und dazu 4 Vektor-ALUs die 16 Werte fassen. 4 * 16 = 64. Damit jede VecALU etwas zu tun bekommt, müssen 4 Threads pro Thread ausgeführt werden, wobei jeder Thread eben einen Befehl sendet.


Jetzt muss ich kurz zurück zu den Shadern gehen - die Programme: In einer Engine weist der Spieleentwickler einer Textur, einem Polygon und Co einen oder mehrere Shader zu, kleine Programmhappen, die entweder die Farbwerte der Pixel oder eben die Form der Kante bestimmt. Da nicht jeder Shader auf jede Oberfläche oder jede Kante ausgeführt wird, kommen heute bei modernen Engines pro Bild mehre voneinander unabhängige Shader, die parallel ausgeführt werden können: die sogenannten Threads auf der GPU. Wie im vorherigen Abschnitt beschrieben, braucht jede Vec-ALU der CU einen Thread und damit einen Shader um ausgelastet zu werden.


Jetzt kommen wir zu dem zweiten Punkt: Bei GCN werden die Befehle eines Shaders in einem Wave64-Befehl verpackt - also einen Befehl der einen Vektor mit 64 Elementen verarbeitet. Jetzt ist es so, dass eine VecALU aber nur 16 Werte in einem Takt verarbeiten kann und hier liegt jetzt das Problem von GCN: Der Treiber schickt Wave64-Befehle, die auf einer Vec16-ALU ausgeführt wird und diese braucht dann pro Operation 4 Takte - auch das könnt ihr im Whitepaper nachlesen. Um GCN optimal auszulasten braucht man also pro CU 4 Threads zu bis zu 64 Werten, ansonsten benötigt die CU zwar Strom, aber liefert keine Ergebnisse und genau das ist auch der Grund warum GCN - auch insbesondere Vega - zwar eine massiv höhere theoretische FLOPS Leistung als die NVIDIA Pendants hatten, diese Leistung aber nicht auf die Straße bringen konnten.


Bei RDNA wiederum hat AMD die vier Vec16 durch 2 Vec32 ALUs ersetzt, jetzt hilft einfache Mathematik: Wie viel Takte braucht die Vec32-ALU für einen Wave64-Befehl? Genau 2. Entsprechend steigt hier pro Thread die IPC theoretisch um 50 %, da man nur noch die hälfte der Zeit braucht und damit sind wir bei der Steigerung der Rechenleistung pro Kern bei RDNA.


Und das ist der Knackpunkt, warum ich denke, dass man auch bei RDNA3 nicht davon ausgehen kann, dass die IPC pro CU um 15 % steigt, denn für solche Sprünge müssen die CUs von AMD umstrukturiert werden und man kann davon ausgehen, dass AMD so eine Umstrukturierung mit RDNA 3 nicht vornimmt und damit dürfte zumindest die IPC bei normalen Rechenoperationen eher im unteren bis mittleren einstelligen Prozentbereich verändern.


Im Übrigen: AMD hat auch im Treiber - erneut ins Whitepaper sehen - mit der Zeit eine Anpassung von Wave64 zu Wave32 vorgenommen, solche Anpassungen passen im übrigen auch zu den anfänglichen Blackscreen-Problemen von RDNA. Das führt heute dazu, dass je nach Spiel RDNA bei Taktnormierung zwischen 30 - 50 % zulegt, je nach Spiel.

Spezialfälle - es könnte sogar deutlich mehr werden

Während ich bei der normalen Rechenleistung also nicht davon ausgehe, dass da wirklich die IPC steigt, sieht es bei speziellen Rechenoperationen anders aus. Gerade bei den Tensor-Operationen, sowie allgemein bei Matrizen-Operationen könnte es sein, dass AMD die Vec32-ALUs um entsprechende Schaltungen erweitert und man somit am Ende hier eine sogar deutliche Steigerung erfahren kann. Genau so sieht es bei CU auch bei der RT-Leistung aus, die man durch Verbesserungen der Ray-Accelator beschleunigen kann.


Nur muss man dann beachten, dass diese Spezialfälle nicht in jedem Szenario greifen und auch eine softwareseitige Anpassung benötigen, also nicht sofort zur Verfügung stehen. Es kann daher durchaus sein, dass in kommenden Spielen dann - weil zum Beispiel FidelityFX Super Resolution in die Engine implementiert wurde - die IPC wegen Anpassungen an den CUs wirklich steigt und in den einem Algorithmus eventuell sogar weit mehr als die 15 % - so kann man bei Zen+ zu Zen 2 sogar eine IPC-Steigerung von über 100 % erreichen, wenn man die AVX2 - 256Bit-Code ausführt und deren Ausführung auf Zen und Zen+ erzwingt.

Theoretische und reale Rechenleistung - Die Software und Arbeitslast haben ebenso einen großen Einfluss

Noch wichtiger ist aktuell jedoch folgendes: Die IPC bei einer Grafikkarte ist nicht nur abhängig von Verbesserungen an einer CU und wie diese die ALUs organisiert, sondern auch von Treibern sowie der Arbeitslast die anliegt. Wunderbar ist das zu sehen, wenn man eine Radeon RX 6900 XT gegen eine RTX 3090 antreten lässt über viele Spiele hinweg in verschiedenen Auflösungen.


Die RTX 3090 hat nominell mehr als doppelt so viele ALUs und auch mehr Kerne, dennoch - wir lassen RT und DLSS außen vor - kann gerade in FullHD sowie WQHD sich die RTX 3090 nicht wirklich absetzten im Mittel, sondern unterliegt sogar: Die IPC der Ampere-Karte hat sich zu Turing hin drastisch verschlechtert. Gleichzeitig steigt aber auch bei Ampere die IPC mit steigender Arbeitslast an, weil es dem Grafikkartentreiber einfacher fällt die schiere Anzahl an ALUs pro SM zu füllen, das führt dann dazu, dass Ampere in 4K dann schneller wird als die RX 6900 XT.


Mit DX12 und HLSL 6.0 haben Spieleentwickler sogar noch mehr Einfluss auf die IPC einer Grafikkarte als jetzt schon, da sie nun sogar gezielt die Vektorbreite bestimmen können.

Abschluss

Eine Steigerung von 15 % Rechenleistung pro Takt ist bei RDNA 3 eher unwahrscheinlich, GPUs arbeiten anders als CPUs und sind wesentlich einfacher aufgebaut, der Treiber als auch die Spiele haben hier maßgeblichen Einfluss auf die IPC. Die IPC hängt bei GPUs davon ab, wie viele Vektoren mit genug Elementen man zusammen bekommt. Wenn AMD nicht noch einmal die Strukturierung der CU umbaut, sondern bei 2 * Vec32 belässt, dann sind die primären Stellschrauben für eine IPC-Steigerung die Länge der Pipeline. Größe und Geschwindigkeit der Chaches und des Arbeitsspeichers und diese wiederum können vollkommen wirkungslos verpuffen, weil die ohnehin nicht genug Daten vorhanden sind.


In speziellen Fällen - Tensor-Operationen oder RayTracing - könnten wir eine deutlich größere IPC-Steigerung sehen, aber das würde dann nur in gewissen Fällen greifen. Die Leistung pro Takt wäre dann zwar vielleicht im Mittel 15 % stiegen, wir hätten aber nur zwei Möglichkeiten: Keine Veränderung der Rechenleistung, weil entsprechende Fälle gar nicht anliegen, oder eine drastische Beschleunigung.


Am Ende muss man aber sagen: Man sollte nicht von CPUs auf GPUs schließen, das weckt falsche Erwartungen, die am Ende sogar eher enttäuscht werden.