Test RDNA 2 vs. RDNA vs. GCN im Test: IPC und CU-Skalierung bei Radeon RX seit GCN analysiert

[Taxxor]

Vielleicht schafft es AMD ja, bei zukünftigen GPU-Architekturen die IPC zu steigern, ohne die Frequenz wieder zu senken.

Solange sie nicht mehr verbrauchen, ist es doch egal, wo die Leistung herkommt. Wenn sie mit RDNA3 in 5nm dann immer noch die gleiche IPC, aber dann 2.75-3.00GHz als Standardtakt haben und mit z.B. 96CUs weiterhin bei maximal 300W und 135% einer 6900XT beim Rastern und 150% beim RT sind, wäre es doch auch okay^^

So, zumindest der Verbrauch und die Prozente sind jetzt meine vorläufige Prognose zur 7900XT, zitiert mich in einem Jahr

 

[DaHell63]

Mit meinem neuen UW-Monitor im April kann ich dann auch Retrospiele in smoother Bildpracht genießen.

Geht sicher. Mit meinem Retro Sys I7 3930K/GTX 770 spiele ich auch Stalker in 3440x1440p.

 

[Tanzmusikus]

Ich hatte bisher einen 60Hz-TV ohne VRR genutzt. Das war die Grundlage meines Schreibens.
Übrigens hat mein neuer Monitor eine Auflösung von 2560x1080. 3440x1440 war mir zu klein auf 34".

Ich komme übrigens von 37" mit 1080p.
Die 290X hat also nur ein paar Pixel mehr zu schubsen, dafür wird sie mit variabler Synchronisation belohnt.

 

[.Sentinel.]

Solange sie nicht mehr verbrauchen, ist es doch egal, wo die Leistung herkommt.

Ein wichtiger Satz, denn der ist universal gültig. Nicht nur in Sachen Verbrauch.

Wenn die Rechneleistung bzw. das Ergebnis stimmt, ist es schnuppe, in welchem Verfahren, mit welcher IPC, welchem Takt oder sonstigen Faktoren das Resultat zustandekommt.

 

[zeedy]

@zeedy Effizienz ist ja auch nicht fest an ein bestimmtes Szenario gebunden, der Vergleich bei gleichem Takt kommt in diesem Fall ja einem Vergleich mit festem FPS Target recht nahe.

Nein immer noch nicht. Bei einem FPS Limit können verschiedene Architekturen unterschiedlich reagieren. Die eine könnte weniger Shader auslasten aber den Takt hoch halten, die andere könnte den Takten so weit reduzieren bis die gewünschte FPS Zahl gehalten wird bei möglichst hoher Shaderauslastung.
Guck dir PCGH an, da ist in FHD bei 60FPS sogar eine VII "effizienter" als eine 6800XT. Und wir wissen ja, dass sogar eine 5700XT effiezienter ist als die VII. RDNA2 ist da eine ganz andere Liga.

 

[Kommando]

"ein guter Tausch: IPC gegen Frequenz."

Das hat Intel doch beim Wechsel vom Pentium 3 zum Pentium 4 auch gemacht. Bekanntlich hat sich dieser Weg als Sackgasse erwiesen. Vielleicht schafft es AMD ja, bei zukünftigen GPU-Architekturen die IPC zu steigern, ohne die Frequenz wieder zu senken.

Von mir aus können die Karten auch mit einem kHz takten. Hauptsache die Leistung stimmt. 😉

 

[noxcivi]

Toll aufbereitet und interessant zu lesen. Vielen Dank!

 

[FeldiSan]

Wenn man die Taktraten so sieht die AMD bei der 6700xt so auffahren, wird man unweigerlich an die alten Nvidia-Karten mit dem HotClock Hadern erinnert. Und selbst die liefen nicht so schnell!
Schon Krass was die roten zurzeit auffahren!

 

[Blackfirehawk]

Auch sollte man die Treiber betrachten.

Während Nvidia in Dx11 stark ist/war weil sie einen Software sheduler benutzen der die Last besser über die CPU multithreated..
sieht die Lage bei dx12 /Vulkan anders aus und dieser Software sheduler bricht ihnen leicht das Genick in niedrigeren Auflösungen und mehr CPU lästigen zenarien.
Dieser sheduler verbraucht selbst bedeutend mehr CPU Leistung die einfach in einem CPU Limit fehlen .

AMD macht dieses sheduling in der Hardware, wodurch einiges offloadet ist, was ihnen wiederum Vorteile in dx12/Vulkan bringt.
Wie diverse Seiten wie zb igorslab und Hardware unboxed festgestellt haben, ist die performance mit einer AMD GPU im absoluten CPU Limit bedeutend besser als mit einer Nvidia Karte (+15-30% mehr FPS)

 

