AMD/ATI - Navi 1X (7nm, RDNA1, 2019) & Navi 2X (7nm, RDNA2, 2020) [Archiv] - Seite 52

dargo

2020-09-28, 18:53:15

Würde denn eine Kombination Sinn machen? Also HBM und GDDR6?
Für mich als Laien schon... denn ich sehe außer diesen ominösen Cache der die fehlende Bandbreite kompensieren soll keine andere Lösung ohne ein 384-512Bit SI um aus dem Bandbreitenmangel (projeziert auf die 80 CUs Rohleistung) bei 256Bit SI mit max. 16Gbps rauszukommen.

Mal eine ganz verrückte Idee von mir. Hier sieht man links Navi 10 mit einem 256Bit SI (8x 32Bit).
https://m.3dcenter.org/dateien/abbildungen/AMD-Navi-10-vs-Navi-12.jpg

Was ist wenn man einen HBM2e Stack oben plaziert? Also oben einen 1024Bit HBM-Memorycontroller dazu. Man müsste dann eventuell noch die Bandbreite von dem einen Stack auf die Gesamt-Bandbreite von den acht 32 Bit Controllern anpassen. Wobei letzteres gar nicht nötig ist denn bei 1x 460GB/s @HBM2e und in Summe 512GB/s @GDDR6 ersterer eh der Flaschenhals wäre. Von daher hätte man effektiv dann halt trotzdem im ungünstigsten Fall 920GB/s. Wahrscheinlich eine völlig bekloppte Idee von mir. :tongue: So wären aber zumindest bis zu 920GB/s machbar ohne gleich zwei Stacks verwenden zu müssen. :anonym: So eine Lösung wäre dann aber wohl nur ohne Interposer eventuell wirtschaftlich interessant. Mein Beispiel wäre dann 8GB GDDR6 + 8GB HBM2e.

gedi

2020-09-28, 18:55:06

Wir drehen uns auch im Kreis, das Ding ist auf der dünnen Faktenbasis ausspekuliert. Irgendein zentraler Baustein von RDNA2 ist bisher verborgen und ohne einen handfesten Leak kommen wir hier auch nicht weiter.

Ich hab mir nur kurz nochmals die Tabelle gegeben und sah, mal wieder mumpitz was ich da geschrieben habe.

Cyberfries

2020-09-28, 18:57:07

Bitte Zitat wo ich für N31 Chiplets prognostiziere. Beweise dein Textverständnis.

Du willst mein Textverständnis prüfen und kommst mit sowas? Weitab vom Thema.

Ich würde bei N31 in diesem Fall eher nicht von einem großen Chip ausgehen - das macht für Chiplets kaum Sinn

So und damit ist das Thema abgeschlossen. Ich bin hier raus.

Scheint so, als wenn Navi 21 Lite eine Entwicklungsstufe von Navi 21, ausgerichtet auf die XBox.
num_packer_per_sc und max_waves_per_simd sind hier ja auch noch identisch zu Navi 10 und nicht zu Navi 2x.
Die Playstation 5 läuft wahrscheinlich dann als Navi 22 LITE?

Die Konsolen sind doch ohnehin ein RDNA1/2-Hybrid.
Wenn AMD so mit ihren Bezeichnungen jongliert, kann man darauf nichts mehr geben.

N21 und N21_lite haben mit Ausnahme der grundlegenden Architektur nichts miteinander zu tun.
Um die Verwirrung komplett zu machen gibts auch noch Navi 12 Lite usw.
Können wir da noch ausschließen, dass N23 ein Salvage von N22 ist und N21 mit HBM als N12 Lite läuft?

gedi

2020-09-28, 18:57:16

Für mich als Laien schon... denn ich sehe außer diesen ominösen Cache der die fehlende Bandbreite kompensieren soll keine andere Lösung ohne ein 384-512Bit SI um aus dem Bandbreitenmangel (projeziert auf die 80 CUs Rohleistung) bei 256Bit SI mit max. 16Gbps rauszukommen.

Mal eine ganz verrückte Idee von mir. Hier sieht man links Navi 10 mit einem 256Bit SI (8x 32Bit).
https://m.3dcenter.org/dateien/abbildungen/AMD-Navi-10-vs-Navi-12.jpg

Was ist wenn man einen HBM2e Stack oben plaziert? Also oben einen 1024Bit HBM-Memorycontroller dazu. Man müsste dann eventuell noch die Bandbreite von dem einen Stack auf die Gesamt-Bandbreite von den acht 32 Bit Controllern anpassen. Wobei letzteres gar nicht nötig ist denn bei 1x 460GB/s @HBM2e und in Summe 512GB/s @GDDR6 ersterer eh der Flaschenhals wäre. Von daher hätte man effektiv dann halt trotzdem im ungünstigsten Fall 920GB/s. Wahrscheinlich eine völlig bekloppte Idee von mir. :tongue: So wären aber zumindest bis zu 920GB/s machbar ohne gleich zwei Stacks verwenden zu müssen. :anonym: So eine Lösung wäre dann aber wohl nur ohne Interposer eventuell wirtschaftlich interessant. Mein Beispiel wäre dann 8GB GDDR6 + 8GB HBM2e.

Was sollte das bringen?

dargo

2020-09-28, 18:58:01

Was sollte das bringen?
Kein 384-512Bit SI @GDDR6 nötig.

Berniyh

2020-09-28, 18:58:31

Mal eine ganz verrückte Idee von mir. Hier sieht man links Navi 10 mit einem 256Bit SI (8x 32Bit).
https://m.3dcenter.org/dateien/abbildungen/AMD-Navi-10-vs-Navi-12.jpg

Was ist wenn man einen HBM2e Stack oben plaziert? Also oben einen 1024Bit HBM-Memorycontroller dazu. Man müsste dann eventuell noch die Bandbreite von dem einen Stack auf die Gesamt-Bandbreite von den acht 32 Bit Controllern anpassen. Wobei letzteres gar nicht nötig ist denn bei 1x 460GB/s @HBM2e und in Summe 512GB/s @GDDR6 ersterer eh der Flaschenhals wäre. Von daher hätte man effektiv dann halt trotzdem im ungünstigsten Fall 920GB/s. Wahrscheinlich eine völlig bekloppte Idee von mir. :tongue: So wären aber zumindest bis zu 920GB/s machbar ohne gleich zwei Stacks verwenden zu müssen. :anonym: So eine Lösung wäre dann aber wohl nur ohne Interposer eventuell wirtschaftlich interessant. Mein Beispiel wäre dann 8GB GDDR6 + 8GB HBM2e.
256 Bit GDDR6 ist nicht 8 x 32Bit (wie bei GDDR5), sondern 8 x 2 x 16 Bit, aber das nur so am Rande.
Für die 1024 Bit HBM2 bräuchtest halt noch mal 8 Speicherkanäle zusätzlich und das geben halt die Daten wohl nicht her. Wenn beides, dann wohl eher 1024 Bit HBM2 + 128 Bit GDDR6, aber da wärst du wahrscheinlich auch wieder nicht zufrieden schätze ich. ;)

dargo

2020-09-28, 19:04:31

Ja... 128Bit SI @GDDR6 bringt ja nichts da wir dann bei max. 256GB/s rauskommen. Und das wäre dann die langsamste Kenngröße in der Gesamt-Bandbreite.

btw.
Hat jemand ein Schaubild vom Die bei Hawaii oder Grenada parat? Wie hat AMD dort das 512Bit SI umgesetzt? Schon alles vergessen. :redface: 384Bit ist ja noch einfach vorstellbar, aber 512Bit? Irgendwo muss ja der I/O Kram noch raus.

Tahiti @384Bit:
https://m.3dcenter.org/dateien/abbildungen/AMD-Tahiti-Die-Shot-markiert.preview.jpg

Edit:
Bei meiner Überlegung da oben sofern überhaupt praktikabel wäre auch 256Bit SI mit 14Gbps GDDR6 (dieser dann u.U. mit 800Mhz auf 410GB/s eingebremst) und 1x HBM2e @410GB/s denkbar. So würde man am Ende bei insgesamt 820GB/s rauskommen was eventuell für 80 CUs auch schon reichen würde.

Edit 2:
Grenada...
https://tpucdn.com/gpu-specs/images/g/779-die-shot.jpg

OgrEGT

2020-09-28, 19:33:18

Wäre es irgendwie möglich dass AMD das 256b SI höher taktet oder mehr Daten pro Takt übertragen kann um auf eine höhere Bandbreite zu kommen?

Gipsel

2020-09-28, 19:39:21

256 Bit GDDR6 ist nicht 8 x 32Bit (wie bei GDDR5), sondern 8 x 2 x 16 Bit, aber das nur so am Rande.
Für die 1024 Bit HBM2 bräuchtest halt noch mal 8 Speicherkanäle zusätzlich und das geben halt die Daten wohl nicht her. Wenn beides, dann wohl eher 1024 Bit HBM2 + 128 Bit GDDR6, aber da wärst du wahrscheinlich auch wieder nicht zufrieden schätze ich. ;)Oder man verdoppelt schlicht die Bandbreite pro TCCS (das sind ja die Cachesegmente, nicht die Anzahl der Speichercontroller) und fertig.
Und falls man die Bandbreite einfacherweise matchen will, dann paart man z.B. einen Stack 3,6GT/s HBM2e mit einem 256Bit GDDR6 Interface bei 14,4 GT/s (hat dann beides 460GB/s, in der Summe 920GB/s). Also wenn man schon GDDR6 und HBM bei einer geraden Anzahl an TCCS kombinieren will, dann so. Geht zwar im Prinzip auch anders, aber das kommt bei AMD recht selten vor (Beispiele wären Tahiti und Tonga sowie die XB1X [die hatten unterschiedliche Anzahl an Cachetiles und Speichercontroller, wobei Tonga die "überzähligen" Controller sogar noch deaktiviert hatte]).
Im Prinzip wäre aber auch jedes ganzzahliges Verhältnis zwischen HBM und GDDR6 denkbar (jeweils sowohl Speichergröße als auch Bandbreite), z.B.
Einsteigerkarten mit GDDR6
Midrange: 1 Stack 8GB HBM only (460GB/s), eventuell als Salvage des High End Chips
High End: 1 Stack 8GB HBM + 4GB GDDR6 @128bit (460GB/s + 230GB/s = 690GB/s)
Enthusiast: 1 Stack 8GB HBM + 8GB GDDR6 @256bit (460GB/s + 460GB/s = 920GB/s)

Vorteil ist, daß dann jeder Speicherkanal* exakt die gleiche Speichermenge mit exakt der gleichen Bandbreite hat (512MB mit 28,8GB/s), also das übliche Adressinterleaving zwischen den Kanälen ohne Probleme funktionieren sollte und die GPU den Mix an Speichertypen gar nicht mitbekommt (und das auch völlig transparent für Spiele ist).

*):
Dies meint einen 16bit breiten Kanal bei GDDR6 sowie die 64bit breiten Pseudochannels von HBM(2), wobei der Speichercontroller jeweils zwei davon auch wie 128bit bzw. 32bit breite "logische" Kanäle behandeln kann.

gedi

2020-09-28, 19:42:27

Dschounz

2020-09-28, 19:44:15

Wäre es irgendwie möglich dass AMD das 256b SI höher taktet oder mehr Daten pro Takt übertragen kann um auf eine höhere Bandbreite zu kommen?

Dann wären wir beim von nVidia genutzten GDDR6X mit all seinen Nachteilen...GDDR6 gibt´s nur bis 16 GBPS.

