PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: AMDs Navi 2X unter N7+ ohne HBM frühestens im November, Navi 3X ...


Leonidas
2020-08-05, 11:59:45
Link zur News:
https://www.3dcenter.org/news/geruechtekueche-amds-navi-2x-unter-n7-ohne-hbm-fruehestens-im-november-navi-3x-nachfolgend-im-c

Complicated
2020-08-05, 14:24:11
Es wäre durchaus möglich, dass CDNA2 zuerst mit Chiplets kommt und anschließend RDNA3 von den Erfahrungen profitiert. CDNA "Arcturus" könnte durchaus auch schon ein Chiplet-Design sein, so wie die Kenndaten hier aussehen:
https://www.anandtech.com/show/15593/amd-unveils-cdna-gpu-architecture-a-dedicated-gpu-architecture-for-data-centers
This will be an Infinity Fabric-enabled part, using AMD’s second-generation IF technology. Keeping in mind that this is a high level overview, at this point it’s not super clear whether this part is going in either of AMD’s supercomputer wins; but given what we know so far about the later El Capitan – which is now definitely using CDNA 2 – CDNA (1) may be what’s ending up in Frontier.

https://www.hardwareluxx.de/index.php/news/hardware/grafikkarten/52971-arcturus-und-ponte-vecchio-neue-verweise-auf-hpc-karten-von-amd-und-intel.html
Hier war die Rede von 7.936 und 7.680 Shadereinheiten bei einem Takt zwischen 1.600 und 1.800 MHz sowie einer Bestückung von 32 GB an HBM2. Die neuen Details sprechen von 120 Compute Units, also 7.680 Shadereinheiten. Da es sich um ein Testboard handelt, liegt der Takt bei nur 878 MHz und die weiteren Komponenten sollen mit 750 MHz arbeiten. Der HBM2-Speicher kommt auf einen Takt von 1.200 MHz. Bei einem 4.096 Bit breiten Speicherinterface läge die Speicherbandbreite damit bei 1.228,8 GB/s.
Oder wurden da schon Details bekannt die Chiplets definitiv ausschließen für Arcturus?
Für RDNA2 und Big Navi werden schließlich ca. 80 CU als oberes Limit gehandelt bei den Spekulationen rund um die Diegrößen.

Leonidas
2020-08-05, 14:38:48
Arcturus ist ziemlich sicher SingleChip. Und mit CDNA2 kann man keine Erfahrungen für RDNA3 sammeln, das liegt zeitlich zu nahe zusammen. Zudem wäre das nur die halbe Miete. Multi-GPU auf heutigen Spielen und APIs, das ist die Frage. Da kann man 1000fach Erfahrung mit Multi-GPU bei CPUs und HPC-GPU haben, das ist (leider) eine ganz andere Kategorie. Ich persönlich denke nicht, das man das so einfach übers Knie brechen kann.

Complicated
2020-08-05, 15:21:16
Eine andere Kategorie ja, doch wir sind uns sicher einig, dass man zuerst ein Compute-Chiplet bestücken wird um dann Optimierungen von einem funktionierende Design aus für das Gaming durchzuführen. Wäre ja bescheuert den kompletten Sprung auf einmal zu machen und höhere Risiken als nötig zu fahren.
CDNA2 könnte ca. 6 Monate vor RDNA3 erscheinen oder auch nur 3 Monate. Warum sollte das zu eng beieinander liegen, wenn völlig verschiedene Märkte bedient werden. Alle Erfahrung mit CDNA2 können da in RDNA3 einfließen. Es wartet doch keiner bis CDNA2 erschienen ist um dann mal zu schauen was man mit RDNA3 macht. So funktioniert AMDs Entwicklung nachweislich nicht, wie wir alle mittlerweile wissen.

stinki
2020-08-05, 15:52:27
falscher Pfaden...

Gast
2020-08-05, 16:06:38
Multi-GPU für Rasterizer ist sehr unwahrscheinlich und lohnt sich sowieso nicht mehr, da Raytracing vor der Tür steht. Dort skaliert das sogar mit 8 GPUs:
https://www.youtube.com/watch?v=Zw3vwCBOjQ0

Berniyh
2020-08-05, 16:32:54
RDNA3 wird sicherlich nicht auf CDNA2 warten.
Letzterer wird vermutlich wieder grob ein halbes Jahr Vorsprung haben, aber das genügt ja einfach nicht.