[Nureinnickname!]

Krass das sich bei der Theoretischen Rechenleistung pro Kern und Takt garnix tut.

 

[Teralios]

Krass das sich bei der Theoretischen Rechenleistung pro Kern und Takt garnix tut.

Was soll,sich da bitte tun? Die aktuell "sinnvollste" Operation ist das MAD (MUL+ADD), das sind also 2 OPs in einem. Jede VecALU kann davon 32, 2 Vec32 sind in einer CU = 2 * 2 * 32. Anschließend mit der Zahl der CU multipliziert und mit dem Takt, schon hat man die FLOPS.

Man könnte höchstens noch 3 Operationennin einem Schritt durch führen, nur welche dann? Das MAD ist noch geläufig, sonst?

Da ist nichts krass dran, sondern es ist einfache simple Logik, das sich da nichts mehr tut.

 

[Nureinnickname!]

Was soll,sich da bitte tun? Die aktuell "sinnvollste" Operation ist das MAD (MUL+ADD), das sind also 2 OPs in einem. Jede VecALU kann davon 32, 2 Vec32 sind in einer CU = 2 * 2 * 32. Anschließend mit der Zahl der CU multipliziert und mit dem Takt, schon hat man die FLOPS.

Man könnte höchstens noch 3 Operationennin einem Schritt durch führen, nur welche dann? Das MAD ist noch geläufig, sonst?

Da ist nichts krass dran, sondern es ist einfache simple Logik, das sich da nichts mehr tut.

Ich glaube jetzt habe ich es verstanden, liegt wohl daran das eine GPU für Spezielle aufgaben gemacht ist, und eine CPU quasi alles kann vereinfach gesagt oder stimmt das nicht? Quanten Physik folgt sicherlich auch irgendeiner Logik, trotzdem begreift es nicht jeder als beispiel.

 

[Colindo]

Da ist nichts krass dran, sondern es ist einfache simple Logik, das sich da nichts mehr tut.

Das ist zwar richtig, greift aber in bestimmten Situationen zu kurz. Wenn man sich eine 5700XT hochskaliert auf 80 CUs vorstellt, wird einem relativ schnell auffallen, dass die am Speicherinterface verhungern würde. Der Datentransport ist aber auch ein Teil der IPC, dementsprechend kann man sagen, dass der Infinity Cache auch die IPC erhöht, nur eben nicht bei 1 GHz bzw bei 2GHz mit wenigen CUs.

Ist immer die Frage, was man alles in die IPC-Betrachtung einfließen lässt. Ich finde den IC sollte man nicht außer acht lassen.

 

[Grundgütiger]

Der Cache kostet an Fläche etwa 20CU‘s, Ob eine AMD Karte mit 100CU und 512bit Speicherinterface schneller wäre? Teuer auf jeden Fall.

 

[Nai]

Was ist denn deiner Meinung nach der Unterschied. Meinst du, dass das 'C' in 'IPC' für Cycle und nicht Clock steht?

Das ganze geht schon damit los, dass man den IPC wert nicht ohne Profiling bestimmen kann, die Performance aber sehr wohl. Dann eignet sich der IPC Wert eher für Betrachtungen, wie stark ein Programm die Rechenwerke auslastet; niemand der bei Sinnen ist versucht beim Programmieren den IPC Wert seines Programmes zu optimieren. Jedoch ist bei einem Vergleich zwischen zwei Rechnern der IPC Wert nur direktproportional zur Performance pro Kern pro Takt, wenn die Instruktionssätze und die Vektorbreiten der verglichenen Rechner und die Programme die auf beiden Rechnern ausgeführt werden, ebenfalls identisch sind. Und gerade das ist ja bei GPUs nicht der Fall, wo jede Generation ihren eigenen Instruktionssatz besitzt, und ein Laufzeitcompiler das Programm auf die entsprechende GPU optimiert.

Krass das sich bei der Theoretischen Rechenleistung pro Kern und Takt garnix tut.

