Next-Gen GPU: Warum ein Multi-Chip-Ansatz für Navi alles andere als trivial ist

[HWL News Bot]

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...

... weiterlesen

 

[Hardwareaner]

Ich stimme dem Fazit zu, der Ansatz ist durchaus interessant, birgt aber auch enorme Risiken. AMD bekommt aktuell nicht einmal bei ihren monolithischen Chips die Leistung auf die Straße. Da sehe ich noch einige Fallstricke bei denen sich AMD wohl wieder einmal verheddern wird. AMD sollte schauen erst einmal die aktuellen Probleme in den Griff zu bekommen. Einfach nur 2 oder 4 Mittelklasse Chips aneinanderzukleben wird nicht reichen.

 

[Holzmann]

Und Du weißt schon jetzt, dass AMD nicht weiter an ihrer IF arbeitet und sie bei zukünftigen Einsätzen deutlich effizienter zu Werke geht? Interessant...
Wenn ich mich nicht irre arbeitet man schon relativ lange an der Skalierbarkeit von mehreren Chips und hat das im Grunde (auch bei Nvidia/Intel) als die Zukunft vorausgesagt.
Klar hat Nvidia ein deutlich höheres Budget, aber was passiert wenn man vergleichsweise lange in bestimmten Bereichen keine echte Konkurrenz hat, haben wir nun hinlänglich bei Intel gesehen.

Und zu guter Letzt: Vielleicht richtest Du Dich in einem Brief einfach direkt an AMD und erklärst ihnen in all Deiner vollkommenen Weisheit, dass sie mit ihren wahrscheinlichen zukünftigen Plänen total daneben liegen. Vielleicht bewahrst Du sie ja vor einem großen Fehler...

 

[majus]

Das wird denen auch klar sein..
Stellt sich eher die Frage, ob Zeit und Geld ausreichen werden das ganze auch richtig umzusetzen.

 

[Alashondra]

Ach Holzmann IF ist nicht alles.

Wenn AMD bei den Monoliths sagen wir nur 80% der Rohleistung auf die Straße bringt ... was bringt dir dann 2x80%? Ihr redet hier aneinander vorbei Du sprichst von der GPU untereinander und Hardwareaner von der GPU zum Bildschirm. An sich ist der Ansatz ja wirklich interessant und eigentlich auch nur logisch - was am Ende, und ob es überhaupt kommt ... erstmal Navi abwarten

 

[Hardwareaner]

Wenn AMD bei den Monoliths sagen wir nur 80% der Rohleistung auf die Straße bringt ... was bringt dir dann 2x80%?

Selbst diese 2x80% sind nur der Idealfall, der voraussetzt, dass es keine neuen Limitierungen wie z.B. beim Interconnect gibt.
Das Thema ist sehr komplex und die möglichen Probleme löst man nicht mal eben nebenbei. Das kann zumindest anfangs nur ein Testballon wie Fiji werden.

 

[Holzmann]

Das kann zumindest anfangs nur ein Testballon wie Fiji werden.

Du meinst "Overclockers Dream" Oje das wären aber trübe Aussichten.

Mal schauen was Navi für Mainstream dann so kann, so lange ist das ja nicht mehr ...

 

[Don]

Selbst diese 2x80% sind nur der Idealfall, der voraussetzt, dass es keine neuen Limitierungen wie z.B. beim Interconnect gibt.
Das Thema ist sehr komplex und die möglichen Probleme löst man nicht mal eben nebenbei. Das kann zumindest anfangs nur ein Testballon wie Fiji werden.

Das mit der Skalierung und dem Interconnect sind die entscheidenden Punkte. Laut einer Studie von NVIDIA ist es derzeit nicht möglich einen Interconnect zu fertigen, der den Anforderungen gerecht wird. Außerdem können laut NVIDIA keine "normalen" GPUs für ein solches MCM-Design zum Einsatz kommen, sondern nur sogenannte GPU-Module (GPM), die speziell dafür ausgelegt sind – unter anderem um die Interconnect-Bandbreite zu sparen. Das würde dann aber wiederum nicht dazu passen, dass AMD einfach eine Mittelklasse-Navi-GPU mehrfach nimmt.

 

[why_me]

Schöner Text, aber da sind mMn. ein Paar kleine Schnitzer/falsche Annahmen drinne.