Wären wir wieder bei der Wunderkompression, wenns`s ohne dickes SI oder "Infinity-Cache" gehen soll.

Ihr habt so recht: Man kommt nicht wirklich weiter...wo sind die Leaks !!!!:whisper: ;D

Gipsels Vermutung ergibt absolut Sinn und lässt sich sehr gut mit den dürftigen Infos in Einklang bringen!!!!

OgrEGT

2020-09-28, 19:49:07

Gegen die Theorie des GDDR/HBM SI spricht mMn wenn man schon den höheren Fertigungsaufwand mit HBM betreibt dann könnte man besser konsequent auf HBM setzen da kleiner flexibler und effizienter.

gedi

2020-09-28, 19:50:25

Oder man verdoppelt schlicht die Bandbreite pro TCCS (das sind ja die Cachesegmente, nicht die Anzahl der Speichercontroller) und fertig.
Und falls man die Bandbreite einfacherweise matchen will, dann paart man z.B. einen Stack 3,6GT/s HBM2e mit einem 256Bit GDDR6 Interface bei 14,4 GT/s (hat dann beides 460GB/s, in der Summe 920GB/s). Also wenn man schon GDDR6 und HBM bei einer geraden Anzahl an TCCS kombinieren will, dann so. Geht zwar im Prinzip auch anders, aber das kommt bei AMD recht selten vor (Beispiele wären Tahiti und Tonga sowie die XB1X [die hatten unterschiedliche Anzahl an Cachetiles und Speichercontroller, wobei Tonga die "überzähligen" Controller sogar noch deaktiviert hatte]).
Im Prinzip wäre aber auch jedes ganzzahliges Verhältnis zwischen HBM und GDDR6 denkbar (jeweils sowohl Speichergröße als auch Bandbreite), z.B.
Einsteigerkarten mit GDDR6
Midrange: 1 Stack 8GB HBM only (460GB/s), eventuell als Salvage des High End Chips
High End: 1 Stack 8GB HBM + 4GB GDDR6 @128bit (460GB/s + 230GB/s = 690GB/s)
Enthusiast: 1 Stack 8GB HBM + 8GB GDDR6 @256bit (460GB/s + 460GB/s = 920GB/s)

Vorteil ist, daß dann jeder Speicherkanal* exakt die gleiche Speichermenge mit exakt der gleichen Bandbreite hat (512MB mit 28,8GB/s), also das übliche Adressinterleaving zwischen den Kanälen ohne Probleme funktionieren sollte und die GPU den Mix an Speichertypen gar nicht mitbekommt (und das auch völlig transparent für Spiele ist).

*):
Dies meint einen 16bit breiten Kanal bei GDDR6 sowie die 64bit breiten Pseudochannels von HBM(2), wobei der Speichercontroller jeweils zwei davon auch wie 128bit bzw. 32bit breite "logische" Kanäle behandeln kann.

Wie sieht es dann mit den Latenzen aus? Dann geht auch 16+16?

Dschounz

2020-09-28, 19:54:23

Gegen die Theorie des GDDR/HBM SI spricht mMn wenn man schon den höheren Fertigungsaufwand mit HBM betreibt dann könnte man besser konsequent auf HBM setzen da kleiner flexibler und effizienter.

Wenn HBM, dann direkt auf der GPU gestacked, oder?

Da gab´s doch schon Überlegungen/Patente zu....Hitze/Wärmeleitung war da das vermutete Problem.

Cyberfries

2020-09-28, 19:55:15

Beispiele wären Tahiti und Tonga sowie die XB1X [die hatten unterschiedliche Anzahl an Cachetiles und Speichercontroller, wobei Tonga die "überzähligen" Controller sogar noch deaktiviert hatte]

Sicher?
Bei Tahiti passt die Größe des L2$ (768kb) perfekt zum Interface (384bit), die Marketingfolien zeigen eine Partition je MC.
https://pcper.com/wp-content/uploads/2011/12/87a9-slide25.jpg
Tonga sollte ebenfalls passen (512kb, 256bit).

Waren vielleicht RBEs / ROPs gemeint?

edit: Ok, vielleicht war Verhältnis 2:1 gemeint. Dann ist meine Frage erledigt.
Das besondere bei der xBox One X ist ja 8L2$-Tiles und 4MCC für 384bit, ein Verhältnis von 2:1:3
https://pbs.twimg.com/media/Eh0Eum-XYAA4dAD?format=png&name=large

dargo

2020-09-28, 20:03:02

High End: 1 Stack 8GB HBM + 4GB GDDR6 @128bit (460GB/s + 230GB/s = 690GB/s)

Ah... hier war also mein Denkfehler. :D GDDR6 muss in dem Fall die halbe Speicherkapazität aufweisen. Danke Gipsel für die Erleuchtung. :wink:

Gegen die Theorie des GDDR/HBM SI spricht mMn wenn man schon den höheren Fertigungsaufwand mit HBM betreibt dann könnte man besser konsequent auf HBM setzen da kleiner flexibler und effizienter.
Also die Flexibilität in den Beispielen von Gipsel ist wunderbar gegeben. Zwei HBM2e Stacks wären sicherlich kleiner (Die-Size) und effizienter aber nicht unbedingt günstiger.

OgrEGT

2020-09-28, 20:04:17

Wenn HBM, dann direkt auf der GPU gestacked, oder?

Da gab´s doch schon Überlegungen/Patente zu....Hitze/Wärmeleitung war da das vermutete Problem.

Warum nicht HBM klassisch 2.5D...
2 Stacks würden ja für 16GB schon reichen... einige Erfahrung mit der Fertigung ist ja vorhanden...

Das Dumme ist nur dass die Gerüchte vermehrt von GDDR ausgehen...

gedi

2020-09-28, 20:05:33

Ah... hier war also mein Denkfehler. :D GDDR6 muss in dem Fall die halbe Speicherkapazität aufweisen. Danke Gipsel für die Erleuchtung. :wink:

Er ist schon genial, aber es fehlt trotzdem an Bandbreite

basix

2020-09-28, 20:06:25

Midrange: 1 Stack 8GB HBM only (460GB/s), eventuell als Salvage des High End Chips
High End: 1 Stack 8GB HBM + 4GB GDDR6 @128bit (460GB/s + 230GB/s = 690GB/s)
Enthusiast: 1 Stack 8GB HBM + 8GB GDDR6 @256bit (460GB/s + 460GB/s = 920GB/s)

Würde es nicht Sinn machen, das ganze umzudrehen? Also zuerst mit 256b GDDR6 auffüllen für tiefste SKU? Zumindest auf Seiten Marge würde das mehr Sinn machen. Und da das HBM Interface nicht viel Heu frisst (incl. Speichercontroller knapp 15-20mm2) hätte man auch nicht viel ungenutzte Fläche spendiert (ca. äquivalent zu 32b GDDR6 SI). Mit 14-16 Gbps hätte man auch 448-512 GB/s und weiter oben im Produktstack deine angesprochenen 14.4 Gbps oder evtl. gar nur 12.8 Gbps (3.2 Gbps HBM2e).

Midrange: 8-16GB GDDR6 @ 256bit (512 GB/s)
High End: 1 Stack 8GB HBM + 4GB GDDR6 @128bit (410GB/s + 205GB/s = 615GB/s)
Enthusiast: 1 Stack 8GB HBM + 8GB GDDR6 @256bit (410GB/s + 410GB/s = 820GB/s)

Bei der langsamsten SKU kann man nur GDDR6 verwenden und bei den teureren HBM2e mit zusätzlich noch etwas günstigerem GDDR6 mit 14 Gbps, um die HBM-Kosten etwas zu kompensieren. Wenn der kleinere Navi mit 40 CUs und so hohem Takt kommen sollte (bei 192b GDDR6) wäre doch so etwas wie 56, 68 und 80 CU sinnvoll. Bei den HBM SKUs könnte man allenfalls noch die Speichermenge verdoppeln, auch wenn so viel Speicher nicht viel Sinn macht.

dargo

2020-09-28, 20:09:49

Er ist schon genial, aber es fehlt trotzdem an Bandbreite
Weil?

Edit:
Das fände ich echt genial.

High End: 1 Stack 8GB HBM + 4GB GDDR6 @128bit (460GB/s + 230GB/s = 690GB/s)
Enthusiast: 1 Stack 8GB HBM + 8GB GDDR6 @256bit (460GB/s + 460GB/s = 920GB/s)

Sowas würde ich auch unter einem "Halo Produkt" verstehen. Etwas was es noch nie gab. :D

Das Beispiel könnte man dann weiter spinnen sofern diese Variante günstiger wäre oder es für den 460GB/s HBM2e zu spät war.

High End: 1 Stack 8GB HBM + 4GB GDDR6 @128bit (410GB/s + 205GB/s = 615GB/s)
Enthusiast: 1 Stack 8GB HBM + 8GB GDDR6 @256bit (410GB/s + 410GB/s = 820GB/s)

Bei Midrange würde ich dann auch eher auf die reine Variante mit GDDR6 von basix tippen.

fondness

2020-09-28, 20:16:58

Mal eine ganz verrückte Idee von mir. Hier sieht man links Navi 10 mit einem 256Bit SI (8x 32Bit).
https://m.3dcenter.org/dateien/abbildungen/AMD-Navi-10-vs-Navi-12.jpg

Was ist wenn man einen HBM2e Stack oben plaziert? Also oben einen 1024Bit HBM-Memorycontroller dazu. Man müsste dann eventuell noch die Bandbreite von dem einen Stack auf die Gesamt-Bandbreite von den acht 32 Bit Controllern anpassen. Wobei letzteres gar nicht nötig ist denn bei 1x 460GB/s @HBM2e und in Summe 512GB/s @GDDR6 ersterer eh der Flaschenhals wäre. Von daher hätte man effektiv dann halt trotzdem im ungünstigsten Fall 920GB/s. Wahrscheinlich eine völlig bekloppte Idee von mir. :tongue: So wären aber zumindest bis zu 920GB/s machbar ohne gleich zwei Stacks verwenden zu müssen. :anonym: So eine Lösung wäre dann aber wohl nur ohne Interposer eventuell wirtschaftlich interessant. Mein Beispiel wäre dann 8GB GDDR6 + 8GB HBM2e.

:naughty:

https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12439596#post12439596

Halte ich angesichts der aktuell geleakten Daten für nicht unbedingt unplausibel.

Berniyh

2020-09-28, 20:18:39

Oder man verdoppelt schlicht die Bandbreite pro TCCS (das sind ja die Cachesegmente, nicht die Anzahl der Speichercontroller) und fertig.
Ja natürlich, aber dann könnte es auch sein, dass man schlicht mehr Speicherkanäle für GDDR6 hat als wir annehmen. (also z.B. für 512 Bit)

Gipsel

2020-09-28, 20:19:24

Sicher?
Bei Tahiti passt die Größe des L2$ (768kb) perfekt zum Interface (384bit), die Marketingfolien zeigen eine Partition je MC.
https://pcper.com/wp-content/uploads/2011/12/87a9-slide25.jpg
Tonga sollte ebenfalls passen (512kb, 256bit).

Waren vielleicht RBEs / ROPs gemeint?Ja, das war aus dem Gedächtnis (und zu kurz gedacht). Die Organisation wurde ja im Vergleich zu GCN umgestellt. Dort war tatsächlich der L2 noch fest an die Speicherkanäle gekoppelt und die ROPs mitsamt deren Caches waren damals nicht an den L2 angebunden (sondern liefen an dem vorbei). Dort gab es bei Tahiti und Tonga vier 2x3 Crossbars zwischen jeweils 2 RBEs und 3 Speicherkanälen. Dies ermöglichte die Deaktivierung von Speicherkanälen ohne ROPs zu verlieren (oder andersrum). Achja, Tonga hatte on-Die die exakt gleiche Konfiguration des Speicherinterface (384bit), nur waren bei praktisch allen Consumerkarten nur 512kB und 256bit aktiviert.
Das besondere bei der xBox One X ist ja 8L2$-Tiles und 4MCC für 384bit, ein Verhältnis von 2:1:3
https://pbs.twimg.com/media/Eh0Eum-XYAA4dAD?format=png&name=largeJa, das läßt dann die XB1X offenbar als einziges wirkliches Beispiel aus der Vergangenheit für einen Mismatch von TCCS-Anzahl und Speicherinterface-Breite.

Berniyh

2020-09-28, 20:20:48

Warum nicht HBM klassisch 2.5D...
2 Stacks würden ja für 16GB schon reichen... einige Erfahrung mit der Fertigung ist ja vorhanden...
Man schafft 16GB auch mit einem Stack. ;)

Gipsel

2020-09-28, 20:22:28

Ja natürlich, aber dann könnte es auch sein, dass man schlicht mehr Speicherkanäle für GDDR6 hat als wir annehmen. (also z.B. für 512 Bit)512bit hat man dann wieder das Problem des Flächenverbrauchs und des problematischen PCBs.

Berniyh

2020-09-28, 20:25:32

512bit hat man dann wieder das Problem des Flächenverbrauchs und des problematischen PCBs.
Auch das ist klar. Es gibt da halt keine optimale Lösung (außer 2xHBM2e ohne GDDR6 :D).

Daredevil

2020-09-28, 20:27:30

Hmmm.... wenn man eh jede Karte mit mind. 8GB ausstattet, warum flantscht man 8GB dann nicht direkt in die GPU? Das wird doch auch von der Leistung sicherlich was bringen wie niedrige Latenzen ect. oder?
Klingt definitiv verrückt, aber auch echt spannend. :D

dargo

2020-09-28, 20:31:52

In die GPU? Ich glaube das würde zu viel Flächenbedarf in Anspruch nehmen. ;) Und auf die GPU (3D-Stacking) wird offenbar mit thermischen Problemen zu kämpfen haben.

woodsdog

2020-09-28, 20:35:25

Nach genauerem Überlegen ist es wahrscheinlich doch nicht so kritisch.
Man kann sich dabei zunutze machen, dass Grafikkarten ja bis zu 75W über den PCI Slot ziehen dürfen, davon aber eigentlich nie Gebrauch machen, sondern die GPU Versorgung zu über 99% über die Zusatzstecker sicherstellen.

Wenn man nun am USB-C ein vernünftiges Limit definiert von z.B. 60W (12 V, wie über PCI-E bereitgestellt bei max. 5A), dann sollte sich das weitgehend unabhängig von der GPU Versorgung gestalten lassen.
Mehr als 60W wäre hingegen deutlich aufwendiger, denn dafür müsste man dann 20 V bereitstellen.

Erzähl kein Blech.

Alle modernen Grakas nutzen den PCIe Slot more or less innerhalb der Spec mit.
- Polaris aka RX 480 Debakel vergessen? Weil sie 10W mehr als vorgesehen aus dem Slot genuggelt hat gabs Riots.
- Anbei ein Screenshot meiner 1060 im Furmark. 53W vom PCIe Slot...
- Messungen von Igor an 3080/3090 belegen das die Karten den Slot praktisch ausreizen.

Flinx

2020-09-28, 20:36:20

Als mobile Variante dann...nur HBM...möglich?

basix

2020-09-28, 20:40:44

Als mobile Variante dann...nur HBM...möglich?

Denkbar und sinnvoll ;) Dazu noch eine breite GPU (72+ CU) mit niedrigem Takt (< 1.5 GHz) und es wäre eine Hammer mGPU.

Ich habe eine kleine Überschlagsrechnung gemacht. 40 CU mit 192b und 240mm2 skalieren eingermassen gut übereinstimmend nach oben mit 80 CU, 256b und 427mm2.

Edit:
Könnte die "Dual Graphics Pipe" mit einem solchen HBM + GDDR Interface zu tun haben oder ist das egal?

OgrEGT

2020-09-28, 20:41:20

Ah... hier war also mein Denkfehler. :D GDDR6 muss in dem Fall die halbe Speicherkapazität aufweisen. Danke Gipsel für die Erleuchtung. :wink:

Also die Flexibilität in den Beispielen von Gipsel ist wunderbar gegeben. Zwei HBM2e Stacks wären sicherlich kleiner (Die-Size) und effizienter aber nicht unbedingt günstiger.

Genau. Der einzige Grund, der dagegen spricht sind eigentlich die Kosten.
Die Preisrange bei einem Highend Halo Produkt sollte aber eigentlich groß genug sein.

Ich kann den Aufwand des Mix-SI nicht einschätzen, vermute aber dass der Fertigungsaufwand unabhängig der Anzahl der HBM Stacks gleich hoch sein sollte, zusätzlich aber noch GDDR verbaut werden muss. Die Latenzen sind denke ich auch unterschiedlich auch wenn die Bandbreiten gleich wären, so dass dies ggf durch weitere Maßnahmen synchronisiert werden müsste, was wiederum zusätzlichen Aufwand darstellt.

mboeller

2020-09-28, 20:46:57

da hier gerade alle ihre Ideen zu BigNavi posten mache ich auch mal mit:

BigNavi … mal eine verrückte Idee, aber wir sind ja mitten in der Silly Season :)

1. BigNavi gibt es nicht

2. N2x besteht nur aus 2 GPUs:

N24 mit 24CU/192bit GDDR6/1024bit HBM (siehe auch 3)
N23 mit 40CU/256bit GDDR6/1024bit HBM (siehe auch 3)

3. Das erweiterte HBM-Interface dient auch als Highspeed Interface um aus 2 Chiplet „eine GPU“ zu bauen

die 1024bit verbinden dann über einen Bridge-Chip incl. 128MB eDRAM Infinity-Cache (IBM/GF 14nm Prozess) die beiden Chiplet (kein Interposer, sondern im Substrat eingebettet). Die Bandbreite könnte dafür ausreichen.

Es gibt dann 6 mögliche bzw. sinnvolle Konfigurationen:

N23 mobile mit HBM (1 Stack)
N24 mobile mit HBM (1 Stack)
N23 Desktop mit GDDR6
N24 Desktop mit GDDR6
N22 Desktop (2x N24 + 2x 192bit GDDR6) incl. 1 x 1024bit Bridge-Chip
N21 Desktop (2x N23 + 2x 256bit GDDR6) incl. 1 x 1024bit Bridge-Chip

d) und e) haben mit 40 zu 48CU fast die gleiche Leistung, aber die Version e) hat 50% mehr Bandbreite

Basis für die Idee ist, dass N21 2 Command-Prozessoren hat. Ja, ich weiß N22 hat nur einen…

dargo

2020-09-28, 20:52:54

Das wird ja immer verrückter hier, aber spannend allemal. :D

Complicated

2020-09-28, 21:17:35

Du willst mein Textverständnis prüfen und kommst mit sowas? Weitab vom Thema.Machst dich gerade etwas lächerlich, oder? Lies den Kontext nochmals und erkläre wie ich mit "nicht davon ausgehen" für das selbige plädiere. Und jetzt kannst du auch aufhören gegen mich hier Unsinn aufzufahren. Bist du der Thread-Blockwart, der bestimmt welche Begriffe hier jemand benutzen darf? Da hast du dich gleich doppelt verrannt.

aufkrawall

2020-09-28, 21:27:18

[x] Derailst du mal wieder einen Thread auf Grundlage totaler Nichtigkeiten?
Kann mir nicht vorstellen, dass das irgendjemandem nicht auf die Nerven geht...

Rincewind

2020-09-28, 22:39:59

...
Midrange: 1 Stack 8GB HBM only (460GB/s), eventuell als Salvage des High End Chips
High End: 1 Stack 8GB HBM + 4GB GDDR6 @128bit (460GB/s + 230GB/s = 690GB/s)
Enthusiast: 1 Stack 8GB HBM + 8GB GDDR6 @256bit (460GB/s + 460GB/s = 920GB/s)

Vorteil ist, daß dann jeder Speicherkanal* exakt die gleiche Speichermenge mit exakt der gleichen Bandbreite hat (512MB mit 28,8GB/s), also das übliche Adressinterleaving zwischen den Kanälen ohne Probleme funktionieren sollte und die GPU den Mix an Speichertypen gar nicht mitbekommt (und das auch völlig transparent für Spiele ist).

*):
Dies meint einen 16bit breiten Kanal bei GDDR6 sowie die 64bit breiten Pseudochannels von HBM(2), wobei der Speichercontroller jeweils zwei davon auch wie 128bit bzw. 32bit breite "logische" Kanäle behandeln kann.

klingt für mich als stiller Mitleser wie der heilige Gral.

Daredevil

2020-09-28, 22:46:02

Also sind die Löcher auf der Rückseite doch richtig wegen HBM2 und das Testboard mit GDDR6 ebenfalls. :D
Klingt echt komisch, aber so kann man leicht die Vorteile des HBM mit den Vorteilen des GDDR& ( Schnell + günstig ) vereinen. Sowas wäre echt cool und würde sicherlich kosten sparen?!

davidzo

2020-09-28, 23:09:02

Oder man verdoppelt schlicht die Bandbreite pro TCCS (das sind ja die Cachesegmente, nicht die Anzahl der Speichercontroller) und fertig.
Und falls man die Bandbreite einfacherweise matchen will, dann paart man z.B. einen Stack 3,6GT/s HBM2e mit einem 256Bit GDDR6 Interface bei 14,4 GT/s (hat dann beides 460GB/s, in der Summe 920GB/s). Also wenn man schon GDDR6 und HBM bei einer geraden Anzahl an TCCS kombinieren will, dann so. Geht zwar im Prinzip auch anders, aber das kommt bei AMD recht selten vor (Beispiele wären Tahiti und Tonga sowie die XB1X [die hatten unterschiedliche Anzahl an Cachetiles und Speichercontroller, wobei Tonga die "überzähligen" Controller sogar noch deaktiviert hatte]).
Im Prinzip wäre aber auch jedes ganzzahliges Verhältnis zwischen HBM und GDDR6 denkbar (jeweils sowohl Speichergröße als auch Bandbreite), z.B.
Einsteigerkarten mit GDDR6
Midrange: 1 Stack 8GB HBM only (460GB/s), eventuell als Salvage des High End Chips
High End: 1 Stack 8GB HBM + 4GB GDDR6 @128bit (460GB/s + 230GB/s = 690GB/s)
Enthusiast: 1 Stack 8GB HBM + 8GB GDDR6 @256bit (460GB/s + 460GB/s = 920GB/s)

Vorteil ist, daß dann jeder Speicherkanal* exakt die gleiche Speichermenge mit exakt der gleichen Bandbreite hat (512MB mit 28,8GB/s), also das übliche Adressinterleaving zwischen den Kanälen ohne Probleme funktionieren sollte und die GPU den Mix an Speichertypen gar nicht mitbekommt (und das auch völlig transparent für Spiele ist).

*):
Dies meint einen 16bit breiten Kanal bei GDDR6 sowie die 64bit breiten Pseudochannels von HBM(2), wobei der Speichercontroller jeweils zwei davon auch wie 128bit bzw. 32bit breite "logische" Kanäle behandeln kann.

Das ist genau das was ich vor ca. 100 Pages auch schon vorgeschlagen hatte.

1 stack HBM auf das Package zu packen wäre relativ günstig. Parallel zum gddr angesteuert verdoppelt sich damit die bandbreite. Heutzutage braucht man dazu nichtmal einen interposer, das geht auch mit TSMCs INFO-L/LSI zu wesentlich günstigeren Preisen.

Da kam dann sofort der Gegenwind dass es dann doch billiger und einfacher wäre gleich eine 2 Stack HBM Lösung zu bauen oder eben 512bit GDDR.

Ich finde die Möglichkeit hat nach wie vor seinen charme. Man verdoppelt die bandbreite und braucht dafür kein verdoppeltes GDDR SI mit hohe Leitungslänge und Platzproblemen wie bei Ampere. Und trotzdem wird kein fetter interposer für multiple HBM stapel gebraucht.

Ravenhearth

2020-09-28, 23:18:02

Wenn 1 Stack HBM ohne Interposer geht, wieso dann nicht auch 2? Was sind die technischen Gründe dafür?

bbott

2020-09-28, 23:23:37

Mein Senf:
N21a GDDR6X mit 256Bit -> 6900XT/ XL 16GB/ 12GB
N21b HBM2 2048bit -> 6900XTX 16GB

2020-09-28, 23:30:43

@NC

Konsole ist ein anderes Thema. Es ging mir nur um Parallelen zu dem angeblichen Cache bei N21 zu finden der die fehlende Bandbreite bei 256BIt SI + GDDR6 kompensieren soll. Also warum der Spieleentwickler bei dieser Art von Hardware was speziell optimieren muss? Als anderes Beispiel könnte man hier den Broadwell mit seinem 128MB eDRAM und L4 Cache ausführen. Afaik wurde für diese CPU nichts Spezielles auf Softwareseite im Bereich Spiele gemacht. Dennoch profitiert sowohl die iGPU als auch die CPU von diesem Design. Alleine auf CPU-Seite habe ich durch den eDRAM bis zu +30% Performance gesehen vs. non eDRAM.

PS: ich versuche einfach nur herauszufinden ob so eine Lösung technisch sinnvoll wäre. Ob sie dann wirtschaftlich sinnvoll ist steht auf einem anderen Blatt.
Soll auch kein Streit von meiner Seite aus sein.
Intel hat zwar ein paar Tipps gegeben (alle Framebuffer im Frame sollten in 128MB passen, Framebuffer sollten direkt vor der Nutzung erstellt werden, nach der Nutzung direkt clear), wie dafür zu Optimieren ist, aber im Prinzip war 1. der Cache weit überdimensioniert für das was die IGP eigentlich leisten kann (du könntest einen 4k GBuffer reinstecken) und 2. sind Intel "GPUs" sehr selten ein Optimierungsziel gewesen (Ich habe nur Codemasters Spiele gesehen).
Wenn AMD jetzt einen 2GB Cache verbaut, mit 2TByte/s Anbindung, dann würde ich auch zustimmen, dass das in den meisten existierenden Spielen viel bringt, bei zukünftigen wissen Devs bescheid und können dafür optimieren. (Das wäre eben so überdimensioniert wie damals bei Intel).
Ein 128MB Cache wäre hingegend in vielen Fällen zu klein und wenig von nutzen über das was der L3 macht, mMn. Es käme also stark auf die Dimensionierung und Bandbreite an.

dargo

2020-09-29, 07:08:11

Mein Senf:
N21a GDDR6X mit 256Bit -> 6900XT/ XL 16GB/ 12GB
N21b HBM2 2048bit -> 6900XTX 16GB
GDDR6X kannst du dir abschminken, das ist Nvidia exklusiv.

basix

2020-09-29, 07:11:45

Wenn 1 Stack HBM ohne Interposer geht, wieso dann nicht auch 2? Was sind die technischen Gründe dafür?

Technisch? Keine. Es sind die Kosten. HBM ist nunmal teurer als GDDR6.

Dschounz

2020-09-29, 07:44:25

Noch mal zu der HBM und GPU Verbindung:

Grade bei Anandtech gefunden....LSI als Technologieäquivalent zu Intels EMIB:

https://images.anandtech.com/doci/16031/Advanced%20Packaging%20Technology%20Leadership.mkv_snapshot_16.44_%5B2020.08.25_ 14.14.27%5D_575px.jpg

Das ist bei TSMC offiziell erst in der Erprobung/Qualification; könnte das bereits exklusiv von AMD genutzt werden, neben einem zusätzlichen GDDR6 Interface??

basix

2020-09-29, 07:57:54

Ich tendiere eher zu InFO_MS, da kein Interposer benötigt wird (günstiger und sogar energiesparender):
https://fuse.wikichip.org/news/2567/tsmc-talks-7nm-5nm-yield-and-next-gen-5g-and-hpc-packaging/2/
https://fuse.wikichip.org/wp-content/uploads/2019/07/semicon-2019-tsmc-info_ms.png
In many ways TSMC is billing InFO_MS a performance-cost sensitive alternative to CoWoS.

InFo_MS gibt es seit 2018/2019.

Dschounz

2020-09-29, 08:01:58

Ich tendiere eher zu InFO_MS, da kein Interposer benötigt wird (günstiger und sogar energiesparender):
https://fuse.wikichip.org/news/2567/tsmc-talks-7nm-5nm-yield-and-next-gen-5g-and-hpc-packaging/2/
https://fuse.wikichip.org/wp-content/uploads/2019/07/semicon-2019-tsmc-info_ms.png

InFo_MS gibt es seit 2018/2019.

+1

Macht Sinn, das könnte dann auch in die Entwicklung von N2X eingeflossen sein, da es mit Sicherheit seit weit mehr als 2 Jahren TSMC`s Kunden bekannt war.

Berniyh

2020-09-29, 08:04:40

Technisch? Keine. Es sind die Kosten. HBM ist nunmal teurer als GDDR6.
Aber wir reden hier ja von HBM ohne Interposer und zumindest bislang war immer die Annahme HBM sei vor allem teurer, weil man den Interposer benötigt.

basix

2020-09-29, 08:07:26

Dschounz

2020-09-29, 08:20:38

HBM selbst ist ja auch teuerer bei $/GB, ebenso das Packaging da bei GPU + HBM mehrere "Chips". Der Interposer war einfach noch ein zusätzlicher Kostenfaktor obendrauf. Und man kann sich sicher sein, dass das InFO_MS Substrat teurer als ein normales Substrat ist ;)

Diese Kombination von HBM/GDDR6, wobei das Beifügen des GDDR6-Speichers den größeren N2X-Varianten vorbehalten ist, bedeutet doch:

Große Mengen HBM (=> hohe Stückzahl => relativ niedrigere Stückkosten wegen Rabatten und günstigerem Interconnect) wird mit relativ geringen Mengen GDDR6 (=> ohnehin günstig bei üblichen Geschwindigkeiten 14/16 GPBs) gemixt.

Klar, die Kosten sind rein vom Speicher her immer noch höher als pur GDDR6, aber IMHO vertretbar und man vermeidet ein monströses SI für GDDR oder den saufenden GDDR6X, der ja wahrscheinlich ohnehin nicht für AMD verfügbar ist zur Zeit.

basix

2020-09-29, 08:31:42

Ja, beim HBM+GDDR Mix sehe ich das auch so. Habe ich schon vor Wochen mal erwähnt, Gipsel hat nun eine logische technische Möglichkeit zur Realisierung dargelegt.

Die Frage zum Preis bezog sich aber auf 2x HBM ohne GDDR6, und das wäre mit hoher Wahrscheinlichkeit teurer.

Cyberfries

2020-09-29, 09:19:09

Nur weil etwas technisch möglich ist, wird es deshalb nicht sinnvoll.
Klar, ich kann 1024bit HBM & 256bit GDDR6 mit jeweils gleicher Bandbreite kombinieren.
Doch das ist immernoch äquivalent zu einem reinen 384bit Interface, sprich tccs und MC passen nicht zueinander.
Da ist ein gewöhnliches 384bit Interface simpler, bei ähnlicher Bandbreite.

HBM+GDDR kombiniert Nachteile beider Technologien, eine einzelne Lösung ist simpler.
HBM ist teuer wegen des Interposers und der zwei Fertigungslinien.
Ein oder zwei HBM-Stapel ist dann nicht mehr der große Kostenfaktor.

Nehmen wir tatsächlich ein Kombi-Interface an, dann ist 256bit GDDR + 2048bit HBM simpler,
das nicht benötigte Interface wird komplett deaktiviert. Der Flächenaufwand dafür ist ähnlich 384bit.

6900xt -> 80CU, 16gb HBM, 819GB/s (3080-Niveau bei +8% Bandbreite)
6900 -> 72CU, 16gb HBM, 819GB/s
6800 -> 60CU, 16gb GDDR6, 512GB/s (3070-Niveau bei +14% Bandbreite, eine SE deaktiviert)

Das erscheint mir wesentlich sinnvoller, wenn es mir auch widerstrebt von 400mm² rund 90mm² zu deaktivieren.

Brillus

2020-09-29, 10:42:06

Andere Frage wie groß ist den so ein HBM stack. Mit der Idee den Stack oben drauf zu haben. Könnte die 2 unterschiedliche Interfaces sinn machen wenn oben drauf nicht genug Platz ist.

Berniyh

2020-09-29, 11:04:28

Das erscheint mir wesentlich sinnvoller, wenn es mir auch widerstrebt von 400mm² rund 90mm² zu deaktivieren.
Die Spekulation ist ja, dass es AMD irgendwie schafft den GDDR6 Speicher über das HBM2 Interface anzusteuern.
Wie auch immer das funktionieren soll …

Szudri

2020-09-29, 11:08:04

Die Spekulation ist ja, dass es AMD irgendwie schafft den GDDR6 Speicher über das HBM2 Interface anzusteuern.
Wie auch immer das funktionieren soll …

Aber das würde ja dem GDDR6-Emulationsmodus-Spekulation Gewicht verleihen :)
Ggf. sind die beim MC und dem IF schon soweit? Beides ans IF und der MC "Unified" das und gibt es an den Core weiter.

Edit: Endziel beim IF ist es ja, dass die GPU den CPU Ram als "Coherent" sieht (oder so ähnlich). Übertragen auf GPU -> könnte 2 versch. Speichervarianten miteinander vereinen.

Vega kann ja schon das HBCC wo der RAM als VRAM gesehen wird von Spielen und System.

Edit 2: Wenn bei der Zen 3 Vorstellung am 8. Oktober "krasse" Dinger bei IF und MC vorgestellt werden, kann das sicherlich auch bereits in RDNA2 Einzug halten.

Cyberfries

2020-09-29, 11:12:09

Die Spekulation ist ja, dass es AMD irgendwie schafft den GDDR6 Speicher über das HBM2 Interface anzusteuern.

Wenn ich ein 256bit Interface habe, kann ich trotzdem nicht 1024bit HBM + 256bit GDDR gleichzeitig ansteuern.
Und da wir deutliche Hinweise auf maximal 256bit haben, würde ich HBM+GDDR gleichzeitig ausschließen.

(Außer deine Anmerkung bezog sich auf ein Interface, dass GDDR alternativ zu HBM kann.
Das passt dann zu meinem Beitrag, wäre eine spannende Technologie.)

Andere Frage wie groß ist den so ein HBM stack.

Oben drauf ergibt keinen Sinn, X3D kommt nicht vor RDNA3.
Dargo hat zu seiner Idee ein Bild geliefert (siehe unten), HBM ist deutlich kleiner als N12.
Für N21 müssen wir mit mindestens 340mm², eher 400mm² rechnen, das passt mühelos obendrauf.