Was für Möglichkeiten haben die GPU-Hersteller denn?
a) Mehr Vektoreinheiten einbauen (von SIMD auf MIMD): Die zusätzlichen Vektoreinheiten müssen irgendwie befüttert werden, sowohl mit Instruktionen als auch mit Daten über ihre Register. Dies hat NVIDIA mal mit Kepler versucht, lief nicht so effizient; von den 6 Vektoreinheiten auf einer Kepler GPU sind 2 meistens verhungert, weil die Register nicht genügend Bandbreite hatten.
b) Mehr "Subkerne" in einen Kern einbauen (*): Dieser Ansatz bekommt auch Skalierungsprobleme über die Resourcen die sich die Subkerne teilen.
c) Breitere Vektoreinheiten einbauen: Je breiter die Vektoreinheiten sind, umso weniger Kontrolllogik kann man auf einer GPU sich einsparen wenn man die Breite zusätzlich erhöht. Dafür werden die Strafen für Branching innerhalb eines Vektors umso größer.

*: Ich bezeichne hier einen SM oder eine CU als Kern, weil das was NVIDIA und AMD als GPU-Kern bezeichnet, kein Kern ist. Man mag argumentieren, dass je man nach GPU-Architektur man einen Subkern bereits als einen eigenständigen Kern bezeichnen könnte, analog zur Bulldozer debatte.

 

[Teralios]

Der Datentransport ist aber auch ein Teil der IPC, dementsprechend kann man sagen, dass der Infinity Cache auch die IPC erhöht, nur eben nicht bei 1 GHz bzw bei 2GHz mit wenigen CUs.

Ließ mal bitte seinen Beitrag, da geht es nicht um IPC - wozu ich auch bereits was geschrieben habe - sondern um die theoretische Rechenleistung und das diese - abseits vom Takt - nicht mehr gesteigert wird.

Und dort die Rechenleistung hängt halt pro CU davon ab, wie viele ALUs vorhanden sind (Breite) und wie viele Operationen jede ALU pro Takt ausführt und da ist aktuell eben das MAD (2 Operationen) die höchste aktuell sinnvolle Ausbaustufen.

Die IPC ist eine andere Baustelle und hat etwas mit der Auslastung zutun und hängt nicht nur von der Hardware Ab, gerade bei so "simplen" Schaltkreisen wie eine GPU. Da spielt der Compiler der Shader ebenso mit wie der Treiber als auch die Grafikengine.

 

[Colindo]

Ich denke schon, dass er die IPC meinte, weil er ansonsten von den TFlops sprechen würde, und dass die sich bei gleicher Zahl CU und Takt nicht ändern, ist ja für alle offensichtlich.

 

[Taxxor]

Denke ich auch, wie viele Operationen jede ALU pro Takt ausführt und damit auch wie viele Operationen jeder Kern ausführt, bestimmt die Instruktionen pro Taktzyklus der Karte, also IPC.

 

[Nai]

Denke ich auch, wie viele Operationen jede ALU pro Takt ausführt und damit auch wie viele Operationen jeder Kern ausführt, bestimmt die Instruktionen pro Taktzyklus der Karte, also IPC.

Hier zeigen sich wieder die Tücken des IPC Begriffs. Ein Kern einer GPU gibt jeden Takt jeweils bis zu eine Instruktionen an jede seine Vektoreinheiten heraus, wobei die Lanes (aka ALUs) einer Vektoreinheit dann jeden Takt die an ihre Vektoreinheit herausgegebene Instruktion auf unterschiedlichen Daten ausführen, wodurch jede Lane pro Takt wiederum eine eigene Operation ausführt. Fügt ein GPU Hersteller zum Beispiel nun zu einer Vektoreinheit mehr Lanes hinzu, so erhöht sich zwar die Rechenleistung eines Kerns pro Takt, nicht aber die Anzahl der Instruktionen, die ein Kern pro Takt ausführen kann.

Es gibt dann noch so ein philosopisches Dilemma: Wie summiert man die unterschiedlichen (Floating Point) Rechenoperationen zu einer Peak Performance auf? In der Regel gewichtet man hierfür Additionen und Multiplikationen als jeweils eine Operation, FMA als 2 Operationen, und ignoriert Sonderoperationen, wie Kehrwert, inverse Quadratwurzel, Logarithmus, Exponentialfunktion und trigometrische Funktionen. Theoretisch wären aber auch komplett andere Gewichte hier denkbar.... Egal wie man sich hier bei den Gewichten entscheidet, man hat immer das Problem, dass bei einem konkreten Programm die unterschiedlichen Operationen unterschiedlich wichtig sind; zum Beispiel wenn ein Programm nur Additionen ausführt, ist es egal, wie gut die GPU Multiplikationen ausführen kann.

 

[Tom_111]

Was Leistung und Stromverbrauch angeht ist für mich die 6800 der Sweetspot. Mit etwas UV klappt es dann mit Sicherheit auch mit meinem Straight Power 10 500W.

Für mich ist der Sweet Spot die RX 6900 XT, da kaum teuer als die 6800.