PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: Hardware- und Nachrichten-Links des 6. August 2019


Leonidas
2019-08-07, 11:31:10
Link zur News:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-6-august-2019

Gast
2019-08-07, 23:09:13
Gleichfalls findet man damit aber auch eine Erklärung, wieso die GCN-basierten Grafikchips so vergleichsweise stromfressend waren: Die Hardware bekam zwar ihre Arbeit aufgebrummt, die zur Verfügung stehenden Ressourcen (primär die Shader-Einheiten) wurden dabei jedoch nicht vernünftig ausgelastet und konnten somit aus viel Rohleistung nur mittelprächige Performance-Resultate herausziehen. Weil aber die Hardware technisch gesehen arbeitet (und nicht idelte), war der Stromverbrauch immens, immerhin hat AMD zu allen GCN-Zeiten deutlich mehr Shader-Einheiten als nVidia ins Feld geführt.

Wenn das so war/ist, dann ist es aber ein ganz schlechtes Hardware-Design. SIMD-Lanes die nichts zu tun haben könnte man auf jeden Fall clock-gaten, und damit die verschwendete Energie stark verringern.

Dass man nur mehr 128 Threads braucht um einen WGP theoretisch auszulasten, gegenüber den 512 eines GCN-CUs relativiert sich in der Praxis auch stark.

Das Ganze erkauft man sich nämlich durch eine Latenz von 5 Takten innerhalb der Threads, von einander abhängige Instruktionen müssen also mindestens 5 unabhängige Befehle dazwischen haben, ansonsten stallt die Pipeline. Bei GCN war die issue rate gleich der Latenz, auf Abhängigkeiten innerhalb des Codes brauchte man also einerseits keine Rücksicht und konnte gleichzeitig die Hardware um die Abhängigkeiten zu überprüfen ersparen.

Laut dem Paper kann die Hardware immerhin bei Abhängigkeiten die Pipeline-Stalls mit anderen Warps füllen, sofern genügend Threads vorhanden sind, nur dafür braucht man eben wieder mehr Threads (im schlimmsten Fall 5x so viel und damit mehr wie bei GCN) um die Pipeline vollständig zu füllen.
Weiters braucht man insbesondere bei Grafikberechnungen, auf jeden Fall 1000e Threads um Speicherlatenzen zu verstecken, damit relativiert sich dieser Vorteil von RDNA sehr stark. Nur bei Compute-Berechnungen die weitestgehend in den Registern selbst stattfinden hat man wirklich diesen eklatanten Vorteil.

Der eine Takt mehr Latenz erklärt allerdings warum sich RDNA so viel besser takten lässt.

Das Ganze ist nur ein Puzzlestein in der besseren Effizienz von RDNA.

Leonidas
2019-08-08, 08:38:39
Ich denke nicht, das AMD kein Clock-Gating bei GCN hatte. Das Problem sind die Teillasten - wenn ein wenig Arbeit da ist, damit ergo nichts wirklich stillgelegt werden kann.

Und ja - all das sind nur Puzzlesteinchen. Den einen großen Wurf gibt es bei so ausgeklügelter Technik schon lange nicht mehr.

Mr.Smith
2019-08-08, 11:23:18
Ganz an nVidia sind sie noch nicht dran, was Effizienz angeht, aber liest sich ganz gut und ist auch die Erste Generation, lässt auf die späteren Generationen hoffen.

Abzuwarten bleibt, wie sich nVidia's nächste Generationen ändern.

cat
2019-08-08, 12:33:58
Naja bis auf die Positionierung von Nvidias Polymorph-Engines,
sieht man hier jeweils 5 Stück 128ALU (geteilt in 4x 32ALU) an einem Rasterizer.
Beide 2560 ALUs.
Und dann hört es auch schon wieder auf, dass ich Ähnlichkeiten zwischen 5700XT und GTX1080 sehe.
Wobei die kleinere non-XT die mit der vergleichbaren Performance ist und auch die vergleichbarere Effizienz zeigt, die XT ist schneller aber auch ineffizienter.

Turing ist nochmal ein anderes Kaliber.

https://hexus.net/media/uploaded/2019/6/2acaceff-ff7a-4d53-91ee-2cd71d23fd7e.PNG

https://tpucdn.com/gpu-specs/images/g/793-block-diagram.jpg

Achja, für die die es interessiert ... 2560 x1,5 = 3840 (siehe Radeon VII)
Ich hoffe auf 6 Prim-Units und 6 Rasterizer mit der fetten Navi.

Gast
2019-08-08, 21:42:09
Ich denke nicht, das AMD kein Clock-Gating bei GCN hatte. Das Problem sind die Teillasten - wenn ein wenig Arbeit da ist, damit ergo nichts wirklich stillgelegt werden kann.


Clock Gating ist gerade für Teillasten gedacht.
Wenn gar keine Arbeit notwendig ist kannst du gleich komplett Powergaten.

Es sollte technisch überhaupt kein Problem sein, in GCN einzelne 16er SIMDs clockgaten, wenn keine Warps vorhanden sind um diese auszulasten. Wieviel AMD davon umgesetzt hat weiß ich natürlich nicht.

Ich glaube allerdings mal bei Nvidia gelesen zu haben, dass sie sogar einzelne Lanes eines SIMDs clockgaten können, wenn aufgrund divergierender Sprünge innerhalb eines Warps in manchen Lanes ein NOP notwendig ist.

Die geringe Auslastung der SIMDs sollte auf jeden Fall bei guter Umsetzung kein Powerproblem sein, sondern "nur" ein Performanceproblem.

Was natürlich der Fall ist, wenn die durchschnittliche Auslastung der SIMDs bei üblichem Code gering ist, und dann plötzlich Code der diese zu fast 100% auslasten kann kommt, ist ein extremer Verbrauchsanstieg, bzw. umgekehrt beim Powerlimit eine entsprechende Verringerung der Taktfrequenz, weil die "durchschnittlichen Taktraten" natürlich auch auf die "durchschnittliche Auslastung" ausgelegt sind.

Ich glaube eher der Umstieg von 4 x SIMD16 auf 2x SIMD32 einerseits durch den Wunsch höhere Taktraten zu erreichen motiviert. Damit waren die 4 Takte Latenz, welche mit 4x SIMD16 komplett versteckt werden konnten nicht mehr möglich, da dies nur durch eine Verlängerung der Pipeline erreicht werden konnte. Mit der alten Variante hätte man dann zwar nur mehr 1 statt 5 Takte effektive Latenz, aber man hätte in jedem Fall die Hardware erweitern müssen um Abhängigkeiten abzufangen.
Andererseits konnte man so wohl auch das Transistorbudget effizienter einsetzen.

Jedes SIMD braucht seine eigene Kontrolllogik, mit dem Umstieg von SIMD 16 auf SIMD32 spart man hier also ein.
Diese Transistoren konnte man dann beispielsweise in deutlich größere Caches investieren, welche wohl die Auslastung um einiges Verbessern können.

Gleichzeitig hat man auch die Scheduler umgebaut, so dass sie nun neben 64 Thread großen Warps auch 32 Thread große Warps verarbeiten können, was die Granularität verringert und damit wiederum die Auslastung erhöhen kann.

Leonidas
2019-08-10, 05:50:31
Danke für die umfangreiche Erklärung.