- Vega hat schon infintiy fabric, die ersten Schritte sind damit schon einmal getan. Dazu die Erfahrungen mit Epics MCM.
- dazu noch HBCC, mit dem man auf die Daten der anderen DIEs zugreifen könnte
- Die Bandbreite zwischen den GPUs muss gar nicht so groß sein. SLI/Crossfire haben doch über die Jahre gezeigt, dass PCIe2.0 8x (4GB/s) schon ausreicht um gute FPS und keine/kaum Mikroruckler zu erhalten.

Letzten Endes dürfte das Ganze auf technischer Ebene gar nicht so kompliziert werden. Die Technik dazu gibt es seit mehreren Jahren. Problematisch wird da eher die Software/Treiber und wie diese die die GPU ansprechen. Wobei wir hier auch schon seit Jahren mit SLI/Crossfire theoretisch nicht anderes machen. Oder DX12 Multi-GPU mit "doppeltem VRAM" (das würde man für eine MCM GPU benötigen, in jedem Spiel und die Sache wäre geritzt). So weit zumindest die Theorie.

Das mit der Skalierung und dem Interconnect sind die entscheidenden Punkte. Laut einer Studie von NVIDIA ist es derzeit nicht möglich einen Interconnect zu fertigen, der den Anforderungen gerecht wird. Außerdem können laut NVIDIA keine "normalen" GPUs für ein solches MCM-Design zum Einsatz kommen, sondern nur sogenannte GPU-Module (GPM), die speziell dafür ausgelegt sind – unter anderem um die Interconnect-Bandbreite zu sparen. Das würde dann aber wiederum nicht dazu passen, dass AMD einfach eine Mittelklasse-Navi-GPU mehrfach nimmt.

Warum denn nicht? Was ist denn der unterschied zwischen einem GPM und einer GPU? das GPM muss keine Displays ansteuern.

Das mit der Bandbreite einsparen, was Nvidia anspricht mag ja schön und gut sein, aber nicht zwingend Notwendig für ein MCM design. Und Schaden kann es wohl auch nicht, diese Bandbreiten sparmechaniken einfach zu deaktivieren, wenn man bei einer Single-Chip Lösung keinen interconnect braucht.

 

[Elmario]

Ist doch schön. Wenn das mit MCM klappt, würde wohl auch Crossfire sein Comeback feiern können. Mit flexibel skalierbarer Leistung über hinzufügbare Kärtchen

 

[fdsonne]

- Vega hat schon infintiy fabric, die ersten Schritte sind damit schon einmal getan. Dazu die Erfahrungen mit Epics MCM.
- dazu noch HBCC, mit dem man auf die Daten der anderen DIEs zugreifen könnte
- Die Bandbreite zwischen den GPUs muss gar nicht so groß sein. SLI/Crossfire haben doch über die Jahre gezeigt, dass PCIe2.0 8x (4GB/s) schon ausreicht um gute FPS und keine/kaum Mikroruckler zu erhalten.

Was spielen diese 3 Dinge im Text für eine Rolle?
Die "Infinite Fabric" ist in erster Linie ein Marketingname. Was dahinter steht definiert die konkrete Umsetzung. Mit einer Technik, die es in Sachen MCM im GPU Geschäft brauchen würde hat die Namenswahl aber erstmal überhaupt nichts gemein.
HBCC spielt ebenso keine Rolle, da wie im Text schon zu entnehmen eher die Bandbreite das Problem darstellt bei Querzugriffen zwischen den GPUs. Im übrigen auch das "Problem" im NUMA Mode bei non NUMA aware Software auf Epyc/TR und allen anderen Dual bis Multi-NUMA Node Systemen.
Der dritte Punkt ist auch völlig aus dem Kontext. Die notwendige Bandbreite HEUTE ist bei SLI/CF so ultra gering, weil es eben ein AFR (ggf. SFR) Mode ist. Jede GPU berechnet dabei ihr Bild allein oder ein Teil eines Bildes. NACH dem Bearbeitungsprozess wird das Bild übertragen. Das kostet fast keine Bandbreite oder stellt wenig Anforderungen. Wenn man von MCM im GPU Umfeld spricht meint man idR aber viel eher den Punkt, Rechenwerke so zusammen zu schalten, dass eine Skalierung stattfinden kann OHNE spezielle Rendermodi fahren zu müssen.
Also verdoppelte die Coreanzahl und habe (fast) doppelte Performance. Das ist der Punkt in Sachen aktueller GPU Umsetzung. Fiji ist quasi doppelt so schnell wie Tahiti bei Taktgleichheit, weil so ziemlich alles verdoppelt wurde. (Beispiel)
Stecke ich ne zweite Vega in den PC passiert da genau gar nichts, trotz IF -> weils eben nicht zusammen arbeitet.

