Diskussion zu: Hardware- und Nachrichten-Links des 14./15. August 2021

[Leonidas]

Link zur News:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-1415-august-2021

[Gast]

Wieso muss Navi 31 eigentlich 2 GCD haben, die 50% größer sind als die GCD von Navi 32?Wieso nicht 3 GCD mit der selben Größe? Das MCD müsste dann halt ein Interface mehr haben, aber eigentlich wäre das der logische Ansatz:
GCD über alle Karten gleich halten und nur das MCD anpassen (InfinityCache größe und Speicherkanäle).
Teildefekte MCDs kommen dann bei der nächst kleineren Grafikkarten Baureihe zum Einsatz (7800 -> 7700) und teildefekte GCDs beim nächst kleineren Modell der selben Baureihe (7800XT->7800).
Mit dem hier angedachten Portfolio (unterschiedlich große GCD) würde man ja irgendwie die Vorteile von Chiplets nicht nutzen, hätte aber natürlich deren Nachteile. Daher finde ich das nicht wirklich einleuchtend.

[Complicated]

Allerdings kann man aufgrund des Fehlens von Navi 32 durchaus die Vermutung aufstellen, dass Navi 32 terminlich seitens AMD etwas später angesetzt ist, Navi 31 & 33 hingegen grob im selben Zeitrahmen erscheinen dürften. Dies passt dazu, dass zu Navi 31 & 33 zumindest grobe Terminpläne für deren Tape-Out vorliegen, zu Navi 32 hingegen noch nichts bekannt wurde.
Für mich ist der spätere Launch von Navi32 ein Hinweis, dass möglicherweise Teildefekte/-deaktivierte GCDs zum Einsatz kommen und diese zunächst mal gesammelt werden um sich das anzuschauen.

[Gast]

Für mich ist der spätere Launch von Navi32 ein Hinweis, dass möglicherweise Teildefekte/-deaktivierte GCDs zum Einsatz kommen und diese zunächst mal gesammelt werden um sich das anzuschauen.
Wären da 33% deaktiviert nicht etwas viel? Oder rechnet AMD mit so schlechter Ausbeute?

[basix]

Eher nicht wird man N31 so zurückstutzen. Wieso auch? Von N31 wird es auch Salvage SKUs geben. Würde man N31 auf N32 salvagen, würde man fast 1/3 des Chips deaktivieren. Das ist deutlich mehr als bei einer 6800 oder 3080 (beides <20% auf den gesamten Chip gesehen). N31 GCDs sollen irgendwo zwischen 300...340mm2 landen. Das ist relativ klein, N5P soll sehr gute Defect Density haben und man kan bei den WGPs leicht ein paar abknipsen um den Yield zu erhöhen. Z.B. 28 WGPs anstatt 30 WGPs. Oder nach heutigem Sprech 112 CU anstatt 120 CU.

Es ist eher so, dass man N32 recht kurzfristig auflegen wird und somit die Learnings von N31 einfliessen lassen kann. MCDs, Fertigungstechnologie (Stacking), Treiber, Firmware usw. sind zum Grossteil gleich. Anhand N31 kann man noch was lernen/verbessern. Dass N32 später kommt, ist einfach Risikominimierung (höhere Stückzahlen, kostensensitiver).

[Leonidas]

Interessanter Ansatz @ basix.

Generell wäre zu beachten, das Salvage-Lösungen noch nie ganz eigene Chip-Codenamen bekommen haben. Das ist nicht gänzlich unmöglich, wäre aber in jedem Fall eine Premiere.

[basix]

Wäre ja dämlich, wenn man wegen einem MCD Respin oder Stacking-Problemen das GCD ebenfalls anpassen müsste oder whatever. Und man das nach N31 dann bei N32 wiederholen müsste, weil man N32 schon in der Fab hat. Lieber bei N31 alles austüfteln und feinschleifen und bei N32 first time right.

[Gast Ritis]