https://m.3dcenter.org/dateien/abbildungen/AMD-Navi-10-vs-Navi-12.jpg
Was ist wenn man einen HBM2e Stack oben plaziert?

Berniyh

2020-09-29, 11:18:31

Wenn ich ein 256bit Interface habe, kann ich trotzdem nicht 1024bit HBM + 256bit GDDR gleichzeitig ansteuern.
Und da wir deutliche Hinweise auf maximal 256bit haben, würde ich HBM+GDDR gleichzeitig ausschließen.
Ja, deshalb war mein Kommentar zur Idee ursprünglich (paar Seiten zuvor), dass man entweder zusätzliche Speicherkanäle bräuchte oder die mutmaßlich 16 Kanäle auf beide aufteilen müsste.

Berniyh

2020-09-29, 11:21:47

Aber das würde ja dem GDDR6-Emulationsmodus-Spekulation Gewicht verleihen :)
Diesen GDDR6 Emulationsmodus gibt es laut Treiber Code definitiv (und übrigens auch nur bei Navi 21).
Aber man muss da schon sehr vorsichtig bei der Interpretation sein.
Als Bestätigung für ein universelles Interface das HBM2 und GDDR6 kann kann man das in jedem Fall derzeit nicht ansehen.
Zudem kann das ja auch Nachteile mit sich bringen. Evtl. ist so emuliertes GDDR6 Interface langsamer als ein dediziertes.
Oder es verbraucht mehr Fläche als nur GDDR6?

Es bleiben in jedem Fall mehr als genug Fragezeichen um auch noch mal 200 Seiten zu Navi 21 zu füllen. ;)

why_me

2020-09-29, 11:26:28

HOT

2020-09-29, 11:30:26

Wie soll man sowas kostengünstig fertigen und kühlen? Diese ganze HBM-Nummer halte ich für Unsinn. Der hat seine 256Bit und fertig.

dargo

2020-09-29, 11:32:47

Nur weil etwas technisch möglich ist, wird es deshalb nicht sinnvoll.
Klar, ich kann 1024bit HBM & 256bit GDDR6 mit jeweils gleicher Bandbreite kombinieren.
Doch das ist immernoch äquivalent zu einem reinen 384bit Interface, sprich tccs und MC passen nicht zueinander.
Da ist ein gewöhnliches 384bit Interface simpler, bei ähnlicher Bandbreite.

920GB/s (1x HMB2e @460GB/s + 256Bit GDDR6 @460GB/s) ist nicht ähnliche Bandbreite vs. 384Bit GDDR6 mit max. 768GB/s. Für das erste Beispiel brauchst du u.U. nicht mal den höchstwahrscheinlich kostspieligeren 16Gbps GDDR6. Wobei ich jetzt nicht abschätzen kann ob es nicht zu riskant wäre den 14Gbps GDDR6 um 25Mhz zu übertakten, also knapp 3% über der Spezifikation. Falls ja kombiniert man das ganze mit je 448GB/s und gut ist.

HBM+GDDR kombiniert Nachteile beider Technologien, eine einzelne Lösung ist simpler.
HBM ist teuer wegen des Interposers und der zwei Fertigungslinien.
Ein oder zwei HBM-Stapel ist dann nicht mehr der große Kostenfaktor.

Den Interposer können wir denke ich abhaken. Es soll ja schon etwas länger möglich sein ohne diesen auszukommen.

Cyberfries

2020-09-29, 11:46:11

Zwischen Ankündigung und Markteinführung kann unter Umständen viel Zeit verstreichen.
Interposer-Verzicht entwertet mein Argument nicht, unterstützt eher die HBM-These.
Bei 3,6GT/s ebenfalls Verfügbarkeits-???, ich bin von 3,2GT/s HBM ausgegangen.
Das @1024bit und 12,8GT/s GDR6 @256bit sind 819,2GB/s, 6,7% vor 16GT/s GDDR6@384bit.

Wie soll man sowas kostengünstig fertigen und kühlen?

Die Vegas winken freundlich.
300w @400mm² +2xHBM sind durchaus bei rund 700€ machbar.

dargo

2020-09-29, 11:47:20

Wie soll man sowas kostengünstig fertigen und kühlen? Diese ganze HBM-Nummer halte ich für Unsinn. Der hat seine 256Bit und fertig.
Dann würde AMD mit den 80 CUs gerade mal bei der RTX 3070 oder knapp drüber rauskommen. Oder wie soll AMD mit max. 512GB/s die RTX 3080+ erreichen? Da müsste bei der Kompression schon ein Wunder im RDNA 2 passieren.

HOT

2020-09-29, 11:49:24

Weil du das ja auch schon vorher ahnst oder was ;).
Wir haben es hier offensichtlich mit einer neuen Technik zu tun, die bislang unbekannt ist. Da Schlüsse raus zu ziehen ist total müßig. Solange wie das so ist sollte man von mindestens 2x 5700XT-Leistung trotz 256Bit ausgehen.

dargo

2020-09-29, 11:51:27

Das @1024bit und 12,8GT/s GDR6 @256bit sind 819,2GB/s, 6,7% vor 16GT/s GDDR6@384bit.

Stimmt zwar, nur kommst du mit deinem HBM2e + GDDR6 Beispiel garantiert mit 14Gbps GDDR6 aus. Bei 384Bit SI bist du auf den 16Gbps GDDR6 angewiesen und "verballerst" auch einiges mehr an Die-Size. Da können wir noch ewig spekulieren. Ich denke AMD wird schon den besten Kompromis finden. Wir tappen da eh im Dunkeln da wir die Preiskalkulation von Variante A bis Variante Z nicht kennen. ;)

Weil du das ja auch schon vorher ahnst oder was ;).

Nein... aber ich weiß das ein 52 CU SoC mit "gebremsten" Takt bereits 560GB/s spendiert bekommt. ;)

HOT

2020-09-29, 11:56:42

Nein, du weisst gar nix darüber, was RDNA2 macht als GPU, das ist das Problem ;). Die Konsolen haben mit dem Feature u.U. gar nichts zu tun, die sind semi-custom.

dargo

2020-09-29, 11:58:28

HOT

2020-09-29, 12:00:19

Warum nicht? Die Desktop-RDNA-Chips sind auch erheblich jünger i.Ü. Ich halte das für verbohrt das so zu sehen. Wenn die 80CUs mit 2,2GHz an 256Bit machen, das hat das einen Grund und den kennen wir nicht. Ich würd da einfach offen bleiben und schauen, was da kommt.

Screemer

2020-09-29, 12:08:10

Also man merke: hot spekuliert über zog Seiten völlig abseits von technisch möglichem und anhand von Wunschvorstellungen. Andere spekulieren anhand von technischen Gegebenheiten wie eine mögliche Umsetzung aussehen könnte. Letztere sind die Träumer ;D

HOT

2020-09-29, 12:10:55

Endlich hast du es begriffen :D

Complicated

2020-09-29, 12:24:44

Die letzten Konsolen SoCs haben auch nicht alle das selbe Speichersubsystem verwendet. Da unterscheiden sich schon MS und Sony untereinander. MS hatte auf unified memory verzichtet zugunsten eines eDRAMs und Sony hat AMDs unified memory durchgehend genutzt. Semi-Custom ist eben nicht zwingend mit allen Features ausgestattet.

Und in der Raytracing-Umsetzung findet sich auch vielleicht die Lösung zu diesen kursierenden Gerüchten. Der größere Texture-Cache und die zusätzlichen Kanäle für die BVH-Zugriffe auf die FFU könnten bei deaktiviertem Raytracing andere Aufgaben bekommen haben und hier eine Rolle spielen bei der Reduzierung des SI.

dargo

2020-09-29, 12:29:14

Und in der Raytracing-Umsetzung findet sich auch vielleicht die Lösung zu diesen kursierenden Gerüchten. Der größere Texture-Cache und die zusätzlichen Kanäle für die BVH-Zugriffe auf die FFU könnten bei deaktiviertem Raytracing andere Aufgaben bekommen haben und hier eine Rolle spielen bei der Reduzierung des SI.
Das würde im Umkehrschluss bedeuten, dass der Chip beim aktiven RT an Bandbreite "verhungert".

Berniyh

2020-09-29, 12:31:15

Geht das überhaupt vernünftig? Die Anforderungen an Takt und Leitungslänge (Kapazität) sind doch schon sehr unterschiedlich.
Eventuell, wenn man 4 HBM Pins zu einem GDDR Pin kombiniert und dadurch dann eine höhere Leistung pro pin hat. :uponder:
Das wissen wir eben nicht. Ich denke vor 2-3 Monaten hätte das praktisch jeder ohne zu zögern mit einem klaren Nein beantwortet.
Jetzt stellen wir uns eben alle die Frage. ;)

Letztendlich … time will tell. Ich glaube nicht, dass sich das endgültig beantworten lässt bevor AMD dann endlich Navi 21 vorstellt.

Edit: was mir bei den Beispielen zur Mischbestückung am meisten Sorgen machen würde: ihr habt zwar schön die Bandbreite berücksichtigt, aber zumindest bei GDDR6 scheint ja auch die Latenz sehr wichtig zu sein, da man ja extra auf dem Board die Leitungen hier und da verlängert.
Wäre es nicht relativ schwierig hier HBM2 und GDDR6 anzugleichen?

HOT

2020-09-29, 12:32:12

dargo
Ihr steitet über secret sauce. Das kann man machen, führt aber zu nichts, wie die letzten zig Seiten mit dem HBM-Kombi-Unsinn. Das ist fruchtlos, weil total unplausibel, wenn man die wirtschaftliche Seite außer Acht lässt. Natürlich wird man entweder HBM oder GDDR machen. Eine Kombilösung ist total sinnbefreit, weil man da die Mehrkosten für den Interposer/das teurere Package mit den Mehrkosten für das PCB kombiniert. Entweder man spart die Kosten für das PCB oder man spart die Kosten für das Package, beides geht nicht. Von den technischen Schwierigkeiten, die entstehen durch diese völlig anders funktionierenden Speicher mal ganz abgesehen.
Da HBM aktuell noch erheblich teurer ist, ergibt die Konzentration auf GDDR auch heute immer noch Sinn. Fest steht für mich, dass die Lösung auf dem Chip selbst zu finden ist, nirgendwo anders.

davidzo

2020-09-29, 12:34:50

Wenn 1 Stack HBM ohne Interposer geht, wieso dann nicht auch 2? Was sind die technischen Gründe dafür?

Wenn du dir mal die mühe machen würde auf den Link zu klicken den ich vor 100 Seiten und nun erneut gepostet habe statt etwas zu suggerieren was ich nicht geschrieben habe, dann hättest du folgendes
in den TSMC Folien lesen können:
- Info_OS erst seit 2018 verfügbar und beschränkt auf 1,5x reticle size
- Info-R mit 1,7x reticle erst in Q4 20 in mas sproduction
Es gibt also kein Limit auf 1x stack, was ich auch nie behauptet habe, sehr wohl gibt es aber eine begrenzte Packagegröße. Und wieso man das bisher nicht verwendet hat ist klar: Im Vergleich zu Cowos ist es eben nicht schon seit jahren verfügbar, sondenr ganz neu.

Zu CoWos steht da das: "multi year production/proven technology, established in 2012(logic+logic), logic+hbm since 2016 in mass production."

Anandtech hat die präse stark gekürzt, ich hatte aber vor etlichen seiten schonmal die volle Präsentation gepostet: https://fuse.wikichip.org/news/2567/tsmc-talks-7nm-5nm-yield-and-next-gen-5g-and-hpc-packaging/2/

Nur weil etwas technisch möglich ist, wird es deshalb nicht sinnvoll.
Klar, ich kann 1024bit HBM & 256bit GDDR6 mit jeweils gleicher Bandbreite kombinieren.
Doch das ist immernoch äquivalent zu einem reinen 384bit Interface, sprich tccs und MC passen nicht zueinander.
Da ist ein gewöhnliches 384bit Interface simpler, bei ähnlicher Bandbreite.

Was hast du nur immer mit deinen 384bit? Es geht hier um den Ersatz eines 512bit Interfaces, nix 384bit.

HBM+GDDR kombiniert Nachteile beider Technologien, eine einzelne Lösung ist simpler.
HBM ist teuer wegen des Interposers und der zwei Fertigungslinien.
Ein oder zwei HBM-Stapel ist dann nicht mehr der große Kostenfaktor.

Hast du einfach kein Bock zu lesen? Seit 2018 geht das auch ohne Interposer, seit 2020 sogar it einigermaßen großen chips. TSMC würde das wohl nicht in den earnings calls erwähnen bzw. überhaupt entwickeln wenn man dafür nicht auch Kunden aufweisen würde?

Zwischen Ankündigung und Markteinführung kann unter Umständen viel Zeit verstreichen.

Les doch mal selbst statt dir alles vorzukauen, da ging es nicht um Ankündigungen, sondern um "mass production" mit "1,7x reticle size" in 2020. Production ramp mit below 1,5x reticle war in Q2 '18.

Interposer-Verzicht entwertet mein Argument nicht, unterstützt eher die HBM-These.
Bei 3,6GT/s ebenfalls Verfügbarkeits-???, ich bin von 3,2GT/s HBM ausgegangen.
Wenn das so ist dürfte es auch noch keinen GDDR6x in nennenswerten Stückzahlen geben, da gabs bis vor kurzem auch keine Datenblätter zu. Womit wird die 3080 denn gebaut?

SK Hynix hat 3,6Gt/s letztes Jahr im August angekündigt und zuletzt im Juli die Massenproduktion bestätigt: https://www.computerbase.de/2020-07/sk-hynix-hbm2e-speicher-massenproduktion/
3,2Gt/s hat Samsung seit März '19 im Angebot, das ist nicht mehr das was man für ein für Ende 2020 eingeplantes Produkt nehmen würde...

Das @1024bit und 12,8GT/s GDR6 @256bit sind 819,2GB/s, 6,7% vor 16GT/s GDDR6@384bit.
Falsche Rechnung mein Freund, es sind in beiden Fällen 16gt/s gddr6.
Und selbst wenn du 3,2gt/s ansetzt, wie kommst du darauf dass dann der GDDR6 auf 12,8gt/s gebremst wäre? Selbst wenn beide Interfaces unterschiedliche schnell wären, würde der immer noch eine höhere Gesamtbandbreite aufweisen. Und auch Segmentierung ist nichts unmögliches, bzw. worüber die Hersteller nicht nachgedacht hätten wie schon die xbox series X zeigt.

Berniyh

2020-09-29, 12:35:10

Oh ja... AMD wird RDNA 2 bestimmt für den Desktop gravierend ändern damit der mit mickrigen Bandbreite auskommt. :freak: Vielleicht hast du es noch nicht mitbekommen, aber Raytracing hängt auch gut an der Bandbreite.
Tatsächlich gibt es wohl Unterschiede. Navi 21 LITE scheint der XBox weitgehend zu entsprechen, aber unterscheided sich wohl hier und da von Navi 21 und zwar nicht nur in Bezug auf die Anzahl der CU.

dargo

2020-09-29, 12:37:15

@HOT
Wir streiten nicht, wir diskutieren.

Ob ein Interposer immer noch nötig ist oder nicht ist ebenso noch offen. Wie kannst du also auf dieser Datenbasis schon sicher sagen, dass eine Variante X günstiger ist als Variante Y? Was kosten 8GB HBM2e heute gegenüber 8GB 16Gbps GDDR6? Im welchen Verhältnis steht das zu den gesparten Kosten bei der Die-Size? Das sind alles Punkte von denen wir überhaupt keine Ahnung haben. ;)

Tatsächlich gibt es wohl Unterschiede.
Ich sprach von gravierenden Unterschieden. Man müsste schon deutlich mehr im Desktop RDNA 2 umbauen damit ein 80CUs RDNA2 mit noch höheren Taktraten mit 512GB/s auskommt.

HOT

2020-09-29, 12:42:05

Die XBox hat auch 7 WGPs pro Pipeline, was sonst kein anderer RDNA-Chip hat. Das ist einfach customisiert.

dargo
Es ist doch so: wir kennen das PCB aus dem Leak, es ist mit 8 GDDR-Chips ausgestattet. Das sind 256Bit, der Fall ist also klar. Selbst die Bohrungen des PCBs passen zur finalen Variante der Karte, die AMD selbst veröffentlicht hat.
Wir wissen also, dass der Chip 256Bit GDDR6 hat, wie wissen sogar, dass es 16GB mit 16GT in 16Gb-Chips sind, es gibt da keinen Zweifel mehr. Da HBM als Lösung schlicht ausscheidet und 3D-Stacking und andere Exoten ausgeschlossen sind und nur in Verbindung von N31 von MCM gesprochen wird, sonst wäre das für N2x schon längst geleakt, ist die Lösung auf dem Chip. AMD macht irgendwas, damit die 512GB/s für die 22,5 TFLOPs reichen, wir werden erfahren was das ist, wenn das jemand leakt oder AMD damit rausrückt.

Screemer

2020-09-29, 12:45:10

basix

2020-09-29, 12:47:15

HBM+GDDR kombiniert Nachteile beider Technologien, eine einzelne Lösung ist simpler.
HBM ist teuer wegen des Interposers und der zwei Fertigungslinien.
Ein oder zwei HBM-Stapel ist dann nicht mehr der große Kostenfaktor.

Nochmal:

Kein Interposer
1024b HBM2e Interface
256b GDDR6 Interface
Kein PHY oder Memory Controller Sharing oder sonst was. Nach den MCs werden die zwei Datenpfade zu einem Datenpfad zusammengeführt
GDDR6 + HBM2e separat und kombiniert nutzbar (siehe Post von Gipsel)
1024b HBM2e ~64b GDDR6 von der Die Size her. Bringt aber ~256b GDDR6 Bandbreite

Damit kombinierst du sogar die Vorteile beider Welten, ohne dass die Nachteile überhand nehmen.

Mittels des einen HBM-Stacks gewinnst du ca. +10% Energieeffizienz auf eine 280W Karte gesehen, dafür zahlst du halt etwas mehr für den Speicher. Da HBM nur bei den teuersten SKUs zum Einsatz käme , relativiert sich das etwas
Beim kleinsten/günstigsten Salvage nimmt man nur 256b GDDR6 und hat aufgrund des kleinen Flächenbedarfs des HBM Interfaces nur wenig Verschnitt.
Da man zum Teil GDDR6 oder HBM nutzt, sind auch teildefekte Die verwendbar (z.B. HBM Controller defekt). Somit steigt der Yield
Reine HBM basierte Lösung für Mobile denkbar (breiter Chip, niedriger Takt, energieeffizienter HBM).
Bei HBM+GDDR6 Kombination werden die Kosten geringer sein als bei 2xHBM und nicht sehr viel höher wie bei 512b GDDR6.
Da nur 8x GDDR6 Packages aufs PCB müssen, kann das PCB besser designed werden (z.B. VRMs näher an den Chips usw.).

Natürlich ist ein reines 384b Interface weniger Designaufwand, hat aber auch keine
Nehmen wir tatsächlich ein Kombi-Interface an, dann ist 256bit GDDR + 2048bit HBM simpler, das nicht benötigte Interface wird komplett deaktiviert. Der Flächenaufwand dafür ist ähnlich 384bit.
Simpler ja. Aber das wollen wir ja eben NICHT. Denn genau dann tritt das ein, was du sagst. Ungenutzte Chipfläche und das schlechteste von beiden Welten ohne effektiv einen Vorteil zu haben. Ausser dass man ein 2048b Interface zur Verfügung hätte, was aber eben teurer beim Speicher wäre und man mehr ungenutzte Chipfläche spendieren müsste (ganze 65mm2 beim GDDR6 SI).

Edit: was mir bei den Beispielen zur Mischbestückung am meisten Sorgen machen würde: ihr habt zwar schön die Bandbreite berücksichtigt, aber zumindest bei GDDR6 scheint ja auch die Latenz sehr wichtig zu sein, da man ja extra auf dem Board die Leitungen hier und da verlängert.
Wäre es nicht relativ schwierig hier HBM2 und GDDR6 anzugleichen?

Ist die Latenz so unterschiedlich? Wir reden hier von ein paar Zentimeter und somit ein paar hundert Picosekunden. GDDR Latenz liegt im Bereich >100ns. Beim GDDR ist wichtig, dass die Leitungen zueinander die gleichen Signallaufzeiten haben. Das hat etwas mit Signalqualität und Signaldemodulation zu tun, weniger mit Latenz der Daten. Zumindest ist das mein Verständnis, ich kann auch falsch liegen.

dargo

2020-09-29, 12:47:47

dargo
Es ist doch so: wir kennen das PCB aus dem Leak, es ist mit 8 GDDR-Chips ausgestattet. Das sind 256Bit, der Fall ist also klar.
Das war ein Enginering Sample. :freak: Und noch nicht mal klar von was.

HOT

2020-09-29, 12:48:53

Und das ändert was? Es ist von einem zuverlässigen Leaker bestätigt worden, dass das N21 ist. Der Fall ist klar. Man bestückt auf einem Sampleboard den Chip komplett als andere ist völlig sinnfrei.

dargo

2020-09-29, 12:50:08

Zuverlässiger Leaker... soso. :ulol:

HOT

2020-09-29, 12:50:47

Ist doch klar, was damit gemeint ist. Ein Risiko besteht bei Spekulation immer.

Screemer

2020-09-29, 12:54:06

Aber wir sollen nicht über technisch mögliches diskutieren? Jetzt wird's aber arg krude.

dargo

2020-09-29, 12:54:49

AMD könnte den zuverlässigen Leaker (hust) genauso gut mit N22 getrollt haben. Meine Meinung dazu im Rahmen einer Spekulation. ;)

BlacKi

2020-09-29, 12:55:24

Das war ein Enginering Sample. :freak: Und noch nicht mal klar von was.

wie stark sind die ES in der vergangenheit vom release produkt abgewichen?

das was wir gesehen haben wird so kommen. wie amd das dann macht, darüber könnt ihr gerne spekulieren.

edit: die gpu fläche der rückseite ist rießig. die leute haben 80cu + 2xhbm dahinter vermutet und du kommst mit n22^^

basix

2020-09-29, 12:55:33

Man bestückt auf einem Sampleboard den Chip komplett als andere ist völlig sinnfrei.

Typischerweise ja. Betonung auf typisch. HBM confirmed? ;D

Berniyh

2020-09-29, 12:55:42

Die XBox hat auch 7 WGPs pro Pipeline, was sonst kein anderer RDNA-Chip hat. Das ist einfach customisiert.
--> Navi 21 Lite:
https://www.reddit.com/r/Amd/comments/j06xcd/number_of_cus_of_navi_23_navi_31_van_gogh_cezanne/

HOT

