Test 7900 XTX OC vs. RTX 4080 OC: RDNA 3 und Ada Lovelace mit maximalen Taktraten im Duell

[Jenergy]

@EmeraldlyMint Und wie würdest du so einen Test angehen? Minimale Leistungsaufnahme ist im Grunde genommen nichts anderes als Leerlauf.

 

[DerRico]

Naja, die Redaktion macht diese Aussage.

Nein, die Aussage des Test der Redaktion ist: Einfach volles Watt geben führt zu perversen Verbräuchen.
Das ist aber nicht, was in der Überschrift steht. Man darf auch mal sagen, wenn ein Bericht bei CB vielleicht nicht zu 100% zielsicher ist.

Wenn Dich der Artikel voll zufriedenstellt, ist es doch für Dich okay. Ich finde es ein bisschen unausgewogen und Deine Aussage passt zum Artikel, ist aber eben absolut betrachtet - siehe meinen anderen Post dazu - so nicht korrekt.

 

[DJMadMax]

Was mir persönlich noch gefehlt hätte, wäre eine Gegenüberstellung der Performance pro Watt bei Übertaktung - wobei es klar ist, dass bei unproportional steigendem Strombedarf auch die Performance pro Watt sinkt. Was leider auch nicht aus dem Artikel herausging ist die Antwort auf die Frage, ob das besonders beim Compute recht deutliche Overclocking zu erzielbar besseren/schnelleren Ergebnissen führt.

 

[fox40phil]

Ich ordne das bei mir im Kopf als "interessante Machbarkeitsstudie" ein, danke für den ganzen Aufwand.

Schade um die Zeit.
Ein kompletter UV Test hätte mir besser gefallen. Das hier ist nicht mehr Zeitgemäß!

 

[DJMadMax]

Maximaler Takt alles schön und gut - wie wärs mal mit Leistung bei minimaler Leistungsaufnahme? Das würde mich interessieren.

Das gibts halb-gar mit der 144 FPS-Messung in drei Spielen im Schnitt. Die 4090 ist unangefochten auf Platz 1, was Energieeffizienz pro Watt bei "geringer/limitierter" Leistung angeht.

 

[numerus]

Wenn die Grafikkarten unter 1000 € fallen ist die Rede wert, welche genau soll es sein! Bist dato finde ich die Preise einfach überteuert.

 

[DevPandi]

ie 4090 ist unangefochten auf Platz 1, was Energieeffizienz pro Watt bei "geringer/limitierter" Leistung angeht.

Wobei da eine aktuellere Messung für die 7900XTX und 7900XT gibt.

Aktuell kann man die 7900 XTX und 7900 XT auch per Treiber nicht so "schön" limitieren, wie man denkt. (Einer der Treiber-Bugs, die ich angemerkt hatte.)

 

[kiffmet]

Die Frage an der Stelle - die wirfst du ja selbst auch ein - ist, wie viel Power-Budget an anderen Stellen benötigt werden, wenn nicht nur die Vec32-ALUs ausgelastet werden.

Um hier wirklich Klarheit zu haben, müsste man an der Stelle weit tiefer in die Materie abtauchen und müsste den Treiber samt der Befehle, die an die GPU gehen, tracken. Frage ist dann, nutzt Blender bereits die Dual-Issues oder DPP, wenn nein, könnte es an der Stelle sein, dass sich die halbe Vec32 quasi langweilt und daher mehr Taktpotential freigibt. Dafür spricht ja auch, dass man die 3 GHz bei ca. 310 Watt erreicht.

Frage ist an der Stelle dann auch, inwieweit der Memory-Controller bei Blender gefordert wird, was da an Daten liegt, aber auch bei Spielen.

Hui, jetzt hab ich irgendwie Lust mal den Treiber vollständig zu tracken und die Auslastung der Karte, gleichzeitig weiß ich aber, dass das wieder so eine massive Arbeit ist, die am Ende zwar Klarheit bringt, aber bis auf wenige kaum interessiert.

Und am Ende ändert es auch nichts an den Problemen, sondern erklärt diese nur.

Ich glaube, dass hier das Problem bei den neuen Vec32 liegt, weil AMD hier versuchte relativ "elegant" sich für die Zukunft vorzubereiten, ohne dass sie die Fehler von GCN wiederholen. Auf der einen Seite die Dual-Issues, dass zwei OPs in der Vec aus dem gleichen Thread bearbeitet werden kann, oder dass man bei "zu wenig" Daten pro Thread auch die Threads zusammenfassen kann, was die Operatoren angeht.