Abgesehen davon sollte man auch im Hinterkopf behalten, dass ein Chiplet-Design bei RDNA3 sich ja auch nicht durch die komplette Chip-Serie ziehen muss.
Hat man bei den CPUs ja auch nicht gemacht, die APUs sind nach wie vor monolithisch aufgebaut.
Genauso könnte man bei RDNA3 mehrere Chips auflegen von denen manche monolithische Designs sind und manche auf Chiplets basieren um verschiedene Anwendungszwecke zu bedienen (z.B. High-End GPUs, Low-End GPUs, APUs etc.).
Mobile-Chips z.B. wären zwecks Stromverbrauch wohl eher monolithisch zu erwarten.

Gast
2020-08-05, 18:14:43
Schaut euch mal an welchen Bandbreiten die kommende gen hängt ,
wir sind höchstwahrscheinlich schon im Bereich über 1TB/S IF nuckelt schon bei einem Bruchteil davon auf den CPUs deutlich am powerbudged , chiplet Gaming GPUs bräuchten ein IF in ganz anderen Dimensionen wie CPUs inkl aller Nachteile teils potenziert wie Verbrauch Latenz usw.

Ich wage zu bezweifeln das wir sowas auch Gaming gepus in 2 Jahren schon sehen werden .

AMDoderNvidia
2020-08-05, 20:26:47
Hatten wir nich vor allzu langer Zeit hier im Forum eine Diskussion über den Chiplet-Ansatz bei Grafikkarten? Damals war konsens, dass man nicht nur den Compute-Teil (also die reinen Shader), sondern auch alles drumherum (Rasterizer, ROPs, ...) anbinden muss und dazu einfach die Bandbreite fehlt. Im Kern ging es darum, dass das benötigte Bussystem (was AMD als Infinity Fabric bezeichnet) weder die nötige Bandbreite für Grafikkarten hat noch dass es auf Grund der Wärmeentwicklung kühlbar (und effizient) ist.

Ist das noch der Stand? Oder hat AMD einen anderen Ansatz gewählt, der bekannt wurde?

Complicated
2020-08-05, 21:04:23
CDNA wird wohl keine Render-Einheiten haben.
https://www.pcgameshardware.de/AMD-Radeon-Grafikkarte-255597/News/Radeon-Instinct-MI100-CDNA-Architektur-erscheint-2020-1352587/
Bisher sind kaum Details über die Radeon Instinct MI100 bekannt. Es wird beispielsweise gemunkelt, dass CDNA noch auf der GCN-Architektur basiert, wenngleich natürlich trotzdem einige Änderungen eingeflossen sein könnten. Angeblich verzichtet MI100 auf den Grafikteil, um Chipfläche einzusparen. Im Gegenzug könnte sich die Zahl der ALUs im Vergleich zur Vega-20-GPU der Radeon Instinct MI60 abermals verdoppeln. Im Raum stehen 8.192 ALUs und 128 Compute-Units.

Gast
2020-08-05, 21:20:58
Multi-GPU für Rasterizer ist sehr unwahrscheinlich und lohnt sich sowieso nicht mehr, da Raytracing vor der Tür steht. Dort skaliert das sogar mit 8 GPUs:
https://www.youtube.com/watch?v=Zw3vwCBOjQ0

Offline Raytracing ist aber was ganz anderes als Realtime Raytracing, und es wird noch mindestens 10 Jahre dauern bis Spiele wirklich auf Rasterizing verzichten können.

Digidi
2020-08-05, 21:22:55
Ich frage mich ob multigpu wirklich so unwahrscheinlich ist? Man kann ja das Bild schon von vorneherein zerlegen und dann aufteilen. Gibt es denn zwischen den Cus von den 4 verschiedenen Rasterengines so viell corss-talk?

Gast
2020-08-05, 22:26:26
Ich frage mich ob multigpu wirklich so unwahrscheinlich ist? Man kann ja das Bild schon von vorneherein zerlegen und dann aufteilen. Gibt es denn zwischen den Cus von den 4 verschiedenen Rasterengines so viell corss-talk?

Selbst ohne technische Probleme gäbe es noch immense Software Hürden , das tut sich kein Hersteller an wenn’s auch anders geht und das geht es noch .