Für mich ist der spätere Launch von Navi32 ein Hinweis, dass möglicherweise Teildefekte/-deaktivierte GCDs zum Einsatz kommen und diese zunächst mal gesammelt werden um sich das anzuschauen.

Das dachte ich spontan auch, aber dafür gibt man nicht einen Code-Namen für den Chip-SKU, aka Navi32, sondern nur fürs Endprodukt.
Von daher wird Navi32 schon ein separater Chip. Bei Navi24 hat man jetzt auch nicht sehr viel weniger CUs, mit kleinerem im Cache und SI loht sich schon das zusätzliche Chip Design.


Zum Thema Mining fehlt mir noch ein Kommentar zu neuer Dual Polaris als Minig-Karte von Sapphire.
Ich denke das ist glaubwürdig und nicht nur ein altes Engineering-Sample PCB.
https://wccftech.com/sapphire-radeon-rx-570-duo-dual-amd-polaris-mining-graphics-card-pictured/

[Leonidas]

Hatte ich schon verlinkt. Wüsste nicht, was ich da kommentieren kann. Es wird halt explizit für Miner aufgelegt und verkauft. Besser als wenn jene RDNA2-Karten nutzen.

[Complicated]

Das dachte ich spontan auch, aber dafür gibt man nicht einen Code-Namen für den Chip-SKU, aka Navi32, sondern nur fürs Endprodukt.
Die Chip SKUs mit Multichips hatten immer einen eigenen Codenamen, z.B. auch bei Dual-GPUs. Siehe Evergreen-Serie mit der HD5970 die 2xCypress verbaut hatte und "Hemlock" hies: https://de.wikipedia.org/wiki/ATI-Radeon-HD-5000-Serie#Namensgebung
Das selbe:
HD 6990 2xCaymann -> Antilles
HD 7990 2xTahiti -> Malta

Also wurde da immer noch ein zusätzlicher Codenamen für den Multichip verwendet. Das hörte allerdings mit Vega dann auf und wurde bei Polaris Dual-GPUs auch nicht weiter geführt. Es könnte aber bei den Anpassungen am MCD wieder Sinn machen, wenn die GCPs unverändert bleiben, wie das bei den Navi31-33 sein könnte.

[iamthebear]

1.) Also dass Navi32 nur aus teildefekten Navi31 Chips aufgebaut wird würde ich einmal ausschließen. Wenn man 33% deaktiviert ist man lediglich beim Navi32 Topmodell. Man muss ja auch die Lücke zwischen Navi33 und 32 irgendwie schließen.

Wenn man das auf die aktuelle Generation umlegt und von einer Verdopplung der Performance ausgeht:
Navi33 ist die 7700 XT mit 5K FP32
Navi32 ist die 7900 XT mit 10K FP32, teildefekte Chips werden 7800 XT (9K FP32) und 7800 (7.5 FP32)
Navi 31 ist eine neue Sonderedition mit 15K FP32, teildefekte Chips könnten dann z.B. 12K FP32 haben.

2.) Die Idee, dass Navi32 später launched halte ich für extrem seltsam.
.) Wenn Navi33 später launched macht das Sinn. Dann liefert man eben weiter Navi21 Chips aus. Bis auf einen kleinen Shrink von 7nm auf 6nm ist da sowieso nicht viel Unterschied.
.) Wenn Navi31 später launched, dann macht das auch Sinn. Dann holt man sich mit Navi32 erst einmal die Performancekrone und setzt nach Lovelace noch einmal einen drauf und schiebt alle Preise um eine Stufe nach unten. Das ist in etwa das, was Nvidia mit der 1080 und später mit der 1080 Ti gemacht hat.
.) Aber welchen Sinn macht es Navi33 um die 500-700 Euro zu bringen und dann eine Ultra High End Karte über 2K mit der 3 fachen Rohleistung mit nichts dazwischen.