Es gibt hier einige Fallstricke, aber die wirklich zu analysieren, benötige es einiges an Zeit und auch Fachwissen. Sowas wäre als Hausarbeit im Studium interessant.

Die zusätzlichen Vec32 Einheiten sind extrem limitiert. Es gibt viele Rahmenbedingungen, die erfüllt werden müssen, damit diese eingesetzt werden können, z.B. betreffend der nutzbaren Anzahl an Quell-, Ziel- und Operandenregistern. Momentan lässt sich da nicht viel mehr, als FMA (A*B + shared_const bzw. A*shared_const + B) beschleunigen, und das dann auch nur, wenn sich eben beide Vec32 Blöcke dieselbe Konstante teilen. Das RDNA3 Whitepaper ist diesbezüglich sehr aufschlussreich.

Bezüglich Blender/OpenCL werden die zusätzlichen Einheiten auf Windows noch nicht genutzt. Zum Launch gabs außerdem nur OpenCL 1.x - das spricht stark für einen unfertigen Treiber bzw. Compiler.

Generell scheint RDNA3 viel stärker auf softwareseitige Optimierungen angewiesen zu sein. Es war beispielsweise üblich, dass AMDs Grafikhardware automatisch eine andere Wave bearbeitet, wenn die derzeit ausgeführte ins Stalling kommt. Der Compiler muss dies jetzt voraussehen, und manuell eine entsprechende Instruktion emittieren. Das war ein Tradeoff, um eine höhere ALU-Dichte am GCD zu erreichen.

Errata gibts auch genug (siehe Whitepaper und Mesa gitlab); Manche Instruktionen liefern falsche Ergebnisse, wenn diese innerhalb von X Takten nach bestimmten, vorherigen Instr. ausgeführt werden, oder kein Synchronisierungs, Warte- oder Cache-Flush Befehl eingeschoben wird. Das erzeugt Pipeline Bubbles und Leerlauf.

Die Raytracing Verbesserungen, wie "early Subtree Culling", oder das Benötigen von weniger Instruktionen für BHV Traversal müssen ebenfalls durch die Nutzung anderer HW Funktionalität via Compiler angestoßen werden (z.B. via ds_bhv_stack_rtn)…

Fixed function Geometriepipeline gibt es auch keine mehr. Das läuft jetzt alles über die Shader via NGG - auch hier wird eine Heuristik benötigt, die den Betriebsmodus festlegt (NGG Culling ja/nein, welche Form des Cullings, Nutzung von Streamout ja/nein, …)

IPC Tests unter Linux (sowohl für 3D, als auch Compute) wären interessant - der Treiber lässt einen dort CUs deaktivieren; so könnte man einen relativ genauen CU für CU Vergleich ggü. RDNA2 anstellen. Dass im worst-case die 7900XTX gerade mal 5%-10% schneller ist, als eine 6900XT/6950XT (trotz 20% mehr CUs!), zeigt, dass es hier interessante Funde geben könnte.

Ich gehe auch davon aus, dass AMD mit RDNA4 einen neuen Commandprozessor benötigen wird. Dass dieser durchwegs höher takten muss, als die Shader, lässt darauf schließen, dass dieser manchmal mit der Arbeitsverteilung nicht hinterher kommt. Das Delta scheint größer zu werden, je höher der Shadertakt ist, beträgt es bei 2,3GHz auf den Shadern nur +200Mhz: In dem von GerryB eingebetteten Video sind fast 3,8GHz am Commandproc. bei ca. 3-3,1GHz auf den Shadern angeführt…

Also ein bisschen Sorgen mache ich mir schon bezüglich dieser Entwicklungen. Compilerkomplexität war das, was letztlich zum Tod von AMDs VLIW Architektur (und Intels Itanum) geführt hatte. Der hohe Stromverbrauch erinnert ein bisschen an GCN, ist aber wenigstens diesmal von einem hohen Takt begleitet, was nebenbei fast schon ein bisschen Pentium 4 Vibes aufkommen lässt

 

[Rockstar85]

Diese 5% mehr Leistung durch OC lohnen sich bei beiden Karten nicht, viel zu hoher Verbrauch für kaum Mehrwert.

Bedenke... wenn die XTX mit ~3,0Ghz nicht mal das Powerlimit reißt, dann wäre sie vllt am Ende doch bei ~80% einer 4090 rausgekommen.. Die OC werte sind nett, das war es dann aber auch.