Letzten Endes dürfte das Ganze auf technischer Ebene gar nicht so kompliziert werden. Die Technik dazu gibt es seit mehreren Jahren. Problematisch wird da eher die Software/Treiber und wie diese die die GPU ansprechen. Wobei wir hier auch schon seit Jahren mit SLI/Crossfire theoretisch nicht anderes machen. Oder DX12 Multi-GPU mit "doppeltem VRAM" (das würde man für eine MCM GPU benötigen, in jedem Spiel und die Sache wäre geritzt). So weit zumindest die Theorie.

Halte ich für den falschen Ansatz - MCM bei GPUs wird dort interessant, wo man Hardware ohne notwendige Softwareanpassungen verschalten kann.

Warum denn nicht? Was ist denn der unterschied zwischen einem GPM und einer GPU? das GPM muss keine Displays ansteuern.

Das mit der Bandbreite einsparen, was Nvidia anspricht mag ja schön und gut sein, aber nicht zwingend Notwendig für ein MCM design. Und Schaden kann es wohl auch nicht, diese Bandbreiten sparmechaniken einfach zu deaktivieren, wenn man bei einer Single-Chip Lösung keinen interconnect braucht.

Ganz einfach - ne GPU hat als Interconnect ein PCIe Interface nach außen. Ne zweite GPU müsste über diesen Interconnect mit sprechen. Ne Dritte ebenso, ne Vierte auch usw.
Um dem Problem aus dem Weg zu gehen bräuchte es wohl eher einer Art Connector, wo du die Rechenwerke dran tackerst. So wie früher - steckst halt nen Co Prozessor dazu.
Die Dinger laufen dann aber wahrscheinlich nicht allein. Ich könnte mir da dann bspw. ALU DIEs vorstellen, die nach oben skaliert werden. TMU/TAU DIEs, ROPs auf eigenem DIE usw. Das ganze kommt dann auf einem Interposer oder wie auch immer - wird mit einer Logikunit gepaart, welche auch ein PCIe Interface (oder welchen Typ auch immer) mitbringt und ebenso für eine Speicheranbindung sorgt.

Bei AMD könnte dieser Mittler die IF sein. Aber auch AMD fehlt es im Moment noch (mMn) an einer fertigen Lösung, an diese IF mehrere schnelle HBM Interfaces anzubinden und die Bandbreiten dann nutzbar zu machen. Genau so wie die Anbindung zwischen den einzelnen Units nicht existiert im Moment. Auf einem nativen Design sind die Wege sehr kurz und der Spaß skaliert nach gewissen Regeln. Die Anordnung der Units gibt den Skalierungsrahmen vor. Bei aktuellen AMD Modellen ist das sehr flexibel - die können in fast jede Richtung hoch oder runter skalieren. Bei NV ist das wohl weniger flexibel. Mehr SI = mehr ROPs. Oder mehr GPCs = mehr Teile vom FrontEnd... AMD hingegen baut halt ne Vega/Fiji GPU mit 4096 ALUs auf einem ähnlich aufgebauten FrontEnd wie ne Tonga GPU bei nur halber ALU Ausbaustufe. Würde es in der Form bei NV gar nicht geben...

Hätte AMD hier eine fertige Lösung, hätte man doch diese Ideen lose Umsetzung bei Epyc/TR als Multi-NUMA Node Ansatz gar nicht in der Art gebracht.

 

[why_me]

Häää? Oben sagst du IF und HBCC sind hier uninteressant und unten forderst du genau das, was die beiden liefern.

Eine skalierbare, kohärente Verbindung zwischen den Modulen kann man mit IF erreichen.
PCIe wird an einem Master angebunden und alle Anderen Module werden über einen interconnect (=IF) verbunden.
HBM muss nicht direkt mit IF verbunden werden, dafür gibt es ja den HBCC, der sich um die ganzen Adressräume, Verwaltung der Daten, etc kümmert und die Daten holt, wenn sie gebraucht werden.


