AW: AMD Radeon RX Vega 56: Gut 1.700 MHz bei bis zu 400 Watt Leistungsaufnahme möglich
Ich hab' hier 3 Probleme/Gründe, warum ich vom GPGPU Zeug schreib':
1) die meisten, mir eingeschlossen, wissen ungefähr was gemeint ist, ohne dies wirklich genau zu verstehen. Ich habe 2007 einen Raytracing Algorithmus für die R600 geschrieben, aber die Hardware selbst kann ich dennoch nicht erklären
Ich persönlich habe von Programmierung praktisch keine Ahnung, entsprechend empfinde ich es etwas bizarr, wenn die Softwarewelt von der Hardwarewelt so getrennt erscheint, dass habe ich aber schon öfters mitbekommen.
Du musst jetzt nicht hämlisch werden. Ich weiß nicht was konkret im Falle von GCN so viel mehr Fläche/Transistoren benötigt als noch unter Terascale Zeiten oder im Vergleich zu Nvidia. Ob es zusätzliche Caches sind oder aber Funktionen, die Nvidia so nicht in Hardware unterstützt... ich gebe zu, ich weiß es nicht, welches Ausmaß diese zusätzlichen "Features" benötigen. Am ehesten kann ichs noch vom Cache abschätzen, alles andere könntest du mir Fantasiezahlen nennen und ich müsste es wohl glauben.
Da bist viel eher du der Experte, das gebe ich ja auch offen zu.
Mein hämischer Zorn hat dich einfach nur zufällig getroffen, es hat mich nur wieder an das Thema erinnert, was seit der Kepler-Ära in der Echo Chamber reflektiert wird.
Dabei maße ich mir auch gar nicht an, es viel besser zu wissen, nur wenn man ständig davon spricht, sollte wohl auch irgendein Argument oder eine Eigenschaft dahinter stehen, solche Ausführungen liest man dagegen viel seltener.
Gut, wenn du dich als Laie bezeichnest, sind wir wohl komplett Ahnungslose. Letztlich weiß AMD doch sicher seit 2011 selbst um die Schwächen der GPU, da verwundert es schon, dass es so lange dauert, diese zu beheben. In derselben Zeit entwickelte man früher völlig neue Architekturen.
Im Verlauf der Zeit gewichte ich AMDs geringes R&D-Budget immer mehr.
Vega brachte eine Menge Änderungen mit sich, die besonders für den Gaming-Bereich entwickelt worden und die Endresultate sind stellenweise mies, man merkt auch das die Hardware nur einen schwachen Rückhalt von der Software bekommt.
Gerade wenn man zieht, dass viele Features erst zum Launch aktiviert worden sind und einige selbst Heute nicht funktionieren.
Paar Sachen die einem zu Denken geben können oder einfach interessant sind:
1. Die General-Purpose-Register bei Vega haben das Know-How von den Zen-Entwicklern verwendet, die neuen GPRs sollen 18% weniger Fläche benötigen und 43% weniger Energie konsumieren.
Das ist massiver Fortschritt und absolut allgemein, da GPRs bei jeder Operation die Werte zwischenspeichern und 4096 mal im Falle von Vega 10 vorhanden sind.
https://www.techpowerup.com/reviews/AMD/Vega_Microarchitecture_Technical_Overview/images/arch-30.jpg
2. Das neue ROP-Backend funktioniert wie es soll.
Unter Vega sind die ROPs an den L2$ angeschlossen und die Daten werden kohärent gehalten, entsprechend kann man sich Cache-Flushes vom L2$ sparen, wenn man Rendering-Operationen zu einer Textur durchführt:
The curtain comes up on AMD's Vega architecture - The Tech Report - Page 3
Sebastian Aaltonen (Ex-Rendering-Lead by Red Lynx, einer Ubisoft-Tochter) hat diesbezüglich Zahlen für sein Indie-Spiel Claybook genannt:
I was on a one week vacation during the Vega launch. Now back at office. I can now freely talk about Vega, since I am now using public Vega RX drivers.
Some tidbits:
- I can confirm that Vega's ROP caches under L2 seem to work properly. I see a reduction in L2 cache flushes in Claybook (UE 4.16.1) with RGP (
Radeon GPU Profiler - GPUOpen) on Vega FE versus RX 480. Flushes (L1+L2+K$+CB+DB) = 881 (RX480) -> 674 (Vega). 142 L2, 60 CB and 66 DB flushes on Vega (will paste RX 480 numbers when I get home). I actually found some UE 4.16.1 DX12 back end perf bugs and sync bugs with this tool.
- Async compute works fine on Vega and RX 480. In Claybook we don't currently have enough async compute work (mostly physics and fluid sim) to cover all raster passes (shadows, g-buffer, velocity buffer, custom Z) on Vega. Currently our async compute workload is designed around current gen base consoles, which only have 12-18 CUs. You could easily add 10x+ more fluid on Vega without seeing noticeable slow down (would simply increase GPU utilization). RX 480 behaves more like consoles, but even it would need more async compute work to be fully occupied.
- Currently RX 480 runs Claybook at 2560x1440 @ locked 60 fps (~15 ms). Vega runs 4K at ~50 fps (~20 ms). Haven't yet done PC specific optimizations, but console opts work pretty well on PC AMD.
AMD Vega 10, Vega 11, Vega 12 and Vega 20 Rumors and Discussion | Page 186 | Beyond3D Forum
Das heißt Polaris muss ~31% häufiger seinen L2$ leeren, im Vergleich zu Vega.
Den L2$ zu leeren gehört nach dem DRAM-Zugriff zu den langsamsten Operationen und frisst auch entsprechend viel Strom, diese Architektur-Änderung verbessert entsprechend die Perf/Watt nennenswert.
Leider frisst Vega trotzt 14nm und all den architektonischen Verbesserungen zu viel Strom, zu viel um sein Taktpotential überhaupt auszunutzen, obwohl gerade hier AMD anscheinend am meisten investiert hat.
Primitive Shader sind noch gar nicht aktiv, werden vermutlich auch noch ein paar % die Perf/Watt verbessern, aber insgesamt muss so vieles verbessert werden, bevor Vegas Performance schlüssig erscheint.
Shader Engines, vielleicht ist es auch möglich DP Einheiten extra zu fertigen oder andere "Dinge", die es ermöglichen, dass AMD ähnlich wie bei Zen einen Die fertigt, der dann mit anderen Funktionseinheiten (in dem Fall andere Dies) verbunden werden können.
Ist halt jetzt Theorie, inwieweit das Sinn macht und funktioniert weißt du wieder besser wie ich.
DP-Einheiten auf jeden Fall nicht, da du für die Recheneinheiten entsprechende Register und Caches benötigst, eig. fast die ganze Pipeline, entsprechend ergibt es nur Sinn, dass neben den FP32-Einheiten zu integrieren oder die ALUs entsprechend aufzupumpen, dass beides geht.
Die Idee dahinter ist aber natürlich interessant, auch was sich in der Praxis lohnen wird, als eigenständiges Modul zu existieren.
Bei GPUs würde man ja nicht unbedingt 2-4 mal die Media-Engine für Video-Decoding haben wollen, aber würde es sich lohnen, extra ein Modul ohne zu entwickeln, weil die Fixkosten pro Chip-Entwicklung sind ziemlich hoch.
Für die Zukunft scheint aber dieses Bild von Intel ganz adäquat zu erscheinen:
https://www.pcgamesn.com/sites/default/files/Intel Heterogeneous CPU design.jpg