Ich sehe die Benchmarks in UE5.1 und frage mich, ob Hardware RT wirklich noch in diesem Jahrzehnt relevant wird. EPIC zeigt derzeit das Gegenteil und dann ist die 7900XTX sehr dicht an der 4090... Es ist erstaunlich, wie sehr diese GPU an der jeweiligen Engine hängt.

 

[HierGibtsNichts]

Dafür gibt es die kleineren

Auf Grund der hier ermittelten Werte und der Ergebnisse steigt die Wahrscheinlichkeit das die Gerüchteküche richtig liegt und RDNA3 als Navi31 einen Designfehler hat ein wenig.

Sowas wurde schon in Sachen deaktiviertem Shader Perfetch vermutet und hat sich nicht bestätigt bzw. widerlegt.

Ich denke nicht, das man hieraus einen Grundlegenden architektonischen Designfehler ableiten oder bestätigen kann.
Es hat eher mit fehlender Optimierung der Treiber und der Anwendungen z.B Spielen an sich zutun, auf die Architektur Besonderheiten von RDNA3 . Nicht umsonst hat AMD nun ein 600 Seiten Referenzhandbuch für Entwickler veröffentlicht.

https://www.pcgameshardware.de/Rade...r-RDNA-3-Optimierung-veroeffentlicht-1411254/

 

[Rockstar85]

So ist der Artikel auch gedacht.
Das "7900 XTX vs. 4080 OC" gibt es quasi nebenbei. Eigentlich geht es in dem Artikel darum, RDNA 3 etwas besser zu verstehen und zu analysieren, was mit den Taktraten los ist und machbar ist.

Danke Wolfgang.. Nun wird spannend, was Navi32 wird, so er denn kommt.. Wenn Navi 33 am Ende pro CU 1TFlop schafft, dann Respekt. Ich hoffe ihr testet das ausgiebig.

 

[Fighter1993]

Es gibt hier einige Fallstricke, aber die wirklich zu analysieren, benötige es einiges an Zeit und auch Fachwissen. Sowas wäre als Hausarbeit im Studium interessant.

Meinste nicht ehr als Masterarbeit? 🤪

 

[Caramelito]

@Wolfgang
Danke für den Test! Sehr interessant und gut gemacht!

Kannst du vllt. noch etwas zum Thema Spulenfiepen sagen?
Wie sieht es vor allem bei der XTX mit 400w+ Verbrauch aus?

Die 4080 TUF gilt auch als Fiepmonster laut Luxx Forum - Wie ist es da?

Danke dir!

 

[JahJah192]

Puh. Also eine übertaktete 4080 verbraucht noch weniger als eine non oc XTX. Kann sich ja jeder die Langzeitkosten ausrechnen, vor allem bei 40+ ct Stromkosten aktuell. Denke bei 1000 Euro würde ich bei einer 4080 zuschlagen, vielleicht gibt's das ja im Herbst bei irgendwelchen Cashback Optionen.

Behalte den Super Bowl im Auge, Media Markt hat da die letzten Jahre während des SB die Mehrwertsteuer geschenkt Aktion

 

[HierGibtsNichts]

Ich würde da jetzt wirklich gerne wissen, was da im Detail schief lief.
Denn offensichtlich kann RDNA3 ja so irre hoch takten, wie ursprünglich avisiert.
Und sprengt damit in Spielen alle auch nur ansatzweise sinnvolle Verbrauchswerte.

Also: Was lief - wo - schief?

Fehlende Optimierungen auf Treiber und Anwendungsseite. Sieht man ja in den Verbesserungen am 22.12.2 Treiber Test sowie die Veröffentlichung des 600 Seiten RDNA3 Referenzhandbuch für ISA an die Entwickler. Hier fehlt sehr viel Optimierung hauptsächlich an die neue Architektur samt Chiplet Design.

Ergänzung (17. Januar 2023)

Ich hatte doch mal was gehört, dass es nen Hardware Bug bei RDNA3 geben soll. Vielleicht ist das der Grund, warum die Leistungsaufnahme so hoch ist.

Das war das Thema deaktivierter Shader Perfetch. Dieser ist aber aktiv somit wurde die Vermutung widerlegt.

 

[Zer0Strat]

Das war das Thema deaktivierter Shader Perfetch. Dieser ist aber aktiv somit wurde die Vermutung widerlegt.

Oh ne, das mit dem Shader Prefetching war ne ganz andere Sache und widerlegt ist das nicht wirklich. AMD hat das behauptet, aber die haben auch behauptet, dass nur ein kleiner Prozentsatz der Referenzkarten von dem Vapor Chamber Fehler betroffen seien.

 