Mega-Zord
2020-08-05, 22:34:18
Gab es bei NV nicht vor einigen Monaten nicht mal eine Meldung über alternative Multi-GPU-Nutzung? Das war deutlich effizienter als SLI aber nur für den professionellen Bereich vorgesehen. Möglich wäre ja, dass AMD was ähnliches entwickelt hat.

Gast
2020-08-05, 23:24:18
Offline Raytracing ist aber was ganz anderes als Realtime Raytracing, und es wird noch mindestens 10 Jahre dauern bis Spiele wirklich auf Rasterizing verzichten können.

Das funktioniert auch mit Echtzeit-Raytracing. Schon mit heutiger Fertigungstechnologie könnte man auf Rasterizing verzichten, wenn man dedizierte RT Hardware benutzen würde.
https://www.youtube.com/watch?v=uxE2SYDHFtQ
https://www.youtube.com/watch?v=tOdaU0u9c3U&t=18m

iamthebear
2020-08-06, 00:41:36
Das mit dem Aufteilen des Bildes hat vielleicht noch zu Vodoo Zeiten funktioniert. Heute braucht man andere Ansätze.

Die Hauptprobleme von Multi GPU sind:
1.) Mikroruckler: Da die Frames immer abwechselnd berechnet werden müssen mit unterschiedlicher Berechnungszeit wirddie Zeit für 1 Frame immer kürzer und das nächste länger sein. Man kann jetzt bei den Benchmarks tricksen indem das 2. Frame etwas später ausgegeben wird aber das beseitigt nicht die Rucker, da der Inhalt von Frame2 ja trotzdem fast ident mit Frame1 ist.

2.) Es müssen alle Daten doppelt im RAM gespeichert werden. Das bedeutet doppelte Kosten für Speicher und der Grafikspeicher ist vor allem bei Nvidia in letzter Zeit immer sehr knapp bemessen.

pixeljetstream
2020-08-06, 01:13:31
Man muss multi GPU nicht zwangsläufig mit alternate frame rendering lösen. Geht auch mit Split frame, Checkerboard etc. für load balancing. Das ist auch heute eher der Fall weil alternate frame rendering mit den frame Abhängigkeiten heute nicht wirklich gut klappt.

Man braucht auch nicht direkt viel mehr Speicher. Bei zwei Boards profitiert man eventuell halt kaum im System mehr zu haben, aber bei multi Chip gäbe es nur ein Pool.

Raytracing skaliert beim eigentlichen rendern in der Tat besser als rasterization, weil wir mehr "pullen" was man braucht (Problematik der Shadowmaps entfällt...). Aber da in nem Spiel viel mehr Dinge dynamisch sind, ist deren Skalierbarkeit nicht trivial (animierte Charakter, Simulationsergebnisse etc.)

Auch Post Processing braucht einfach oft globaler Daten. Das heißt irgendwann muss man Daten synchronisieren.

Aber für high-end lòsungen wird auch heute multi GPU schon eingesetzt, sei es sowas wie Entertainment Rides aber auch Flugsimulatoren wo N Projektoren betrieben werden. Man lebt dort allerdings dann halt mit den Verlusten beim synchronisieren die trotz nvlink halt existieren weil es nicht anders geht. Das Problem ist dass trotz höheren Bandbreiten bei nvlink die Anforderungen einfach mit ansteigen. Mehr Datentransfers weil mehr Auflösung oder mehr Datentransfers weil mehr globale berechnete Inputs.

Gast
2020-08-06, 07:24:21
Man muss multi GPU nicht zwangsläufig mit alternate frame rendering lösen. Geht auch mit Split frame, Checkerboard etc. für load balancing. Das ist auch heute eher der Fall weil alternate frame rendering mit den frame Abhängigkeiten heute nicht wirklich gut klappt.

Man braucht auch nicht direkt viel mehr Speicher. Bei zwei Boards profitiert man eventuell halt kaum im System mehr zu haben, aber bei multi Chip gäbe es nur ein Pool.


Separates RAM an jeden Chiplet?

Gast Ritis
2020-08-06, 10:25:25
Wird schon viel seltsames in Foren geschrieben. Dass das mit CDNA und RDNA sehr unklar ist in Bezug auf Chiplets-Fortschritt denke ich auch.