Also ich sehe derzeit nur 2 plausible Erklärungen:
1.) Man sieht Navi32 nur als cut down Navi31 und geht davon aus, dass alles. was bei Navi31 funktioniert auch 1:1 bei Navi32 so umsetzbar ist.
2.) Es gibt gar keinen Navi32 und die 4 Shader Engines waren eine Fehlinformation. Navi32 besteht dann einfach aus 1Navi31 GCD und weniger MCDs. Das würde insofern Sinn machen als dass die Navi 31 GCDs dann auch wirklich real zum Einsatz kommen weil recht viel mehr als ein paar Review Samples und einige Karten für Leute ohne Geldsorgen wird von Navi31 kolaum produziert werden. Ich denke nicht. dass wir hier die Preise unter 2K liegen werden.

[Leonidas]

Navi 32 hat in jedem Fall noch das Potential, zu überraschen - im Sinne dass die jetzt gehandelten Specs zu N32 falsch sind.

[Gast]

Navi 32 könnte einfach 2x Navi 33 + MCD sein.

Mit je 128MB IC in den GCDs + 128MB im MCD würde das perfekt passen.

Lediglich die 192bit Interface zum RAM passen nicht, die müssten eigentlich physikalisch 256bit sein, aber man könnte dieses natürlich teildeaktivieren.

[Gast]

Navi 32 könnte einfach 2x Navi 33 + MCD sein.

Mit je 128MB IC in den GCDs + 128MB im MCD würde das perfekt passen.
Das wäre für mich aber unlogisch: Zur Kommunikation zwischen GCD und MCD braucht man ein Interface. Bei einem Monolithen braucht man das allerdings nicht (kostet sinnlos Platz). Also würde man Navi33 etwas einbauen, was die Kosten bei einem sowieso kostensensiblen Chip unnötig steigert. Und das MCD wäre dann nur einfach ein 128MB Cache? Für Navi31 braucht man den Chip dann auch neu? Das sind alles viel zu viel sinnlose Kosten. Ziel muss doch sein, möglichst viel wieder verwenden zu können. Wie bei den CPUs auch. Sonst macht Chiplet keinen Sinn.

Für mich würde es am meisten Sinn ergeben, wenn im MCD der IC und das SI sowie z.B. die Video Einheit (En-/Decoder) und andere SFUs integriert ist (könnte man aber auch in einen separaten Chip auslagern, der wird dann halt sehr klein).
Über ein Interface sind dann die GCDs mit Shadern und evt. weiterer Cache Stufe (zum Abfedern des Interfaces) angebunden. Ziel müsste dann sein, die GCDs über alle Segmente gleich zu halten und nur die Anzahl der GCDs zu erhöhen. Das MCD ist dann für jedes Segment separat und bietet damit eine unterschiedliche Anzahl an Speicherkanälen und an InfinityCache, je nach angepeilter Leistung des Marktsegmentes.

[Complicated]

Das wäre für mich aber unlogisch: Zur Kommunikation zwischen GCD und MCD braucht man ein Interface. Bei einem Monolithen braucht man das allerdings nicht (kostet sinnlos Platz). Also würde man Navi33 etwas einbauen, was die Kosten bei einem sowieso kostensensiblen Chip unnötig steigert. Und das MCD wäre dann nur einfach ein 128MB Cache? Für Navi31 braucht man den Chip dann auch neu? Das sind alles viel zu viel sinnlose Kosten. Ziel muss doch sein, möglichst viel wieder verwenden zu können. Wie bei den CPUs auch. Sonst macht Chiplet keinen Sinn.
Das ist hier anders. Das Bridge-Chiplet wird noch als Wafer auf dem MCD integriert und wenn die Dies geschnitten werden sind 2 Wafer gestapelt und das Interface im Chip integriert auf den das GDC drauf gepackt wird - Siehe LSI:
https://images.anandtech.com/doci/16031/Advanced%20Packaging%20Technology%20Leadership.mkv_snapshot_11.38_%5B2020.08.25_ 14.14.11%5D.jpg

[Gast]

