AMD Vega 20: XGMI-Interconnect als NV-Link-Konkurrent

Was soll man denn anpassen müssen, wenn Nvidia bei gesteckten NVlink eine einzelne GPU silutliuert?

In erster Linie "spricht" die Software mit dem Treiber und wenn der Treiber sagt: jo hier ist nur einer.. Aber mal schauen ob es das Konzept überhaupt gibt

Jensen hat auf der Präsentation gesagt "erweitere deine GPU selbst" NVLink die Brücke kosten ca. 80 EUR da muss doch ein Konzept dahinter stecken das mehr bietet als einfaches SLI.

Wie wärs mit Geld verdienen? Ne mal im Ernst, das ist nur im profesionellenbereich interessant wo viel im Vram ausgelagert werden muss da macht das Sinn.Ich glaube kaum das sich die Probleme von SLI damit erübrigen.
 
Aber warum verkauft NV dann diese NVLink Bridge auch für Gamer Karten, wenn für einfaches SLi eine normale Bridge reichen würde?
 
Ich frag mich wie man hier auf die Idee von CPu-GPu verbindung kommt.
Das einzige was man weis ist das die neuen Vega XGMI unterstüzen sollen - was für ein verbindungs-Kabel zwischen GPUs spricht (ala SLI-brücke oder Sidechannel)

Moment mal - zu geringe SPP - ist das womöglich die Erklärung für das gestern von mir beobachtete Bildrauschen in BF V unter DX12?
Das dürfte doch auf meiner Radeon gar keine Relevanz haben!? Sieht aber 1:1 danach aus.
Besonders in dunkleren Arealen ist mir das gleich aufgefallen. Und nur unter DX12.

Ne, hat wirklich nichts damit zu tun da derzeit das Dx12 Feature Raycasting nicht genutzt wird.
 
Ich frag mich wie man hier auf die Idee von CPu-GPu verbindung kommt.
Die Antwort dazu steht doch schon in der News drin, nicht gelesen?

Mittels XGMI kommunizieren zwei Epyc-CPUs auf Dual-Sockel-Mainboards miteinander. In Zukunft könnte AMD zusätzlich zur Inter-GPU/-CPU-Kommunikation auch die Daten zwischen Epyc-CPUs und Vega-20-GPUs über XGMI-Links austauschen lassen und so ein geschlossenes Ökosystem anbieten. Nvidias NV-Link integriert IBM in seine Power-CPUs, AMD und Intel haben daran logischerweise kein Interesse.
 
Nein, da das nichts mit AMDs Techonologie zu tun hat.
AMD hat früher eine HPC-APU geplant, wo GMI/IFOP verwenden worden wäre, für die On-Package-Kommunikation zwischen CPU und GPU:
7e42c9447e754167c85105ffe1a1d866_xl-jpg.1008630


Aktuelle zwei Sockel EPYC-Systeme verwenden xGMI/IFIS um zwischen den Sockeln zu kommunizieren und genauso könnte es AMD auch für die Kommunikation zu GPUs verwenden.
Ob AMD das auch machen wird, ist aktuell noch nicht ersichtlich und eine HPC-APU ist weiterhin MIA.
 

Anhänge

  • 7e42c9447e754167c85105ffe1a1d866_XL.jpg
    7e42c9447e754167c85105ffe1a1d866_XL.jpg
    205,5 KB · Aufrufe: 307
@Casurin:
Deswegen hat die Redaktion das auch im Konjunktiv geschrieben, als Möglichkeit.

Oder hälst du Nvidia für so technologisch überlegen, dass das AMD nicht kann? ^^
 
Oder hälst du Nvidia für so technologisch überlegen, dass das AMD nicht kann? ^^
Ich halte Nvidia durchaus für technologisch überlegen -das ist ja auch ein Fakt. Aber so strohdumme Aussagen wie "AMD kann das nicht" wirst du von mir nicht hören - nur das die ganze Geschichte hier auf reiner Spekulation und nicht der Realität beruht da die einzige richtige Information die war haben ist das im Code für zukünftige GPUs die Unterstützung von XGMI steht. und Nvlink mit powerPC ist nochmal eine ganz andere Art von zusammenspiel und hat mit dem hier wenig bis gar nichts zu tun
 