Und für jede Funktion ein extra DIE, das ist der beste Witz. Back to the 70s. Da bringen einen die Latenzen um, jedes Modul bräuchte riesige Caches um die Bandbreite abzufangen etc. .... Wenn MCM kommen wird, dann wird es spezial module für KI geben (Tensor Cores), Compute Module mit DP Leistung etc. Aber nicht für zum Beispiel den Memory Controller oder die ALUs ein extra DIE.

Auch wird man den HBM nicht über IF an die Module liefern, sondern eher Module mit 2k shadern und je 1 stack HBM mit 2-4GB speicher und davon dann 1,2,3,4 neben einander. Ein Modul wäre dann mit 7nm ca. 150mm² groß und sehr günstig zu produzieren. Man könnte mit einem DIE die Grafikkarten von 150€-1k€+++ abdecken.

Und selbst wenn die GPU nur ein NUMA Node wäre, das kann dir als Endanwender doch egal sein, der Treiber muss damit klar kommen. Ob man da am Ende was von den Latenzen merkt bleibt abzuwarten.

 

[Balle]

Möglich wäre auch dass man Navi über die nächste Zeit nur leicht optimiert und lediglich die Mittelklasse bedient. Mit dem übrigen Budget könnte man bis 2020/21 dann den nötigen interconnect auf die Beine stellen. Ich kann mir einfach nicht vorstellen, dass sich monolithische GPUs (besonders für die Oberklasse) auf Dauer lohnen.

 

[Marfy]

Ein Sehr guter Artikel! Es werden fragen aufgeworfen die auch mich beschäftigen.

AMD muss es irgendwie schaffen die Latenz zwischen den GPU-Modulen zu verringern und die Bandbreite für die Kommunikation unter den GPU-Modulen zu maximieren.
Wie das gehen soll - gute Frage! Ich hoffe AMD hat eine Lösung! ;-) Das es zu Flaschenhälzen innerhalb des Prozessors kommen kann haben wir bei Ryzen gesehen. Ich hoffe AMD hat aus diesen Erfahrungen gelernt und weiß diesen Herausforderungen zukünftig zu begegnen!

Der Vergleich an manchen stellen mit Crossfire und SLI ist aber etwas schwierig. Zwar kann man Rendering Methoden die dort anwendungen finden als Beispiel heranziehen. Aber dennoch sind große teile von diesem Multi-GPU betrieb in Software realisiert.
Wie wir in der IT wissen, sind Software und Hardware equivalent. Was man mit einem Hardware Router machen kann, kann man auch in Software mit einem PC und mehreren Netzwerkkarten realisieren.
Was eine CryptoMiner Software wie Claymore zusammen mit einer Grafikkarte "erminen" und Hashen kann, kann man ebenso in Hardware als ASIC "gießen" (zumindest wenn der Algorithmus nicht geändert wird oder das Überprüfungsparadikma von Proof of Work zu Proof of Stake gewechselt wird).
Es wurde ein Load Balancer erwähnt. So etwas braucht es definitiv, aber in Hardware, transparent für die Anwendungen, direkt auf der Grafikkarte. Sofern soetwas in Software ausgelagert wird, gibt es garantiert Probleme. Der Overhead für Crossfire oder SLI, explizit programmieren zu müssen, ist der Grund für den schlechten Support in Spielen dieser Tage.

Die Hier erwähnten schwerpunkte und Herausforderungen, sind meiner Meinung nach der Grund warum AMD zunächst die "neue Mittelkasse" des Jahres 2019 anstrebt.
Mit so einem neuen und Revolutionären Ansatz wird es schwer die Erwartungen an ein High-End Gerät zu befriedigen.

Ich finde die Gerüchteküche aber gerade sehr spannend! Eine willkommene Auflockerung zum ganzen Trübsahl blasen der vergangenen Tage und Wochen.

 

[MG127]

Hört sich für mich an, als wenn AMD extrem verzweifelt ist.

 

[why_me]

@MG127: Wie kommst du denn da drauf?

 

[Hardwareaner]