Das wäre für mich aber unlogisch: Zur Kommunikation zwischen GCD und MCD braucht man ein Interface. Bei einem Monolithen braucht man das allerdings nicht (kostet sinnlos Platz).


Zen 3 hat auch die Interfaces für den Stacked Cache bereits verbaut, obwohl man sie (noch) nicht benötigt.

Und wenn man wenn man den Gerüchten glauben kann, ist der MCD nicht viel anderes als zusätzlicher Cache und die GCDs selbst vollständige GPUs.

Diese "Verschwendung" dürfte deutlich weniger kosten als einen weiteren DIE zum Tapeout zu bringen.

Wenn man schon auf Multichip geht dann erscheint es extrem ineffizient, die DIEs nicht wiederzuverwenden.

[Leonidas]

Wenn man schon auf Multichip geht dann erscheint es extrem ineffizient, die DIEs nicht wiederzuverwenden.

Das denke ich mir auch. Aber noch gibt es keinen guten Hinweis darauf, ob und wie AMD dies lösen will.

[Gast]

Das ist hier anders. Das Bridge-Chiplet wird noch als Wafer auf dem MCD integriert und wenn die Dies geschnitten werden sind 2 Wafer gestapelt und das Interface im Chip integriert auf den das GDC drauf gepackt wird - Siehe LSI:
https://images.anandtech.com/doci/16031/Advanced%20Packaging%20Technology%20Leadership.mkv_snapshot_11.38_%5B2020.08.25_ 14.14.11%5D.jpg

Du sagst es werden die ganzen Wafer gestapelt und nicht die einzelnen DIEs?

Was soll das dann noch bringen? Das würde ja bedeuten, dass man immer nur 2 benachbarte DIEs zusammen verwenden kann, wodurch es dann keine Yield-Vorteile durch die einzelnen kleineren DIEs mehr geben würde, damit hat man effektiv erst wieder einen gemeinsamen großen DIE.

[Complicated]

Das gilt für den Cache und die aktive Bridge (LSI), die dann im MCD-Die integriert sind. Der GCD kommt dann oben drauf als eigener Die.
https://www.freepatentsonline.com/20210098419.pdf
https://pics.computerbase.de/9/8/0/5/6-bdd27f887373a9aa/2-1080.706b0f70.png
Zusammenfassung https://www.computerbase.de/2021-04/gpus-im-chiplet-design-amd-patente-bringen-den-cache-ins-spiel/
Neben einer sogenannten „Active Bridge“, einen aktiven Silizium-Die, der die Verbindung unter den GPU-Chiplets übernimmt, wird einmal mehr ein über alle Chiplets kohärenter L3-Cache sowie ein „Primary Chiplet“ beschrieben, wodurch Programme die GPU auch weiterhin als eine Einheit wahrnehmen.

In dem Patent „GPU Chiplets using High Bandwidth Crosslink“ aus dem Dezember 2019 wurden stattdessen noch die passiven HBX-Verbindungen in Form eines Interposers („Crosslinks“) mit sehr hoher Bandbreite beschrieben.
Der Cache wandert auf die Brücke

Die Besonderheit der „Active Bridge“ besteht darin, dass der L3-Speicher direkt auf der Brückenverbindung und nicht mehr auf dem entsprechenden GPU-Chiplet untergebracht werden soll. Das erklärt auch die aktive Auslegung der Brücke.

Zudem ist die Größe des L3-Cache damit durch die Größe der „Active Bridge“ beliebig skalierbar und ermöglicht Lösungen für Systeme respektive GPUs und Beschleunigern mit wenigen (1 bis 2) oder vielen (3 und mehr) GPU-Chiplets.

Der L3-Cache ist damit auch von der Hitzeentwicklung und dem Stromverbrauch der GPU-Chiplets entkoppelt. Ob der Cache damit tatsächlich besser gekühlt werden kann oder einfach die dezentrale Hitzeentwicklung von Vorteil ist, geht aus der Patentschrift indes nicht hervor.