So schlecht fand ich die News jetzt nicht geschrieben, und normalerweise bin ich da sehr kritisch. ^^
Es ist halt wieder einmal ein Spekulationsthread, weil genaue Infos dazu von der Industrie nicht verfügbar sind.
 
Grundsätzlich ist es möglich.
Jedoch sind der kritische Punkt neben der Bandbreite auch die Zugriffslatenzen auf Speicher und das Controlling. Die für die GeForce Karten verfügbare Bandbreite von 100GB/s wird weder für den Zugriff auf Speicher der jeweils anderen Karte nicht ausreichen und die Koordinierung der beiden Karten ist massiv aufwändig für Spiele. Ich denke, dass es nicht funktionieren wird.
Es wäre allerdings schön, denn wäre der Fluch von SLI kein Problem mehr.

160GB/s steht in dem Artikel hier. Nicht gelesen?

Wäre dann übrigens immerhin noch schneller als so manche Low End Grafikkarte generell in den Speicher pumpen kann.

Aber warum verkauft NV dann diese NVLink Bridge auch für Gamer Karten, wenn für einfaches SLi eine normale Bridge reichen würde?

Weil die normale SLI Brücke deutlich zu wenig ist um eine gescheite Synchronisation ohne MR hinzubekommen.
 
Moment mal - zu geringe SPP - ist das womöglich die Erklärung für das gestern von mir beobachtete Bildrauschen in BF V unter DX12?
Das dürfte doch auf meiner Radeon gar keine Relevanz haben!? Sieht aber 1:1 danach aus.
Besonders in dunkleren Arealen ist mir das gleich aufgefallen. Und nur unter DX12.
Kann halt auch ein Film Graining Shader sein. Raytracing in der nicht-raytraced Version wird nicht Schuld sein
 
Aber warum verkauft NV dann diese NVLink Bridge auch für Gamer Karten, wenn für einfaches SLi eine normale Bridge reichen würde?
Weil dies z.B. den Vram addiert - wo da der nutzen ist? Nun dass must die MultiGPU User fragen. In jedem Fall ist es, sollte man sich, warum auch immer, für Multi GPU entscheiden, einfach besser - insbesondere angesichts der knausigren Vram Politik bei Grün aktuell...
 
160GB/s steht in dem Artikel hier. Nicht gelesen?

Wäre dann übrigens immerhin noch schneller als so manche Low End Grafikkarte generell in den Speicher pumpen kann.
[...]
Es sind 50-100GB/s beim Turing:
NVLink High-Speed GPU Interconnect | NVIDIA Quadro

Die 160GB/s kommen von der einfachen Hochrechnung, dass wenn die aktuelle HB-Brücke 3,2GB/s liefert Faktor 50 ungefähr 160GB/s wären, aber wie gesagt sind es "nur" 50-100GB/s.
 
Ich habe keine Ahnung welche Anpassungen es benötigen würde, um zwei GPUs als Eine anzumelden, aber falls es möglich wäre, würde es miserabel laufen.
Wenn Abhängigkeiten bei der Arbeitslast bestehen, müsste man so etwas auflösen und bei Bedarf Daten hin und her kopieren müssen, die im besten Fall im Video-RAM wären, sprich mit >500GB/s angebunden und im schlimmsten Fall beim Chip selber im L2$ oder noch tieferen Speicherstruktuturen, dann sind es schon mindestens TB/s über die wir reden.
Ein GV100 mit 6 NVLINKs bietet 300GB/s, ein GT102 scheint nur 2 Links anzubieten, also 100GB/s.
Das reicht nie und nimmer für eine gute Performance aus, wenn die Arbeitslast so aufgestellt ist, als ob das eine einzelne GPU wäre.

Es würde wohl eine andere Herangehensweise an den Aufbau einer GPU erfordern.
Z.B.:

1) Controller Chip mit komplettem Frontend und "slots", um Chiplets mit SMs anzumelden
2) Chiplets mit allen SMs
3) Backend Chip mit ähnlichem Konzept wie der Frontend Chip.