2020-09-29, 12:56:10

Aber wir sollen nicht über technisch mögliches diskutieren? Jetzt wird's aber arg krude.

Hä? Du kannst diskutieren worüber auch immer du willst :freak:.
Ich finde es nur müßig über etwas zu diskutieren, das schon mit den ersten 2 logischen Gedanken nicht mehr standhält :freak:

Wenn man GDDR6 sowieso verwendet, wieso sollte man noch teureren HBM dazu verwenden? Das ergibt 0 Sinn. Dann machst halt das PCB komplexer und verbaust 512Bit, aber man würde doch auf keinen Fall den teureren Speicher verwenden... Aktuell würdest du sogar was sparen, wenn du 16 8Gb statt 8 16Gb-Chips verwenden würdest... HBM+GDDR ist einfach kompletter Unfug.

Berniyh
ist doch völlig egal, wie das Ding benannt ist. N21 ist offensichtlich ein völlig anderes Produkt. AMD wird schon seine Gründe haben, warum sie wie was benennen.

dargo

2020-09-29, 12:58:36

Wenn man GDDR6 sowieso verwendet, wieso sollte man noch teureren HBM dazu verwenden? Das ergibt 0 Sinn. Dann machst halt das PCB komplexer und verbaust 512Bit, aber man würde doch auf keinen Fall den teureren Speicher verwenden...
Steht du gerade auf dem Schlauch? Weil für den schnellsten RDNA 2 512GB/s zu wenig sein könnten?

Dann machst halt das PCB komplexer und verbaust 512Bit, aber man würde doch auf keinen Fall den teureren Speicher verwenden.
Stimmt... warum hat AMD sich bloß bei Vega10 und Fiji nicht für ein 512Bit SI entschieden? :uponder:

mironicus

2020-09-29, 13:00:30

Vielleicht werden sogar gleich zwei 256 Bit-Schnittstellen emuliert, so daß wir auf 512 Bit Speicherbandbreite kommen. :D

Rampage 2

2020-09-29, 13:02:11

512bit hat man dann wieder das Problem des Flächenverbrauchs und des problematischen PCBs.

Hawaii und Grenada habens geschafft, sogar mit GDDR5 und bei Grenada konnte AMD den Speichertakt sogar nochmal um 500MHz erhöhen. Und das ist schon mehr als ein halbes Jahrzehnt her...

Warum sollte es jetzt nicht mehr gehen!?

Ich habe mittlerweile verstanden, dass sich der Speichercontroller nicht so gut shrinken lässt wie der Rest des Grafikchips, aber größer als vor 7 Jahren ist ein 512 Bit-SI aber auch nicht geworden;) Im schlimmsten Fall gleich groß wie damals...

R2

basix

2020-09-29, 13:02:21

HBM+GDDR ist einfach kompletter Unfug

Ich sehe das Potential und du die Nachteile. Klassischer Fall von Glas halb voll oder halb leer :D

Hawaii und Grenada habens geschafft, sogar mit GDDR5 und bei Grenada konnte AMD den Speichertakt sogar nochmal um 500MHz erhöhen. Und das ist schon mehr als ein halbes Jahrzehnt her...

Warum sollte es jetzt nicht mehr gehen!?

Ich habe mittlerweile verstanden, dass sich der Speichercontroller nicht so gut shrinken lässt wie der Rest des Grafikchips, aber größer als vor 7 Jahren ist ein 512 Bit-SI aber auch nicht geworden;) Im schlimmsten Fall gleich groß wie damals...

R2

Das 512b SI von Hawaii und Grenada war extrem klein. Die heutigen GDDR6 PHYs sind deutlich grösser, und zwar fast 2x. Ich komme mit einer ganz groben Rechnung auf 6mm2 für 64b bei Hawaii. Bei Navi 10 sind es 10-12mm2

HOT

2020-09-29, 13:03:55

Steht du gerade auf dem Schlauch? Weil für den schnellsten RDNA 2 512GB/s zu wenig sein könnten?

Das wird schon reichen, die machen das nicht aus jux und dollerei so. Dafür gibt es einen Grund, das ist exakt das was ich sage.

Stimmt... warum hat AMD sich bloß bei Vega10 und Fiji nicht für ein 512Bit SI entschieden? :uponder:
Ja das ist total vergleichbar :freak:.
Fiji wurde 2014 designt, Vega (alias Greenland) 2015. Warum hat Vega wohl HBM... War ja auch ne wahnsinns Erfolgsstory...

Bei dem großen Package würd ich nicht auf HBM tippen, da ist ja selbst ein externes Cache-Die wahrscheinlicher. Ich glaubs aber auch nicht, sonst hätten wir was von MCM mitbekommen für N21. Ich würd einfach mal davon ausgehen, dass der Chip 505mm² hat und damit auch ziemlich groß ist.

Berniyh

2020-09-29, 13:06:59

Zum Thema GDDR6+HMB2:
Letzterer hat scheinbar eine grob 3x höhere Latenz.
Das führt dann im Grunde eine neue Speicherebene ein, was wieder signifikante Nachteile (gegenüber rein 384 Bit GDDR6) mit sich bringen würde.
Das 512b SI von Hawaii und Grenada war extrem klein. Die heutigen GDDR6 PHYs sind deutlich grösser.
Weil du bei GDDR6 doppelt so viele Kanäle brauchst.

Cyberfries

2020-09-29, 13:08:02

Was hast du nur immer mit deinen 384bit? Es geht hier um den Ersatz eines 512bit Interfaces, nix 384bit.

Wieso kommst du hier mit einem 512bit Interface?
1024bit HBM + 256bit GDDR wären üblicherweise 24 tccs, genau wie 384bit GDDR.

Hast du einfach kein Bock zu lesen?

Was soll diese blöde Unterstellung?
Ich treffe eine Aussage über bisherige Implementierungen.
HBM ohne Interposer habe ich selbst bereits oft genug erwähnt.

... Ankündigungen, sondern um "mass production" ....

Auch Produktionsbeginn ist nicht gleichbedeutend mit Markteinführung.

3,2Gt/s hat Samsung seit März '19 im Angebot,

Und wo wird er eingesetzt? Samsung ist da durchaus Ankündigungsweltmeister.
Wo ist Samsungs 18GT/s GDDR6? Laut Samsung seit Januar 2018 in Produktion....

Falsche Rechnung mein Freund, es sind in beiden Fällen 16gt/s gddr6.

Seit wann bin ich dein Freund?
Die Rechnung basiert auf GDDR und HBM mit gleicher Bandbreite, das sind 12,8GT/s oder 14,4GT/s.
Worauf ich mich beziehe kann man nachlesen.

Kein PHY oder Memory Controller Sharing oder sonst was. Nach den MCs werden die zwei Datenpfade zu einem Datenpfad zusammengeführt

Du brauchst 256bit für GDDR6 +128bit Pseudo für HBM, macht 24 Pfade.
Die kann ich durchaus mit 16tccs verknüpfen, ist nur unwahrscheinlich.
Wenn ich nur 16Pfade hätte, wäre HBM+GDDR nicht gleichzeitig nutzbar.

Damit kombinierst du sogar die Vorteile beider Welten, ohne dass die Nachteile überhand nehmen.

Nein, tue ich nicht. Ich brauche trotz HBM ca.80mm² Interface und habe ein komplexes PCB.
Nur HBM sind ca.30mm² bei simplem PCB, nur GDDR sind ca.97mm² Interface bei simplem Package.

Dazu kommen eben große Fragezeichen hinter der Verdrahtung und der Zusammenarbeit der verschiedenen Speicher.
Die Konsolen als Gegenbeispiel sind wenig geeignet.
edit: Latenzen! siehe Berniyh

HOT

2020-09-29, 13:09:31

Ich sehe das Potential und du die Nachteile. Klassischer Fall von Glas halb voll oder halb leer :D[...]
Was soll denn da der Vorteil sein? Es gibt keinen. Es ist teuer, das wars. Wenn du die Speichermenge und Geschwindigkeit brauchst, nimm einfach mehr GDDR.

Rampage 2

2020-09-29, 13:15:32

Weil du bei GDDR6 doppelt so viele Kanäle brauchst.

Ist das technisch bedingt? - also weil GDDR6 anders funktioniert als GDDR5 braucht es doppelt so viele Kanäle?

R2

Berniyh

2020-09-29, 13:18:56

Ist das technisch bedingt? - also weil GDDR6 anders funktioniert als GDDR5 braucht es doppelt so viele Kanäle?
Das ist eine der wesentlichen Änderungen von GDDR5 auf GDDR6.
Bei GDDR5 hast du einen 32 Bit Kanale je DRAM Baustein, bei GDDR6 hingegen 2 in 16 Bit.
Daher gibt es z.B. bei Navi 10 auch 16 Kanäle zum Speicher, welcher aus 8 Bausteinen besteht.
Bei GDDR5 wären das 8 gewesen.

Edit: siehe z.B.
https://graphicscardhub.com/gddr5-vs-gddr5x-vs-hbm-vs-hbm2/

Zusammenfassung:
- GDDR5: 1 Kanal / Die
- GDDR6: 2 Kanäle / Die
- HBM2: 8 Kanäle / Stack

Eldoran

2020-09-29, 13:25:54

Die als gesichert angesehenen Aspekte ergeben Widersprüche. Vor allem die vielen mutmasslich besonders leistungsfähigen CUs stehen in einem seltsamen Verhältnis zu der erwarteten Bandbreite. Selbst die PS5 oder XBox sind in dieser Hinsicht deutlich konservativer im Design. Es ergibt sich daraus, dass AMD entweder irgendeinen bisher unbekannten Trick nutzt um das Problem aufzulösen oder das die bisher angenommenen Datenpunkte fehlerhaft/unvollständig sind. Die einfachste Auflösung wäre bei der Leistungsfähigkeit der CUs zu finden - also deutlich weniger oder ein niedriger Takt. Nur würde das bedeuten, dass die bisherigen Annahmen zu Performance ebenfalls übertrieben sind.
Ich hoffe auf eine andere Auflösung, allerdings wird sich das ganze wohl kaum korrekt erraten lassen. Ich denke das wird erst mit der offiziellen Präsentation bzw. Leaks dazu klar werden. Zum Glück sollte es ja nicht mehr lange dauern.

basix

2020-09-29, 13:34:36

Zum Thema GDDR6+HMB2:
Letzterer hat scheinbar eine grob 3x höhere Latenz.

Hast du einen Link zu der Info? Ich dachte, die Speicherlatenz wäre bei GDDR5/6 und HBM in etwa ähnlich.

Du brauchst 256bit für GDDR6 +128bit Pseudo für HBM, macht 24 Pfade.
Die kann ich durchaus mit 16tccs verknüpfen, ist nur unwahrscheinlich.
Wenn ich nur 16Pfade hätte, wäre HBM+GDDR nicht gleichzeitig nutzbar.

Gipsel hat 64b Pseudochannels erwähnt, somit wäre es ein 1:2 Mapping (16*64b HBM, 16*16b GDDR6). Allenfalls sind die 16tccs doppelt so breit?

Nein, tue ich nicht. Ich brauche trotz HBM ca.80mm² Interface und habe ein komplexes PCB.
Nur HBM sind ca.30mm² bei simplem PCB, nur GDDR sind ca.97mm² Interface bei simplem Package.

Dazu kommen eben große Fragezeichen hinter der Verdrahtung und der Zusammenarbeit der verschiedenen Speicher.
Die Konsolen als Gegenbeispiel sind wenig geeignet.
Klar macht es das Design etwas komplexer. Dafür mit reduziertem Stromverbrauch und Mobile / Apple Eignung. Ist wie immer ein Tradeoff von Kosten, Designaufwand und Anwendungsgebieten. Zumindest wäre das auch eine mögliche Variante, sich den Navi 12 Stunt bei RDNA2 zu sparen ;)

mksn7

2020-09-29, 13:37:07

Mein Favorit ist mittlerweile doch die 2x 40CU Variante mit jeweils 256bit Variante. Ich halte es nicht unbedingt für das Wahrscheinlichste (da würde ich darauf tippen dass die 256bit memory interface Breite einfach falsch sind), aber das coolste.

Es braucht auch definitiv keine chip-to-chip Verbindung mit der gleichen Breite wie das Speicherinterface, was zwingend wäre wenn es keinerlei locality bei den Zugriffen gäbe.

Die verteilten ROPs, angeschlossen an die seperaten L1's, fangen viel von dem write traffic ab, bzw der Teil vom framebuffer wird sowieso in den nahen Speicher gemapped. Der getrennte L2 bekommt daher nicht mehr soviel traffic.

Die ganzen read only Sachen wie Texturen werden dupliziert, solange Speicher da ist. Bei 2x8GB kann man sicherlich für viele Spiele den allergrößten Anteil der read-only Assets einfach zweifach vorhalten. Und wenn doch mehr Speicher benötigt wird, werden Speicherseiten allmählich dedupliziert, angefangen mit den am seltensten benötigten Speicherseiten. Dafür sind in hardware Zugriffscounter implementiert die die Benutzungshäufigkeit mitprotokollieren (zumindest haben nvidia's HPC chips sowas). Nur ein relativ kleiner Teil der Inhalte, die im Grafikspeicher enthalten sind werden auch tatsächlich verwendet, die kann man dann auch duplizieren. Selbst bei 15GB Grafikspeicherbelegung kann also noch das wichtigste 1GB an Assets dupliziert werden. Vielleicht meldet sich die Grafikkarte auch einfach nur mit einer etwas kleineren Größe, um da Luft zu haben. Oder lagert vorher aggressiv in den System RAM aus.

Ein 100-200 GB/s chip-to-chip interface langt dann vielleicht schon. Bräuchte aber vermutlich immer noch ein Haufen Energie.

Dagegen spricht das aufwendige management der Information wo welche Speicherseite liegt. Bei NVIDIAs uniform memory bremst jede Änderung am memory mapping erstmal ganz schön und verursacht stalls.

Berniyh

2020-09-29, 13:38:15

Kurz nach mal bzgl. TCCS vs. Speicheranbindung.
Fiji hatte 4 HBM Stacks --> 32 Speicherkanäle, hat aber nur 16 TCCS, d.h. Verhältnis 2:1
Vega 10: 2 Stacks, 16 Speicherkanäle, 16 TCCS, d.h. 1:1
Vega 20: 4 Stacks, 32 Speicherkanäle, 32(?) TCCS, wahrscheinlich 1:1
Arcturus: 4(?) Stacks, 32(?) Speicherkanäle, 16(!) TCCS, wahrscheinlich 2:1

Die Angaben mit Fragezeichen sind nicht gesichert, zu Vega 20 konnte ich keine gpu_info Firmware finden aus der ich die num_tccs hätte auslesen können.
Auf jeden Fall aber hat Arcturus 16 TCCS, wird sich aber sicherlich nicht(?) mit 2 HBM2 Stacks zufrieden geben, also würde ich von 32 Speicherkanälen, d.h. 4 Stacks ausgehen.
Entsprechend könnte es auch durchaus sein, dass AMD bei Navi 21 ebenfalls die TCCS im Verhältnis zu den Speicherkanälen reduziert hat, sei es nun 32:16 (4 Stacks HBM2 oder 512 Bit GDDR6) oder 24:16 (3 Stacks HBM2 oder 384 Bit GDDR6).
Generell ist schon überraschend, dass Arcturus und Navi 21 gleich viele TCCS haben.

Gipsel

2020-09-29, 13:40:45

Hawaii und Grenada habens geschafft, sogar mit GDDR5Mit GDDR5 dürfte das einfacher sein als mit GDDR6. Die hatten damals maximal 6GT/s, heute stehen wir bei mehr als dem Doppelten.
Zum Thema GDDR6+HMB2:
Letzterer hat scheinbar eine grob 3x höhere Latenz.Ganz klares Nein. Die DRAM Latenzen sind wie immer völlig vergleichbar bei Speicher vergleichbarer Qualität (irgendwelcher OC-RAM hat niedrigere Latenzen okay, aber run-of-the-mill DDR4 hat vergleichbare Latenz [innerhalb von sagen wir mal 10% Prozent] wie schon DDR3/GDDR5 ihn hatte oder GDDR6 bzw. HBM ihn haben).

pixeljetstream

2020-09-29, 13:42:02

mksn7, wenn das ausreichend wäre dann würde sich nvlink bei Games auch mehr lohnen, tut es aber nicht. Es gibt viel mehr Dinge die dynamisch ausgerechnet werden und leicht verfügbar sein müssen. Denke an was einfaches wie dynamische shadow maps. Oder post process Filter Kernel die größeren Bereich sehen.

Berniyh

2020-09-29, 13:43:42

Hast du einen Link zu der Info? Ich dachte, die Speicherlatenz wäre bei GDDR5/6 und HBM in etwa ähnlich.
https://www.reddit.com/r/hardware/comments/bmirhx/latency_under_load_hbm2_vs_gddr6/

Ich kann das Video jetzt leider nicht anschauen, aber in den Kommentaren wird dazu diskutiert und es scheint ein Faktor von 3-4 zu sein, wobei sich das mit den neuen Taktraten sicher wieder verschiebt.

Unabhängig davon kann ich mir aber trotzdem gut vorstellen, dass hier und da bei der Diskussion davon gesprochen wird, dass die Latenz "in etwa ähnlich" ist.
Das kann aber in dem Zusammenhang (wenn es darum geht ob man einer Karte GDDR6 oder HBM2 spendet) auch einfach nur heißen, dass die Latenz in der gleichen Größenordnung ist (also im ns-Bereich). Bei so einer Diskussion sind die Unterschiede dann nicht ausschlaggebend.
Das ändert sich aber unter Umständen, wenn du versuchst diese Speichertypen zu kombinieren. Man verknotet ja auf dem PCB sogar die Leitungen regelrecht um möglichst identische Latenzen zu allen Bausteinen zu haben und so nicht mehrere Speicherstufen zu erhalten.

Berniyh

2020-09-29, 13:44:46

Zumindest wäre das auch eine mögliche Variante, sich den Navi 12 Stunt bei RDNA2 zu sparen ;)
Bei Navi 12 ging es um mehr als nur anderen Speicher. Der Chip ist allgemein mehr auf Stromsparen ausgelegt.

dargo

2020-09-29, 13:52:28

Hawaii und Grenada habens geschafft, sogar mit GDDR5 und bei Grenada konnte AMD den Speichertakt sogar nochmal um 500MHz erhöhen. Und das ist schon mehr als ein halbes Jahrzehnt her...

Warum sollte es jetzt nicht mehr gehen!?

Gehen tut vieles, die wichtige Frage dabei sind immer die Kosten. Hawaii/Grenada war noch 28nm.

Ich habe mittlerweile verstanden, dass sich der Speichercontroller nicht so gut shrinken lässt wie der Rest des Grafikchips, aber größer als vor 7 Jahren ist ein 512 Bit-SI aber auch nicht geworden;) Im schlimmsten Fall gleich groß wie damals...

Die Preise für 7nm Wafer sind aber stark gestiegen im Vergleich zu 28nm.

Das wird schon reichen, die machen das nicht aus jux und dollerei so. Dafür gibt es einen Grund, das ist exakt das was ich sage.

Da bist du momentan alleine mit diesem "Fakt".

Ja das ist total vergleichbar :freak:.
Fiji wurde 2014 designt, Vega (alias Greenland) 2015. Warum hat Vega wohl HBM... War ja auch ne wahnsinns Erfolgsstory...

Dass Fiji/Vega10 nicht unbedingt erfolgreich waren lag nicht an HBM. Ok... Fiji vielleicht so halb da technisch dummerweise nicht mehr als 4GB damals mit 4 Stacks möglich waren.

basix

2020-09-29, 13:54:08

https://www.reddit.com/r/hardware/comments/bmirhx/latency_under_load_hbm2_vs_gddr6/

Ich kann das Video jetzt leider nicht anschauen, aber in den Kommentaren wird dazu diskutiert und es scheint ein Faktor von 3-4 zu sein, wobei sich das mit den neuen Taktraten sicher wieder verschiebt.

Unabhängig davon kann ich mir aber trotzdem gut vorstellen, dass hier und da bei der Diskussion davon gesprochen wird, dass die Latenz "in etwa ähnlich" ist.
Das kann aber in dem Zusammenhang (wenn es darum geht ob man einer Karte GDDR6 oder HBM2 spendet) auch einfach nur heißen, dass die Latenz in der gleichen Größenordnung ist (also im ns-Bereich). Bei so einer Diskussion sind die Unterschiede dann nicht ausschlaggebend.
Das ändert sich aber unter Umständen, wenn du versuchst diese Speichertypen zu kombinieren.
Klar, wie weit sie auseinander sind und wie stark sich das bei der GPU auswirkt kann ich dir nicht sagen. Gipsel meint, beide sollten sehr nahe beinander sein, nicht Faktoren auseinander.

Man verknotet ja auf dem PCB sogar die Leitungen regelrecht um möglichst identische Latenzen zu allen Bausteinen zu haben und so nicht mehrere Speicherstufen zu erhalten.
Das hat wie gesagt nichts mit der DRAM-Latenz zu tun. Bei 1750 MHz (14Gbps) hat man Signalpulse mit einer Pulsbreite von 286ps. Der Clock ist glaube ich sogar doppelt so hoch wie bei den Datenleitungen (3500MHz) Wenn hier die Flanke um 10% verschoben wird, hat das nachteilige Effekte auf die Demodulation (SNR). Ausserdem wird mit diesen "Verknotungen" eine Impedanzanpassung realisiert, welche wiederum das SNR und auch den Stromverbrauch verbessern. Zudem wird auch die Störempfindlichkeit reduziert.

Gipsel

2020-09-29, 14:02:04

Complicated

2020-09-29, 14:14:02

Das würde im Umkehrschluss bedeuten, dass der Chip beim aktiven RT an Bandbreite "verhungert".
Das wäre der Fall, wenn diese Optimierung nicht schon für RT verwendet würde und lediglich die dort genutzten Ressourcen im "normalen" Rendermodus genutzt werden. Das "Hybrid-Patent" beschreibt zusätzliche Caches und Zugriffsoptimierung die RT nutzt mit den Textur-Einheiten.

Brillus

2020-09-29, 14:23:09

Berniyh

2020-09-29, 14:24:10

Im Video wird auf die Latenz unter Last (also wenn auch Bandbreite gefordert wird) eingegangen. Die Hauptaussage ist, daß HBM und GDDR6 (bei gleich hoher Bandbreite; allgemein Speichersysteme mit hoher maximaler Bandbreite) mehr Last aushalten, bevor die effektive Latenz hochgeht. Ein Unterschied zwischen HBM und GDDR6 wird in dem Video nicht aufgemacht. Es fällt sogar explizit der Satz "DRAM is still DRAM" in Bezug auf die Latenzen.
Effektiv transferieren HBM2e bei 3,6GT/s und GDDR6 bei 14,4GT/s pro 64bit Pseudochannel von HBM (optional ab HBM2) und ein 16bit GDDR6-Kanal exakt die gleiche Datenmenge pro Zeiteinheit mit gleicher Zugriffsgranularität (32Byte).
Ok, danke für die Ausführungen. :)