Aber zu Multi-GPU:
Gaming-Grafik ist prinzipiell extrem parallel, mehr CUs/CUDACores auch auf Chips verteilt sind prinizipiell sehr gut nutzbar.
Das Gaming-Problem bei Multi-GPU ist ein getrennter bzw. doppelter Adressraum des Speichers
Bei multiplen Karten ist da die AFR Krücke die Anwendung gewesen, das ist tot
Ein I/O Chip mit mehreren Compute-Chiplets hätte ein gemeinsamer Speicher. Die Frage ist dann die Cache-Koheränz, was bei Rendern mit vielen unterschiedlichen Tiles und Shader-Code aber auch gut handlebar ist
Vega hatte bereits das SI per IF onChip an den Core angebunden, Die2Die müssen "nur" die L1/L2-Caches der CUs gross genug sein, die CUs nicht zu viele, damit der IF nicht zu eng ist, das ist eine Balancing-Aufgabe für die Entwickler
Zen1 hatte vollständige CPUs per IF verbunden, jeder mit eigenem SI, die Latenzunterschiede könnten mit entsprechender GPU beim Rendering kompensiert werden, nicht max FPS aber hohe min-FPS.
Nicht jede CU benötigt jedes Speicherobjekt, aber alle schreiben idR auf das gleiche Frustrum Objekt.
Die 10MB eDRAM der X360 waren nicht grundsätzlich falsch (256GB/s für FullHD), nur viel zu klein.
Selbst wenn die CUs z.B. mit je eigenem GDDR SI einer GPU vom Rest getrennt würden könnten zentrale Teile auf einem I/O Chiplet sinnvoll zusammengefasst werden: Shared HBCC mit HBM-SI für Render-Target, die PCIe Anbindung, LoadStore-Units, Kohärenz-Einheiten wie bei PS5, SSG-Controller, Codecs, Scaler/Bildausgabe.

Da AMD schon seit Ewigkeiten mit vielen solcher Teil-Lösungen Produkte im Markt hatte ist es nur eine Frage der Fertigungsverfahren und Optimierung des IF bzw. der MCM-Interkonnects bis ein Punkt erreicht wird an dem neue Kombinationen sinnvoll umgesetzt werden können...
Mit dem Fortschritt bei 7nm und IF bei Zen3 kann man das doch schon erwarten. Nur AMD weiss wie man am besten die Puzzelteile dann verklebt. Eins gibt das Andere.

Gast
2020-08-06, 10:29:30
Die Gemeinschaft der bekannten und trusted Leaker scheint zu wachsen 😂
Wer hat den vorher was von 'AquariusZi' gehört ?

Lehdro
2020-08-06, 11:52:36
Die Gemeinschaft der bekannten und trusted Leaker scheint zu wachsen 😂
Wer hat den vorher was von 'AquariusZi' gehört ?
War schon ein paar mal auf der Main, siehe u.a. hier:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-29-april-2020
https://www.3dcenter.org/news/geruechtekueche-chipflaechen-zu-navi-2x-aufgetaucht-angeblich-unter-besserer-fertigung-als-7nm

paul.muad.dib
2020-08-06, 21:35:17
Wenn ich mir die Preisentwicklung 2070 Super https://pasteboard.co/Jl9zVpk.png
https://pasteboard.co/Jl9zVpk.png

und 2060 Super https://pasteboard.co/Jl9Axqx.png[

anschaue, scheint so langsam der Abverkauf zu starten.
https://pasteboard.co/Jl9Axqx.png

Berserkus
2020-08-07, 03:25:18
Bei MuliChip GPUs werden die ganz sicher nicht für jedes Chiplet eine eigenen VRAM mit einsetzen, da eh in allen der gleiche Speicherhinhalt stecken muss, wird das ganz sicher so geregelt werden das alle Chiplets parralel auf den gleichen Speicher zugreifen kann.
Wie auch immer das Geregelt wird, es wird so und nicht anders kommen.

Denniss
2020-08-07, 08:19:22
Könnte so wie bei Zen2 sein - ein chip der alles kontrolliert und weitere chips als pure Rechenknechte. Bleibt das Problem der Kommunikation untereinander mit entsprechend hoher Datenbandbreite ohne das eben diese Verbindungen das große Stromsaufen anfangen.