Letzten Endes dürfte das Ganze auf technischer Ebene gar nicht so kompliziert werden. Die Technik dazu gibt es seit mehreren Jahren. Problematisch wird da eher die Software/Treiber und wie diese die die GPU ansprechen. Wobei wir hier auch schon seit Jahren mit SLI/Crossfire theoretisch nicht anderes machen. Oder DX12 Multi-GPU mit "doppeltem VRAM" (das würde man für eine MCM GPU benötigen, in jedem Spiel und die Sache wäre geritzt). So weit zumindest die Theorie.

Wenn AMD wieder von Software und Treibern abhängig sein sollte, dann hätten sie bereits jetzt verloren. Aus der Vergangenheit sollte man auch mal lernen und nicht immer wieder in dasselbe Messer rennen.
Für den Kunden zählt nur eins: was am Ende rauskommt bzw. auf dem Bildschirm ankommt.

 

[mustrum]

Hört sich für mich an, als wenn AMD extrem verzweifelt ist.

Ehrlich gesagt, muss ich zustimmen. AMD Multi GPU Karten haben wir schon öfter gesehen, immer wenn ihnen die Ideen ausgehen.
Die Geschichte zeigt vor allem, dass keine einzige dieser Karten eine gute Lösung war, da von Crossfire Profilen abhängig.

Eine solche Karte wäre wirklich nur dann für mich interessant, wenn es von Spieleentwickler Seite her gesehen absolut keinen Anpassungsbedarf gibt, um die volle Leistung abzurufen. Es müsste alles auf Treiberlevel passieren. Ich kann mir ehrlich gesagt nicht vorstellen, dass das möglich ist.

Ansonsten endet man, wie immer, mit einer Karte die zum Teil im Leerlauf rumdümpelt und ein Benchmarkkönig ist.

 

[Marfy]

Wenn AMD wieder von Software und Treibern abhängig sein sollte, dann hätten sie bereits jetzt verloren. Aus der Vergangenheit sollte man auch mal lernen und nicht immer wieder in dasselbe Messer rennen.
Für den Kunden zählt nur eins: was am Ende rauskommt bzw. auf dem Bildschirm ankommt.

Dem kann ich nur zustimmen!

Eine "Zen-artige" Navi-MCM-GPU darf auf keinen Fall auf Software zurückgreifen um die Kommunikation zwischen den Modulen zu organisieren. Dies wäre einfach viel zu langsam! Die Infinity Fabric oder ein anderer Hardware-Controller muss das schaffen diesen "Crosstalk" auf dem GPU-Package vor zugreifenden Software-Schichten zu verstecken. Eine Anwendung darf nur die gesamte GPU sehen. Selbst der Radeon Treiber dürfte meiner Meinung nach, nicht einmal etwas davon mitbekommen das es eigentlich mehrere GPU-Dies sind die die Arbeit machen.
Anderenfalls hat man nur eine weitere Multi-GPU Grafikkarte und wir wissen ja wie erfolgreich diese heutzutage sind.

 

[sekas]

Sehe in der Grundannahme "interconncet zu langsam, da IF nur 100GB/s schnell" schon einen großen fehler!

HBM wird doch zZ auch mittels interconnect angebunden, und liefert eine höhere Bandbreite als GDDR5 bei (angeblich) geringerem Stromverbrauch. Würde also eine deutliche steigerung in dem BEreich nicht ausschließen, denn ob nun Chip mit HBM, HBM mit HBM oder Chip mit Chip kommuniziert ist ja der schnittstelle egal .

 

[Don]

Nein, der HBM hängt über den Interposer direkt am Speichercontroller der GPU. Da wäre der IF ein Flaschenhals.

 

[sekas]

Dennoch zeigt HBM mMn dass es möglich ist eine hohe BAndbreite zwischen verschiedenen Chips zu realisieren.
Und ich denke dass somit zwischen 2 GPUs mindestens die selbe bandbreite erreichbar wäre wie zwischen GPU und CPU.

Auch frage ich mich, ob es in Games wirklich so auf die Bandbreite ankäme. dass NVlink kommt ja auch vorwegend für Neuronale netze zum einsatz, wo die bandbreite einfach eine ganz andere rolle spielt. Da ist nciht wie bei Spielen die Busanbindung nur im einstelligen bereich ausgelastet.

 

[kozfogel]

Dennoch zeigt HBM mMn dass es möglich ist eine hohe BAndbreite zwischen verschiedenen Chips zu realisieren.