HOT

2020-09-29, 14:33:29

[...]

Da bist du momentan alleine mit diesem "Fakt".

Nein, Grund, nicht Fakt. Es gibt einen Grund dafür, dass man Bandbreite spart. Fakten gibts hier gar nicht.

Dass Fiji/Vega10 nicht unbedingt erfolgreich waren lag nicht an HBM. Ok... Fiji vielleicht so halb da technisch dummerweise nicht mehr als 4GB damals mit 4 Stacks möglich waren.
Die zeitliche Nähe der Entwicklung ist entscheidend. Fiji war ein Schnellschuss in 2014 für HBM1, Vega (damals Greenland) war der nachfolgende Chip, die auf diesen HBM-Erfahrungen aufbauen sollte. Greenland liess man aktiv und deshalb hat Greenland HBM. Das hat genau 0 mit der Qualität von Greenland/Vega zu tun, das ist einfach in dieser Zeit so geplant und später dann als Vega umgesetzt worden. Man würde das heute aber nicht mehr tun aus der Erfahrungen der Vergangenheit. AMD hat einfach versucht etwas, eben HBM, durchzusetzen, was eben nicht funktioniert hat. Wirtschaftlich war HBM ein Reinfall, mehr meinte ich auch nicht.

Vega selbst hätte auch mit 384Bit GDDR5 funktioniert, das hätte den Chip nicht grossartig vergrößert usw. aber es war einfach nicht vorgesehen. Es wär AMD aber sicherlich deutlich billiger gekommen und die ganzen Package-Probleme u.A. wären nicht aufgetreten.

davidzo

2020-09-29, 14:50:38

Nur noch ein kleine Notiz pro GDDR6 + HBM. Hier ist immer wieder die Sache mit wenn GDDR6 dann PCB teuer. Der Punkt ist aber nicht so einfach, die Kosten für PCB gehen nicht linear hoch sondern ab einer bestimmten Layermenge explodieren die Kosten. So eine Mischung kann also sinn machen um unter dem kritischen Wert zu bleiben selbst wenn rein HBM sich nicht rechnet.

Ja genau, die Frage ist halt ob man ohne buried vias auskommt. Buried Vias sind bei einem consumer Produkt für die Masse ein absolutes no-go. Über Layer alleine lässt sich nicht unbegrenzt skalieren, da man irgendwann keinen Platz mehr für Vias zwischen den Layern hat. Zudem laufen die vielen vias bei erhöhter Layerzahl dem aktuellen Trend entgegen die Speicherchips und VRM näher an den Prozessor zu packen umd hochtakt und effizienz zu ermöglichen. Für MLCCs, spcaps und SMD Induktivitäten geht in 2020 vergleichsweise viel mehr Pad-Fläche auf dem PCB drauf als noch 2013 bei Hawai wo THT Kondensatoren und Drosselspulen die weit über das PCB verteilt wurden noch an der Tagesordnung waren. Daher verbieten sich Layouts mit weiteren extra Layern, wo viel PCBfläche direkt an der GPU für Vias draufgeht. Ich will damit nicht sagen dass moderne layouts weniger Layer haben, im Gegenteil, aber wenn man sich moderne layouts aus wie die 3080 anschaut, dann wird einem klar dass es mit 384bit schon extrem knapp ist und ein 512bit interface in 2020 nicht mehr so einfach ist wie noch 2013 mit langsamen gddr5.

Im Engineering Sample mit 16gt/s gddr6 sehe ich gar keinen Widerspruch zur HBM+GDDR Theorie, sondern viel eher einen Hinweis genau darauf. An den Drosselspulen auf der GPUrückseite sieht man doch das es sich um ein erheblich größeres Package handelt als noch bei Navi10. Und das obwohl es wieder bei 256bit off package bleibt? Sollen das alles neue power delivery pins sein? Das kann ich kaum glauben, viel eher könnte man hier den HBM unterbringen für den man das Package vergrößern musste.

Dschounz

2020-09-29, 15:22:27

Im ersten Moment spricht sicher vieles gegen eine Mischbestückung Hbm2(e)+GDDR6.

Wenn man allerdings bedenkt, welchen Aufwand nVidia betreiben muss, um das 384bit GDDR6X SI stabil zu betrieben, nämlich eine 12(!)-Layer-Platine mit aufwändigem Routing und Fertigung (Stichwort: Backdrill-Verfahren), dann muss man sich doch ernstlich fragen, ob eine Mischbestückung mit einer "einfachen" Platine ala 5700 mit 256bit GDDR6 Bestückung wirklich teurer ist für AMD.

Diese Vereinfachung im Vergleich könnte die Kosten ggf. egalisieren.

dargo

2020-09-29, 15:24:09

Vega selbst hätte auch mit 384Bit GDDR5 funktioniert, das hätte den Chip nicht grossartig vergrößert usw. aber es war einfach nicht vorgesehen. Es wär AMD aber sicherlich deutlich billiger gekommen und die ganzen Package-Probleme u.A. wären nicht aufgetreten.
Jau... und dann hätte V10 350-400W gesoffen. Schon die LCE kam an 350W ran. Zudem hätte V10 mit 384Bit max. 384GB/s mit GDDR5, ergo 100GB weniger als mit HBM.

robbitop

2020-09-29, 15:34:01

Wilde "Möglichkeit" - ein IOD Chiplet im 22FDX Prozess oder im 14HP Prozess würde relativ gute Dichten für Caches bringen und gleichzeitig relativ preisgünstig. 22FDX: eMRAM 14HP: DT eDRAM.

Beides ist sicherlich für I/O und Media Logik gar nicht so schlecht. Gerade Interfaces shrinken ja kaum. Beide Prozesse sollen wohl auch recht gut sein, was Leistungsaufnahme angeht.

Um die notwendige Anbindung (sofern die GDDR6 Controller im IOD wären) zu schaffen, müsste man schon den IOD mit dem Compute Die per Microbumps anbinden. Bedeutet moderne Packaging Technologie (nicht günstig). SI oder EMIB.

Bei der X360 gab es übrigens eine ähnliche Konfiguration. Die GPU und einen separaten die auf gleichem Package, der eDRAM und die ROPs enthielt.

Ist aber im PC Zusammenhang ziemlich wild. Wohl unwahrscheinlich - wollte es aber mal erwähnt haben. :D

HOT

2020-09-29, 15:37:45

Jau... und dann hätte V10 350-400W gesoffen. Schon die LCE kam an 350W ran. Zudem hätte V10 mit 384Bit max. 384GB/s mit GDDR5, ergo 100GB weniger als mit HBM.
Das wage ich aber ganz stark zu bezweifeln. Was hatte Vega? 220W TDP? Das Board hatte trotz HBM 285W. Das wär mit GDDR kaum mehr gewesen. Also das ist nichts, was da ins Gewicht fällt.

robbitop
N31 :D. Evtl. Vermeer.

dargo

2020-09-29, 15:42:43

Das wage ich aber ganz stark zu bezweifeln. Was hatte Vega? 220W TDP? Das Board hatte trotz HBM 285W. Das wär mit GDDR kaum mehr gewesen. Also das ist nichts, was da ins Gewicht fällt.

Genau... weil 384Bit SI nichts saufen. Oh man...

Schau dir eine RX5700 non XT @256Bit und im Vergleich die RX 5600XT @192Bit an. Vielleicht geht dir dann ein Licht auf.

Berniyh

2020-09-29, 15:43:47

HOT

2020-09-29, 15:54:24

Genau... weil 384Bit SI nichts saufen. Oh man...

Schau dir eine RX5700 non XT @256Bit und im Vergleich die RX 5600XT @192Bit an. Vielleicht geht dir dann ein Licht auf.
Jo mir geht ein Licht auf. Was verbraucht ein GDDR5-Modul? 2W... mach dich nicht lächerlich. Speichercontroller braucht auch was, aber nichts, was 50W ausmacht, das ist absurd. Dann hätte die Karte vllt. 300 statt 285W gehabt, das ist ja irre. Ich sags nochmal, das ist egal. Wir reden hier von ein paar W Unterschied, das wars.

Brillus

2020-09-29, 16:01:06

Ja, das stimmt schon, aber der Vergleich geht meistens eigentlich weniger in Richtung HBM2+GDDR6 vs. GDDR6, sondern eher HBM2+GDDR6 vs. HBM2. ;)

Daher oben mein Kommentar kann gut sein das die Einsparung GDDR6 -> GDDR6 + HBM2 wessentlich höher ist als die Einsparung GDDR6 + HBM2 -> HBM2 einfach weil der Preis für mehr Layer des PCB hochgradig nicht linear ist.

dargo

2020-09-29, 16:08:40

Jo mir geht ein Licht auf. Was verbraucht ein GDDR5-Modul? 2W... mach dich nicht lächerlich. Speichercontroller braucht auch was, aber nichts, was 50W ausmacht, das ist absurd. Dann hätte die Karte vllt. 300 statt 285W gehabt, das ist ja irre. Ich sags nochmal, das ist egal. Wir reden hier von ein paar W Unterschied, das wars.
Und ich sage, dass du falsch liegst. Speichermodul war btw. gar nicht das Kernthema. Da dir offenbar kein Licht aufgegangen ist liste ich es für dich mal auf.

RX 5700 @256Bit SI, 36 CUs, 8GB GDDR6 = 176W
RX 5600XT @192Bit SI, 36 CUs, 6GB GDDR 6 = 147W (Sapphire Sparbios)
https://www.computerbase.de/2020-01/radeon-rx-5600-xt-test/3/#abschnitt_messung_der_leistungsaufnahme

Die 29W Differenz kommen sicherlich nicht nur von den 2GB Speicherunterschied. Taktraten sind vergleichbar, wenn nicht sogar minimal höher bei der RX 5600XT im Sparbios.
https://www.computerbase.de/2019-07/radeon-rx-5700-xt-test/2/#abschnitt_die_tatsaechlichen_taktraten_unter_last
https://www.computerbase.de/2020-01/radeon-rx-5600-xt-test/2/#abschnitt_die_tatsaechlichen_taktraten_unter_last

Allerdings wurden diese bei der RX 5600XT in 1080p ermittelt. Insofern werden diese in 1440p wieder etwas niedriger sein.

Armaq

2020-09-29, 16:21:32

HOT

2020-09-29, 16:22:02

dargo
Du präsentierst mir hier einen Äpfel/Birnen-Vergleich und willst daraus was ableiten?

Ist auch völlig egal, die Diskussion ist wieder mal völlig am Sinn vorbei. HBM war für Greenland gedacht, der war 2015 in Entwicklung. Das ist einfach nicht vergleichbar mit heute und Ende. Dass sich AMD 2014/15 auf HBM versteift hat und Raja bei 2017 dabei geblieben ist, ist ne Tatsache und hat mit AMDs heutiger Situation nichts zu tun. Das dient auch nicht als Beweis für irgendwas, was man heute tun würde und schon gar nicht dafür, dass HBM in den heutigen Produkten verwendung findet außer Profi.

Armaq
Ist wohl kein Zufall, dass Zen3 genau so viel früher kommt, dass die Benchmarksysteme darauf umgerüstet werden vorher ;).

dargo

2020-09-29, 16:33:03

Mir ist noch ein neuer Gedanke gekommen zum Launch. Wenn die guten Daten stimmen, dann könnte es sogar sein, dass AMD bei den gängigen Benchmarks doppelt profitieren will. Wenn Zen3 die kolpotierten Sprünge macht, dann wäre zum Release einer RNDA2 Big es natürlich geil das CPU Limit zumindest anzuheben in gängigen Vergleichen. Dadurch würde die gesamte Plattform noch besser dastehen als Intel+Nvidia. Für AMD nach 10 Jahren ein massiver Win.
Da erwartest du aber zu viel von Zen 3. ;) Schon eine Stufe Auflösung höher bringt wesentlich mehr GPU-Last als irgendwelche IPC-Steigerungen zwischen Zen 3 und Zen 2 im Bereich CPU-Limit-Verschiebung.

basix

2020-09-29, 16:34:12

Es bleibt spannend :D

Grundsätzlich sind wohl alle damit einverstanden, dass 256b GDDR6 zuwenig für 80CU sind. Das sieht man anhand der PS5/XBSX sofort. Ausser AMD hat irgendwas spezielles gemacht oder die 256b sind eine Fehlinformation.

Was das "Spezielle" sein könnte:

256b = 512bit :D
256b = 2048b HBM2e
256b + 1024b HBM2e
256b + "Infinity Cache" (wie auch immer der aussieht)
256b + heiliger Gral der Bandbreiteneffizienz
80CU = 40CU

Wir können ja ein Voting machen und abstimmen, wer was für am wahrscheinlichsten hält ;)

unl34shed

2020-09-29, 16:46:40

Das dient auch nicht als Beweis für irgendwas, was man heute tun würde und schon gar nicht dafür, dass HBM in den heutigen Produkten verwendung findet außer Profi.

Warum hat N21 xGMI :uponder:

Armaq

2020-09-29, 16:59:49

Da erwartest du aber zu viel von Zen 3. ;) Schon eine Stufe Auflösung höher bringt wesentlich mehr GPU-Last als irgendwelche IPC-Steigerungen zwischen Zen 3 und Zen 2 im Bereich CPU-Limit-Verschiebung.
Selbst in WQHD liegt ein CPU Limit in einigen Spielen vor. Mehr würde hier auch mehr bringen.

gedi

2020-09-29, 17:38:36

dargo

2020-09-29, 17:44:24

Selbst in WQHD liegt ein CPU Limit in einigen Spielen vor. Mehr würde hier auch mehr bringen.
Ich weiß... aber bei einem 80 CU BigNavi wird man eher auf 4k Benchmarks achten. Oder schaust du bei GA102 auf 1440p Benches ausschließlich?

HOT

2020-09-29, 17:48:04

Bessere CPUs bedeutet größere Abstände zur vorherigen Generation. Allerdings auch für GA102.

basix
Klar ist 512GB/s zuwenig für einen 4k-Chip in der Leistungsklasse. Daher muss es ja etwas geben, was das kompensiert. Darum gehts ja, das weiß schlichtweg keiner bisher. Es gibt Anhaltspunkte in Patenten oder Spekulationen im Caching oder sowas, aber wir werden es erst von AMD oder einem Leak entsprechend erfahren. Wir haben bisher erst folgende Infos:

- Testboard mit 256Bit 16GB 16GT 16Gb GDDR6-Speicher
- Testboard soll lt. Leaker N21 sein
- Testboard-Bohrungen passen ziemlich exakt zu AMDs N21-Renders
- 80CUs in 8x 5 WGP-Konfiguration
- 2,2GHz und 22,5TFLOPs
- RDNA2-Architektur mit RT und KI-Beschleunigung

Klar kann man alle möglichen Kram abseits spekulieren. Aber im Rahmen dieser Daten sollte man schon eher an der Wahrheit liegen.

Zusätzlich gibts noch "wilde" Gerüchte:
- ursprünglich soll 18GT-Speicher vorgesehen worden sein, aber Samsung kann nicht liefern
- Referenzlayout für Samsung 16GT-Speicher auf dem Testboard
- 128MB Ininity-Cache
- HBM statt GDDR (was ich für ausgeschlossen halte)
- kein HBM mehr im Consumerbereich (ja, war ein Gerücht bei Chiphell https://www.3dcenter.org/news/geruechtekueche-amds-big-navi-wohl-doch-mit-512-bit-interface-samt-16-gb-speicher)

Berniyh

2020-09-29, 17:48:41

Ne ernsthaft: Gibt es was Neues?
Nö, aber ist eigentlich auch nicht wirklich zu erwarten. Schau dir doch Zen 3 an. Von den Leaks kommt da so gut wie fast wenig und da sind wir nur noch eine Woche von der Veröffentlichung entfernt.

Die öffentlich zugänglichen Quellen haben wir nun eigentlich komplett ausgeschlachtet, da ist wohl nicht mehr sonderlich viel zu holen.

Werden also wohl sehr zähe 4 Wochen.

gedi

2020-09-29, 17:57:05

Da die Wochen so hart werden, noch etwas lustiges: https://twitter.com/heyitschris89/status/1310741623056334850?s=21

unl34shed

2020-09-29, 18:05:09

6800 Shader/64 = 106,25CUs

btw. ist das nicht schon alt?

basix

2020-09-29, 18:05:09

GPixel/s :uclap::D

gedi

2020-09-29, 18:11:25

6800 Shader/64 = 106,25CUs

btw. ist das nicht schon alt?

Ich sag ja, .... Hypetrain ahoi - trotzdem komme ich nur auf gerade 85CUs. Naja egal-war nur zur Belustigung

gedi

2020-09-29, 19:02:06

Setzt euch bitte mal mit den Sensorwerten auseinander: https://twitter.com/heyitschris89/status/1310748815771799553?s=21

Sieht schlüssig aus, lässt aber einiges an Fragen offen

Screemer

2020-09-29, 19:09:31

Da erwartest du aber zu viel von Zen 3. ;) Schon eine Stufe Auflösung höher bringt wesentlich mehr GPU-Last als irgendwelche IPC-Steigerungen zwischen Zen 3 und Zen 2 im Bereich CPU-Limit-Verschiebung.
die aktuellen "gerüchte" im zen3 faden hast du gesehen. wenn die 8-kerner bei den minfps wirklich so stark im verlgeich zu 3800x und 10900k zulegen, dann kann das neue karten noch mal in ein ganz anderes licht rücken.

dargo

2020-09-29, 19:14:49

Soll ich gleich auf den nächsten Hypertrain aufspringen? :ulol: Nein... danke. :wink: Auch wenn Zen 3 25+% auf Zen 2 drauflegt ändert das nichts merkbar. Der Wechsel von 1440p auf 4k bringt wesentlich mehr bei GPUs um aus möglichen CPU-Limits rauskommen.

gedi

2020-09-29, 19:18:09

dargo

2020-09-29, 19:28:28

Am 08.10.2020 bilde ich mir ein Urteil über Zen 3. ;)

Armaq

2020-09-29, 19:32:38

And that is were you are wrong! :D

Scherz beseite, wenn Zen3 Anfang Oktober die Performance-Krone etabliert, dann wird AMD ja nicht aus Güte mit einem Zen3 System nachbenchen. Die werden hübsch die Zahlen von nvidia nehmen und ihre Zahlen dagegen halten. Das kann u.U. ausreichen um mit einem Win nach Hause zu gehen.

why_me

2020-09-29, 19:35:41

Ist wohl kein Zufall, dass Zen3 genau so viel früher kommt, dass die Benchmarksysteme darauf umgerüstet werden vorher ;).

Das ist schon sehr illusorisch, es wird sehr sicher niemand sein Benchsystem kurz vor dem BN launch auf Zen3 umstellen. Da hängt ein Haufen Arbeit hinten dran, Benchmarks mit X alten GPUs in 10+ Spielen mit min. 3 verschiedenen Einstellungen/Auflösungen + RT, dazu eventuelle Probleme mit der Plattform, die Treiber/BIOS fixe benötigen etc. Zen3 wird höchstens ein Sondertest und wenn er die beste Gaming CPU sein sollte gegen Q2 2021 in die Bench systeme Wandern, wenn sich die releases beruhigt haben.

gedi

2020-09-29, 19:38:18

@dargo

Da hast du recht. Ich denke die CPU wird der Gamechanger, kaufen werde ich ihn mir trotzdem nicht, da ein 3950x bei dauerhaften 4.5G auf allen Kernen in 4K sicher keinen Unterschied machen wird. Also finde meine CPU schon richtig gut, von daher keinen Grund aufzurüsten. Bottlenecks sind hier in 4K auf jeden Fall ausgeschlossen. Mit diesem Setting nehme ich es gerne auch mit nem 10900k auf! Ist aber OT

Um mal wieder den Train zum laufen zu bringen:

N31 = 160/2 CUs da MCM und verfügbar in Feb. 2021

OgrEGT

2020-09-29, 20:16:58

gedi

2020-09-29, 20:29:51

Mal unabhängig von den Leaks die vermehrt von 256b SI sprechen... Auf dem Testboard von N21 (wenn der es wirklich ist), sieht man nur eine einseitige Bestückung mit 8 Chips, so dass dies ebenfalls auf 256b hindeutet. Wenn es möglich wäre, dass das finale Board nicht ein- sondern doppelseitig bestückt wird, so könnte doch auch ein 512b SI möglich sein. Wenn es ebenfalls wie bei Grenada mit 6mm2/64b also ca. 50mm2 groß ist, dann würde man das in einem 505mm2 großen Chip auch gut unterbringen können...

Wenn man N10 verdoppelt, aber das SI gleich lässt und den Takt vom 14 auf 16GPS erhöht lande ich automatisch im Bandbreiten-Limit. Ich weiß Dargo hört es nicht gerne, aber bereits N10, vor allem ausgefahren, hängt im Limit. An 512-Bit mag ich aber auch nicht mehr glauben, da HBM ohne Interposer möglich ist. Also 256-Bit an HBM und habe trotzdem noch etwas Diesize für Halo

Daredevil

2020-09-29, 22:08:55

Nvidia bringt die 3070 wohl auch mit 256bit.
Hmmmm... wäre es möglich, das AMD die Strategie verfolgt, einfach extrem Stark im RT zu sein ?
Also das sie viel Rechenleistung koppeln mit "geht so" Bandbreite, also 16GB bei 256bit für natives gutes 4K ( ~3070-3080 Leistung ) und dafür einfach überproportional gut bei RT weg kommen ( über 3080 Leistung ), weil man dafür nicht viel Bandbreite benötigt?

Braucht man für RT viel Bandbreite? :<

dargo

2020-09-29, 22:14:04

Braucht man für RT viel Bandbreite? :<
Ja.

mczak

2020-09-29, 23:12:29

aber bereits N10, vor allem ausgefahren, hängt im Limit.
So extrem ist das nicht. Die RX 5700 ist (wenn man Modelle mit ähnlichem Takt vergleicht) im Durchschnitt nur etwa 10% schneller als eine RX 5600 XT, bei 33% mehr Bandbreite.
Aendert aber nichts daran dass eine Karte mit verdoppelter CU-Anzahl und bloss 256bit 16 gbps Speicher extrem bandbreitenlimitiert wäre.

Gipsel

2020-09-29, 23:28:20

Auf dem Testboard von N21 (wenn der es wirklich ist), sieht man nur eine einseitige Bestückung mit 8 Chips, so dass dies ebenfalls auf 256b hindeutet. Wenn es möglich wäre, dass das finale Board nicht ein- sondern doppelseitig bestückt wird, so könnte doch auch ein 512b SI möglich sein.Bei doppelseitiger Bestückung die Chips nicht im Clamshell-Modus zur betreiben (wo die Interfacebreite identisch bleibt), erfordert erheblich mehr Datenleitungen auf gleichem Raum und damit deutlich mehr PCB-Layer. Ist nicht unmöglich aber recht ungebräuchlich im Desktop-Bereich.

