Werbung
In der vergangenen Woche sorgt die Meldung, dass AMDs Navi-Architektur die Mittelklasse bedienen und keine High-End-GPU werden würde, für großes Aufsehen. In den Kommentare entbrannte dabei auch eine Diskussion darüber, ob AMD eine Navi-GPU mit beispielsweise 2.048 Shadereinheiten entwickelt, damit diese die Mittelklassse bedienen kann. Per Multi-Chip-Module (MCM) analog zu den Ryzen-(Threadripper)-Prozessoren könnten dann aber einfach zwei oder vier solcher Navi-Module verwendet werden, um eine entsprechend leistungsstärkere GPU anzubieten.
Als Basis für diese Gedankengänge dient AMDs eigene Beschreibung der Navi-Architektur, denn in früheren GPU-Roadmaps war immer die Rede von NextGen Memory und Scaleability. Während für NextGen Memory nur die Rede von GDDR6 oder HBM3 sein kann, bezieht sich Scaleability wohl auf eben diesen Ansatz: Die Architektur soll entsprechend breiter aufgestellt werden, indem es verschiedene Ausbaustufen gibt. Prinzipiell ist dies bei den aktuellen Architekturen von AMD und NVIDIA heute schon der Fall, allerdings sprechen wir dann noch immer von monolithischen Chips, die im Falle von NVIDIAs GV100 inzwischen 815 mm² groß sind. Bei den Prozessoren sind wir inzwischen bei ähnlichen Größen angekommen. Für die Ryzen-Threadripper- und Epyc-Prozessoren verwendet AMD aber ein MCM-Design bestehend aus vier Dies zu je 213 mm² = 852 mm². Intel hingegen bleibt dem monolithischen nich immer Treu und erreicht damit inzwischen 720 mm² für Knights Corner und 698 mm² für Skylake SP/X.
Also spielen wir eine GFX10/Navi-Architektur im MCM-Design einmal durch und schauen uns dabei vor allem die technischen Hürden an, die sich auch für MCM bei den Prozessoren bereits zeigen:
Ein MCM-Design für GPUs hätte hinsichtlich der Fertigung und Kosten große Vorteile. Anstatt eines großes Chips werden mehrere kleinere, deren Ausbeute gut ist und deren Fertigungskosten gering sind, zusammengeschaltet. Der Overhead eines MCM-Designs gegenüber einem monolithischen Ansatz beträgt laut AMD etwa 10 % (für Epyc/Ryzen Threadripper 777 mm² zu 852 mm²). Für das Beispiel der Prozessoren liegen die Kosten für das MCM-Design beim Faktor 0,59 gegenüber einem monolithischen Design. Diese Werte dürften sich auch in etwa so auf eine GPU übertragen lassen.
Auch bei NVIDIA wird an MCM-Design für GPUs geforscht. Dabei kommen GPU-Module (GPM) zum Einsatz, welche zum Beispiel in einem Mesh mit weiteren solchen Modulen in einem MCM zusammengebracht werden. Es handelt sich dabei um spezielle MCM-GPUs, die auf die Bedürfnisse in einem MCM angepasst sind. Damit erreichen die Forscher eine um den Faktor fünf reduzierte interne GPU-Kommunikation über einen internen Interconnect und gleichzeitig kann die Leistung des einzelnen GPM um 22,8 % gesteigert werden.
Ein schneller Interconnect ist das größte Problem
Schwierig wird es bei den grundsätzlichen Funktionsweisen einer GPU. Einige der Herausforderungen eines MCM-Designs einer GPU zeigen sich auch schon bei den Prozessoren. Für Ryzen, Ryzen Threadripper und Epyc verwendet AMD den eigens entwickelten Infinity Fabric zur Kommunikation der einzelnen Dies untereinander, aber auch für die Anbindung nach außen. Hier spielen vor allem die Speichercontroller eine Rolle, was sich im Falle von Ryzen Threadripper in den unterschiedlichen Speichermodi Non-Uniform Memory Access (NUMA) und Uniform Memory Access (UMA) äußert. Auch bei den Ryzen-Prozessoren zeigt sich eine gewisse Abhängigkeit von schnellem Speicher und möglichst geringen Latenzen innerhalb der CCX-Cluster.
AMD erreicht in seinen Prozessoren eine Die-zu-Die-Bandbreite von 42,7 GB/s und eine Systembandbreite von bidirektionalen 170,7 GB/s. Im Falle von GPUs sind selbst diese kombinierten 170,7 GB/s aber viel zu wenig, denn wir sprechen hier von Speicheranbindungen im High-End-Bereich von 512 bis 1.024 GB/s – also dem Vielfachen dessen, was derzeit über Infinity Fabric möglich ist. Wie wichtig ein schneller Interconnect aber ist, zeigte die Vorstellung des NVSwitch von NVIDIA, der den NVLink-Interconnect über 16 GPUs mit bis zu 7,2 TBit/s verteilt, was etwa 900 GB/s entspricht und damit der Bandbreite des Speichers entspricht. Speicherbandbreite ist das eine, innerhalb einer GPU werden allerdings auch Terabyte an Daten pro Sekunde von und zu den L1-, L2- und L3-Caches geschoben. Eine GPU aus zwei oder mehr Dies teilt sich einige dieser Ressourcen und muss daher untereinander kommunizieren.
Bandbreite ist das eine Thema, Stromverbrauch das andere. Ein Interconnect ist nicht nur hinsichtlich der Anbindung alles andere als trivial, sondern auch was die Leistungsaufnahme betrifft. Ein NVSwitch kommt auf eine Leistungsaufnahme von knapp unter 100 W wenn alle 576 NVLink-Lanes verwendet werden. Aber auch wenn auf einem GPU-Package deutlich weniger Lanes benötigt würden, wäre die Leistungsaufnahme ein Hauptthema für den Einsatz eines solchen Interconnects.
Am Ende ist entscheidend, wie schnell sich der HBM an die einzelnen Dies anbinden ließe. Die UMA/NUMA-Modi der AMD-Prozessoren zeigen das Problem deutlich auf auf einer ähnlichen Ebene wäre dies auch für eine GPU die technische Herausforderung.
MCM-GPU benötigt spezielle Rendermodi
Aus Sicht der Fertigung wäre der notwendige Interconnect also eine recht große Hürde für ein MCM-Design einer GPU. Es kommen aber noch weitere hinzu.
Wie teilt sich ein GPU aus mehreren Dies die Arbeit auf? Hier kommt natürlich recht schnell der Multi-GPU-Ansatz ins Spiel – mit all seinen Nachteilen. Die Diskussion um Alternate Frame Rendering (AFR) und Split Frame Rendering (SFR) haben in der Vergangenheit bewiesen, dass sie nicht der Weisheit letzter Schluss sind. Auch das eigentlich für SLI namensgebende Scan-Line Interleave ist nach heutigen Erkenntnisse keine Maßnahme, um das Rendering eines Frames sinnvoll auf zwei oder mehr GPUs zu verteilen.
Am effektivsten dürfte ein Checker Board/Supertiling sein, also eine Aufteilung des zu berechnenden Frames in mehrere kleine Bereiche. Beim Ray Tracing und dem 3D-Rendering mit Workstation-Karten kommt eine solche Technik bereits zum Einsatz und hat sich hier als relativ effektive Methode herausgestellt. Allerdings sprechen wir dabei noch nicht von einem Echtzeit-Rendering mit 60 FPS, was Auswirkungen auf die Darstellung der gerenderten Frames hat. Eine Art Load Balancer müsste sicherstellen, dass alle Bereiche des Frames zur gleichen Zeit durch die zwei oder mehr GPUs berechnet werden und absolut zeitgleich ausgegeben werden. Wie gesagt, all diese Probleme kennen wir schon von Multi-GPU-Ansätzen wie SLI und CrossFire und die enormen Herausforderungen auf Seiten der Hardware haben wohl auch dazu geführt, dass Multi-GPU-Rendertechniken für das Gaming eine immer geringere Rolle spielen.
Zur Reduzierung der internen Bandbreite und Aufteilung des Renderings auf die zur Verfügung stehenden Ressourcen verwenden aktuelle GPUs bereits ein Tile Based Rendering. Das Gegenkonzept zu Tile Based Rendering (TBR) ist das Immediate Mode Rendering. Dabei wird der Rasterization-Prozess über den kompletten Frame angewendet, während beim Tile Based Rendering der Frame in viele kleine Tiles, also rechteckige Blöcke aufgeteilt und der Rasterization-Prozess durchgeführt werden kann. Typischerweise sind diese Tiles 16x16 oder 32x32 Pixel groß. Diese Parallelisierung kommt den aktuellen GPUs mit mehreren Tausend Shadern natürlich positiv entgegen. Das Immediate Mode Rendering hingegen ist besonders hinsichtlich des Speicherbedarfs recht aufwendig.
Doch das Tile Based Rendering hat nicht nur Vorteile. Nahezu alle Spiele und weitere Anwendungen sind auf ein Immediate Mode Rendering ausgelegt und dahingehend optimiert. Für die Maxwell- und Pascal-Architektur musste sich NVIDIA daher einige Tricks einfallen lassen, damit das Tile Based Rendering seine Effektivität ausspielen kann. Dazu gehört auch spezieller DirectX-Code, der sich spezifisch an die Triangle-Rasterization richtet. Außerdem belässt das Tile Based Rendering Bereich der Grafik-Pipeline unangetastet. Dazu gehört das Tessellation, Geometry-Setup, Shader und vieles mehr.
Es ist also neben der Problematik des Interconnects auch hinsichtlich der Software und des Renderings keine einfache Lösung für eine MCM-GPU in Sicht bzw. uns nicht bekannt.
Vom Ansatz spannend, doch es gibt Fragezeichen
Die Antwort, ob AMD die Navi-Architektur als MCM-Design auch in das High-End-Segment übertragen kann, werden wir heute nicht beantworten können. Wir wissen ja noch nicht einmal, ob AMD mit Navi wirklich wie vermutet auf die Mittelklasse abzielt oder nicht doch ganz andere Pläne hat.
Dennoch ist es einmal interessant sich über ein MCM-Design einer GPU einmal ein paar Gedanken zu machen, wenngleich diese noch nicht zu einer abschließenden Lösung führen.