HBM kommuniziert nicht - das tut der Grafikchip mit seinem Speichercontroller (welcher auf HBM Speicher zugreift).

Und ich denke dass somit zwischen 2 GPUs mindestens die selbe bandbreite erreichbar wäre wie zwischen GPU und CPU.

Das wäre deutlich zu langsam. GPU <-> CPU ist mit PCI-E 16 und seinen ~16GBs ist im vergleich zu einer HBM-Speicheranbindung vom 400-500 GBs doch recht dürftig.

Da ist nciht wie bei Spielen die Busanbindung nur im einstelligen bereich ausgelastet.

Welcher Busanbindung ist gemeint?

 

[Don]

Ich kann mich nur auf die MCM-GPU-Studie von NVIDIA beziehen. Diese besagt es sei eine Package Bandbreite von 1,2 TB/s und eine Inter-Modul-Bandbreite von 10 TB/s notwendig. Davon sind wir noch etwas entfernt.

 

[unl34shed]

Oder eine Redundanz der Daten beim VRAM der einzelnen Module um Speicherzugriffe auf den anderen Chip zu minimieren. Im lokalen Speicher bleibt eine Kopie von allem womit gerade gerechnet wird. Der Speicher müsste also mehr wie ein Cache funktionieren.

 

[sekas]

HBM kommuniziert nicht - das tut der Grafikchip mit seinem Speichercontroller (welcher auf HBM Speicher zugreift).

wirkt der interposer dann nicht torzdem wie ein Bus? sollte doch egal sein ob an einem ende ein passiver oder ein aktiver sender sitzt? Im endeffekt sollten sich doch ähnliche datenraten erreichen lassen, oder?

Das wäre deutlich zu langsam. GPU <-> CPU ist mit PCI-E 16 und seinen ~16GBs ist im vergleich zu einer HBM-Speicheranbindung vom 400-500 GBs doch recht dürftig.

Sorry sollte nciht GPU - CPU sondern GPU - HBM heißen. PCIe ist natürlich deultich langsamer

Welcher Busanbindung ist gemeint?

hier beziehe ich mich auf die PCIe.
bei Spielen ist bspw die leistungseinbuse zwischen 8x PCie 2.0 und 16x PCIe 3.0 sind nahezu vernachlässigbar (bzw waren es vor ein paar jahren mal)
bei Deep learning hingegen ist der Bandbreitenbedarf deutlich größer. und genau darauf ziehlt Nvlink ab (wurde zumindest bei uns so präsentiert)

Hab jetzt allerdings keine tieferen schaltungstechnischen kenntnisse, kann also gut sein dass ich auch falsch liege

 

[Cibo]

PCI ist viel zu langsam für derartige Aufgaben sonst würde man ja auch kein Vram benötigen und alles über den Systemspeicher abwickeln.
PCI 16x dürfte 64GB/s maximal schaffen während sich HBM bei ca 250GB/s je Stack bewegt.

Aber das genau funktioniert ja so einfach nicht weil die Daten auch von anderen Chips benötigt werden. Gerade der lokale Cache (L1-L3) ist ja vorhanden und genau die Daten kriegt man nicht schnell genug in den Nachbarchip damit er damit arbeiten kann. Früher hätte ich evtl. gesagt okay GPU1 berechnet alles innerhalb 50m, GPU2 alles 50m+. Nur heute gibt es soviele Effekte welche alles beeinflussen, geschweige den Echtzeitraytracing was irgendwann kommt das man so eine einfache Trennlinie nicht mehr ziehen kann.

 

[kozfogel]

wirkt der interposer dann nicht torzdem wie ein Bus? sollte doch egal sein ob an einem ende ein passiver oder ein aktiver sender sitzt? Im endeffekt sollten sich doch ähnliche datenraten erreichen lassen, oder?

Der haupt Unterschied ist das es hier eine 1:1 Verbindung ist, und der Chip die alleinige Kontrolle hat - sobald man da ein "switch" einbaut welches Zugriffe verwalten muss, sinkt die Datenrate erheblich und Latzen steigen.

hier beziehe ich mich auf die PCIe.
bei Spielen ist bspw die leistungseinbuse zwischen 8x PCie 2.0 und 16x PCIe 3.0 sind nahezu vernachlässigbar (bzw waren es vor ein paar jahren mal)
bei Deep learning hingegen ist der Bandbreitenbedarf deutlich größer. und genau darauf ziehlt Nvlink ab (wurde zumindest bei uns so präsentiert)