gedi

2020-09-30, 19:16:59

Vor der Zen3 Vorstellung wird’s wohl nichts Neues mehr geben. Ich hoffe trotzdem schwer, dass wenigstens ein Benchmark mit ner RDNA2-GPU gezogen wird, so als Häppchen

Berniyh

2020-09-30, 22:12:30

Was mich echt ein bisschen wundert ist, dass van Gogh schon jetzt im Linux Treiber unterstützt wird.
Eigentlich sollte die APU doch noch mindestens ein halbes Jahr entfernt sein (sofern wirklich (LP-)DDR5 zum Einsatz kommt).
Und eigentlich hätte ich auch damit gerechnet, dass zuerst Cezanne kommt, AMD hat ja in Aussicht gestellt, dass – nach dem weitgehenden Aus von Renoir im Retailhandelt – bald eine neue APU für AM4 kommen soll.
Daher hätte ich gedacht: Cezanne irgendwann Q1/2021, van Gogh tendenziell eher gegen Mitte des Jahres

Scheint aber so, als wenn es nicht so wäre?
Evtl. hat es ja etwas mit van Goghs Rolle/Positionierung zu tun? Gibt es evtl. einen prominenten Partner (i.e. Chromebook o.ä.), der AMD dazu drängt frühzeitig die APU im Linux Kernel zu unterstützen, evtl. auch vor dem Hintergrund, dass 5.10 der nächste LTS Kernel werden könnte?

SKYNET

2020-09-30, 22:36:45

Linmoum

2020-10-01, 01:13:53

The Sienna Cichlid IDs being added as part of this pull is 0x73A0, 0x73A2, 0x73A3, 0x73AB, 0x73AE, and 0x73BF.

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.9-More-RDNA2-NAVI12

Dschounz

2020-10-01, 08:07:02

Neues Video von Moore's Law Is Dead:

https://www.youtube.com/watch?v=IJHnaxZdeEk

Nach seinen Informationen kommt BigNavi mit reinem 256Bit-GDDR6 16/18 GBPS mit Cache aber ohne HBM Mischbestückung...also ist der heilige Gral der Bandbreiteneffizienz gefunden worden..:eek:;D.

Man wird sehen...

dargo

2020-10-01, 08:14:35

Es gibt 18 Gbps GDDR6?

Edit:
Hmm... überarbeiteter PHY. :uponder:
https://www.pcgameshardware.de/Grafikkarten-Grafikkarte-97980/News/GDDR6-Speicher-Rambus-ermoeglicht-18-Gbps-durch-neuen-PHY-1336120/

Kriegsgeier

2020-10-01, 08:16:33

Moore's Law Is Dead
AMD Big Navi Leak: If Nvidia Ampere Wins, it’s a Pyrrhic Victory…

01.10.2020

https://youtu.be/IJHnaxZdeEk

Dschounz

2020-10-01, 08:18:24

Es gibt 18 Gbps GDDR6?

Laut Moore's Law Is Dead...möglich wärs; siehe Micron`s Deal mit nV für GDDR6X.
Möglicherweise produziert Samsung ja wirklich den Speicher und macht mit AMD einen Exkklusivdeal; ich persönlich denke eher, dass es bei 16 Gbps bleibt.

Kriegsgeier

2020-10-01, 08:18:27

dargo

2020-10-01, 08:21:33

Laut Moore's Law Is Dead...möglich wärs; siehe Micron`s Deal mit nV für GDDR6X.

Er schreibt doch selbst, dass GDDR6X zu ineffizient ist. :wink:

Dschounz, AMD hatte schon den Test!
XBox SERIES X und PS5
Also alles schon getestet!
Also nicht zu früh darüber lustig werden. Es kann wirklich so sein, dass es ein heiliger Gral ist und NVIDIA es erst in den nächsten Generation implementieren wird
Das ist jetzt extrem schwierig abzuschätzen. Mit 18Gbps GDDR6 wäre AMD ohne sectret sauce bei 576GB/s. Die RTX 3080 hat 32% mehr Bandbreite. Dafür hätte dann N21 wiederum knapp 29% mehr Bandbreite als die RTX 3070. Wenn N21 etwas unter der RTX 3080 landet (ich sag einfach mal blind -10%) würden die 576GB/s eventuell sogar ohne sectret sauce reichen. Es bleibt weiterhin spannend. :D

PS: nicht vergessen... RTX 3080 hat 70% mehr Bandbreite als RTX 3070. Ersteres ist aber bei weitem nicht 70% schneller.

Edit:
Das Video verwirrt mich wieder. Stehen jetzt also doch wieder 384Bit SI GDDR6 bei N21 zur Debatte? :freak:

dargo

2020-10-01, 08:31:27

Kriegsgeier

2020-10-01, 08:37:49

Nach diesem Video von Moore's Law Is Dead ist mir jetzt mehr und mehr klar geworden dass es wirklich was mit dem Cache werden könnte. Denn Tests hatte AMD mit X Box SERIES X und PS5 ja genug. Also ist das System erprobt und funktioniert!
Stellt mal vor: wenn die Spiele, die auf Konsolen rauskommen und genau diesen Cache berücksichtigen MÜSSEN, genau diese Spiele auf RDNA2 Architektur laufen werden?! Ja! Wesentlich besser als auf NVIDIAs Ampere...

Adam D.

2020-10-01, 08:40:52

Moore's Law Is Dead
AMD Big Navi Leak: If Nvidia Ampere Wins, it’s a Pyrrhic Victory…

01.10.2020

https://youtu.be/IJHnaxZdeEk
Ich halte nichts von dem Typen, aber das Szenario klingt immerhin realistisch. Das erklärt auch zumindest, warum die 3080 so auf Kante genäht ist und die 3070Ti/Super unmittelbar folgen wird.

dargo

2020-10-01, 08:45:13

Stellt mal vor: wenn die Spiele, die auf Konsolen rauskommen und genau diesen Cache berücksichtigen MÜSSEN, genau diese Spiele auf RDNA2 Architektur laufen werden?! Ja! Wesentlich besser als auf NVIDIAs Ampere...
Da wird auf magische Weise nichts mit einem Cache besser laufen. Dieser Cache (sofern das überhaupt kommt) soll nur die fehlende Bandbreite kompensieren. Sprich... AMD versucht das Dilemma mit GDDR6 + 256Bit SI aufzufangen. Man ist mit dem 256Bit SI auch beim Speicherausbau etwas flexibler. Mit 384Bit SI musst du dich wieder zwischen 12 und 24GB entscheiden. Letzteres drückt die Marge.

Berniyh

2020-10-01, 08:45:38

Zergra

2020-10-01, 08:46:05

Für mich klingt das nicht nach einem heiligen Gral...
Das sieht für mich eher nach einem Mittelweg mit kleinem 256bit Interface, mit der Möglichkeit auf 8/12/16 GB (mit cut), das ganze wird man möglicherweise mit einem Cache teilweise ausgeglichen.

mironicus

2020-10-01, 08:50:47

AMD umgeht damit das Problem was NVidia mit dem hohen Stromverbrauch des Speicher hat. Die Ampere-GPUs selbst verbrauchen ja nicht mehr Watt als ihre Turing-Vorgänger.

Aber die Verbesserung bei AMD betreffen ja nicht nur den Speicher, sie haben durch Architektur-Verbesserungen jetzt deutlich höhere Taktraten als NVidia.

ianm

2020-10-01, 09:08:52

Edit:
Das Video verwirrt mich wieder. Stehen jetzt also doch wieder 384Bit SI GDDR6 bei N21 zur Debatte? :freak:
Verständnisproblem weil englisch? Er hat klar gesagt, es habe wohl früher einen 384bit Prototypen gegeben, dieser sei aber nicht besser oder wesentlich besser als 256bit + Cache gewesen.

HOT

2020-10-01, 09:14:40

Das würde auch zu den beiden Navi-Typen passen, also a und b. Einer davon wurde gecancelt und durch den anderen ersetzt.
Die Konsolen haben die Navi a-Lösung, also nicht den Cache aber dafür viel Bandbreite. Irgendwas muss AMD dazu bewogen haben, mehr Speicher + kompelxeres PCB und mehr I/O durch mehr Die-Fläche zu kompensieren. AMD spricht ja von CPU-Erfahrungen im Zusammenhang mit RDNA2. Da gabs auch ne Folie dazu.

Wenn Samsung jetzt doch angefangen hat 18GT GDDR zu produzieren, kann ja das finale Produkt auch damit ausgestattet werden. Wenn das von Anfang an so gedacht war und nur unsicher war, ob man den Speicher auch bekommt, werden die PCBs ja eh dafür entwickelt worden sein.

Screemer

2020-10-01, 09:17:00

Das ist doch bullshit. Für die Erkenntnis braucht man das nicht in hw gießen.

Cyberfries

2020-10-01, 09:17:36

Wirklich? Was der da an Müll verzapft.
- Er behauptet, 68-72CUs wäre die ursprüngliche Planung gewesen, dann aber kurzfristig umgeschmissen.....
Wohl um seine eigenen falschen "Leaks" zu rechtfertigen. 68CUs, also 4,25WGP je Array?
- Er spricht von 10GB Salvage Varianten - mit 160bit? Nochmal 60% weniger?
- Patente und Doku zur Cache-Behauptung ploppen nur kurz auf - weil sie nichts damit zu tun haben.
- Bei N22 ein kurzer Moment Ehrlichkeit als er zugibt öfter mal ins Blaue zu spekulieren.
- N23 sagt er, das wusste er schon vor Monaten - keinerlei Schamgefühl.
- N22 Launch spekuliert er anhand der "Professional Roadmap" auf Q1....

N21 liegt nach der Spekulation 80% vor N22, bei 25% mehr Interface....

edit: Was war jetzt eigentlich "neu" an diesem "Leak"-Video?
Er hat die letzten Gerüchte nochmal ausgebreitet und behauptet er wäre von alleine draufgekommen - Kindergartenniveau...

dargo

2020-10-01, 09:28:56

Verständnisproblem weil englisch? Er hat klar gesagt, es habe wohl früher einen 384bit Prototypen gegeben, dieser sei aber nicht besser oder wesentlich besser als 256bit + Cache gewesen.
Merci. ;)

Berniyh

2020-10-01, 09:30:31

Das würde auch zu den beiden Navi-Typen passen, also a und b. Einer davon wurde gecancelt und durch den anderen ersetzt.
Nein, Navi A/B haben die gleiche Anzahl an Speicherkanälen.

Müssen mal abwarten ob das was der Typ labert überhaupt stimmt. Ich hab da so meine Zweifel …

gedi

2020-10-01, 09:55:26

Dschounz

2020-10-01, 09:59:03

Dschounz, AMD hatte schon den Test!
XBox SERIES X und PS5
Also alles schon getestet!
Also nicht zu früh darüber lustig werden. Es kann wirklich so sein, dass es ein heiliger Gral ist und NVIDIA es erst in den nächsten Generation implementieren wird

Ich mach mich nicht lustig, das war ernst gemeint...die Aussagen des Sony-Mitarbeiters auf der Playstation-PK weisen ja auch in diese Richtung.

@Dargo: Es war so gemeint

nV/Micron => exklusiv GDDR6X

AMD/Samsung => exklusiv (oder als Early-Adopter) GDDR6 18Gbps, um das Interface voll auszureizen

Iscaran

2020-10-01, 10:00:22

The Sienna Cichlid IDs being added as part of this pull is 0x73A0, 0x73A2, 0x73A3, 0x73AB, 0x73AE, and 0x73BF.

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.9-More-RDNA2-NAVI12

Basierend darauf müsste also N21 in bis zu 6 Modellen/Karten rauskommen und existieren ?!?
Wozu sonst so viele PCI IDs ?

Speku:

Chipaufbau allgemein: 4 Shader Engines, zu je 2 Shader Arrays zu je 5 WGP und 2 CU pro WGP.
Also 4x2x5x2 = 80 CUs
Das ganze mit 64 ROPs pro SE 1 Rasterizer mit 4Raster Backends die je 4 B output generieren pro cycle. =4*4*4 = 64

Durch Quervergleiche mit den Reddit leaks und dem AMD Whitepaper zu RDNA1
https://old.reddit.com/r/Amd/comments/j06xcd/number_of_cus_of_navi_23_navi_31_van_gogh_cezanne/
https://www.amd.com/system/files/documents/rdna-whitepaper.pdf

Folgere ich mal in Kombination mit den 6 PCI IDs:

6900 Pro = 80CU@2.2GHz@256Bit @32GB HBM2@4096Bit = 4stacks = 1024 MB/s
Niveau RTX 3090
N6900 XT = 80CU@2.2GHz@256Bit @16GB HBM2@4096Bit = 4stacks = 1024 MB/s
Niveau RTX 3080 +5%
6900 = 80CU@2.05GHz@256Bit @16GB, 18Gb/s GDDR6 = 576 MB/s
Niveau RTX 3080 -5%

Das ganze ergänzt um die Desktop-Variante des XBox-Chips (Navi21 Lite aus dem Treiberangaben von Reddit).
EDIT: Dieser hat aber den Aufbau 2x2x7x2 = 56 CUs ...wäre also eigentlich ein "eigenständiger" Chip ?!?/EDIT.

6800 XT = 56 CU@2.5 GHz@256Bit @8 GB GDDR6 18 Gb/s = 576 MB/s
Niveau 3070
6800 = 52 CU@2.2 GHz@256bit @8GB
Niveau 3070 -10%

Bleibt noch 1 PCI ID über, vielleicht für den XBOX-Chip wie er ist also 52 CU@1.825GHz @320bit usw.
Den Chip gibt es nur im Treiber, wird es aber nicht zum Kauf geben...

gedi

2020-10-01, 10:02:14

Ich mach mich nicht lustig, das war ernst gemeint...die Aussagen des Sony-Mitarbeiters auf der Playstation-PK weisen ja auch in diese Richtung.

@Dargo: Es war so gemeint

nV/Micron => exklusiv GDDR6X

AMD/Samsung => exklusiv (oder als Early-Adopter) GDDR6 18Gbps, um das Interface voll auszureizen

Ein Produkt, welches auf Samsungs Page nicht existiert?! Wenn, dann kann es sich nur um selektiven 16GPS-Vram handeln, imo.

why_me

2020-10-01, 10:06:41

Dschounz

2020-10-01, 10:11:11

Ein Produkt, welches auf Samsungs Page nicht existiert?! Wenn, dann kann es sich nur um selektiven 16GPS-Vram handeln, imo.

Laut u.g Quelle seit zwei Jahren in Produktion, aber wie du sagst, danach wart er nicht mehr gesehen...

https://www.computerbase.de/2018-01/samsung-gddr6-18gbps/

Cyberfries

2020-10-01, 10:17:19

Was wäre bei einem salvage chip so schlimm daran? :confused:

Er behauptet, das wäre eine Planung für den Vollausbau gewesen....

Das ganze mit 64 ROPs

128 ROPs, xBox hat 2SE mit je 4RBEs und 64 ROPs, N21 4SE.

6900 Pro = 80CU@2.2GHz@256Bit @32GB HBM2@4096Bit = 4stacks = 1024 MB/s

Du meinst wahrscheinlich GB/s. Ich würde von zwei Stapeln mit 3,2-3,6GT/s ausgehen,
vier Stapel wäre übertrieben, das wären selbst mit 2,4GT/s 1229GB/s.

Wieso planst du mit drei 80CU-Varianten? Und alle Consumer?
edit: Ursprünglich war mal von vier Modellen die Rede, Pro, XTX, XT, Salvage.
Gab aber Gerüchte über Streichungen.

Berniyh

2020-10-01, 10:19:47

Basierend darauf müsste also N21 in bis zu 6 Modellen/Karten rauskommen und existieren ?!?
Wozu sonst so viele PCI IDs ?
Nein, so kannst du da nicht rechnen.
Wofür diese ganzen PCI IDs verwendet werden wissen wir nicht, aber es sind nicht einfach irgendwelche Consumer Produkte.
Navi 10 z.B. hat 7 PCI IDs eingetragen, Vega 10 sogar 16.
Jetzt überleg mal wie viele Vega 10 Karten an Consumer AMD rausgebracht hat?

Evtl. sind da auch irgendwelche Workstation Karten dabei, oder Custom Modelle für bestimmte Partner. So genau wissen wir das jedenfalls nicht.

HOT

2020-10-01, 10:41:33

Vega hatte mehr Märkte. N21 hat sicherlich keine Instinct z.B. 7 IDs sind sogar recht wenig.

stinki

2020-10-01, 10:54:35

AMD wird ja wahrscheinlich aus meiner Sicht mindestens 4 Karten/SKUs von Navi21 bringen:
Eine für den professionellen Bereich (80CUs/32GB).
Eine gegen 3080 10/20GB (~72-80CUs/16GB) (ich glaube immer noch an eine SKU <80CUs).
Eine gegen 3070Ti 16GB (~60CUs/16GB) (könnten auch mehr CUs werden).
Und eine gegen 3070 8GB (~60CUs/8GB) (könnten auch weniger CUs werden).

Ich bin wirklich mal auf die Performance und den Preis gespannt...

Berniyh

2020-10-01, 11:02:08

Vega hatte mehr Märkte.
Natürlich, aber auch für Navi 21 wissen wir nicht wo die überall eingesetzt werden.
N21 hat sicherlich keine Instinct z.B. 7 IDs sind sogar recht wenig.
Es können auch immer noch IDs nachträglich hinzugefügt werden.

Der wesentliche Punkt ist aber:
1. Die ID Liste muss mitnichten vollständig sein
2. Die ID Liste lässt keine Rückschlüsse über die Anzahl der ausstehenden Produkte (im Consumerbereich) zu

why_me

2020-10-01, 11:11:23

Er behauptet, das wäre eine Planung für den Vollausbau gewesen....

Ok, muss ich mir nochmal anschauen, wie er das gemeint hat. Aber wenn es 68 als Vollausbau gewesen wären, dann sicher mit einer anderen SE/SH Kombination als wir sie jetzt mit N21 sehen.

Iscaran

2020-10-01, 11:25:17

128 ROPs, xBox hat 2SE mit je 4RBEs und 64 ROPs, N21 4SE.

Der Reddit-Treiber leak legt nahe dass N21 in der Tat nur 4RBs pro SE hat, mit einem Takt von 4 macht das 4x4x4 = 64 ROPS...
Berniyh hatte mich in einem anderen Thread schon darauf hingewiesen, weil ich auch dachte dass es eigentlich nicht sein kann dass N21 nur 64 ROPs hat.

Ja mit den HBM-Werten hab ich nur grob Werte aus dem Kopf zitiert, kann sein, dass diese noch nicht sehr gut ist.

So oder so denke ich, dass Navi21 definitiv mit BEIDEN Varianten kommt. HBM und GDDR6

Wieso planst du mit drei 80CU-Varianten? Und alle Consumer?
edit: Ursprünglich war mal von vier Modellen die Rede, Pro, XTX, XT, Salvage.
Gab aber Gerüchte über Streichungen.

Ist nur dem gechuldet, daß Sienna Cichlid recht eindeutig mit N21 gleichzusetzen ist, es aber 6 PCI IDs dazu gibt.

Navi21 Lite passt aber auch nicht ins Schema, weil es eigentlich vom design her kein Sienna Cichlid ist ?

dargo

2020-10-01, 11:28:27

Basierend darauf müsste also N21 in bis zu 6 Modellen/Karten rauskommen und existieren ?!?
Wozu sonst so viele PCI IDs ?

Speku:

Chipaufbau allgemein: 4 Shader Engines, zu je 2 Shader Arrays zu je 5 WGP und 2 CU pro WGP.
Also 4x2x5x2 = 80 CUs
Das ganze mit 64 ROPs pro SE 1 Rasterizer mit 4Raster Backends die je 4 B output generieren pro cycle. =4*4*4 = 64

Durch Quervergleiche mit den Reddit leaks und dem AMD Whitepaper zu RDNA1
https://old.reddit.com/r/Amd/comments/j06xcd/number_of_cus_of_navi_23_navi_31_van_gogh_cezanne/
https://www.amd.com/system/files/documents/rdna-whitepaper.pdf

Folgere ich mal in Kombination mit den 6 PCI IDs:

6900 Pro = 80CU@2.2GHz@256Bit @32GB HBM2@4096Bit = 4stacks = 1024 MB/s
Niveau RTX 3090
N6900 XT = 80CU@2.2GHz@256Bit @16GB HBM2@4096Bit = 4stacks = 1024 MB/s
Niveau RTX 3080 +5%
6900 = 80CU@2.05GHz@256Bit @16GB, 18Gb/s GDDR6 = 576 MB/s
Niveau RTX 3080 -5%

Das ganze ergänzt um die Desktop-Variante des XBox-Chips (Navi21 Lite aus dem Treiberangaben von Reddit).
EDIT: Dieser hat aber den Aufbau 2x2x7x2 = 56 CUs ...wäre also eigentlich ein "eigenständiger" Chip ?!?/EDIT.

6800 XT = 56 CU@2.5 GHz@256Bit @8 GB GDDR6 18 Gb/s = 576 MB/s
Niveau 3070
6800 = 52 CU@2.2 GHz@256bit @8GB
Niveau 3070 -10%

Bleibt noch 1 PCI ID über, vielleicht für den XBOX-Chip wie er ist also 52 CU@1.825GHz @320bit usw.
Den Chip gibt es nur im Treiber, wird es aber nicht zum Kauf geben...
Ich kann dir hier nicht wirklich folgen.

1. Wozu brauchst du 4 HBM Stacks? Selbst mit dem langsamsten HBM2e würdest du über 1,6TB/s rauskommen. Völlig überflüssig für RDNA2 Gaming. Oder meinst du 256Bit SI GDDR6 + 2 HBM Stacks? Dann wären aber 2 HBM Stacks auch zuviel.
2. Die 6900 in deinem Beispiel macht mit 80 CUs und nur 576GB/s Bandbreite gar keinen Sinn wenn die 6800XT mit 56 CUs auch 576GB/s bekommt. Letztere hätte zwar 22% mehr Takt. Erstere aber 43% mehr CUs. Etwas unausgewogen das Ganze. Und dir fehlt noch ein Salvage. Wenn schon dann müsste die 6900 mit 66-72CUs kommen. Bei 72 CUs fände ich die 576GB/s aber auch noch etwas mager wenn der TopDog 1TB/s braucht.

Iscaran

2020-10-01, 11:32:08

Wie ich oben schon schrieb die Zahl der HBM stacks kann ich schlecht schätzen... da ich die Bandbreiten nicht 100% im kopf hatte...
Wenn ihr sagt es geht auch mit 2 stacks dann ist das nur in meinen Augen noch realistischer als mit 4 stacks.

