AW: Radeon 2018: AMD hält Erwartungen an Vega und Polaris niedrig
ich will Vega mit Aquabolt ... mach ma AMD!
Würde im Schnitt Vega10 auch nicht retten.
Ich glaub Amd entsorgt auf der zusätzliche Chipfläche Atommüll und macht so Gewinn.
Der Chip hat ca 40-50% mehr Transistoren pro Shader im Vergleich zu AMDs Fiji-Chip.
Die komplette Fiji GPU umfasst 8,9 Milliarden Transistoren auf 596 Quadratmillimeter Chipfläche.
Was Amd mit den Milliarden Transistoren macht, ist die Frage , es könnten 2mal Fiji Shader untergebracht werden,das ist ne Menge Chipfläche die bisher "nix" bringt.
Die Ipc ist nicht "BESSER" bei Vega als bei Fij also wozu so viele Transistoren? der Takt kann auch mit 28nm auf 14nm besser werden, Mehrleistung kommt nur vom Takt+ und HBM2.
IPC-Test zur Radeon Vega Frontier Edition zeigt sehr ineffektiven Vega-10-Chip | 3DCenter.org
YouTube
Die FE ging an den Start mit unfertigen Treibern, Vega10 war zum launch z.B. im Schnitt 6% schneller beim gleichen Takt, Spiele wie BF1 und Titanfall 2 sogar über 20%:
Radeon RX Vega 64 & 56 im Test: Der helle Stern wirft lange Schatten (Seite 7) - ComputerBase
Laut AMD ist das meiste Budget für die höheren Taktraten draufgegangen und seit GCN Gen 3 hat sich schon eine Menge getan.
Die Geometrie-Engines sind besser geworden, die Parameter-Caches deutlich größer, die Instruction-Buffer pro CU sind größer, bei Vega10 gibt es im Vergleich zu Fiji auch mehr I$ und K$, da nur noch von 3 CUs geteilt und nicht mehr 4.
Der L2$ ist doppelt so groß und es gibt eine Menge neuer Features wie Draw-Stream-Binning-Rasterizer, Double-Rate FP16, Conservative-Rasterization, ROVs usw. was DX12 anbelangt und andere APIs.
Die Transistoren sind nicht im schwarzen Loch gelandet, die Leistungsskalierung leider irgendwie schon.
Die Ipc kann so auch nicht besser sein als die von Fiji. Die zusätzlichen Tansistoren sind nur für das Routing da, um Vega mehr Takt zu entlocken.
Nochmal ( sollte ich hier große Schnitzer drin haben bitte Korrigieren! ):
GCN ist von der Idee her super. Der Hardware scheduler von GCN macht eine super Arbeit für die geringe Menge die er an Strom frisst. NV ist da mit Fermi bisschen auf die Nase gefallen ...
Das Frontend ist okay, allerdings geht hier schon das debakel von GCN los. Vereinfacht ausgedrückt ist es so ( nehmen wir mal Polaris 10 XT als Beispiel ) das wir einen Chip mit 2304 Shadern haben. Das sind 36 "Shader-Cluster" ( grob gesagt skaliert AMD über die Anzahl an Cluster die "größe" des entsprechenden Chips. Wenn ich nicht ganz falsch liege hat Tonga und Fiji sogar das exakt gleiche Frontend obwohl Fiji doppelt so groß ist
) welche aus 4 x 16 SIMD Blöcken besteht also 64. Diese Aufteilung ist bei allen GCN Produkten identisch, wenn das jemand nachrechnen möchte.
Vereinfacht ausgedrückt ist es halt so das jeder Shader-Cluster 4 verschiedene Befehle gleichzeitig abarbeiten kann. Ohne jetzt weiter ins Detail gehen zu wollen ist es aktuell AMDs Problem das die SIMD Einheiten nicht ausgelastet werden wenn die "Berechnung" weniger als 16 Befehle in Anspruch nimmt. Das
müsste ( bin dann bei der Vorlesung wo es um uArch ansich ging eingeschlafen :> ) auch der Punkt sein wo AsyncCompute in Spiel kommt. Uns wurde da das Beispiel Pentium 4 ans Herz gelegt
welcher unter seiner langen Pipeline lit welche seine Ipc kaputt gemacht hat. Dafür wurde der Leerlauf für SMT benutzt
Natürlich ist die entsprechende Technik eine ganz andere ( CPU serieller Workload, GPU parallel ) und es sollte nur zur Anschaung dienen.
Ich hab mir das laienhaft so übersetzt das GCN in den wichtigen Bereichen "nicht breit genug" und "zu lang" ist um eine höhere Auslastung zu erzeugen.
Das ist zumindest das was mir im Kopf geblieben ist. Sollte hier jemand lesen der noch mehr Wissen als ich hat bitte ich darum das alles zu korigieren bevor ich Unwahrheiten im Netz verbreite.
AMD kann an GCN festhalten wenn sie diese Baustelle mit Navi angehen. Allerdings wird es nicht reichen die Shader zu verändern, das ganze Routing und Latenzen und und und müssen neu überarbeitet werden.
Die "IPC" bzw. sagen wir einfach effektive Leistung pro Takt ist höher und müsste eigentlich im Schnitt viel höher ausfallen.
Letztendlich kann man sich nur die Endleistung anschauen, die sich aus unzähligen Faktoren zusammensetzt und besonders bei Spielen wird es kompliziert, weil dann schauen wir uns die ganze Pipeline einer Architektur an und können Fixed-Function-Einheiten nicht ignorieren, die einen wesentlichen Faktor bezüglich der Performance und Effizienz darstellen.
Seit GCN Gen 3/Fiji hat sich an sehr vielen Stellen etwas getan.
GCN Gen 5/Vega10 vs. 3/Fiji:
- Der Draw-Stream-Binning-Rasterizer reduziert den Overdraw stark und erhöht die Perf/Watt, laut der Hot Chips-Präsentation gewinnt die Vega FE dadurch 7% Performance und auch ungefähr 7% Perf/Watt.
http://extreme.pcgameshardware.de/news-kommentare-zu-grafikkarten/505503-amd-radeon-vega-20-und-vega-12-linux-patches-vermerkt-6.html#post9311413
- Die Geometrie-Engines sind deutlich besser, die Parameter-Caches größer, das Strip-Format führt nicht mehr zu massiven Performance-Verlusten, Dreiecke werden verworfen, wenn sie kleiner als ein Pixel sind und nicht zum Bildinhalt beitragen:
Benchmarks und Fazit
Und das merkt man dann auch besonders bei Tessellation:
https://www.computerbase.de/2017-08/radeon-rx-vega-64-56-test/4/#abschnitt_vega_legt_bei_tessellation_zu
RoTR Tess Off = 29% schneller, Tess on = 54% schneller, TW3 Tess Off = 46% schneller, Tess on = 61%.
- Unterstützt Instruction-Prefetching, erhöht effektiv die Performance der CUs und das sieht man bei so Demos wie 2nd Stage Boss, die nur aus Compute bestehen und der ganze Inhalt in die Caches passt:
http://www.pcgameshardware.de/Vega-Codename-265481/Tests/Benchmark-Preis-Release-AMD-Radeon-Frontier-Edition-1232684/3/#a4
- Hat 33% größere Instruction-Wave-Buffers
- Das Infinity-Fabric hat deutlich bessere Schreib/Leselatenzen was die TMUs betrifft (siehe Hot Chips Präsentation, erster Link beim DSBR)
- Die Delta-Color-Compression unterstützt weitere Kompressionsformate und ist effizienter geworden, erhöht effektiv die Bandbreite.
- Die ROPs halten ihre Caches nun L2$ kohärent, Vega muss seinen L2$ bei Deferred-Rendering deutlich seltener leeren, erhöht die Performance und Effizienz, Sebastian Aaltonen hat wenn ich mich richtig erinnere ~1/3 weniger Cache-Flushes im Vergleich zu Polaris bei seinem kommenden Spiel Claybook gemessen.
Das sind alles Dinge, welche die Performance in vielen Situationen verbessern und an vielen Stellen auch nachgemessen werden konnten, dass am Ende im Schnitt aber die Performance ~6% besser ausfällt, ist ein Trauerspiel, da hängt dann irgendwo an anderer Stelle etwas oder AMD ist mit den Treibern noch nicht soweit (gewesen).
-----
Was GCNs Design-Schwächen angeht wird es sehr akademisch und da braucht es dann wahre Experten, um das seriös einschätzen zu können.
Bezüglich des Hardware-Schedulers kann man aber schon mal die Frage aufstellen, welcher?
Jeder Chip hat zig unterschiedliche Hardware-Scheduler, egal von welchem Hersteller.
Bezüglich der Compute-Unit hat GCN einen Scheduler, welcher jeden Takt eine SIMD-Einheit mit einer Wavefront bzw. Arbeitsbündel aus 64 Threads versorgt und jede SIMD-Einheit rechnet ihre 64 Threads in 4 Takten statisch durch ohne auf die Instruktionen zu achten.
Bei Nvidia sind das Scheduler, welche 32 Threads an die SIMD-Einheiten verteilen und die nicht nur auf Thread-Level-Granularität arbeiten, sondern auch schauen, welche Instruktionen am Besten ausgeführt werde sollten.
Bei Fermi hat sich die Hardware noch darum gekümmert, um zu überprüfen, welche Instruktion als nächstes ausgeführt werden sollten, ab Kepler übernimmt das die Hardware nicht mehr, da eine so komplexe Überprüfung nicht notwendig ist und unnötig Komplex ausfällt und Energie kostet.
Siehe Seite 10 aus dem Whitepaper zu Kepler:
https://www.nvidia.com/content/PDF/kepler/NVIDIA-Kepler-GK110-Architecture-Whitepaper.pdf
Teilweise haben einige es in den Kopf bekommen, dass Nvidia seit Kepler irgendwie allgemein keinen Hardware-Scheduler mehr hat und deswegen die DX12-Performance so schlecht im Vergleich zu AMD ausfällt.
An der Stelle ein völlig falsches Bild.
------
Bezüglich der SIMD-Units, dass ist natürlich ein komplexes Thema und es gibt Vor- und Nachteile bei den Gründen für das Design.
AMD z.B. verwendet Arbeitsbündel von 64 Threads, dass führt schon einmal generell dazu, dass bei AMD im Schnitt prozentual mehr Leerlauf existiert, als bei Nvidia, welche nur 32 verwenden.
Ein anderes Problem ist die Lebenszeit von einem Arbeitsbündel, bei 64 werden mehr Register reserviert, bevor der Platz wieder freigegeben wird, dass kann dann auch wieder zu niedrigerer Performance führen.
Vorteile sind z.B. sind das man aber bei 64 Threads eben 64 verteilt werden und nicht nur 32, damit kann AMD sicherlich Scheduling-Logik sparen, wenn sie nur einen Verteiler und notwendige Funktionen pro 64 Threads brauchen und nicht pro 32, im Optimalfall, wenn es wenig bis keinen Leerlauf gibt, ist das auch effizienter.
AMD kann und muss auch deutlich mehr Threads aktiv im Pool haben, um Latenzen zu verstecken.
Bei AMD kann eine Compute-Units aus 64 "ALUs" 2560 Threads in flight haben, Nvidia 2048 pro 128 "ALUs" (GP102 und GV100 haben nur 64 ALUs pro CU = deutlich mehr Threads möglich)
10 Wavefronts a 64 Threads pro SIMD-Unit = 10 x 64 x 4 = 2560 pro Compute-Unit x 64 im Falle von Fiji/Vega10 = 163.840 Threads in flight.
Bei Nvidia sind es 16 Warps a 32 Threads pro SIMD-Unit = 16 x 32 x 4 = 2048 x 20(1080) = 40.960 Threads bzw. x28 (1080 Ti) = 57.344 Threads.
Bei beiden hängt es davon ab, wie hoch die Registerlast pro Threadgroup ausfällt, denn das theoretische Maximum kann nur erreicht werden, wenn es genug Register bzw. Slots gibt.
Wenn es 256 Slots gibt und ein Arbeitsbündel schon 128 belegt, dann gibt es nur Platz für zwei Arbeitsbündel und damit sehr wenig Potential Latenzen zu verstecken, wenn eine Threadgroup auf die Ergebnisse warten muss und man in den Leerlauf kommt und stattdessen keine andere Wavefront abarbeiten kann.
Es ist aber nicht notwendig die maximale Anzahl an Threads im Pool zu haben, um die maximale Performance zu erreichen, nur nicht zu gering sollte es ausfallen.
Hier werfe ich mal das Thema Async Compute hinein.
Soweit ich das verstanden habe kann AMD mit sehr wenig Overhead zwischen GFX-State und Compute-State hin und her wechseln.
Eine CU kann gleichzeitig Wavefronts von 3D-Workgroups abarbeiten und Compute-Aufgaben.
Das hat dann explizit eine Bedeutung bei Spielen und APIs wie bei den Konsolen und DX12/Vulkan, denn bei Spielen kommen die Fixed-Function-Einheiten zum Einsatz, wie Vertex-Assembly, Rasterizer, TMUs, ROPs usw. und führen notwendige Vor- und Nacharbeiten durch, wo Instruktionen natürlich davon abhängig sein können.
Wartet man auf die Fixed-Function-Hardware können die Shader nichts machen, bei Async Compute kann AMD den Leerlauf damit effektiv fühlen, indem sie währendessen Compute-Aufgaben abarbeiten.
Vor Pascal hat Nvidia das Problem das ihre Hardware nicht "gleichzeitig" GFX- und Compute-Workgroups auf einer Compute-Unit ausführen kann und auch jetzt mit Pascal nicht, aber vor Pascal hat der notwendige Switch Nvidia bei Nvidia viel Zeit gekostet, da es länger gedauert hat bis der Arbeitsmodus gewechselt werden konnte und die Ressourcen für Compute und GFX-Aufgaben konnten nur statisch reserviert werden.
Pascal kann das dynamisch und schaltet wesentlich schneller um, sodass Nvidia jetzt auch schnell genug ist um von Async Compute zu profitieren, wenn man auch dort auf die Fixed-Function-Hardware warten muss.
Soweit ich das sehe, ist das aber nur am Rande ein Problem von GCN, denn wenn man GCN anschaut, dann ist das Herz davon eigentlich die ISA und der Shader-Aufbau und weniger wie die Grafikpipeline aussieht.
Deswegen ist es auch seit Jahren meine Vermutung, dass AMD nicht notwendigerweise von GCN wegkommen muss und eine völlig neue Architektur und Shader benötigt, sondern ihre Grafik-Pipeline auf Trab bekommen muss.
Vega hat hier am meisten verbessert und die Resultate zeigen es teilweise, aber wie gesagt die Endperformance und Effizienz ist miserabel.
Weil der Beitrag wohl schon lange genug ist, schneide ich nur grob noch weitere Themen an, die man natürlich nicht vergessen darf.
Wie der Cache-Aufbau, die Bandbreite pro Unit, welche Formate wie schnell berechnet werden können, die Skalare-Unit bei GCN, welche gewisse Sachen berechnen kann, ohne das man die SIMD-Units dafür braucht und teilweise Probleme mit 64 Thread großen Arbeitsgruppen negiert.
Dann so API und Shader-Sprachen Limitierungen, womit nicht jede Eigenart spezifisch optimiert werden kann und jede Architektur mehr oder weniger deswegen direkt leidet.
Wie gesagt, ohne einen Experten wird man wohl kaum eine seriöse Einschätzung abgeben können, dass Zeug was ich hier geschrieben habe, kann man teilweise sicherlich auch in die Tonne werfen, da es etliche Variablen gibt und grobe Überstellungen ein völlig falsches Bild abgeben könnten, wo Probleme bzw. Vor- und Nachteile herrschen.
