PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: Navi 33 monolithisch mit 80 CU, Navi 31 im MultiChip-Design mit 160 CU


Leonidas
2021-05-04, 14:18:33
Link zur News:
https://www.3dcenter.org/news/geruechtekueche-amds-navi-33-monolithisch-mit-80-cu-navi-31-im-multichip-design-mit-160-cu

PuppetMaster
2021-05-04, 14:57:50
Könnte es auch sein, dass die MultiChip-Versionen HPC-only werden, so wie z.B. Nvidias A100?

Gast
2021-05-04, 15:18:24
Ist die Prozent-Rechnung nicht falsch?
2,5 fache Performance, d.h.
1*2*1,25 =2,5
Hieße, dass 25% aus Architekturverbesserungen kommen, nicht 50 %
(die 2 dann wegen der Verdopplung)

Mr.Smith
2021-05-04, 15:31:43
die "2" in "2,5fach" kommt aus der verdoppelten Menge an Shader-Clustern. Der Rest muß dann aber aus internen Architektur-Verbesserungen und/oder mehr Taktrate erzielt werden, wo mittels der aktuellen RDNA2-Architektur bereits ein so hohes Level erreicht wurde, dass Verbesserungen um gleich +50% eher unwahrscheinlich klingen
@Leonidas
das wären dann doch "nur" +25% und nicht +50%
2*1,25 == 2,5

und bei den 25% ist auch Takt etc. mit dabei, wie du ja schon sagst, damit klingt das realistischer.

Lehdro
2021-05-04, 16:31:18
Das MCM Design ab 80 Clustern kann auch dahingehend Sinn ergeben, dass man eben keinen 120er CU Design sinnvoll aufbauen kann, da man dann grundlegend anders Strukturieren müsste. Der nächste logische Schritt, eine Verdopplung, wäre somit 160 CUs, was damit weit oberhalb von 600mm² rauskommen würde - da lohnt dann ein Multichipdesign definitiv.
Also kann man somit die Struktur von RDNA2 beibehalten und sich auf die eigentlichen Recheneinheiten konzentrieren - womit man eben nicht den ganzen "Fütterungskram" (Verwaltungslevel oberhalb von 80 CUs) der GPU neu erstellen muss, sondern "relativ einfach" skalieren kann.

das wären dann doch "nur" +25% und nicht +50%
2*1,25 == 2,5