dargo

2020-10-01, 11:35:52

Wie ich oben schon schrieb die Zahl der HBM stacks kann ich schlecht schätzen... da ich die Bandbreiten nicht 100% im kopf hatte...

HBM2 je Stack max. afaik 307GB/s (könnten auch 312GB/s sein, wird beim GA100 (https://www.golem.de/news/a100-nvidias-7-nm-monster-gpu-misst-826-mm-2005-148480.html) verwendet)
HBM2e je Stack max. 460GB/s

Iscaran

2020-10-01, 11:39:15

Der wesentliche Punkt ist aber:
1. Die ID Liste muss mitnichten vollständig sein
2. Die ID Liste lässt keine Rückschlüsse über die Anzahl der ausstehenden Produkte (im Consumerbereich) zu

Hmm, ja hast Recht.

Schaut man mal für Navi10 in die PCI ID repository findet man
2 Einträge für den PCI-e Switch (Upstream und Downstream)
1 Eintrag für die W5700X
1 Eintrag W5700
sowie NUR
1 Eintrag für die ganzen Desktopkarten Radeon RX 5600 OEM/5600 XT / 5700/5700 XT
Und dann noch
1 Eintrag für den HDMI Audio chip auf Navi10

Das sind witzigerweise ebenfalls genau 6 PCI IDs in Summe

Iscaran

2020-10-01, 11:41:41

@dargo: Danke !
wieviel GB Speicher können pro Stack realisiert werden ?
4GB, 8GB ?

Demnach sind aber 2x307GB/s für HBM2 auch nur 614 GB/s und damit nicht wesentlich mehr als mit dem 18 Gb/s GDDR6 (18/8*256 Bit SI)=576 GB/s

dargo

2020-10-01, 11:47:11

@dargo: Danke !
wieviel GB Speicher können pro Stack realisiert werden ?
4GB, 8GB ?

HBM2 = 8GB
HBM2e = 16GB

prinz_valium_2

2020-10-01, 11:47:27

Also wenn es HBM und GDDR6 gibt, dann 80CUs mit HBM und den 72CU salvage mit 256 bit GDDR6

So ist die geringe Bandbreite weniger problematisch.

dargo

2020-10-01, 11:49:33

Also wenn es HBM und GDDR6 gibt, dann 80CUs mit HBM und den 72CU salvage mit 256 bit GDDR6

So ist die geringe Bandbreite weniger problematisch.
Dann brauchst du 2 verschiedene Speichercontroller für den gleichen Chip. Also eher nein.

unl34shed

2020-10-01, 11:50:05

HBM2 = 8GB
HBM2e = 16GB

AFAIK sind es 4(2hi), 8, 12, 16, 20 oder 24GB(12hi) pro Stack bei HBM2e. HBM2 ist nur bis 16GB (8hi) spezifiziert.

Complicated

2020-10-01, 12:04:55

Was mir hier immer fehlt bei den PCI-Zuordnungen ist der CDNA Chip. Worunter läuft der eigentlich....soll ja noch dieses Jahr erscheinen.

davidzo

2020-10-01, 12:23:03

Was mir hier immer fehlt bei den PCI-Zuordnungen ist der CDNA Chip. Worunter läuft der eigentlich....soll ja noch dieses Jahr erscheinen.

Eine device ID zu Arcturus gab es doch schon im Februar: 0x1002 0x738C

Der ist aber sowieso merkwürdig verspätet. Die ersten Leaks dazu gehen noch auf September 2018 zurück, tapeout leaks hatten wir in 2019 und im Februar20 hatten wir schon biosdateien mit device IDs und (vorläufigen?) Taktraten, seitdem schwirren also schon ES herum. Da sollte das Vieh doch demnächst mal launchen?
Ich kann mir das nur damit erklären dass Arcturus nicht den Erwartungen entspricht und in einer kompetitiven Umgebung gegenüber A100 nicht bestehen kann. Stichwort Int8-Leistung, Tensorkerne und sparsity.
In dem Fall würde AMD die HPC Variante trotzdem launchen müssen, da es bestehende Verpflichtungen gibt und das Gesamtpaket mit EPYC CPUs und xGMI dann doch gar nicht so schlecht ist und in Supercomputern verplant ist. Die off-the-shelf version als Instinct Mi-100 würde dann aber entfallen.

basix

2020-10-01, 13:02:57

Bei HPC steht und fällt es mit der Infrastruktur. D.h. Software als auch Systemdesign. Das braucht halt etwas länger, wenn man vorher noch nicht viel hatte. CDNA wird aber vor Ende dieses Jahres vorgestellt werden, da bin ich mir ziemlich sicher. Ich tippe auf Dezember.

Und Ampere wird man bei der Auslegung von Arcturus sicher berücksichtigt habe. Vermutlich mit GV100*2, was ja nicht so schlecht stimmt, wenn man das Sparsity Feature aussen vor lässt. Es sind wohl eher die restlichen Features, welchen den Unterschied ausmachen werden: Bfloat16, TF32, Sparsity, MIG, Software und Tools.

JVC

2020-10-01, 13:04:13

[MK2]Mythos

2020-10-01, 13:08:40

JVC

2020-10-01, 13:09:49

Nahm halt nur den Satz als "aufreißer" ;)
Aber meine das komplette Post!

M.f.G. JVC

Shaft

2020-10-01, 13:25:34

Wie wird Navi Nvidias RTX Unterstützen, ist das was bekannt?

Und Frage mich wenn ja, wie gut es Performen wird.

Derzeit tendiere ich sehr stark zum grossen N21, der Verbrauch muss nur noch passen.

dargo

2020-10-01, 13:27:54

https://extreme.pcgameshardware.de/threads/geforce-rtx-3080-3090-fehlt-den-grafikkarten-leistung.591990/page-2#post-10501737
"AMD bastelt in meinen Augen gerade am heiligen Gaming-Ökosystem..."
:up:

M.f.G. JVC
Ich finde diesen Teil wesentlich interessanter auch wenns etwas OT ist. :)
https://gpuopen.com/learn/porting-detroit-1/

Mir war nicht klar, dass ein PC-Port 1,5 Jahre in Anspruch nehmen kann. Aber gut... wir wissen auch nicht wieviel Manpower daran gesessen hat.

JVC

2020-10-01, 13:34:49

Inklusive seiner Links natürlich :smile:

M.f.G. JVC

unl34shed

2020-10-01, 13:36:29

mboeller

2020-10-01, 13:46:50

Kriegsgeier

2020-10-01, 13:48:22

Leute, was ist wenn dieser Infinity-Cache bei RDNA2 Architektur dafür sorgt, dass es mit ZEN3 Architektur am optimalsten läuft?
Intel CPUs somit weniger attraktiv erscheinen lässt?
Möglich?

Oder ist dieser Cache eher deswegen da weil der Chip mit DDR6 UND HBM2 funktionieren soll?

Fragen über Fragen

Berniyh

2020-10-01, 13:49:27

Hmm, ja hast Recht.

Schaut man mal für Navi10 in die PCI ID repository findet man
2 Einträge für den PCI-e Switch (Upstream und Downstream)
1 Eintrag für die W5700X
1 Eintrag W5700
sowie NUR
1 Eintrag für die ganzen Desktopkarten Radeon RX 5600 OEM/5600 XT / 5700/5700 XT
Und dann noch
1 Eintrag für den HDMI Audio chip auf Navi10

Das sind witzigerweise ebenfalls genau 6 PCI IDs in Summe
Das sind aber nicht diese PCI IDs. In der Datei die wir diskutieren werden nur GPU Chips genannt. Schau dir das z.B. bei meinem Kaveri an:
lspci -nn
[...]
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Kaveri [Radeon R7 Graphics] [1002:130f]
00:01.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Kaveri HDMI/DP Audio Controller [1002:1308]
[...]

Eben jene ID 1308 fehlt im GPU Treiber logischerweise (steht stattdessen dann an ganz anderer Stelle im Linux Kernel bei den Sound Treibern):
»···/* Kaveri */
»···{0x1002, 0x1304, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_KAVERI|AMD_IS_MOBILITY|AMD_IS_APU},
»···{0x1002, 0x1305, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_KAVERI|AMD_IS_APU},
»···{0x1002, 0x1306, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_KAVERI|AMD_IS_MOBILITY|AMD_IS_APU},
»···{0x1002, 0x1307, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_KAVERI|AMD_IS_APU},
»···{0x1002, 0x1309, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_KAVERI|AMD_IS_MOBILITY|AMD_IS_APU},
»···{0x1002, 0x130A, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_KAVERI|AMD_IS_MOBILITY|AMD_IS_APU},
»···{0x1002, 0x130B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_KAVERI|AMD_IS_MOBILITY|AMD_IS_APU},
»···{0x1002, 0x130C, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_KAVERI|AMD_IS_MOBILITY|AMD_IS_APU},
»···{0x1002, 0x130D, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_KAVERI|AMD_IS_MOBILITY|AMD_IS_APU},
»···{0x1002, 0x130E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_KAVERI|AMD_IS_MOBILITY|AMD_IS_APU},
»···{0x1002, 0x130F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_KAVERI|AMD_IS_APU},
»···{0x1002, 0x1310, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_KAVERI|AMD_IS_APU},
»···{0x1002, 0x1311, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_KAVERI|AMD_IS_APU},
»···{0x1002, 0x1312, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_KAVERI|AMD_IS_APU},
»···{0x1002, 0x1313, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_KAVERI|AMD_IS_APU},
»···{0x1002, 0x1315, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_KAVERI|AMD_IS_APU},
»···{0x1002, 0x1316, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_KAVERI|AMD_IS_APU},
»···{0x1002, 0x1317, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_KAVERI|AMD_IS_MOBILITY|AMD_IS_APU},
»···{0x1002, 0x1318, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_KAVERI|AMD_IS_MOBILITY|AMD_IS_APU},
»···{0x1002, 0x131B, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_KAVERI|AMD_IS_APU},
»···{0x1002, 0x131C, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_KAVERI|AMD_IS_APU},
»···{0x1002, 0x131D, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_KAVERI|AMD_IS_APU},
Die 130F ist aber natürlich drin (sonst würde das nicht funktionieren).
Wie es bei den PCI Switches ist weiß ich nicht, das könnte bei den dedizierten GPUs anders sein (hab jetzt keine Lust deswegen den anderen PC zu starten ;)), aber ich schätze mal die zählen da auch nicht dazu.

Was es am Ende mit den ganzen IDs auf sich hat weiß ich auch nicht genau, aber viele gehören vermutlich zu Produkten die wir nie zu Gesicht bekommen werden. Und manche waren evtl. mal geplant, wurden dann aber nicht verwirklicht.

Troyan

2020-10-01, 13:53:17

mal was zum Infinity Cache ...

auch wenn ich nicht glaube, dass dieser 128MB Cache wirklich existiert.

Basis: XBox One: 28nm -> 32MB SRAM

die 2 Blöcke an SRAM die man in diesem Artikel hier gut sieht sind jeweils ca. 35mm² groß: https://www.golem.de/news/die-shot-analyse-tausche-esram-gegen-compute-units-1311-103035.html

bei TSMC 28nm ist eine SRAM Zelle 0,127µm² groß
bei TSMC 7nm ist eine SRAM Zelle min. 0,027µm² groß

Der embedded Framebuffer scheint bei der XBO trotz 28nm sehr kompakt zu sein. Umgerechnet wäre ein 128MB Framebuffer bei N21 in 7nm also nur so 60mm² groß.

Der Cache, wenn er genauso kompakt gehalten ist wie bei der XBO wäre also von der Die-Size her schon effektiv.

Nein, er ist nicht effektiv. Hier der Vergleich zwischen One/S und One X:
https://images.anandtech.com/doci/15994/202008180212521_575px.jpg

Die One X hat 4x mehr Rechenleistung als die S und ist dabei nur 1,5x größer. Selbst Microsoft hat es eingesehen, dass es kein Sinn ergibt und nutzt die Fläche für mehr Rechenleistung.

dargo

2020-10-01, 13:53:53

Oder ist dieser Cache eher deswegen da weil der Chip mit DDR6 UND HBM2 funktionieren soll?

Bei GDDR6 und HBM2(e) brauchst du keinen Cache da genug Bandbreite da wäre. Der Cache ist nur relevant wenn Bandbreite für Rohleistung X fehlt und ausschließlich GDDR6 an einem 256Bit SI verwendet werden will.

Berniyh

2020-10-01, 13:59:53

Was mir hier immer fehlt bei den PCI-Zuordnungen ist der CDNA Chip. Worunter läuft der eigentlich....soll ja noch dieses Jahr erscheinen.
Steht doch schon drin:
»···/* Arcturus */
»···{0x1002, 0x738C, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_ARCTURUS},
»···{0x1002, 0x7388, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_ARCTURUS},
»···{0x1002, 0x738E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_ARCTURUS},
»···{0x1002, 0x7390, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_ARCTURUS},

Die Frage ist halt an wen sich Arcturus richtet. Wenn der Chip hauptsächlich für irgendwelche Supercomputerprojekte ist, dann liegt es evtl. daran, dass man davon nichts hört.
Ich schätze mal man hat den Chip einfach nur in recht geringer Stückzahl produziert, da er relativ viele Wafer frisst und man viele 7nm Wafer für den ganzen anderen Mist braucht.
Daher wird der Chip dann evtl. auch nur an ausgewählte Partner angeboten und gar nicht in öffentlichen Produkten.

dargo

2020-10-01, 14:03:14

Nein, er ist nicht effektiv. Hier der Vergleich zwischen One/S und One X:
https://images.anandtech.com/doci/15994/202008180212521_575px.jpg

Die One X hat 4x mehr Rechenleistung als die S und ist dabei nur 1,5x größer. Selbst Microsoft hat es eingesehen, dass es kein Sinn ergibt und nutzt die Fläche für mehr Rechenleistung.
Was ist das denn wieder für ein kruder Vergleich? XBox Series X...
https://cdn.mos.cms.futurecdn.net/sxYFVg6RJTviZ93MC8aYLE-650-80.png.webp

Bei der XBox Series S ändert sich gar nichts an den beiden CPU-Clustern im Bereich Die-Size. Wie denn auch wenn es gleich bleibt, nur die Frequenzen werden etwas kleiner ausfallen? Gleiches gilt den Multimedia-Teil sowie den IO. Man wird nur auf die beiden oberen Memory-Controller verzichten.

Edit:
Argh... sorry, du vergleichst hier die alten Konsolen. :redface:

Edit 2:
Wie sicher sind eigentlich die 16GB bei N21? Ist das 100% bestätigt? Wenn ich mir das Diagramm der XBSX so ansehe wären auch 320Bit GDDR6 mit den 16Bit Memory-Controllern denkbar. Mit 18Gbps wäre man bei immerhin 720GB/s. Man verballert auch etwas weniger Die-Size im Vergleich zu 384Bit. Und beim Salvage wäre man auch ziemlich flexibel. Dort einfach 14Gbps verbauen und optional 10GB/20GB Versionen anbieten. Etwas blöd wäre dann halt, dass 20GB GDDR6 anstatt 16GB angeboten werden müssten. Mit nur 10GB würde es ziemlichen Shitstorm geben.

gedi

2020-10-01, 14:34:01

Was ist das denn wieder für ein kruder Vergleich? XBox Series X...
https://cdn.mos.cms.futurecdn.net/sxYFVg6RJTviZ93MC8aYLE-650-80.png.webp

Bei der XBox Series S ändert sich gar nichts an den beiden CPU-Clustern im Bereich Die-Size. Wie denn auch wenn es gleich bleibt, nur die Frequenzen werden etwas kleiner ausfallen? Gleiches gilt den Multimedia-Teil sowie den IO. Man wird nur auf die beiden oberen Memory-Controller verzichten.

Edit:
Argh... sorry, du vergleichst hier die alten Konsolen. :redface:

Edit 2:
Wie sicher sind eigentlich die 16GB bei N21? Ist das 100% bestätigt? Wenn ich mir das Diagramm der XBSX so ansehe wären auch 320Bit GDDR6 mit den 16Bit Memory-Controllern denkbar. Mit 18Gbps wäre man bei immerhin 720GB/s. Man verballert auch etwas weniger Die-Size im Vergleich zu 384Bit. Und beim Salvage wäre man auch ziemlich flexibel. Dort einfach 14Gbps verbauen und optional 10GB/20GB Versionen anbieten. Etwas blöd wäre dann halt, dass 20GB GDDR6 anstatt 16GB angeboten werden müssten. Mit nur 10GB würde es ziemlichen Shitstorm geben.

AFAIK gründen alle Spekulationen auf dem Bild des Testboards.
Sprich 8x2G = 256-Bit
Irgendeine XT, wovon alle von N21 ausgehen.

why_me

2020-10-01, 14:46:03

AFAIK gründen alle Spekulationen auf dem Bild des Testboards.
Sprich 8x2G = 256-Bit
Irgendeine XT, wovon alle von N21 ausgehen.

Der Kühler passt aber auch zum ES Board, nicht nur die Schrauben, sondern auch die Bauteile auf der Rückseite. Die von Mir irrtümlich angenommene Klappe ist keine Vertiefung, sondern eine Erhebung, um Platz für Bauteile darunter zu haben.

Sunrise

2020-10-01, 14:48:14

Wie sicher sind eigentlich die 16GB bei N21? Ist das 100% bestätigt?
Kannst du zu 99,99999% als bestätigt ansehen:

1) AMD wird keine (Halo)-GPU bringen, die weniger VRAM als die Vega20/Radeon VII unterstützt
2) Mehrere “bekannte” Leaker sprechen inzwischen davon (und ich rede nicht von irgendwelchen Youtube-“meine Quellen sagen, dass”-Blendern)
3) Bei N22 wird von max. 12GB VRAM ausgegangen, warum sollte also N21 weniger haben?

Es gibt zuviele Anzeichen...

Cyberfries

2020-10-01, 14:49:08

Wie sicher sind eigentlich die 16GB bei N21? Wenn ich mir das Diagramm der XBSX so ansehe wären auch 320Bit GDDR6 mit den 16Bit Memory-Controllern denkbar.

Die xBox hat 20tccs, also vrmtl. auch 20MC.
Zu den 16GB:
31.Juli wjm47196: 16G again. The news I just got, AMD really never stingy on video memory.
5.August wjm47196: zwei Versionen von "Navi 21", mit 12 & 16 GB Grafikkartenspeicher.
9.Sept: Das Eng.Sample mit 16GB
17.Sept: _rogame: I've now got confirmation for both:
> Navi21 16GB VRAM
> Navi22 12GB VRAM

gbm31

2020-10-01, 14:51:19

Wie wird Navi Nvidias RTX Unterstützen, ist das was bekannt?

RTX ist Nvidia proprieitär und wird von AMD wohl nicht unterstützt werden, allerdings werden DX12 RT Titel auf beiden laufen

https://de.wikipedia.org/wiki/DirectX_Raytracing

ich denke die N21-Karte mit selber Performance wie 3080 10GB bei 250W GPU/MEM (wie VII) und 16GB whatever-Speicher wird meine VII beerben für 8-900€.

Und ich fürchte die muss ich genauso wie meine VII umbauen um sie leise zu bekommen...

Eine 3080 20GB wäre auch sinnvoll, aber Geld an Jensen? Nä!

gedi

2020-10-01, 14:56:24

Die xBox hat 20tccs, also vrmtl. auch 20MC.
Zu den 16GB:
31.Juli wjm47196: 16G again. The news I just got, AMD really never stingy on video memory.
5.August wjm47196: zwei Versionen von "Navi 21", mit 12 & 16 GB Grafikkartenspeicher.
9.Sept: Das Eng.Sample mit 16GB
17.Sept: _rogame: I've now got confirmation for both:
> Navi21 16GB VRAM
> Navi22 12GB VRAM

Bisher war es aber auch so, dass die XBOX GPU nie ein größeres SI hatte, als das Premium-Produkt. Zudem braucht die GPU für RT ne anständige Bandbreite.

dargo

2020-10-01, 15:05:43

Bisher war es aber auch so, dass die XBOX GPU nie ein größeres SI hatte, als das Premium-Produkt. Zudem braucht die GPU für RT ne anständige Bandbreite.
Eben das macht mich so extrem stutzig. Eine "poppelige" Konsole mit 52 CUs und 12 RDNA2 TFLOPs hängt an 320Bit und ein 80CUs Desktop-RDNA2 mit 20+ TFLOPs soll nur an 256Bit hängen? :freak: Besonders bei der Konsole muss man auf Kostenoptimierung noch stärker achten.

why_me

2020-10-01, 15:09:38

Hängt ja noch mehr bei der Xbox am Speicher z.B. CPU, 3D Audio,... Auch scheint die Xbox diesen Cache nicht zu besitzen, sonst hätten wir denke ich davon gehört, oder?

dargo

2020-10-01, 15:17:06

Hängt ja noch mehr bei der Xbox am Speicher z.B. CPU, 3D Audio,... Auch scheint die Xbox diesen Cache nicht zu besitzen, sonst hätten wir denke ich davon gehört, oder?
CPU braucht wenig Bandbreite. 3D Audio braucht Bandbreite? Da bin ich überfragt. Und der Cache ist auch nur reine, "wilde" Speku aktuell.

Smee

2020-10-01, 15:17:30

Eine 3080 20GB wäre auch sinnvoll, aber Geld an Jensen? Nä!

Nicht das er nachher seine Lederjacken aus Menschenhaut fertigen lässt, da du im die € vorenthälst:freak:

Spaß bei Seite:
Ich bin immernoch mit meiner 5700XT voll zufrieden.
Zocke aber auch nur in 1080p^^
Mal sehen was da von AMD kommt.

Complicated

2020-10-01, 15:21:27

Die Xbox hat doch ein völlig anderes Speicher_Design:
Der Speicher in der Xbox Series X ist in vielerlei Hinsicht außergewöhnlich. Microsoft verbaut 16 GByte GDDR6 in einer asynchronen Bestückung an 320 Datenleitungen: 6 × 2 GByte und 4 × 1 GByte. 10 GByte erreichen eine Übertragungsrate von 560 GByte/s und 4 GByte müssen sich mit 336 GByte/s begnügen. Die im Vorfeld gemunkelten 20 GByte RAM ließen sich an 320 Bit zwar realisieren, wären aber auch teurer. Spielen stehen insgesamt 13,5 GByte RAM zur Verfügung, 10 GByte davon als Grafikspeicher, 3,5 GByte als System-RAM. Das Betriebssystem der Xbox Series X reserviert sich 2,5 GByte.

prinz_valium_2

2020-10-01, 15:24:03

Anstatt ein 60mm² cache einzubauen, könnte man auch gleich von 256 auf 512 bit gehen.

dargo

2020-10-01, 15:27:14