Hab jetzt allerdings keine tieferen schaltungstechnischen kenntnisse, kann also gut sein dass ich auch falsch liege

Das liegt daran das über die PCI-E Schnittstelle nur "Ergebnisse" ausgetauscht werden. Die Grafikkarte muss nicht auf Ressourcen im Hauptspeicher zugreifen, solange der eigene speicher reicht. Wenn das passiert, geht die FPS in den Keller - genau dafür braucht man diese hohen Datenraten. Bei einem SLI/CF System zB wird es dadurch umgangen dass die Daten redundant auf jeder GPU gelagert werden - was natürlich bei einem MCM nicht sein sollte.

 

[[HOT]]

Bei dem Thema haben viele denke ich einfach ne falsche Vorstellung. Gesetzt des Falles, AMD würde Navi wirklich per-Chip-skalierbar machen, dann würde das nicht aussehen, wie ein SLI/CF-Gespann. Man braucht Hardware um effizient zu sein, AFR und SFR sind jedoch Softwarelösungen. Und da greift der Artikel schon an die richtige Stelle. Wenn wir in die Vergangenheit schauen, sehen wir bei 3dfx skalierbare Architekturen. Mit einfachem DX7-Rendering (shaderlos) war es möglich ber SLI zu arbeiten und die Renderchips einfach hochzuskalieren, diese Chips waren jedoch aus heutiger Sicht reine Backends. Bei Spectre/Rampage änderte sich alles aufgrund der neuen DX8-Shaderarchitektur. Man teilte damals in Vertex und Pixelshader auf, Vertexshader Spectre war ein Vertexshader-Zusatzcontroller (transparent für die Architekur, deshalb Spectre) und Rampage war der eigentliche Grafikprozessor mit Pixelshader, welcher wiederum skalierbar war aber eben sehr schwer zu beherrschen. Leider endete damit ja die Story, das ist ja bekannt.
Seit AMDs Xenos und NVs G80 bieten die Hersteller jedoch GPUs mit unified shadern an, welche Geometrie und Pixelberechnungen in denselben Recheneinheiten ausführen und somit eine Chip-Skalierung sehr kompliziert machen. Man unterscheidet nicht länger zwischen Geometriechips und Renderchips sondern wie beim Prozessor zwischen Frontend und Backend. Die einzige Skalierbarkeit, die ich dort sehe, wäre, wenn man hier die Trennlinie zieht. Man braucht einen Frontendchip, der den Framebuffer bildet der dann ALU-Coprozessoren anbindet mit entsprechend hoher Bandbreite. Beispielsweise bräuchte man einen Mainchip, der bis zu 3 Backends anbinden kann mit 3x je 64Bit breitem Interfache, jeder Backendchip kann dann meinetwegen, 2K Shader beinhalten. Das Ganze muss man mit relativ großen Caches versehen, um die Latenzen abzufangen (wie Zen das macht). Zusammenfassend kann man sagen, dass GPU-Skalierung alles andere als umsonst ist, dennoch könnte der Kostenvorteil entscheidend sein. Das Ganze muss auf einem Interposer realisiert werden, da nur dieser schnelle Direktverbindungen in großer Bandbreite ermöglicht und den Stromverbrauch in Grenzen hält. Denn der Stromverbrauch ist die Archillesverse einer Multi-Chip-Architektur. 7nm ist so teuer, dass es erstmals lohnend sein kann, eine MCM-Architektur für GPUs zu designen.

 

[smalM]

Ich kann mich nur auf die MCM-GPU-Studie von NVIDIA beziehen. Diese besagt es sei eine Package Bandbreite von 1,2 TB/s und eine Inter-Modul-Bandbreite von 10 TB/s notwendig. Davon sind wir noch etwas entfernt.

Das sind Werte weit jenseits der Speicheranbindung einer GPU an den VRAM. Wozu sollte eine GPU-GPU-Verbindung das benötigen? Zumal es hier um die traditionelle Rolle der GPU als Grafikkarte geht, bei der viele Speicherzugriffe auf den VRAM der anderen GPU durch redundante Speicherung völlig überflüssig werden.