und bei den 25% ist auch Takt etc. mit dabei.
Korrekt. Zudem ist RDNA1 mit derselben IPC ausgestattet wie RDNA2 (https://www.computerbase.de/2021-03/amd-radeon-rdna2-rdna-gcn-ipc-cu-vergleich/#abschnitt_amd_rdna_2_vs_rdna_sind_die_cus_schneller_geworden) - also hat man quasi schon einmal die Steigerungen "ausgelassen" und sich auf Takt konzentriert. Jetzt könnte es also einen Nachschlag an IPC geben, der in etwa dem entspricht was im Laufe der Jahre möglich gewesen wäre.

Mr.Smith
2021-05-04, 16:46:25
.. Korrekt. Zudem ist RDNA1 mit derselben IPC ausgestattet wie RDNA2 (https://www.computerbase.de/2021-03/amd-radeon-rdna2-rdna-gcn-ipc-cu-vergleich/#abschnitt_amd_rdna_2_vs_rdna_sind_die_cus_schneller_geworden) - also hat man quasi schon einmal die Steigerungen "ausgelassen" und sich auf Takt konzentriert. Jetzt könnte es also einen Nachschlag an IPC geben, der in etwa dem entspricht was im Laufe der Jahre möglich gewesen wäre.

der infinity cache ist halt das große Novum dabei gewesen, zusätzlich zum massiven Taktsprung. Denk mal der Infinity-Cache wird weiter verbessert werden, und auch nochmal ein paar % mitbringen. RayTracing hingegen könnte etwas kosten, da dort sicherlich massiv aufgerüstet wird mit RDNA3.

Gast Ritis
2021-05-04, 16:47:52
Denke auch - das sind Milchmädchen Hochrechnungen für eine grobe Einschätzung.

Zwei 80er CUs machen 2.5 fache Perf. Ein 80er CU hat dann noch 1.25 fache Perf.
Letzteres wäre schon realistisch wenn es nicht IPC sondern allein Perf/Watt wäre, mehr Takt erlaubt. Die CUs werden wohl kaum neues bringen. Die RT-Einheiten doppelt so breit. Bissl mehr IF-Cache, damit es auch für 4k genügt.
Allein ein Wechsel auf Chiplet, ggf. mit Interposer-Cache ist schon ehrgeizig genug.

GPUs werden bei Design immer in theoretischer Peak Perf. verglichen, sicherlich nicht an FPS taxiert.

Am Ende muss man schauen wie viel Watt das überhaupt aufnehmen darf wenn sich der Bedarf pro CU nicht eben mal einfach so halbiert. Dann laufen die zwei Dies nicht wie heute im Spitzentakt sondern bei Max nahe am Effizienz Sweet-Spot. Da kann man dann froh sein wenn der auf 2GHz geschraubt werden kann.

Seid ihr sicher wenn jetzt schon über so Zeug zu Twitter Leaks spekuliert wird, dass RDNA3 erst in einem Jahr+ kommt?

Gast
2021-05-04, 17:13:04
Ich behaupte mal das ein Multichip Package nur dann Sinn macht wenn man es auch skaliert. Ausser man ist sich absolut unsicher das es auch performt und es ist lediglich ein Experiment. Also denke ich:

Navi 31 = 2 GPU die, 1 IO Die, 160 CU => 200% performance
Navi 33 = 1 GPU die, 1 IO Die, 80 CU => 100% performance

oder

Navi 31 = 2 GPU Die, 1 IO Die, 160 CU => 150% performance
Navi 33 = 1 GPU, 80 CU => 100% performance

Was mich aber schon wseit einiger Zeit immer mal wieder beschaeftigt ist die Frage in wie weit sich die Raytracing Logik von der klassischen GPU trennen lassen koennte. Mit Raytracing Die, Rasterizer Die und IO Die waere man sehr viel flexibler. Vor allem wenn man alle drei in je zwei Groessen zur Verfuegung hatte waere die Bandbreite moeglicher Kombinationen, auch mit einer CPU, viel groesser. Je nachdem wie die Interconnects und Interfaces aussehen wuerden waeren sogar SoCs moeglich die wie die Konsolen Chips auf GDDR speicher zugreifen koennten. Fuer Gamingnotebooks gar nicht so uninteressant, vor allem fuer die Hersteller.

Gast
2021-05-04, 17:35:59
Der IC wird wahrscheinlich im IO die sein? Den könnten sie auf 7nm fertigen? Nur dann brauchen sie für Navi 33 ein separates die mit compute, ic, io, alles auf 5nm.
Dann sollte der Unterschied Navi 33 zu 31 vielleicht nicht 100% oder 75%, sondern eher "nur" 50% sein?

Leonidas
2021-05-04, 18:18:44
Könnte es auch sein, dass die MultiChip-Versionen HPC-only werden, so wie z.B. Nvidias A100?

Nein, HPC geht AMD mit einer eigenen Architektur an (CDNA).



Seid ihr sicher wenn jetzt schon über so Zeug zu Twitter Leaks spekuliert wird, dass RDNA3 erst in einem Jahr+ kommt?

An noch früher als Frühsommer 2022 mag gar keiner denken. Aber wahrscheinlich sind die Vorbereitungszeiten einfach so lang. Und sobald der Chip im Tape-Out ist, steht die HW fest.

AlterSack
2021-05-04, 19:17:13
Wenn man schon ein 80CU-Die für N31 nutzt, wäre es logischer dieses auch für N33 zu verwenden, anstatt einen extra Chip aufzulegen.
Klingt für mich nicht glaubwürdig.

Gast
2021-05-04, 19:25:31
Irgendwie ist die Aussage auf Twitter mehrdeutig:
"Navi 31 is about 2.5x faster than Navi 21" Das würde bedeuten, Navi31 ist 2,5x schneller als Navi21. In Prozent ausgedrückt: 250% schneller oder 350% so schnell. Müsste es nicht bei 2,5x so schnell heißen "Navi 31 is about 2.5x as fast as Navi 21"?
Selbst 2,5x halte ich als sehr viel. Die Fertigung bringt vielleicht 30%, da müsste die Effizienz schon massiv steigen damit der Verbrauch nicht explodiert.

Platos
2021-05-04, 21:29:56
Egal ob es nun beim grössten Chip + 150% (Gaming-) Leistung gibt oder nicht (was jeder bezweifeln sollte), wird es schonmal garantiert nicht +150% Leistung bei selbem (Listen)preis geben.

Traurigerweise sehe ich es dann bei der nächsten Gen schon kommen, dass Leute die Listenpreise mit überhöhten Strassenpreisen vergleichen und sich das dann irgendwie schönrechnen.

Gast
2021-05-04, 22:04:20
Wenn man schon ein 80CU-Die für N31 nutzt, wäre es logischer dieses auch für N33 zu verwenden, anstatt einen extra Chip aufzulegen.
Klingt für mich nicht glaubwürdig.

aber was soll dann im IO Die noch sein? Macht auch wenig sinn im IO die praktisch eine art pcie switch einzubauen, oder vielleicht IF. Man muss dann sowieso eine Art IF Logik im Compute die haben, warum dann noch ein drittes IO die überhaupt? Analog zu Epyc/TR 1 im Vergleich zu Epyc 2/3/Zen2/3 und Renoir.

Gast Ritis
2021-05-05, 00:23:12
Was mich aber schon wseit einiger Zeit immer mal wieder beschaeftigt ist die Frage in wie weit sich die Raytracing Logik von der klassischen GPU trennen lassen koennte. Mit Raytracing Die, Rasterizer Die und IO Die waere man sehr viel flexibler. Vor allem wenn man alle drei in je zwei Groessen zur Verfuegung hatte...

Das braucht man so nicht. Es geht allein darum die Fläche für ein Chiplet unter eine kritische Grösse zu drücken um beim Binning richtig gute Chiplets zu bekommen, die den Mehraufwand und die Latenz beim Interposer mehr als aufwiegen, mehr aus der Fertigung heraus holen als mit grösseren Chips möglich wäre.

Fläche braucht da nur der Infinity Cache der vielleicht in den Interposer wandert. Alle Einheiten, die nicht zu einer CU gehören können da auf den separaten Chiplet, solange das nicht zu langsam wird. Z.B. die Scheduler/ACE werden wohl bei den CUs bleiben.

Im Prinzip könnte das "RT" - was ja nur BVH-Beschleuniger für Hit-Berechnung sind - in einer separaten Area/Chiplet ausgelagert werden. Bei ImgTec war das ein separater Chipbereich, bei Nvidia soll es das auch sein.
AMD hat das aber bei den Textureinheiten direkt am Low Level Cache eingepflanzt. Entweder weils einfacher war oder weil die glauben es könnte noch wichtig werden, beim Inline-Raytracing vielleicht.
Muss man in 2-3 kommenden Generationen schauen wie es sich entwickelt...

Leonidas
2021-05-05, 04:40:32
Irgendwie ist die Aussage auf Twitter mehrdeutig:
"Navi 31 is about 2.5x faster than Navi 21" Das würde bedeuten, Navi31 ist 2,5x schneller als Navi21. In Prozent ausgedrückt: 250% schneller oder 350% so schnell.

Das ist wohl etwas unsauber geschrieben. Gemeint ist Faktor 2,5. Das wurde auch zum Jahresanfang bei RGT bereits so genannt.

Gast
2021-05-05, 08:56:56
Das ist wohl etwas unsauber geschrieben. Gemeint ist Faktor 2,5. Das wurde auch zum Jahresanfang bei RGT bereits so genannt.
Ah, ok. Also 2,5x as fast... Dann bin ich aber trotzdem noch wegen dem Verbrauch skeptisch. Damit der nicht explodiert, müsste man die Effizienz deutlich steigern, was bei einem angeblichen Multichip Ansatz mit den vielen schnellen Interfaces noch schwieriger wird als bei einem Monolithen... Bei 250% Leistung in besserer Fertigung kann man grob laut TSMC 30% Verbrauch einsparen bei gleichem Takt. Damit müsste die Architektur grob 70% schneller als Navi21 bei etwa gleichem Verbrauch sein. Oder man nimmt den Mehrtakt der neuen Fertigung mit, was vermutlich ungefähr die 25% zusätzlich zur CU Verdoppelung wären. Damit hätte man dann aber auch einen massiven Mehrverbrauch, der wohl bei 400 bis 450W liegen dürfte. Also entweder hat AMD noch einen genialen Kniff für die Effizienz, oder man holt sich mal wieder auf Biegen und Brechen die Performance Krone (bis NV dann kontert). Entsprechend bin ich da noch sehr skeptisch, was diese Meldungen angeht. Die doppelte Rechenleistung bedeutet ja noch lange nicht doppelte FPS, ich hoffe daher, dass AMD nicht die Effizienz für die Leistungskrone opfert.

Gast
2021-05-05, 12:01:44
Also so macht das überhaupt keinen Sinn.

Die Vorteile von Multichip-Designs liegen einerseits darin dass man sich Entwicklungskosten spart weil man im Endeffekt viel weniger Chips zur Marktreife bringen muss um damit ein breites Marktsprektrum abzudecken.
Andererseits kann man theoretisch mit ziemlich kleinen Chips auskommen.

Beides ist hier nicht der Fall, eher im Gegenteil. Man muss nach dem Gerücht 2 80CU GPUs designen, und zusätzlich noch den IO-DIE.

Mit 80CUs werden diese DIEs auch garantiert alles andere als klein ausfallen, also hat man den zweiten Vorteil auch nicht.

Dafür müsste man aber die inhärenten Nachteile eines Multichip-Designs, wie geringere Energieeffizienz, mehr Hardware aufwand für die selbe Performance, in kauf nehmen.

Und um ans andere Ende des Spektrums zu gehen, nämlich dass man Multichip nur verwendet um noch mehr Performance zu erreichen als in einem Singlechip Design überhaupt fertigbar wäre, dafür ist der Ansatz zu klein. 160CU könnte man sicher ohne Probleme auch monolithisch herstellen.

Leonidas
2021-05-05, 12:18:23
Für mich sieht dies weniger nach Einsparung von Entwicklungskosten aus, als vielmehr nach einer effizienteren Fertigung. Lieber 2x 300mm² + ein I/O-Chip als ein großer Chip á 650mm².

Gast
2021-05-05, 12:41:11
Im Endeffekt werden die Designs der nächste Jahre drauf ausgelegt sein die Yields zu maximieren. Die Produktionskapazität ist mittelfristig zu klein, also muss man möglichst viel rausholen. Wenn man vielleicht den IO Die noch einem älteren Prozess fertigen kann, wäre das ein massiver Win.

Gast
2021-05-05, 13:45:41
Für mich sieht dies weniger nach Einsparung von Entwicklungskosten aus, als vielmehr nach einer effizienteren Fertigung. Lieber 2x 300mm² + ein I/O-Chip als ein großer Chip á 650mm².

So geht die Rechnung nicht auf.
Multichip erfordert mehr Fläche für die gleiche Hardware.
Wenn du 300mm² für ein 80CU Multichip-Modul brauchst, kommst du mit einem 160CU Singlechip-Modul wahrscheinlich im Bereich 500-550mm² raus, das sollte ohne Probleme zu fertigen sein, wenn Nvidia in der Vergangenheit sogar über 700mm² gegangen ist.

Wie groß soll den vor allem auch das Package werden?

2x 300mm² GPU + nehmen wir mal an vielleicht noch mal 150-200mm² IO.

Das Package wäre riesig, wie willst du das überhaupt einer Grafikkarte unterbringen, VRAM und die ganze Spannungsversorgung die bei so einem Monster auch nicht ohne ist muss ja auch noch irgendwie rauf.

Und wie will man das Ganze anordnen? IO in der Mitte und Compute-DIEs herum? Das würde zu extrem langen Leitungen für den VRAM-Bus führen und sehr schlecht für die Stabilität vom VRAM sein. Es hat schon seinen Grund warum bei "normalen" GPUs die VRAM-Controller an den Seiten verteilt sind.

Oder man platziert den IO irgendwo am Rand des Packages und die Compute-DIEs daneben. Dann könnte man zwar kurze Wege zum VRAM erreichen, aber den nur an einer Seite um das Package anbringen, weil "Rundherum" wie es bisher üblich war würde extrem unterschiedliche Leitungslängen ergeben, was noch schlimmer als die zuvor genannte Variante wäre. Zudem hätte man eventuell je nach Platzierung der Compute-DIEs auch noch mit unterschiedlichen Leitungslängen zwischen IO und Compute-DIEs zu kämpfen.

Was auch immer da raus kommt, das Teil hätte wesentlich mehr Nachteile gegenüber einer monolithischen Lösung als es Vorteile bringen kann.

Lehdro
2021-05-05, 14:50:06
Was auch immer da raus kommt, das Teil hätte wesentlich mehr Nachteile gegenüber einer monolithischen Lösung als es Vorteile bringen kann.
Ein Wort: Yield (https://caly-technologies.com/die-yield-calculator/). Spiel ruhig mal mit rum. Bei eine Def. Density von 0.1 hast du mit 300mm² rund 75% Yield, mit 500mm² nur noch 62% und mit 550mm² 59%. TSMCs N7 hatte Ende 2019 angeblich eine Def. Density von 0.09 (https://fuse.wikichip.org/news/2879/tsmc-5-nanometer-update/), N5 sollte das sogar noch schlagen können laut Berichten (https://www.anandtech.com/show/16028/better-yield-on-5nm-than-7nm-tsmc-update-on-defect-rates-for-n5). Gehen wir bei N5 einfach mal von 0.07 aus:
300mm² = 81,4%
500mm² = 71,2%
550mm² = 68,9 %
Der Unterschied ist massiv, selbst bei solch guten Prozessen. Dazu kommt das man den I/O Teil potenziell in älteren Nodes fertigen kann, da gerade analog Sachen und auch Speichercontroller (z.B. wegen der physisch notwenigen Anschlüsse) nicht gut mit kleineren Nodes skalieren. Hier kann man zum Beispiel auf GFs oder TSMCs ausgereifte Nodes zurückgreifen.

Weiteres:
Spannungswandler: Brauchst du auch bei monolithischen GPUs, absolut null Problemo, das zeigen die 400W+ Monster von NV.
VRAM: Vorder- und Rückseite bestücken hält Signalwege klein. Wenn es wirklich so ein Problemfall ist, gäbe es noch HBM.

Gast
2021-05-05, 16:51:49
Yield ist ja nicht das einzige, je kleiner die Chipfläche um so geringer der Verschnitt. Also mehr Chips pro Wafer.

Wenn ich das Patent richtig verstanden habe soll ja auch nur ein Chiplet
die IO-Kommunikation übernehmen und die Aufgaben an die anderen Chiplets weiterleiten. Das hätte den Vorteil die Software sieht nur einen Chip und muß nicht angepasst werden. Weiterhin hat das Vorteile für AMDs RT. Ihr Ansatz erledigt mehr Berechnungen auf den Shadern als NV, jetzt kann man die Shader des ersten Chiplets zum rastern nutzen und die RT wandert auf das zweite Chiplet.

Außerdem bringt es Vorteile für die Kühlerkonstruktion, durch die Chiplets sind die Hotspots weiter voneinander entfernt und damit besser abzuleiten.

Gast Ritis
2021-05-05, 17:15:54
Chiplets sind scheinbar trotz der Zen-Generationen noch immer unverstanden.

Zen1 war ein identischer Chiplet mit allem drin, der als EYPC bis zu 4x auf einem Interposer verschaltet wurde. Jedes Chiplet brachte ein Speicherinterface mit.

Für den Ansatz hat AMD auch für GPU-Chiplets ein Patent eingereicht.

Zen2 war die Trennung von Cores und dem Rest (IO) in zwei separate Chiplets. Der komplizierte Interposer mit den Crosslinks wurde dadurch sehr einfach, die Verlinkung erfolgt im IO-Die. Noch mehr kleine Core Chiplets zu einem grossen möglich. Die Latenzen via Interposer konnten gesenkt werden. Das Speicherinterface musste offensichtlich nicht via Anzahl Chiplets skalieren.

Es geht um Yield und Binning-Flexibilität mit Ausbeute für hohe Takte oder alternativ sehr effiziente Samples nebst günstigeren SKUs für Einsteiger.

Zwei 8-Kern Chiplets können immer mit höheren Frequenzen angeboten werden als ein 16-Kern Monolith.
Die Bremse via Interposer-Links müssen durch den Taktgewinn kompensiert werden, sonst macht es keinen Sinn.
Deshalb werden auch APUs nach wie vor als Monolith gefertigt. Dort braucht es keine Chiplets für EPYC. Mit wenigen CUs für Vega war das als Monolith besser und noch immer klein genug.

Bei GPU darf entsprechendes erwartet werden. Der LL-Cache im Interposer ist auch ein neues Patent von AMD, der könnte die Bremse zwischen GPU-Chiplets lösen helfen. Gross genug auch ein IO Chiplet Speicherinterface ermöglichen.

Es geht aber nicht! um ein Baukastensystem mit möglichst viel Flexibilität. Da schaltet man lieber unnötig doppelte Einheiten in Chiplets ab, wie schon bei Zen1 EPYC (zu viele USB) oder Ryzen (zu viele Chip2Chip Links).

Gast
2021-05-05, 18:08:25
Ein Wort: Yield (https://caly-technologies.com/die-yield-calculator/). Spiel ruhig mal mit rum. Bei eine Def. Density von 0.1 hast du mit 300mm² rund 75% Yield, mit 500mm² nur noch 62% und mit 550mm² 59%. TSMCs N7 hatte Ende 2019 angeblich eine Def. Density von 0.09 (https://fuse.wikichip.org/news/2879/tsmc-5-nanometer-update/), N5 sollte das sogar noch schlagen können laut Berichten (https://www.anandtech.com/show/16028/better-yield-on-5nm-than-7nm-tsmc-update-on-defect-rates-for-n5). Gehen wir bei N5 einfach mal von 0.07 aus:
300mm² = 81,4%
500mm² = 71,2%
550mm² = 68,9 %


Die ganzer herumspielerei ist ja schön und gut, geht nur vollkommen an der Realität vorbei.

Die Grundannahme dieser ganzen Rechnung ist nämlich, dass du einen vollständig Fehlerfreien DIE für ein funktionierendes Produkt brauchst. Und diese Annahme hat mit der Realität nicht das geringste zu tun.
Jeder Chip hat heute Redundanzen integriert die Produktionsfehler ausgleichen können, und damit mein ich noch nicht mal das Deaktivieren einzelner Chipteile.
Das kommt nämlich noch dazu. Wenn wir als Beispiel den GA102 mit seinen 7 GPCs nehmen ist es relativ egal, ob wir diese 7 GPCs in einzelnen Chiplets fertigen und dann jene wegwerfen die nicht funktionieren, oder ob wir das als Ganzes herstellen und dann einzelnen GPCs deaktivieren.

So ziemlich jeder DIE mit einem einzelnen Fehler ist verwendbar, und wenn du die auch noch mitrechnest rücken die Yields schon sehr nahe zusammen.


Der Unterschied ist massiv, selbst bei solch guten Prozessen. Dazu kommt das man den I/O Teil potenziell in älteren Nodes fertigen kann, da gerade analog Sachen und auch Speichercontroller (z.B. wegen der physisch notwenigen Anschlüsse) nicht gut mit kleineren Nodes skalieren.


Du brauchst aber nicht weniger IO, sondern mehr. Du brauchst IO für die Kommunikation nach außen, das wird ja nicht weniger, und zusätzlich IO für die Kommunikation der Chiplets untereinander.



Spannungswandler: Brauchst du auch bei monolithischen GPUs, absolut null Problemo, das zeigen die 400W+ Monster von NV.


Schon, nur mit dem Multichip-Design ist das Package viel größer, und damit bleibt viel weniger Platz für den Rest.


VRAM: Vorder- und Rückseite bestücken hält Signalwege klein. Wenn es wirklich so ein Problemfall ist, gäbe es noch HBM.

Schränkt aber den Speicherausbau stark ein, wenn man das schon für "normale" Mainstreamhardware braucht.
HBM wäre in der Tat eine Lösung, dafür braucht es dann aber riesige Interposer.

AlterSack
2021-05-05, 18:41:53
So geht die Rechnung nicht auf.
Multichip erfordert mehr Fläche für die gleiche Hardware.
Wenn du 300mm² für ein 80CU Multichip-Modul brauchst, kommst du mit einem 160CU Singlechip-Modul wahrscheinlich im Bereich 500-550mm² raus, das sollte ohne Probleme zu fertigen sein, wenn Nvidia in der Vergangenheit sogar über 700mm² gegangen ist.

Wie groß soll den vor allem auch das Package werden?

2x 300mm² GPU + nehmen wir mal an vielleicht noch mal 150-200mm² IO.

Das Package wäre riesig, wie willst du das überhaupt einer Grafikkarte unterbringen, VRAM und die ganze Spannungsversorgung die bei so einem Monster auch nicht ohne ist muss ja auch noch irgendwie rauf.

Und wie will man das Ganze anordnen? IO in der Mitte und Compute-DIEs herum? Das würde zu extrem langen Leitungen für den VRAM-Bus führen und sehr schlecht für die Stabilität vom VRAM sein. Es hat schon seinen Grund warum bei "normalen" GPUs die VRAM-Controller an den Seiten verteilt sind.

Oder man platziert den IO irgendwo am Rand des Packages und die Compute-DIEs daneben. Dann könnte man zwar kurze Wege zum VRAM erreichen, aber den nur an einer Seite um das Package anbringen, weil "Rundherum" wie es bisher üblich war würde extrem unterschiedliche Leitungslängen ergeben, was noch schlimmer als die zuvor genannte Variante wäre. Zudem hätte man eventuell je nach Platzierung der Compute-DIEs auch noch mit unterschiedlichen Leitungslängen zwischen IO und Compute-DIEs zu kämpfen.

Was auch immer da raus kommt, das Teil hätte wesentlich mehr Nachteile gegenüber einer monolithischen Lösung als es Vorteile bringen kann.

für die 160 cu-variante käme wohl eh hbm2e in betracht. bei den kartenpreisen sicher machbar. an 512bit SI glaub ich nicht.

FarCry
2021-05-05, 19:04:48
...

Was auch immer da raus kommt, das Teil hätte wesentlich mehr Nachteile gegenüber einer monolithischen Lösung als es Vorteile bringen kann.

... dann würden sie es wohl nicht bauen. :wink:

Lehdro
2021-05-05, 19:05:02
Die ganzer herumspielerei ist ja schön und gut, geht nur vollkommen an der Realität vorbei.
Und deine Realität ist das wohl ALLES Redundant ist? Aha. Sicherlich trifft man sich da irgendwo in der Mitte, aber mehr voll funktiuonstüchtige Dies gibts nun einmal mit Chiplets. Es hat wohl durchaus seinen Grund warum Chiplets im Kommen sind - überall. Du hattest das immer so dargestellt als hätten sie nur Nachteile, während du die Vorteile andauernd krass marginalisierst:

- besseres Binning
- bessere Yield
- Skalierbarkeit
usw.

Sind wohl alles Idioten bei AMD am Werk.

FarCry
2021-05-05, 20:35:42
...
Sind wohl alles Idioten bei AMD am Werk.

Hat man doch schon an Navi21 und dem InfinityCache gesehen, dass die nix können. :wink:

Gast
2021-05-05, 20:47:19
Und deine Realität ist das wohl ALLES Redundant ist?


Nicht alles ist Redundant und nicht alles ist deaktivierbar. Aber fast alles ist entweder das eine oder das andere.


Aha. Sicherlich trifft man sich da irgendwo in der Mitte, aber mehr voll funktiuonstüchtige Dies gibts nun einmal mit Chiplets.


Spielt keine Rolle, dafür braucht man auch wesentlich mehr DIEs.

Wie gesagt ist es egal ob du ein Stück Silizium gleich wegwirfst oder deaktiviert zum Kunden lieferst.


Du hattest das immer so dargestellt als hätten sie nur Nachteile, während du die Vorteile andauernd krass marginalisierst:


In der kolportierten Form mit 2(3) ziemlich großen Chiplets hat man eben keine Vorteile mehr, die ergeben sich nur wenn man wie bei Zen viele sehr kleine Chiplets verwendet.

Sind wohl alles Idioten bei AMD am Werk.

Ja solche Idioten, dass sie nur dort Chiplets verwenden wo es für sie Sinn macht, und nicht dort wo es eben nicht sinnvoll ist.

Für das Produkt selbst haben Chiplets nur Nachteile, die einzigen Vorteile sind wirtschaftlicher Natur. Und diese sind eben nur gegeben wenn man sehr wenige DIEs hat die man für viele verschiedene Produkte verwenden kann.

Ein Chiplet Design für ein einzelnes Produkt ist komplett sinnbefreit. Damit hast du eben so gut wie keine wirtschaftlichen Vorteile mehr, und die technischen Nachteile hast du sowieso immer.

Ich könnte mir ja durchaus vorstellen, dass an dem Gerücht irgendwo ein funken Wahrheit dran steckt, aber so macht es einfach überhaupt keinen Sinn.

Ich würde eher davon ausgehen, dass es sich bei den 80CU und 2x 80CU Varianten in Wirklichkeit um die selben DIEs handelt, und es keinen IO-DIE gibt, sondern ähnlich wie bei Zen1 die DIEs direkt miteinander Kommunizieren.
Das würde für GPUs viel mehr Sinn machen.
Einerseits würde man die Skalierbarkeit der Chiplets auch wirklich nutzen, andererseits den Bandbreitenbedarf im Package im Vergleich zu einer Lösung mit extra IO-Die halbieren. Bits zwischen den DIEs hin und herzuschieben kostet viel Energie, und für GPUs bräuchte es viel mehr Bandbreite als bei CPUs, also würde es durchaus Sinn machen die Zwischenstation einzusparen.
Auf GPUs sollte sich die unterschiedliche Latenz zu den jeweiligen RAMs auch viel besser verstecken lassen als bei CPUs.
Auch sind es lediglich 2 Compute-DIEs bei der GPU, damit ist ein extra IO-DIE eigentlich kaum sinnvoll, das wird es bei Zen2 und 3 eigentlich erst dadurch, dass man ja bis zu 8 Compute DIEs auf einem Package verbaut.

iamthebear
2021-05-05, 22:14:17
Ich denke Navi33 wird der reguläre High End Chip sein so im Preisbereich von 700 Euro.

Navi 31 dürfte dann so etwas sein wie früher die Dual Karten (z.B. damals die HD 4870 X2), nur dass das diesmal nicht über Crossfire läuft, sondern sich nach außen als ein Kern ausgibt.
Preislich denke ich nicht, dass sich da unter 1500-2000 Euro viel abspielen wird bzw. große Stückzahlen verkaufen werden. Das dürfte eher mehr der Test für zukünftige Generationen sein, wo man je nach Bedarf kleinere Chiplets einsetzen kann bzw. will man Nvidia einfach beim Topmodell schlagen, da sich dann die anderen Karten auch deutlich besser verkaufen.

Das langfristige Ziel von AMD scheint zu sein, sich sowohl für CPUs als auch GPUs relativ früh die jeweils aktuellen Fertigungsverfahren bei TSMC zu sichern auch wenn die Yields noch nicht so toll aussehen und dafür einfach auf kleinere Chips zu setzen.

Leonidas
2021-05-06, 04:01:05
So geht die Rechnung nicht auf.
Multichip erfordert mehr Fläche für die gleiche Hardware.
Wenn du 300mm² für ein 80CU Multichip-Modul brauchst, kommst du mit einem 160CU Singlechip-Modul wahrscheinlich im Bereich 500-550mm² raus,

So habe ich das auch gerechnet. Meine Rechnung war 2x300mm² + I/O-Die. Das sind zusammen 700-750mm² - also mehr als der Monolith mit 650mm². Egal ob es das extra I/O-Die gibt oder nicht, ich bin mir natürlich darüber im klaren, das Monolith kleiner ist.

Zum Rest gab es genügend andere Antworten vorstehend.

Gast
2021-05-06, 07:43:21
Nicht alles ist Redundant und nicht alles ist deaktivierbar. Aber fast alles ist entweder das eine oder das andere.[...]
Ich würde eher davon ausgehen, dass es sich bei den 80CU und 2x 80CU Varianten in Wirklichkeit um die selben DIEs handelt, und es keinen IO-DIE gibt, sondern ähnlich wie bei Zen1 die DIEs direkt miteinander Kommunizieren.
Das würde für GPUs viel mehr Sinn machen.
Einerseits würde man die Skalierbarkeit der Chiplets auch wirklich nutzen, andererseits den Bandbreitenbedarf im Package im Vergleich zu einer Lösung mit extra IO-Die halbieren. Bits zwischen den DIEs hin und herzuschieben kostet viel Energie, und für GPUs bräuchte es viel mehr Bandbreite als bei CPUs, also würde es durchaus Sinn machen die Zwischenstation einzusparen.
Auf GPUs sollte sich die unterschiedliche Latenz zu den jeweiligen RAMs auch viel besser verstecken lassen als bei CPUs.
Auch sind es lediglich 2 Compute-DIEs bei der GPU, damit ist ein extra IO-DIE eigentlich kaum sinnvoll, das wird es bei Zen2 und 3 eigentlich erst dadurch, dass man ja bis zu 8 Compute DIEs auf einem Package verbaut.
Dir ist schon klar, dass man mehr Redundanzen braucht, je größer der Chip ist? Und die brauchen auch Fläche... Insofern ist die Rechnung von Leonidas mit vielleicht 750mm2 Chiplets gegenüber einem 650mm2 Monolithen durchaus realistisch.
Und dein Konstrukt ohne IO Die ist genau was? Im Prinzip ist das ein Crossfire Setup, mit all seinen Nachteilen. Jede GPU kann nicht (oder nur langsam) auf den Ram der andere GPU zugreifen, man müsste also mit Techniken wie AFR und Co. wieder das Bild zerlegen und kommt damit wieder in die Probleme, die Crossfire schon bietet. Um das zu umgehen, braucht man ein zentrales IO Chiplet, welches den Ram beiden GPUs zur Verfügung stellt. Und den Ram könnte man dann vermutlich auch mit auf den Träger packen, wodurch man besonders kurze Signalwege hätte. Damit wäre der Ram dann am Kühler der GPU mit dran, was aber bei ausreichend Kühlleistung kein Problem sein sollte.
Und wieso genau macht ein IO Chiplet bei zwei Compute Chiplets keinen Sinn? Ist doch bei Ryzen auch nicht anders? Wer sagt denn, dass die Compute Chiplets von Navi nicht auch für CDNA verwendet werden? Vielleicht ist bei CDNA die ganze für Server relevante Logik im IO Chiplet und die Recheneinheiten sind für RDNA und CDNA dann wieder (in Zukunft) gleich? RDNA kann ja auch sehr gut mit niedriger Präzision (also z.B. INT8) umgehen, was für ML wichtig ist, kann mir daher durchaus vorstellen, dass AMD versucht, die Recheneinheiten so zu gestalten, dass man die für beides nutzen kann. CDNA bekommt dann im IO Die vielleicht noch Themen wie Virtualisierung, mehr Links zur Kommunikation und anderen Speicher.

Gast Ritis
2021-05-06, 09:04:52
Für das Produkt selbst haben Chiplets nur Nachteile, die einzigen Vorteile sind wirtschaftlicher Natur. ...

andererseits den Bandbreitenbedarf im Package im Vergleich zu einer Lösung mit extra IO-Die halbieren. ..

Auch sind es lediglich 2 Compute-DIEs bei der GPU, damit ist ein extra IO-DIE eigentlich kaum sinnvoll, das wird es bei Zen2 und 3 eigentlich erst dadurch, dass man ja bis zu 8 Compute DIEs auf einem Package verbaut.

GPUs kratzen schon immer an der Grenze des technisch machbaren bei Die-Size bzw. Anzahl Shader vs. Takt und Spannung um das Maximum in Perf/Watt und Spitzenleistung für eine Massenproduktion auszuloten.

GPUs sind deshalb prädestiniert die Grösse bzw. Shader-Anzahl über Chiplets zu skalieren ohne den Takt und Spannung runter drücken zu müssen. Der zusätzliche Energiebedarf für den Interposer darf nicht zu gross werden, die Links müssen kurz bleiben.
Wenn man aber über die Core-Zahl fast linear skaliert können diese GPU-Chiplet im Sweetspot Takt/Spannung laufen und müssen nicht in exponentiell höhere Spannung für wenig mehr Takt gefahren werden. Ab bestimmter Grösse kehrt die Gleichung linear vs. exponentiell immer ins Positive. Allein darum sind GPU-Chiplet für die Performance-Spitze notwendig.

Nur mit Chiplets konnte AMD mit dem rückständigen GloFo Prozess überhaupt konkurrenzfähig werden. Die Vorteile kann man aber bei allen Fertigungsverfahren entsprechend nutzen.

Bei Zen2 hat sich gezeigt, dass für den Abverkauf der Chiplets im Einstiegssegment abseits der Leistungsspitze der separate IO auch nicht gestört hat. Die erwarteten Bulk-Lowend Zen Monolithen hat es bis heute nicht gegeben.

Zwei vollwertige Chiplets haben nicht weniger Bandbreitenbedarf als zwei Core-Chiplets an einem IO-Die. Der Bandbreitenbedarf bleibt gleich relativ zu den Shadern/Cores. Die Frage ist eher ob die Software sich für UMA/NUMA eignet und wie das bei AMDs hUMA aussieht. Letzteres würde eher mit einem shared LLC umsetzbar sein.

Es kann sowohl ein Zen1 ähnlicher Aufbau mit "NUMA" aus Sicht eines Master GPU-Chiplet sein, das ggü. der CPU als eine GPU auftritt, wie das durch as AMD Patent mit im Beispiel 4 GPU Chiplets vorexerziert wurde.
... als auch ein Zen2 ähnlicher Aufbau mit IO Chiplet sein, der in wie bei Ryzen/EPYC in Varianten beim SI (z.B. GDDR od. HBM) oder LLC Grösse verbaut wird.

Letzteres würde sich nur anbieten, wenn keine Bulk-Ware bei GPUs verkauft werden soll, z.B. weil der Markt von APUs/iGPUs bedient würde. Z.B. mit RDNA2 APUs mit deutlich mehr als 8 CUs.

Gast
2021-05-06, 12:02:33
Und dein Konstrukt ohne IO Die ist genau was? Im Prinzip ist das ein Crossfire Setup, mit all seinen Nachteilen. Jede GPU kann nicht (oder nur langsam) auf den Ram der andere GPU zugreifen, man müsste also mit Techniken wie AFR und Co. wieder das Bild zerlegen und kommt damit wieder in die Probleme, die Crossfire schon bietet.


Jede GPU kann genauso schnell oder langsam auf den RAM der andern zugreifen wie sie es über den IO-DIE immer könnte.

Mit IO-Die muss jeder Speicherzugriff über einen fremden DIE gehen und ist damit "langsam". Ohne IO-DIE sind die Zugriffe auf den am eigenen DIE angebundenen RAM "schnell" und die über den benachbarten DIE gleich "langsam" als sie über einen IO-DIE immer wären.

Zudem braucht man mit IO-Die wesentlich mehr Bandbreite.

Wenn wir jetzt mal mit einem Speicherinterface das 1TB/s schafft rechnen müssten mit IO-Die 1TB/s vom VRAM in den IO-Die transportieren, und dann nehmen wir bei gleichverteilten Zugriffen mal an noch 0,5TB/s vom IO-Die in die jeweiligen Compute-DIEs.
Insgesamt müssen wir also 2TB/s durch das Package transportieren.

Ohne IO-Die bekommt jeder Compute-Die seinen eigenen Speicher mit 0,5TB/s angeschlossen. Wenn wir wieder von einer 50:50-Verteilung der Speicherzugriffe ausgehen, fließen jeweils 0,5TB/s vom RAM in den jeweiligen Compute-DIE und 0,5TB/s zwischen den 2 Compute-DIEs.
Insgesamt müssen wir durchs Package also nur 1,5TB/s transportieren und sparen uns jede Menge ein und erleiden dadurch keinerlei Nachteil, weil die Speicherzugriffe am eigenen DIE sogar schneller sind als mit extra IO-Die, und die Speicherzugriffe die über den fremden DIE geschehen sind gleich schnell als wenn sie über einen IO-Die laufen würden.

Erst mit mehr als 2 Compute-Dies wird der IO-Die sinnvoll, wenn wir dann keine Performance verlieren wollen, müssen wir jeden mit jedem anderen DIE verbinden, ansonsten müssten wir unter Umständen über mehrere Hops auf den fremden Speicher zugreifen, während wir mit extra IO-Die eine Sterntopologie verwenden können und jeder Compute DIE wird einfach mit dem IO-DIE verbunden, was das Ganze um einiges einfacher macht.

Die Nachteile vom IO-Die werden auch wesentlich kleiner, weil wenn wir davon ausgehen, dass beispielsweise bei 4 Compute-DIEs 75% der Speicherzugriffe eh über einen fremdden DIE stattfinden macht es auch nicht mehr so viel aus, wenn es die restlichen 25% auch tun.


Um das zu umgehen, braucht man ein zentrales IO Chiplet, welches den Ram beiden GPUs zur Verfügung stellt.

Nein braucht man nicht. Ob du die Daten zwischen IO-DIE und Compute-DIE transportierst oder zwischen 2 Compute-DIEs ist erstmal egal.


Und den Ram könnte man dann vermutlich auch mit auf den Träger packen, wodurch man besonders kurze Signalwege hätte.


Mit HBM schon, mit GDDR nicht. Das wird dann aber sehr teuer.


Wer sagt denn, dass die Compute Chiplets von Navi nicht auch für CDNA verwendet werden?

Was für einen Sinn hat CDNA dann noch?
Entweder du verwendest eine eigene Architektur für HPC und Gaming, dann wirst du aber auch keine DIEs teilen, oder die beiden Architekturen werden wieder zusammengeführt, dann gibt es aber kein RDNA+CDNA mehr sondern nur mehr eine gemeinsame Nachfolgerarchitektur.

Leonidas
2021-05-06, 14:33:14
Nur zum Thema CDNA:
Das ist vom Aufbau der Recheneinheiten inzwischen so abweichend, dass ich da keinen Zusammenschluß mehr annehme. Im Endeffekt reitet AMD bei CDNA weiterhin die Schiene von immer mehr Einheiten und nimmt dafür Verwaltungslogik raus, die man nur für Gaming braucht. Umgedreht sind die RDNAs intelligenter geworden und bringen mehr Nebenbei-Logik, um die vorhandene Rechenleistung besser auf die Straße zu bringen. Glaskugel: Das führt man nie wieder zusammen.

Gast Ritis
2021-05-06, 17:22:56
...
Mit IO-Die muss jeder Speicherzugriff über einen fremden DIE gehen und ist damit "langsam". Ohne IO-DIE sind die Zugriffe auf den am eigenen DIE angebundenen RAM "schnell" und die über den benachbarten DIE gleich "langsam" als sie über einen IO-DIE immer wären.

Zudem braucht man mit IO-Die wesentlich mehr Bandbreite.

Wenn wir jetzt mal mit einem Speicherinterface das 1TB/s schafft rechnen müssten mit IO-Die 1TB/s vom VRAM in den IO-Die transportieren, und dann nehmen wir bei gleichverteilten Zugriffen mal an noch 0,5TB/s vom IO-Die in die jeweiligen Compute-DIEs.
Insgesamt müssen wir also 2TB/s durch das Package transportieren.
....

Das ist alles theoretischer Unsinn weil die tatsächlich vorliegenden Grössenordnungen und Bedürfnisse nicht berücksichtig sind.

Die zusätzliche Latenz eines Hops über einen benachbarten Die ist nie so gross wie die Latenz des Speicherzugriffs auf externes DDR via einem SI selbst.
Die Latenzen werden soweit von Caches bei den SI-Controllern kompensiert, dass das weitestgehend irrelevant wird, wie das 256bit SI mit InfinityCache vortrefflich bewiesen hat.
Nur weil die eine GPU eine theor. 1TB Bandbreite hat bedeutet das nicht, das wäre notwendig in der Bandbreite. Oftmals geht es dabei nur um minimierung der Latenzen durch höheren Takt. Zumindest beim Gaming skaliert sehr sehr selten etwas linear mit VRAM-OC. Bandbreite ist zumeist Überprovisioniert.

Es genügt bei I/O Dies alle umliegenden Off-Chip Links mit der jeweiligen möglichen! oder bei Compute-Chiplets notwendigen! Bandbreite anzubinden. Im I/O Die sind mehrere TB/s crossbar performance möglich, das kann man aus der Betrachtung streichen. Allein die Anbindung zählt. Die Latenz ist je nach VRAM wenige Prozent mehr.

Wenn AMD ein 256bit SI für eine 80CU GPU bei 2.7GHz genügt, dann genügt auch locker ein 512bit SI am I/O für 2 80CU Dies mit vllt nur noch 2.5GHz oder ein breites HBM Interrface für 4x 80 CUs bei 2GHz.
Die lokalen Caches müssen gross genug sein und kohärent gehalten werden. Das läuft parallel zur Auslasung der CUs. Das genügt.
Ist ein Shared Interposer LL-Cache im Einsatz ist der vermutlich immer noch Faktor 10+ schneller als ein Zugriff über ein lokales SI auf GDDR.

Zum Glück arbeiten bei den GPU-Herstellern aber fähige Ingenieure und keine Laien. Selbst ich wäre nicht auf den Trick mit dem InfinityCache bei 256bit SI gekommen. ;D Nvidia zaubert auch oft genug verblüffendes zu Tage. Bei Intel sind wir noch gespannt.

Gast
2021-05-07, 12:35:33
Die zusätzliche Latenz eines Hops über einen benachbarten Die ist nie so gross wie die Latenz des Speicherzugriffs auf externes DDR via einem SI selbst.


Ja, das ändert aber nichts an der Aussage, dass es egal ist ob der zusätzliche Hop ein spezialisierter IO-DIE ist, oder einfach jeder Compute-DIE einen Teil der IO-Arbeit zum Gesamtsystem beiträgt.


Nur weil die eine GPU eine theor. 1TB Bandbreite hat bedeutet das nicht, das wäre notwendig in der Bandbreite.


Schon klar, nur warum stattest du dann eine GPU mit 1TB/s an Bandbreite aus, wenn sie die eh nicht benötigt?

Und vor allem hat das alles nichts mit der ganzen Diskussion Chiplet oder Monolithisch, und expliziter IO-Die oder nicht zu tun. Jedes GPU-System egal wie es aufgebaut ist wird nicht immer die maximal zur Verfügung stehende Bandbreite brauchen, und jedes GPU-System wird, wenn das nicht der Fall ist auch weniger Energie brauchen.

Das ändert aber nichts am Verhältnis der einzelnen Systeme zueinander, monolithisch wird trotzdem immer das effizienteste System bleiben, und die Vor- und Nachteile von IO-Die und keinem bleiben auch die selben, nur die absoluten Werte ändern sich.



Selbst ich wäre nicht auf den Trick mit dem InfinityCache bei 256bit SI gekommen.

Der Cache an sich, und dessen Wirksamkeit ist eigentlich nicht großartig überraschend, da ist nichts wirklich großartiges dabei. Eher im Gegenteil, der IC ist sogar eher ein ziemlich "dummes" Stück Hardware ausgeführt als extrem simpler Victim Cache, und die Wirkungsweise kommt eher durch Masse statt Klasse.

Und das ist dann wieder mehr das überraschende, nämlich wie es AMD in Verbindung mit TSMC gelungen ist eine derartige Cachemenge so dicht zu packen. Wenn man sich mal ausrechnet wie viel Transistoren dieser eigentlich benötigt, und dann die DIE-Shots sieht wie wenig Fläche dadurch verbraucht wird ist das schon sehr beeindruckend.

Gast
2021-05-08, 13:26:19
Ohne mir die anderen Spekulationen durchgelesen zu haben:
Klar könnte 31 als 2+1 Chiplets aufgelegt sein. Und die Compute-Chiplets 33er ohne I/O oder gar komplett andere Chips sein. Bezweifle ich.
Man nehme 2x 33, nutze nur auf einer der I/O und kopple nicht wie Crossfire sondern als von außen monolithisch.
In jedem Fall unrealistisch, dass 31 doppelt so schnell ist wie 33, sofern nicht Takt, Caches, usw. erhöht sind.

Leonidas
2021-05-08, 15:42:47
Ich sehe da sicherlich noch größeren Klärungsbedarf samt der Chance, dass einiges anderes herauskommt als derzeit genannt wird.