Die Xbox hat doch ein völlig anderes Speicher_Design:
Stimmt... die GPU hat somit die volle Bandbreite von 560GB/s zur Verfügung.

Spaß bei Seite:
Ich bin immernoch mit meiner 5700XT voll zufrieden.
Zocke aber auch nur in 1080p^^
Mal sehen was da von AMD kommt.
Hehe... ich spiele in 1440p und bin noch voll zufrieden. :) Deshalb warte ich auch völlig entspannt den Release ab. In 1080p brauchst du dir überhaupt keine Gedanken machen über RDNA 2. Für dich wird dann eher RDNA 3 erst interessant. :tongue:

why_me

2020-10-01, 15:35:55

Anstatt ein 60mm² cache einzubauen, könnte man auch gleich von 256 auf 512 bit gehen.

Das ist kurzfristig gedacht sicher richtig, aber langfristig will AMD zu Stacking
und Chiplets gehen und je mehr externe Bandbreite man hier sparen kann, desto kleiner fallen die Interconnects aus.
Mal 2 Beispiele:
1. Wenn man den I/O DIE in 12nm stacked mit einem Compute die, dann ist der Cache "umsonst", da der IO Die mindestens gleich groß wie der Compute DIE sein muss und man ihn gut in der Fläche des IO DIEs unterbringen kann.
2. Wenn ein 40 CU Chiplet mit Cache 120mm² statt 90mm² groß ist, dafür aber "nur" 200GB/s anstatt 400GB/s Bandbreite benötigt, dann spart man Energie, die man in Performance umsetzen kann.

Stimmt... die GPU hat somit die volle Bandbreite von 560GB/s zur Verfügung.

Nur solange die CPU nicht auf ihren Speicher zugreift, dann muss die GPU warten. Die effektive Bandbreite sollte mMn. ein gutes stück niedriger liegen.

Cyberfries

2020-10-01, 15:52:17

da der IO Die mindestens gleich groß wie der Compute DIE sein muss

Sicher?
Müssten nicht auch andere Varianten oder gar nur eine teilweise Überlappung möglich sein?
Intel zeigt z.B. diese Folie (https://www.hardwareluxx.ru/images/cdn01/92E9FBBE70F745E08512656D08C308E1/img/5BC79BF1ECC0402E9B7BE808E5E68E2D/Intel-ArchitectureDay2018-Foveros-01_5BC79BF1ECC0402E9B7BE808E5E68E2D.jpg) mit klarer Überlappung.
Und im Notfall drehe ich das Ding halt um.

why_me

2020-10-01, 15:56:41

Gute Frage, wie ist die Verbindung zum Speicher da gelöst?
Der I/O Die ist da auch größer :P

dargo

2020-10-01, 15:58:44

Das ist kurzfristig gedacht sicher richtig, aber langfristig will AMD zu Stacking
und Chiplets gehen und je mehr externe Bandbreite man hier sparen kann, desto kleiner fallen die Interconnects aus.
Mal 2 Beispiele:
1. Wenn man den I/O DIE in 12nm stacked mit einem Compute die, dann ist der Cache "umsonst", da der IO Die mindestens gleich groß wie der Compute DIE sein muss und man ihn gut in der Fläche des IO DIEs unterbringen kann.
2. Wenn ein 40 CU Chiplet mit Cache 120mm² statt 90mm² groß ist, dafür aber "nur" 200GB/s anstatt 400GB/s Bandbreite benötigt, dann spart man Energie, die man in Performance umsetzen kann.

Ein guter Punkt! RDNA 2 praktisch die Vorstufe zum RDNA 3? :uponder:

why_me

2020-10-01, 16:11:40

Komisch, dass man das extra erwähnen muss, obwohl hier alle paar Seiten RDNA mit der Zen Evolution verglichen wird ;)

davidzo

2020-10-01, 16:12:15

Bei HPC steht und fällt es mit der Infrastruktur. D.h. Software als auch Systemdesign. Das braucht halt etwas länger, wenn man vorher noch nicht viel hatte.

Software Verzögerungen, dran dachte ich auch zuerst. Aber Arctuturs ist ja eben nichts was neue Software braucht, sondern praktisch eine verdoppelte Vega20, soviel wissen wir ja schon. Insofern hat man schon eine Solide Softwarebasis an der man 2 Jahre lang herumschrauben konnte. Treiber- und Firmwaredaten zu Arcturus /CDNA geistern zudem schon sehr lage herum, viel länger als die Treiber zu RDNA2. Daher halte ich das Softwareökosystem als Grund für die Verzögerung für äußerst unwahrscheinlich.

Anstatt ein 60mm² cache einzubauen, könnte man auch gleich von 256 auf 512 bit gehen.
Nicht wirklich. Bei den heutigen Ansprüchen an die Signalqualität für hochtaktenden GDDR6 und hochfrequenztaugliche, effiziente und kompakte VRMs, ist 512bit mit einer normalen Platine wohl nicht mehr möglich, siehe den aufwand für 384bit bei der 2080ti und 3090.
niedrig taktender GDDR5 in 2013 ist etwas anderes...

gedi

2020-10-01, 17:40:44

Bei einem 512-Bit SI brauche ich keinen wahnsinnig hochgezüchteten VRAM. Da reichen die 16GPS locker!

Und vielleicht hat die Platine ja ebenfalls annähernd 12 Layer, dann ist jedes Szenario möglich.

dargo

2020-10-01, 17:57:28

Bei einem 512-Bit SI brauche ich keinen wahnsinnig hochgezüchteten VRAM. Da reichen die 16GPS locker!

Öhm... der effektive Takt bei Hawaii mit GDDR5 lag bei 5.000Mhz, bei Grenada dann bei 6.000Mhz. Der effektive Takt von 16Gbps GDDR6 beträgt 16.000Mhz.

gedi

2020-10-01, 18:15:14

Öhm... der effektive Takt bei Hawaii mit GDDR5 lag bei 5.000Mhz, bei Grenada dann bei 6.000Mhz. Der effektive Takt von 16Gbps GDDR6 beträgt 16.000Mhz.

Eben!

Lass uns doch mal Spekulieren ausgehend von einem 512-Bit SI:

6900 XTX 32GB (16x2GB) -> 3090
6900 XT 16GB (16x1GB) = 3090
6900 LE 16GB (16x1GB) = 3080-3090
6800 XT 12GB-24GB (12x1GB) = 3080 (64 oder 68 CUs bei 384-Bit)
6800 LE 10-20GB 14 GPS gegen 3070 Ti 320-Bit
.
.
.

Und wenn man sich die Backplate anschaut, dann wäre es doch möglich, dass da Pads zur Kühlung des Vrams verbaut sind.

Und der Prosumer bekommt halt die XTX@HBM aufgedrückt.

Für mich wäre letztere Variante the way to go, da ich ziemlich viel mit Solid Works, Opus usw. geschäftlich zu tun habe. Und wenn die Treiber bez. dem Vega-Ansatz nicht so beschissen sind, dann ist dies meine nächste Karte. In der Simulation taugen nämlich weder Turing noch RDNA1 was!

Wenn es viel zu optimistisch ist, dann sagt was. Ich programmiere bloß, von der Hardware für sich habe ich keine Ahnung. Ich reime mir da nur etwas zusammen, was Sinn ergeben könnte. Wenn etwas per se ausgeschlossen werden kann, sorry

Gipsel

2020-10-01, 21:25:34

Der Reddit-Treiber leak legt nahe dass N21 in der Tat nur 4RBs pro SE hat, mit einem Takt von 4 macht das 4x4x4 = 64 ROPS...
Berniyh hatte mich in einem anderen Thread schon darauf hingewiesen, weil ich auch dachte dass es eigentlich nicht sein kann dass N21 nur 64 ROPs hat.Bei RDNA1 sind die RBEs genau wie die Rasterizer und L1 and die Shader-Arrays gekoppelt, nicht die Shaderengines. Wenn es genau so bleibt wie bisher, hat jedes Shaderarray einen Rasterizer (maximal 16 Pixel/Takt) und 4 RBEs (16 ROPs, also auch 16 Pixel pro Takt). Bei 4 Shaderengines zu je 2 Shaderarrays macht das 8 Rasterizer und 32 RBEs (128 ROPs).

Armaq

2020-10-01, 21:30:36

Eben!

Lass uns doch mal Spekulieren ausgehend von einem 512-Bit SI:

6900 XTX 32GB (16x2GB) -> 3090
6900 XT 16GB (16x1GB) = 3090
6900 LE 16GB (16x1GB) = 3080-3090
6800 XT 12GB-24GB (12x1GB) = 3080 (64 oder 68 CUs bei 384-Bit)
6800 LE 10-20GB 14 GPS gegen 3070 Ti 320-Bit
.
.
.

Und wenn man sich die Backplate anschaut, dann wäre es doch möglich, dass da Pads zur Kühlung des Vrams verbaut sind.

Und der Prosumer bekommt halt die XTX@HBM aufgedrückt.

Für mich wäre letztere Variante the way to go, da ich ziemlich viel mit Solid Works, Opus usw. geschäftlich zu tun habe. Und wenn die Treiber bez. dem Vega-Ansatz nicht so beschissen sind, dann ist dies meine nächste Karte. In der Simulation taugen nämlich weder Turing noch RDNA1 was!

Wenn es viel zu optimistisch ist, dann sagt was. Ich programmiere bloß, von der Hardware für sich habe ich keine Ahnung. Ich reime mir da nur etwas zusammen, was Sinn ergeben könnte. Wenn etwas per se ausgeschlossen werden kann, sorry
Was ich in Relation dazu interessant finde sind die Preise von nvidia.

Sie haben ihre eigenen Preise "unterboten" (Straßenpreise sind ja gleich). Warum sollte man das tun? Das geht nur, wenn man von etwas mehr Bums bei AMD ausgeht, ansonsten wären die Karten in jedem Fall nicht für den MSRP erschienen.

Wenn AMD die Eier hat (und das trau ich Lisa ja zu), dann könnte AMD auch mal all-in gegangen sein. Sie hatten ja Zeit sich den Markt anzuschauen. Warum nicht 512 Bit SI, andere Speicherkopplung a la Xbox ggf. sogar HBM und DDR.

Man darf nicht vergessen das AMD hier häufig sehr experimentierfreudig war mit neuen Prozessen/Technologien in der Fertigung.

Iscaran

2020-10-01, 22:04:23

Bei RDNA1 sind die RBEs genau wie die Rasterizer und L1 and die Shader-Arrays gekoppelt, nicht die Shaderengines. Wenn es genau so bleibt wie bisher, hat jedes Shaderarray einen Rasterizer (maximal 16 Pixel/Takt) und 4 RBEs (16 ROPs, also auch 16 Pixel pro Takt). Bei 4 Shaderengines zu je 2 Shaderarrays macht das 8 Rasterizer und 32 RBEs (128 ROPs).

Ja bei RDNA1 schon.

Aber der REDDIT Treibereintrag lässt vermuten dass man die Zahl tatsächlich halbiert hat.
https://old.reddit.com/r/Amd/comments/j06xcd/number_of_cus_of_navi_23_navi_31_van_gogh_cezanne/
Property Navi 10 Navi 14 Navi 12 Navi 21 Lite Navi 21 Navi 22 Navi 23 Navi 31
num_rb_per_se 8 8 8 4 4 4 4 4

Und der Reddit eintrag ist seit langem das "handfesteste" über das spekuliert wird, zumal er ja auch direkt die Hinweise auf die 256 Bit SI gibt und die Hinweise auf >2GHz Takt.
Navi 21 Lite passt eigentlich auch perfekt auf den XBox-Chip...im Treiber hat das Ding 320bit SI, 56 CUs usw. passt eigentlich alles.

Genau deswegen habe ich die Vermutung dass es nicht so bleibt wie bisher mit den ROPs.

Am ehesten könnte sein, daß man gemerkt hat dass man gar nicht soviele ROPs braucht bei dem hohen Takt, und weil ja auch nicht mehr alles via Rasterizing läuft (?).

Abgesehen davon, fand ich die Idee mit dem via HBM "simulierten" GDDR-Interface bisher am interessantesten.
Wenn das ginge und genauso performant bliebe - wäre das ein einfacher Weg hier die passende "Bandbreite" hinzuklatschen. GDDR6 für die "billigen", kleineren Chips und HBM2 für den großen.

HBM2e glaub ich jetzt noch nicht, das das käme, aber AMD ist ja immer für ne Überraschung als Early Adopter gut in diesen Dingen.

Mit 2048 bit HBM wären also "virtuelle" 256Bit GDDR6 am selben Interface möglich ?
Damit entfiele ja auch der "Zwang" irgendwie beide Arten von SI einzubauen bzw. unterschiedliche Produkte zu designen.

Für den Treiber könnte das dann tatsächlich wie ein 256 bit SI aussehen, bzw. ist es eben aus "kompatibiltätsgründen" so gestrickt.
TATSÄCHLICH aber würde man 2 stacks HBM zu je 1024 verbauen mit 2x8 GB chips = 16GB. Passt und für 80 CU ist da genug Bandbreite mit zu erschlagen.
Und preislich sollte das gehen mit einer GPU >700€ ?

Gipsel

2020-10-01, 22:17:58

Ja bei RDNA1 schon.

Aber der REDDIT Treibereintrag lässt vermuten dass man die Zahl tatsächlich halbiert hat.
https://old.reddit.com/r/Amd/comments/j06xcd/number_of_cus_of_navi_23_navi_31_van_gogh_cezanne/Ich kenne die Tabelle. Die ist bei Navi1x schon irreführend, weil sie die RBEs den Shaderengines zuordnet (was wie gesagt nicht stimmt, Navi1x hat 4 RBEs pro Array und nicht 8 pro Engine). Für Navi2x wird das vermutlich die Angabe pro Array sein (was mit einiger Wahrscheinlichkeit der Gliederung der Hardware entspricht, denn auch bei Navi1 ist das so organisiert). In der falsch bezeichneten Zeile wurden vermutlich einfach verschieden gezählte Werte zusammengeworfen. Das gab es früher auch schon mal bei solchen Treibereinträgen. ;)

Oder mit anderen Worten: Ich würde mich nicht krampfhaft an den Werten aufhängen.

Iscaran

2020-10-01, 22:24:38

Ich kenne die Tabelle. Die ist bei Navi1x schon irreführend, weil sie die RBEs den Shaderengines zuordnet (was wie gesagt nicht stimmt, Navi1x hat 4 RBEs pro Array und nicht 8 pro Engine).

Das deckt sich aber nicht mit dem RDNA1 Whitepaper von AMD - denn dort bestehen die Engines aus je 2 Arrays. So gesehen stimmt der Eintrag mit 8 RBs pro Engine durchaus, auch wenn die Aufteilung auf 4RBs pro Array runterbricht.
https://www.amd.com/system/files/documents/rdna-whitepaper.pdf
(EDIT: Die Beschreibung des Kernstücks des ganzen des "Shader Arrays" findet sich ca auf Seite 8)
"As Figure 4 illustrates the Radeon RX 5700 XT includes four shader arrays, each one including a primitive unit, a rasterizer, four RBs, five dual compute units, and a graphics L1 cache." /EDIT

Der Eintrag bei Reddit ist insofern "korrekt" da er den RDNA1 Aufbau sehr wohl widergibt.
Die Zeile num_sh_per_se zeigt die Anzahl der Shader Arrays (SH) pro Shader Engine (SE) (bestehend aus 2 shader arrays) an.
Und die Werte passen für Navi10, 12, 14 und Navi 21 Lite (sofern dies der XBox-GPU Teil ist).

Gipsel

2020-10-01, 22:28:59

Das deckt sich aber nicht mit dem RDNA1 Whitepaper von AMD - denn dort bestehen die Engines aus je 2 Arrays. So gesehen stimmt der Eintrag mit 8 RBs pro Engine durchaus, auch wenn die Aufteilung auf 4RBs pro Array runterbricht.
https://www.amd.com/system/files/documents/rdna-whitepaper.pdf
(EDIT: Die Beschreibung des Kernstücks des ganzen des "Shader Arrays" findet sich ca auf Seite 8)

Der Eintrag bei Reddit ist insofern "korrekt" da er den RDNA1 Aufbau sehr wohl widergibt.
Die Zeile num_sh_per_se zeigt die Anzahl der Shader Arrays (SH) pro Shader Engine (SE) (bestehend aus 2 shader arrays) an.
Und die Werte passen für Navi10, 12, 14 und Navi 21 Lite (sofern dies der XBox-GPU Teil ist).
Wenn Du das Whitepaper schon aufhast, dann schau Dir auch mal die Grafik (Abbildung 4 auf Seite 6) dazu an! 2 Shaderengines zu je zwei Arrays. Jedes Array hat seinen eigenen Rasterizer, L1 und RBEs. Der Text ist nur an ein paar Stellen ungenau und nennt die Arrays manchmal (nicht immer) Engines. Es gibt bei RDNA1 4 RBEs pro Array, nicht 8 pro Engine. Auch (bzw. vor Allem) laut Whitepaper:
The two shader engines house all the programmable compute resources and some of the dedicated graphics hardware. Each of the two shader engines include two shader arrays, which comprise of the new dual compute units, a shared graphics L1 cache, a primitive unit, a rasterizer, and four render backends (RBs).
For scalability and performance, the RDNA architecture is built from multiple independent arrays that comprise fixed-function hardware and the programmable dual compute units. To scale performance from the low-end to the high-end, different GPUs can increase the number of shader arrays and also alter the balance of resources within each shader array. As Figure 4 illustrates the Radeon RX 5700 XT includes four shader arrays, each one including a primitive unit, a rasterizer, four RBs, five dual compute units, and a graphics L1 cache.

Der Punkt war, daß die Tabelle nicht die eigentliche Gliederung der Hardware von RDNA-GPUs wiedergibt. Es ist halbwegs wahrscheinich, daß die RDNA2-Einträge dies tun, nur dann in einer falsch bezeichneten Zeile stehen. ;)

Iscaran

2020-10-01, 22:34:24

Jedes Array hat seinen eigenen Rasterizer, L1 und RBEs. Der Text ist nur an ein paar Stellen ungenau und nennt die Arrays manchmal (nicht immer) Engines. Es gibt bei RDNA1 4 RBEs pro Array, nicht 8 pro Engine. Auch (bzw. vor Allem) laut Whitepaper:

Ja, aber genau das gibt doch der Reddit eintrag GENAU so wieder ?

Num_SH = shader arrays

Die RBs werden halt zusammen notiert.

Ich denke nicht das das Whitepaper hier fehlerhaft mal so mal so bezeichnet....das ist schon genau so gewählt wie es sein soll.

Gipsel

2020-10-01, 22:43:37

Ja, aber genau das gibt doch der Reddit eintrag GENAU so wieder ?

Num_SH = shader arrays

Die RBs werden halt zusammen notiert.Und das entspricht eben nicht der eigentlichen Organisation der Hardware! Die Angaben für RDNA2 tun dies aber mit einiger Wahrscheinlichkeit. Die Zeile ist also für sie falsch bezeichnet. Wäre zumindest meine Occams Razor Schlußfolgerung.
Alternative für recht kleine Arrays wären eventuell 2 RBEs pro Array und Rasterizer, die maximal 8 Pixel pro Takt ausspucken. Die hat AMD ja auch im Angebot (normalerweise bei kleinen Karten oder APUs). Aber keine Ahnung, ob man sich das beim Topmodell für 4K antun will. :rolleyes:
Ich denke nicht das das Whitepaper hier fehlerhaft mal so mal so bezeichnet....das ist schon genau so gewählt wie es sein soll.Du hast vermutlich nie versucht, mit den Dokus von AMD zu arbeiten. Solche Copy&Paste-Fehler sind dort sehr üblich. In den ISA-Dokus zu GCN haben noch mehrere Jahre lang einige (dann natürlich falsche) Absätze (und z.T. sogar Abbildungen) aus den VLIW-Dokus überlebt. :lol:

Iscaran

2020-10-01, 23:01:59

Und das entspricht eben nicht der eigentlichen Organisation der Hardware! Die Angaben für RDNA2 tun dies aber mit einiger Wahrscheinlichkeit. Die Zeile ist also für sie falsch bezeichnet. Wäre zumindest meine Occams Razor Schlußfolgerung.

Wieso soll das nicht der Organisation entsprechen ? Es passt doch alles in Figure 4 des Whitpaper findet sich im Reddit eintrag 1:1 wieder.

Die Rasterizer sind zwar jeweils den Arrays zugeordnet - aber es könnte natürlich sein, dass die dafür erforderliche "kontroll-Logik" eben nur jeweils 1x in jeder Engine vorkommt ?

Alternative für recht kleine Arrays wären eventuell 2 RBEs pro Array und Rasterizer, die maximal 8 Pixel pro Takt ausspucken. Die hat AMD ja auch im Angebot (normalerweise bei kleinen Karten oder APUs).

EDIT: ach ne habs falsch verstanden...habs erst so verstanden, dass AMD RBs hat die anstelle von 4 Pixel pro Takt 8 ausspucken aber in deinem Beispiel sind es ja einfach doppelt so viele RBs pro Array /EDIT:

DAS wusste ich nicht, dachte bisher ALLE RBs von AMD spucken genau 4 Pixel pro Takt aus...

Wenn Sie das natürlich für RDNA2 geändert haben wäre der Effekt dergleiche nämlich 4x4x8 = 128 ROPs

Btw. sprach nicht Lisa (oder wars der Papermaster ?) irgendwann mal davon dass man für die neuen RDNAs VIEL von der im Frühjahr vorgestellten optimierung für die APUs/Mobile Chips gelernt hat ?

Vielleicht ein Anspielung darauf dass man die RBs aus den kleinen Einheiten nun in die großen Chips packt.

Gipsel

2020-10-01, 23:22:36

Wieso soll das nicht der Organisation entsprechen ? Es passt doch alles in Figure 4 des Whitpaper findet sich im Reddit eintrag 1:1 wieder.Was nicht paßt, ist die in der Tabelle implizierte Struktur dieser Organisation. RBEs gibt es pro Array und nicht pro Engine.
Die Rasterizer sind zwar jeweils den Arrays zugeordnetDie RBEs auch.

Am Ende werden wir sehen, wie es wird. Nochmal: Mein Punkt war eigentlich nur, daß man sich nicht krampfhaft auf die Werte in dieser Tabelle versteifen sollte, wenn es auch alternative und durchaus plausible Erklärungen dafür gibt.

EDIT: ach ne habs falsch verstanden...habs erst so verstanden, dass AMD RBs hat die anstelle von 4 Pixel pro Takt 8 ausspucken aber in deinem Beispiel sind es ja einfach doppelt so viele RBs pro Array /EDIT:Das "ausspucken" bezog sich auf die Rasterizer (die "normalen" machen maximal 16 Pixel/Takt) ;). Aber die Kapazität von Raster und ROPs wäre dann gleich.