So könnte man deutlich kleinere Chiplets bauen und bewahrt Skalierbarkeit für alle, ohne in Cache Probleme zu rennen.
 
Warum muss man denn gleich volle Bandbreite bieten? Wenn zwei GPUs auf den shared HBM gleichermaßen zugreifen können, dann könnte man einen schmalen Interconnect zwischen den GPUs verwenden, der es ermöglicht Daten auszutauschen. Das wäre dann zwar hinsichtlich der Flexibilität eingeschränkt. Aber was soll's, dann nimmt man es für spezielle Aufgaben, die sich dadurch auszeichnen, dass die Ergebnisdaten einer Berechnung relativ klein sind, wie das bei Raytracing der Fall ist.
 
Es würde wohl eine andere Herangehensweise an den Aufbau einer GPU erfordern.
Z.B.:

1) Controller Chip mit komplettem Frontend und "slots", um Chiplets mit SMs anzumelden
2) Chiplets mit allen SMs
3) Backend Chip mit ähnlichem Konzept wie der Frontend Chip.

So könnte man deutlich kleinere Chiplets bauen und bewahrt Skalierbarkeit für alle, ohne in Cache Probleme zu rennen.
Schematisch hat Nvidia in ihrem Forschungspaper nur ein Front-End dargestellt mit I/O und dann vier Chiplets:
https://cdn01.hardwareluxx.de/razun...studie-1_72D8A36A6BA1419883DE761D54C1EF86.jpg

+

1008687-amd-vega-20-xgmi-interconnect-als-nv-link-konkurrent-nvidia-mcm-gpu-gpc-dram-dies_3-1030x679.png


https://research.nvidia.com/sites/default/files/publications/ISCA_2017_MCMGPU.pdf

Im Forschungspaper wird eine GPU mit 256 SMs (4 x 64 SMs) simuliert mit insgesamt 3 TB/s an HBM2 Speicher, wobei jedes Chiplet lokal Zugriff zu ihrem HBM2-Speicher mit 768GB/s besitzt.
Dabei wurde der Einfluss von der Geschwindigkeit beim Interconnect zwischen den GPUs berücksichtigt, von 6TB/s bis hinab zu 384GB/s:
https://cdn01.hardwareluxx.de/razun...studie-4_7F7CF7E63A604D90B81DE89D94C62D94.jpg

Bei Speicher intensiven Aufgaben führt ein Interconnect schwächer als die aggregierte HBM2-Speicherbandbreite von 3TB/s zu relativ starken Leistungsverlust.
Bei 1,5TB/s sind es 12% Verlust, bei 768GB/s dagegen schon ganze 40% und 384GB/s führen zu 57% Leistungsverlust.
Aber Nvidia stellt zwei Modifizierungen vor, womit der NUMA-Charakter soweit abgeschwächt wird, sodass der Leistungsverlust stark verringert wird und 768 GB/s einen guten Kompromiss darstellen.
1. Es wird ein 16MB großer L1.5$ eingeführt, um die Synchronisation von Daten zwischen Chiplets zu beschleunigen.
2. Es wird das Scheduling angepasst, um die Daten lokaler zu verteilen.

Beides hat dann soweit ich das richtig überflogen habe die Geschwindigkeit, um über 20% erhöht.

Allgemein sind wir noch weit entfernt von solchen Dimensionen und es könnten noch weitere Verbesserungen beim Konzept geben, aber der grobe Leitfaden empfiehlt gerade eine Interconnect Geschwindigkeit, welche ungefähr mit der Speicherbandbreite von einem Chiplet übereinstimmen sollte + entsprechende Architekturänderungen sind notwendig und Herausforderungen bei der Zusammenschaltung von unterschiedlichen dies und Funktionen.
Rein von der Interconnect-Geschwindigkeit scheinen wir aber nicht weit entfernt zu sein, um solche Konzepte zu ermöglichen.
 

Anhänge

  • NVIDIA-MCM-GPU-With-GPC-and-DRAM-Dies_3-1030x679.png
    NVIDIA-MCM-GPU-With-GPC-and-DRAM-Dies_3-1030x679.png
    124,9 KB · Aufrufe: 198
Zurück