[Unnu]

Fehlende Optimierungen auf Treiber und Anwendungsseite.

Irgendwie ist mir "alles ein Softwareproblem" zu wenig.
Klar, kann gut sein, aber bei derartigen Problemen halte ich auch diverse schlechte Entscheidungen bei der HW für durchaus Möglich.

 

[ThirdLife]

Nein, die Aussage des Test der Redaktion ist: Einfach volles Watt geben führt zu perversen Verbräuchen.

Watt ist ja der Verbrauch. Dass Watt also zu Verbrauch führt ist jetzt dann aber ne voll zielsichere Aussage ?

 

[Pjack]

und die Zeiten von Übertakten (mehr Nachteile als Vorteile) haben wir zum Glück hinter uns gelassen (verbrauchen auch so schon mehr als genug)

Früher hat man die Karten nah am Sweetspot der jeweiligen Architektur betrieben, und Enthusiasten haben sie auf Kosten der Effizient ausgequetscht.
Heute werden die Karten ausgequetscht, und Enthusiasten suchen nach dem Sweetspot.

Ob das eine jetzt wirklich besser ist als das andere?
Bei meiner Karte spare ich etwa 100 Watt, wenn ich auf 10% Performance verzichte, und da würde sicherlich noch mehr gehen, wenn ich mich noch intensiver damit beschäftige.

In dem Zusammenhang würde mich da auch eher ein Artikel interessieren, der ausleuchtet, wo etwa der effizienteste Betriebspunkt der aktuellen Karten ist. Da kann man dann auch nochmal besser die unterschiedlichen Architekturen vergleichen.

[...]aber die haben auch behauptet, dass nur ein kleiner Prozentsatz der Referenzkarten von dem Vapor Chamber Fehler betroffen seien.

Komischer Vergleich. Keine Ahnung, wie die Maschine arbeitet, die die Flüssigkeit in die Kühler füllt. Wie viel bei welcher drin ist, wird aber vermutlich gar nicht erfasst, sonst wäre der Fehler ja aufgefallen. Ob AMD da trackt, welcher Kühler aus welchem Werk wo genau drauf gelandet ist, kann ich nicht nachvollziehen.
Da das ganze aber alles nicht hausintern passiert, sondern bei Zulieferern, ist es natürlich sehr schwer, da kurzfristig Informationen zu organisieren. Was macht ein gewinnorientiertes Unternehmen demzufolge natürlich? Dementieren bzw. Problem kleinreden. Das ist natürlich dann nicht schön, wenn sich später raus stellt, dass da doch mehr kommt.
Zu behaupten, dass eine Funktion vorhanden ist, die es nicht gibt, ist aber etwas ganz anderes. Natürlich weiß AMD, was ihre Hardware kann und was nicht.

Ich denke nicht, das man hieraus einen Grundlegenden architektonischen Designfehler ableiten oder bestätigen kann.

Frage ist halt auch, mit welchen Fehlern man leben kann und will. Jede Architektur hat irgendwo Fehler, die man an anderer Stelle wieder ausbügelt. Oder halt auch (erstmal) nicht, zB. die ganzen Lücken in x86-CPU's, die in den letzten Jahren bekannt wurden.
Bin mal gespannt, wohin die Reise mit Navi 31 noch geht. Rein gefühlt könnte da noch einiges Potenzial durch neue Treiber sein, auf der anderen Seite ist es halt auch eine große Veränderung.
Natürlich lässt sich das nicht vergleichen, aber Zen1 war auch nur ok, aber nicht auf Augenhöhe.

 

[Zer0Strat]

Errata gibts auch genug (siehe Whitepaper und Mesa gitlab);

Hier mal ein paar mehr Infos dazu: https://forums.anandtech.com/thread...ectures-thread.2589999/page-143#post-40907243

Compilerkomplexität war das, was letztlich zum Tod von AMDs VLIW Architektur (und Intels Itanum) geführt hatte.

Schafft aber auch mehr Unabhängigkeit von Entwickleroptimierungen. Ich denke nicht, dass AMD den Schritt gegangen wäre, wenn sie keine Strategien dafür hätten. Wer weiß, vielleicht sind AI-optimized Ansätze geplant. ^^

Komischer Vergleich.

Es geht darum, dass sie scheinbar keine Skrupel haben, Schutzbehauptungen aufzustellen. Ich glaube AMD das nicht ohne weiteres. Es steht so im Code eines Open Source Treibers. Die machen das schließlich nicht zum Spaß.