RDNA3 (Navi 3X, Radeon RX 7000 Serie, tlw. Chiplets, 5/6 nm, 2022)

[mr coffee]

Wieso denn beschrieben? Hier geht‘s doch um das Lesen der Texturdaten, oder nicht?

[Zossel]

Auf dem PC stellen sich so Fragen wie das Auslagern von VRAM auf die SSD gar nicht.

Das läuft andersherum.

[HOT]

Jo kapiert auch nicht, was diese SSD-Diskussion soll. Es wird doch nur gelesen :freak:.

[Neurosphere]

AMD und intel haben zumindest den Vorteil daß auf den eigenen Plattformen umsetzen zu können falls man es will.

[Zossel]

AMD und intel haben zumindest den Vorteil daß auf den eigenen Plattformen umsetzen zu können falls man es will.

Wo siehst du die Notwendigkeit für spezielle HW außerhalb der GPU?

[Neurosphere]

Wo siehst du die Notwendigkeit für spezielle HW außerhalb der GPU?

Wenn ich möchte das die GPU direkten Zugriff auf die SSD, erhält müsste ich ja CPU und Chipsatz dazu bringen das auch zuzulassen. Die Speicherverwaltung ändert sich ja in diesem Moment und hier haben normalerweise Intel und AMD den Hut auf. Außer ich verstehe euren Ansatz nicht korrekt.

[Platos]

Das läuft andersherum.

Stimmt, das habe ich gar nicht gesehen. Es geht ja nicht ums auslagern, es geht ums Streamen von der SSD in den Grafikspeicher.

Wie schnell kann eine Grafikkarte eig. dekomprimieren? Gibts da Zahlen dazu bei einer bestimmten Kompression und Kompressionsverfahren ? Also sowas wie xy GB/s ?

Ich frage mich ja schon lange, ob neben Grafikdaten (Texturen) auch die SSD genug schnell wäre, um von der SSD in den RAM zu streamen. Bei der Konsole ist ja alles der gleiche Speicher und so genau wurde nie gesagt, welche Daten da hin kommen und welche nicht. Aber würde es technisch vlt. Sinn machen, auch beim RAM zu streamen, so dass auch dort die Grösse besser ausgenutzt werden kann?

[mboeller]

Wenn ich möchte das die GPU direkten Zugriff auf die SSD, erhält müsste ich ja CPU und Chipsatz dazu bringen das auch zuzulassen. Die Speicherverwaltung ändert sich ja in diesem Moment und hier haben normalerweise Intel und AMD den Hut auf. Außer ich verstehe euren Ansatz nicht korrekt.

MS DX12/DirectStorage API

[Platos]

Wenn ich möchte das die GPU direkten Zugriff auf die SSD, erhält müsste ich ja CPU und Chipsatz dazu bringen das auch zuzulassen. Die Speicherverwaltung ändert sich ja in diesem Moment und hier haben normalerweise Intel und AMD den Hut auf. Außer ich verstehe euren Ansatz nicht korrekt.

https://www.turn-on.de/article/direct-storage-in-windows-11-was-steckt-eigentlich-dahinter-640894

So soll das laut diesem Artikel funktionieren. Kann das jemand bestätigen? Ich habe bisher nie so eine richtig detaillierte Erklärung für Direct Storage gefunden.

[Neurosphere]

DS wäre möglich, danke hatte ich nicht auf dem Schirm.

Problematisch sehe ich da nur das es Windows 11 only ist und das bei der Marktdurchdringung mit 20% seinen Zenit erreicht hat so wie's aussieht.

Zumindest für diese Gen würde ich da nicht drauf setzen.

[Platos]

Ja, leider ist es Win11 only. Das zerstört leider vieles. Microsoft versucht wieder mal per indirektem Zwang Leute auf Win11 zu bewegen.

[basix]

DS wäre möglich, danke hatte ich nicht auf dem Schirm.

Problematisch sehe ich da nur das es Windows 11 only ist und das bei der Marktdurchdringung mit 20% seinen Zenit erreicht hat so wie's aussieht.

Ja, leider ist es Win11 only. Das zerstört leider vieles. Microsoft versucht wieder mal per indirektem Zwang Leute auf Win11 zu bewegen.

Nö.
An seiner Windows 11-Veranstaltung im letzten Monat kündigte Microsoft an, dass das neue Betriebssystem über die neue Direct-Storage-API verfügen wird. Nun hat das Unternehmen bestätig, dass die Technologie auch für Windows 10 kommt.
https://www.itmagazine.ch/artikel/75138/Direct_Storage_kommt_auch_fuer_Windows_10.html

- Windows 10 wird den vollen Umfang der sogenannten Storage-Stack-Optimierungen nicht nutzen können, die das volle Potenzial von DirectStorage erst unter Windows 11 ermöglichen sollen, das auch mit Hinblick auf die neue API entwickelt worden sei.
- Dennoch sollen Spiele schon unter Windows 10 „von dem neuen Programmiermodell und der GPU-Dekomprimierungstechnik“ profitieren.
https://www.computerbase.de/2022-03/directstorage-api-microsoft-windows-10-11/

Ergo:
Direct Storage geht auch auf Win 10. Auf Win 11 wird es einfach etwas schneller/performanter sein

Edit:
Hier gibt es Benchmarks zwischen DirectStorage und Win32 API (~Win 11 vs. Win 10). Unterschiede sind z.B. 2.2sec vs. 2.6sec Ladezeiten --> vernachlässigbar. Es ist deutlich wichtiger, dass das Game mal die Möglichkeiten von SSDs, insbesondere NVMe, von sich aus ausnutzen können. Und dafür ist die DirectStorage API da. Der DirectStorage Festplatten-Zugriffskernel oder wie man dem auch sagen will, ist da im Verhältnis deutlich weniger wichtig. Zumindest bei den momentanen RAM und VRAM-Anforderungen der Spiele. Sobald Spiele mehr RAM verwenden, wird sich DirectStorage auf Win11 wieder etwas stärker absetzen können.

Wenn man sich die Datenübertragungsraten anschaut, dann erreicht man mit DirectStorage ~2x Durchsatz verglichen mit Win32. Das wäre so der Idealfall bezüglich Performanceunterschied. Da es neben der reinen Datenübertragung auch noch andere Dinge zu tun gibt, ist die resultierende Differenz halt deutlich kleiner.
https://uk.pcmag.com/games/139409/with-microsoft-directstorage-game-load-times-dip-to-2-seconds-or-less

https://i.pcmag.com/imagery/articles/03k8kYxG8wHpBB9F38JTXZq-3.png https://i.pcmag.com/imagery/articles/03k8kYxG8wHpBB9F38JTXZq-6.png

Sobald GPU Decompression noch dazu kommt, werden die (relativen) Unterschiede aufgrund der höheren Bandbreiten vermutlich auch wieder etwas ansteigen. Evtl. ist dann der Unterschied zwischen DirectStorage und Win32 dann >2x wie oben mit CPU Decompression. Absolut wird in beiden Fällen (DirectStorage & Win32) die Performance aber steigen und somit kürzere Ladezeiten erreicht. Ergo auch für Win 10 ein Gewinn. Aber bereits 2.6sec Ladezeiten sind eine deutliche Verbesserung verglichen zu dem, was man heute typischerweise hat.

[Platos]

Ah super, danke für die Korrektur.

Aber sehr schön. Wie damals mit ihren ganzen AoE Titeln, die sie zuerst nur in ihrem Store anbieten wollten :D

Aber was heisst, wenn GPU-dekomprimierung dazukommt? Ich dachte, Direct Storage wäre explizit mit GPU Dekompression? Steigt die CPU-Last nicht extrem an, wenn man 5GB/s dekomprimieren muss ? Und wann kommt denn GPU Dekompression dazu, wenns jetzt nicht der Fall ist ?

Also grundsätzlich ist es natürlich erstmal wichtig, dass es überhaupt funktioniert, aber im Grunde sind 5GB/s lesend für den PC etwas langsam. War die SSD einfach nru 5GB/s lesend?

Edit: Aber Ladezeiten sind ja nur die Spitze des Eisbergs. Das eigentlich krasse ist ja das Streaming in den Grafikspeicher (von z.B Texturdaten). Also in Echtzeit meine ich, wie eben bei den Konsolen/PS5.

[basix]

Aber was heisst, wenn GPU-dekomprimierung dazukommt? Ich dachte, Direct Storage wäre explizit mit GPU Dekompression? Steigt die CPU-Last nicht extrem an, wenn man 5GB/s dekomprimieren muss ? Und wann kommt denn GPU Dekompression dazu, wenns jetzt nicht der Fall ist ?
Die oben genannten Bandbreiten waren noch mit Dekomprimierung via CPU. Über die GPU ist es noch nicht möglich:
But for now, the current version of DirectStorage doesn’t support GPU decompression. “This implementation, however, still outperforms existing Win32 APIs,” he said.
Und ja, das punished dann die CPU ;) Wann und wie das via GPU kommen soll ist mir aber unklar. Nvidia hat mit RTX IO ja schon lange was vorgestellt.


Also grundsätzlich ist es natürlich erstmal wichtig, dass es überhaupt funktioniert, aber im Grunde sind 5GB/s lesend für den PC etwas langsam. War die SSD einfach nru 5GB/s lesend?
Hast du dir die Bandbreiten der SATA SSDs mal angesehen? Die sind sogar nach der Dekomprimierung ;) Zum Einsatz kam eine NVMe SSD mit PCIe 4.0, die Limitierung war dann glaube ich die CPU (kann halt nicht schneller dekomprimieren). Via GPU wird es da also schon noch einen Bandbreiten-Boost geben.


Edit: Aber Ladezeiten sind ja nur die Spitze des Eisbergs. Das eigentlich krasse ist ja das Streaming in den Grafikspeicher (von z.B Texturdaten). Also in Echtzeit meine ich, wie eben bei den Konsolen/PS5.
Klar. Das mit dem direkten Streaming in den VRAM ist aber anscheinend auch noch nicht verfügbar. Momentan geht alles noch via CPU. Nichtsdestotrotz ist es bereits ohne GPU-Acceleration ein sehr deutlicher Fortschritt.
While DirectStorage doesn’t fully eliminate the load times, Ono noted the technology is still a work in progress. Future versions will be able to accelerate the load times even more by storing the game’s GPU data on the graphics cards’ memory without going through any CPU processes.

[Neurosphere]

https://abload.de/img/greymon3xjpjbd.jpg

Was immer das heißen mag.

Fast übersehen:

https://abload.de/img/3xlwjvj.jpg

[Platos]

@basix: Ja also das ist ja mal echt lahm. Dann sehe ich auch kein Texturenstreaming in den nächsten Jahren. Aber ja, nvidia mit RTX IO, aber solange AMD da nicht auch was hat, wäre das nicht möglich, sonst müsste man ja 2x das Spiel entwickeln bei völlig unterschiedlicher Streaminggeschw. Der PC bremst hier leider ordentlich aus.

Wenn man die GPU nicht nutzen kann, steigt die CPU-Last vermutlich enorm an. Bei einem Savegameload natürlich irrelevant. Aber in Echtzeit in den Grafikspeicher Streamen geht sicher nicht (vernünftig) mit der CPU, dann braucht jeder nen 16-Kerner aufwärts. Abgesehen davon ist m.M.n nach genau das das Weltbewegende und nicht kürzere Ladezeiten. Das verändert die Spiele nicht, nur die Wartezeit für Gamer.

Also dann finde ich das doch ziemlich enttäuschend.

[Zossel]

Also dann finde ich das doch ziemlich enttäuschend.

Microsoft, wie es leibt und lebt.

[Linmoum]

Linux ist echt immer ein gefundenes Fressen für zukünftige AMD-Produkte. :D I like.

Wieso die Gerüchteküche N33 mit nur 4096 Shadern gleich schnell/schneller als N31 verortet hat, ergibt dann jetzt auch deutlich mehr Sinn.

Das sind 30720 FP32, also 15360 pro GCD.

[HOT]

256Bit pro WGP ist doch nix neues. Daher hat N33 ja nur 20WGPs, ein N32-Chiplet 20WGPs und ein N31-Chiplet 30WGPs.
Die Performance kommt also bei N33 allein durch den Takt, crazy eben.

[OgrEGT]

Linux ist echt immer ein gefundenes Fressen für zukünftige AMD-Produkte. :D I like.

Wieso die Gerüchteküche N33 mit nur 4096 Shadern gleich schnell/schneller als N31 verortet hat, ergibt dann jetzt auch deutlich mehr Sinn.

Das sind 30720 FP32, also 15360 pro GCD.

Gem Schaubild sinds 256 ALUs pro WGP was dann bei 2x30WGPs immer noch 15360 ALUs ergibt?

[Tobalt]

Wenn man die GPU nicht nutzen kann, steigt die CPU-Last vermutlich enorm an. Bei einem Savegameload natürlich irrelevant. Aber in Echtzeit in den Grafikspeicher Streamen geht sicher nicht (vernünftig) mit der CPU, dann braucht jeder nen 16-Kerner aufwärts.

Es liegt doch eh jetzt schon immer viel CPU Leistung brach. Das wäre also ein netter Sinn.

[basix]

Gem Schaubild sinds 256 ALUs pro WGP was dann bei 2x30WGPs immer noch 15360 ALUs ergibt?

Jepp, anhand des Schaubilds ist es nur eine andere Organisation des WGP. Anstatt 4 CU sind es 2 CU, die halt jeweils doppelt so fett sind. An der Rohperformance ändert sich dadurch nicht viel. Bezüglich Flächeneffizienz (Area/Flop) ist es sogar besser, da der Overhead des CU-Aufbaus relativ zur Anzahl ALUs geringer wird.

Es liegt doch eh jetzt schon immer viel CPU Leistung brach. Das wäre also ein netter Sinn.
Ich denke auch ohne das GPU-Streaming ist es schon eine grosse Verbesserung. Meiner Meinung nach werden am PC eh SATA SSDs lange das Minimum bleiben. Und mit dem System-RAM kann man noch was puffern.

Aber ja, Microsoft sollte mal in die Puschen kommen und das GPU-Streaming endlich anbieten. Nvidia hat RTX IO, AMD würde wohl gerne direkt auf den Standard setzen aber wird mMn vermutlich auch mit einer eigenen Lösung nachziehen (man kann VRAM sparen) und Intel vermutlich auch. Aber mit drei separaten Lösungen anstatt einer direkt via API ist das ein wenig unbefriedigend.

DirectStorage GPU Streaming und Sampler Feedback Streaming wären schon sehr hilfreich ;)

[iamthebear]

256Bit pro WGP ist doch nix neues. Daher hat N33 ja nur 20WGPs, ein N32-Chiplet 20WGPs und ein N31-Chiplet 30WGPs.
Die Performance kommt also bei N33 allein durch den Takt, crazy eben.

Navi33 hat nur 16 WGPs @ 3GHz.

Es scheint also so als hätte es AMD geschafft:
.) Den Takt um ca. 20% zu erhöhen ohne Transistoreinsatz oder mehr TDP/FP32
.) Das Speicherinterface zu halbieren ohne Performance zu verlieren oder den Cache zu erhöhen
.) Die FP32 Anzahl/CU zu verdoppeln mit 100% Skalierung

Das ist schon eine sehr beachtliche Leistung.

Von Navi33 aus kalkuliert:
Navi31 = 60/16 = 3.75x

Ich gehe nur davon aus, dass die 375W von Navi31 dann auch hinfällig sein werden. Wenn ich das (sehr) grob kalkuliere:
Navi33 200W mit N6. Bei 1.3x Energieeffizienz in N5 wären wir dann bei 200 / 1.3 * 3.75 = 580W

Meine Vermutung:
Der ursprüngliche Plan war es Navi33 mit 3GHz eher am oberen Ende zu takten (ähnlich Navi22) mit 3GHz während Navi31 ähnlich wie Navi21 ca. 10-15% niedriger getaktet wird bei ca. 2.6-2.8GHz und 375-450W. Aber nachdem Nvidia sich nun entschieden hat das Ding mehr zu pushen wird es AMD auch tun und zumindest einige High End Modelle auch mit 500-550W ausliefern.

Es könnte jedoch auch sein, dass die Taktraten durch die Bank höher sind und sich die 1x 6900XT bei Navi33 auch auf 3.2-3.3GHz beziehen.

[HOT]

Thx for correction.

Und ich stimme zu, 350W für N31 ist utopisch. N32 wirst du im 300W+-Bereich sehen mMn, N31 aber sicherlich über 400W. 600W wird AMD mMn aber nicht machen.
Und ich schätze auch, IPC wird es soviel nicht geben, das wird über den Takt laufen. Aber um die Rechenleistung von einer 6900XT zu schlagen reichen 2,9GHz für N33. Die Taktraten werden aber bei N3x in N5 nicht niedriger ausfallen, kann eher sein, dass man sie dabei belässt und von einer deutlich höheren Energieeffizienz profitiert, weil die 2,9GHz in N5 einfach näher am Sweetspot wären als bei N33 in N6.

[Neurosphere]

Greymon hat seine TFlops angaben bei Navi31 nach oben korrigiert. Von 75 auf 92, was dann doch deutlich mehr als angenommen sind.

Videocradz hat schon eine News dazu rausgehaun:
https://videocardz.com/newz/amd-navi31-flagship-rdna3-gpu-could-hit-92-tflops-of-fp32-performance-four-times-more-than-navi21

Ich mag den Hypetrain nicht.

[ChaosTM]

Ich glaube ehrlich gesagt nicht, dass AMD so dumm wie NV sein wird und wirklich 500+Watt GPUs baut, die dann bei 300 Watt nur 10% kürzere Balken produzieren, aber wer weiß.

Lisa ist glaub ich nicht so balken-fixiert wie der Lederjacken-Mann.
Zumindest bei den AMD eigene Produkten. Die Brettpartner könne sich dann austoben.

[BlacKi]

Ich glaube ehrlich gesagt nicht, dass AMD so dumm wie NV sein wird und wirklich 500+Watt GPUs baut, die dann bei 300 Watt nur 10% kürzere Balken produzieren, aber wer weiß.

Lisa ist glaub ich nicht so balken-fixiert wie der Lederjacken-Mann.
Zumindest bei den AMD eigene Produkten. Die Brettpartner könne sich dann austoben.
würde eine verdoppelte 6900xt bei 300w nur 10% verlieren?

[TheAntitheist]

Ich glaube ehrlich gesagt nicht, dass AMD so dumm wie NV sein wird und wirklich 500+Watt GPUs baut, die dann bei 300 Watt nur 10% kürzere Balken produzieren, aber wer weiß.

Lisa ist glaub ich nicht so balken-fixiert wie der Lederjacken-Mann.
Zumindest bei den AMD eigene Produkten. Die Brettpartner könne sich dann austoben.
Stimmt, Bulldozer war nicht komplett über die Kotzgrenze getaktet nur damit man etwas mit Intel mithalten konnte und das mit fast 300Watt für eine CPU. Stimmt AMD war gar nicht so dumm ;D

Dumm ist wer dummes sagt

[w0mbat]

Dumm ist wer denkt, AMD hätte sich seit Zen und Lisa Su nicht verändert. Bulldozer ist ein Produkt von einem ganz andern AMD.

[ChaosTM]

Nvidia wird, nach dem 3090ti Feld-Test, wohl mindestens 500 Watt für eine halbwegs konkurrenzfähige High End Leistung brauchen.
AMD kann sich zurück lehnen und abwarten diesmal.

Und zur Erinnerung.: ich liebe meine(n) 3080m. Ein Meisterstück an Effizienz, nur schauen die Vorzeichen diesmal gar nicht so gut aus für den Marktführer.

[Linmoum]

Stimmt, Bulldozer war nicht komplett über die Kotzgrenze getaktet nur damit man etwas mit Intel mithalten konnte und das mit fast 300Watt für eine CPU. Stimmt AMD war gar nicht so dumm ;D

Dumm ist wer dummes sagtGab in Deutschland auch mal Kaiser. Für die heutige Zeit nur völlig irrelevant, genau wie sinnlose Bulldozer-Vergleiche.

Noch sinnloser wird dieser Beitrag dann, wenn man bedenkt, dass er extra von Su sprach. Die beim Bulldozer-Launch noch nicht einmal bei AMD tätig war. ;D

Dass der Fokus seit Jahren vor allem auch auf hoher Effizienz liegt, sollte selbst ein blinder mit Krückstock erkennen. Auch, dass man nicht mehr sinnlos alles hochprügelt. Bei N21 hätte man noch Luft gehabt für ein paar Prozente mehr Performance. Wollte man aber offensichtlich nicht.

[Redneck]

Nvidia wird, nach dem 3090ti Feld-Test, wohl mindestens 500 Watt für eine halbwegs konkurrenzfähige High End Leistung brauchen.
AMD kann sich zurück lehnen und abwarten diesmal.


Denke das wäre falsch.. Immer nur zu reagieren. Wenn man vermutlich das schnellste Pferd im Stall hat, muss man irgendwann auch mal überholen und den lead übernehmen und die anderen reagieren lassen. Das image vom sympathischen Underdog wird sich nicht ewig halten lassen.

Könnten ja RDNA3 wieder mit verschiedenen BIOS releasen.. Eco, balanced. Oc.. So ähnlich wie bei Vega damals (nur besser). Damit holt man die Balken und die Öko Fraktion ab.

[robbitop]

Wenn man wirklich deutlich mehr Leistung hat reichen schon 10-15% Takt weg von der Kotzgrenze um deutlich effizienter zu sein als an der Kotzgrenze. Takt ist nunmal extrem nicht linear abhängig von der TDP.

[HOT]

Wobei jetzt angeblich echt 3 GHz mit N31 erreicht werden soll, also 92TFLOPs. Das wäre exakt 4x N21 full. Die Leistung, die dann auf der Strasse bleibt, wird dann sicherlich 2x sein. Vielleicht mehr mit nem Zen4 X3D.

https://videocardz.com/newz/amd-navi31-flagship-rdna3-gpu-could-hit-92-tflops-of-fp32-performance-four-times-more-than-navi21

Das widerspräche meiner Theorie, dass AMD bei irgendwas über 400W bleibt, ich schätz mal das ist an die Kotzgrenze getaktet und dürfte eher 550W entsprechen.

[AffenJack]

Mit diesen Gerüchten ist es einfach komplett unklar, wo man landet. Es ist offensichtlich, dass man wohl nur FP32 in den CUs verdoppelt. Der Großteil vom Rest dagegen nicht. Wird also wie bei Ampere eine massive Compute Steigerung, die aber kaum auszunutzen ist. Damit lässt sich nicht mehr einschätzen, wieviel Leistung das nun bringt. Mehr als 2x natürlich, sonst hätte man sich die Verdopplung der FP32 units sparen können.

[basix]

2.7x Performance steht ja schon lange im Raum. Bei 4x FLOPs ist das nichtmal so abwegig. RDNA2 skaliert mit ~1.7x bei verdoppelten CUs. Nimmt man die selbe Basis für RDNA3, landet man bei 1.7*1.7 = 2.9x.

[w0mbat]

Es ist offensichtlich, dass man wohl nur FP32 in den CUs verdoppelt. Der Großteil vom Rest dagegen nicht.
RGT behauptet in seinem letzten Video, dass eben nicht nur die shader verdoppelt werden, sondern auch der Rest.

[HOT]

Jo sonst würde N33 = N21 Leistung schlichtweg auch nicht passen.

[AffenJack]

RGT behauptet in seinem letzten Video, dass eben nicht nur die shader verdoppelt werden, sondern auch der Rest.

Kann er gerne machen, macht es nicht realistischer, er gibt da eh nur Twitter wieder. Dann hätte man auch gleich 4 CU pro wgp machen können oder einfach mehr verbauen, dann landen wir aber auch in komplett anderen verbrauchsregionen. Man macht die CU mir SIMD32 fetter, damit man sich zusätzliche Logik sparen kann. Manches kann durchaus verdoppelt werden, bei TMUs glaube ich zb nicht dran.

4x Energieeffizienz wird es bestimmt nicht geben.

[fondness]

Da ist sowieso noch einiges im argen IMO. 4x Leistung bei weiterhin nur 256 bit SI? Selbst mit verdoppelten Cache scheint mir das utopisch. Doppelte Energieeffizienz könnte dank Shrink plus Archverbesserungen schon möglich sein, würde dann halt auch 600W TDP bedeuten bei 4x Leistung. Die Kosten sollten halbwegs im Rahmen sein, da wohl nur die WPGs selbst in 5nm kommen - und die WPGs machen bei N21 deutlich weniger als die Hälfte der Die-Size aus, außerdem sollen es ja zwei WPG-Dies sein. Ergo ein WPG-Die wird wohl selbst bei 15K ALUs unter 200 mm² liegen. Den Cache sollte man dank extra Die doppelt so dicht packen können wie bisher, siehe Zen-Cache-Die.

[Platos]

Sind die Gerüchte nun schon bei 4-Facher Leistung angekommen? ;D

[TheAntitheist]

Nvidia wird, nach dem 3090ti Feld-Test, wohl mindestens 500 Watt für eine halbwegs konkurrenzfähige High End Leistung brauchen.
AMD kann sich zurück lehnen und abwarten diesmal.

Und zur Erinnerung.: ich liebe meine(n) 3080m. Ein Meisterstück an Effizienz, nur schauen die Vorzeichen diesmal gar nicht so gut aus für den Marktführer.
bei dem Technologischem Rückstand würd ich mich aber nicht zurück lhnen... Man konnte gerade so wegen dem viel besseren Fertigungsverfahren mithalten. Hör mal lieber auf mit deinem Fanboy getue. Kommst mir schon fast wie ein religiöser Führer vor.

[iamthebear]

Falls die Leaks stimmen, so ist das eigentliche Wunder Navi33.

Im Vergleich zu Navi22:
.) 20-25% mehr Takt
.) 13% weniger TDP
.) 60% mehr FP32 Einheiten
.) Bei ca. 60% Speicherbandbreite
.) Trotzdem ähnliche IPC (bezogen auf FP32 Einheiten), vielleicht 10% weniger
.) Ohne zusätzlichen Cache
.) Ohne zusätzlichen Transistoreinsatz
.) Bei fast gleicher Fertigung (N6 vs. N7P dürfen im Bereich von 10% Energieeffizienz ODER 5% mehr Takt liegen)

Wenn ich das alles zusammenrechne komme ich auf fast 2x Energieeffizienz nur durch die Architektur alleine, was ich schon etwas unglaubwürdig find.

Der Vergleich mit der Navi22 deshalb, weil beide Midrange Karten sind, die beide ca. im selben Bereich der Taktkurve liegen.

Von da aus sind selbst 3.5x für Navi31 eigentlich nicht mehr wirklich spektakulär:
.) N6 => N5P bringt ca. 1.3x Energieeffizienz
.) Wenn man 10% mit dem Takt runter geht hat man nochmal ca. 1.2x Energieeffizienz

Dann sind knapp 3.5x bei ca. 450W auch nicht mehr wirklich ein Problem wenn es keine Probleme mit MCM gibt, was mich jedoch wundern würde.

Das Speicherinterface sehe ich nicht wirklich als Problem an. Mit 512MB Cache sollte man das eigentlich relativ gut abfangen können. Wenn Navi33 mit 128 Bit und 128MB funktioniert, dann wird auch Navi31 mit 256 Bit und 512MB funktionieren.

Die viel größere Frage ist: Wieviele FPS kommen am Schluss dabei heraus weil selbst unter 4K wird die CPU in vielen Fällen gar nicht viel mehr Takt mitmachen und ab einem gewissen Punkt wird der Sinn fraglich weil alles sowieso großteils CPU limitiert sein wird.
Entweder testet man dann mit 8K (wofür es derzeit weder Monitore/TVs noch Schnittstellen dafür gibt) oder es wird durchgehend mit RT getestet allerdings muss man da wohl noch etwas mehr zu Nvidia aufholen.

[Thunder99]

Mal ins blaue geraten bzw spekuliert,

Es gibt bei Navi 31 2x 256bit, Problem mit der Bandbreite + Cache gelöst ;D

Realistisch oder totaler Blödsinn?

[basix]

Sind die Gerüchte nun schon bei 4-Facher Leistung angekommen? ;D

Rohleistung ;)

Falls die Leaks stimmen, so ist das eigentliche Wunder Navi33.

Im Vergleich zu Navi22:
.) 20-25% mehr Takt
.) 13% weniger TDP
.) 60% mehr FP32 Einheiten
.) Bei ca. 60% Speicherbandbreite
.) Trotzdem ähnliche IPC (bezogen auf FP32 Einheiten), vielleicht 10% weniger
.) Ohne zusätzlichen Cache
.) Ohne zusätzlichen Transistoreinsatz
.) Bei fast gleicher Fertigung (N6 vs. N7P dürfen im Bereich von 10% Energieeffizienz ODER 5% mehr Takt liegen)

Wenn ich das alles zusammenrechne komme ich auf fast 2x Energieeffizienz nur durch die Architektur alleine, was ich schon etwas unglaubwürdig find.

Das Ding soll ~400mm2 gross sein in N6. Inkl. der höheren Density sind das ~1.3x Chipfläche. Also ganz "gratis" wäre es also nicht ;)

Und ob N33 eine niedrigere TDP haben wird, sehen wir dann. Ich hätte eher was um 220W erwartet und somit gleichauf mit N22.

[iamthebear]

OK gebe zu es war etwas blöd formuliert.
Meinte natürlich "ohne zusätzlichen Transistoreinsatz pro FP32"

Oder umgekehrt:
Mit den FP32 Einheiten von Navi22 zieht das Ding nochmal 1.6x weniger

Was die TDP angeht ist mein Stand 200W, 6700 XT hatte 230W.

[basix]

Im Endeffekt ist ein N33 auf ~6900XT Niveau in jedem Fall eine starke Engineering Leistung. RDNA3 scheint in verschiedenen Aspekten der Architektur ein Fortschritt zu sein. 5nm und Chiplets kommen als Sahnehäubchen noch oben drauf.

Was bei N33 "extrem" ist, dass bereits RDNA1 in N7 kam. Und N33 wäre in etwa doppelt so schnell und energieeffizient wie N10. Dazu noch Raytracing, DX12U Support und deutlich gesteigerte Taktraten. Meiner Meinung nach sind das aussergewöhnliche Perf/Watt und Perf/Area Steigerungen bei gleichzeitig stark verbessertem Featureset. Und wer weiss, evtl. Matrix Acceleration noch oben drauf.

[iamthebear]

Was man bei der ganzen Sache nicht vergessen darf:
Navi33 ist ein relativ hoch getakteter Midrangechip. Der läuft weit abseits den Sweet Spot und ist trotzdem noch so effizient.

Anscheinend war Energieeffizienz bei AMD ein wichtiges Thema. Das wird sich vor allem im Notebook und APU Markt bezahlt machen. Im Desktopbereich kann Nvidia alles noch brachialer Keule und moderner Fertigung erschlagen aber im Notebookmarkt wird das nicht so einfach sein.

[Thunder99]

Die 4x Performance Steigerung könnten auch auf Raytracing zurückzuführen sein.

[AffenJack]

Im Endeffekt ist ein N33 auf ~6900XT Niveau in jedem Fall eine starke Engineering Leistung. RDNA3 scheint in verschiedenen Aspekten der Architektur ein Fortschritt zu sein. 5nm und Chiplets kommen als Sahnehäubchen noch oben drauf.

Was bei N33 "extrem" ist, dass bereits RDNA1 in N7 kam. Und N33 wäre in etwa doppelt so schnell und energieeffizient wie N10. Dazu noch Raytracing, DX12U Support und deutlich gesteigerte Taktraten. Meiner Meinung nach sind das aussergewöhnliche Perf/Watt und Perf/Area Steigerungen bei gleichzeitig stark verbessertem Featureset. Und wer weiss, evtl. Matrix Acceleration noch oben drauf.

Ich würde noch nicht von so tollen Leistungen reden, wenn noch gar nix in Sachen Verbrauch klar ist und das alles nur Gerüchte sind. Mit hochtakt könnte n33 am Ende auch nicht effizienter als n21 werden, dafür aber günstiger zu fertigen für amd.

Ebenso wissen wir noch kein Stück, ob die Leistung wirklich Richtung 6900 geht. Wenn N31 4x FP32 braucht die 2,7x Leistung, dann sehe ich nicht das N33 N21 Leistung schafft. Kann am Ende auch nur 6800 werden. Das ist mir hier wieder viel zu viel hypetrain.

[Platos]

Ist doch immer Hypetrain hier...

[Neurosphere]

Ist doch immer Hypetrain hier...

Ist es. Scheint aber gerade auf Ada und Navi3x zuzutreffen. In einem halben Jahr dürften wir mehr wissen.

[Dampf]

Was wäre denn, wenn sie diese 4x mehr Rohpower doch auf die Straße kriegen würden?

Das wäre eine Zerstörung nie gekannten Ausmaßes... Das wäre richtig krass. Oh Gott...

Freunde, ich bin echt gehyped!

[iamthebear]

Ich würde noch nicht von so tollen Leistungen reden, wenn noch gar nix in Sachen Verbrauch klar ist und das alles nur Gerüchte sind. Mit hochtakt könnte n33 am Ende auch nicht effizienter als n21 werden, dafür aber günstiger zu fertigen für amd.

Ebenso wissen wir noch kein Stück, ob die Leistung wirklich Richtung 6900 geht. Wenn N31 4x FP32 braucht die 2,7x Leistung, dann sehe ich nicht das N33 N21 Leistung schafft. Kann am Ende auch nur 6800 werden. Das ist mir hier wieder viel zu viel hypetrain.

Normalerweise würde ich an der Stelle die Navi33 auch anzweifeln aber wenn man das Ganze von 4-5 Ecke über Monate verteilt hört, dann wird da wahrscheinlich was dran dran sein. Eine Zeit lang wurde Navi33 ja sogar 20-30% über der 6900 XT eingeschätzt aber ich denke das war noch mit 20 WGPs.

Die Verlustleistung von um die 200W ist ja schon bekannt. Vielleicht werden es auch 225W.

Natürlich sind das alles keine offiziellen Quellen das ist schon klar. Aber dann kann man dieses Subforum gleich dicht machen und bis zu den ersten unabhängigen Reviews in einem halben Jahr warten.

Was die 4x Performance angeht:
Die Vermutung liegt bei 3.75x weil Navi31 3.75x so viele WGPs hat wie Navi33.

Dass die Framerate dabei nicht 3.75x so hoch sein wird sollte klar sein, da fps nicht linear mit der GPU Performance skalieren genauso wie man mit 1080p nicht die 4 fache Performance hat wie mit 4K. Im Normalfall kann man hier von ca. 75% Skalierung ausgehen, im oberen Bereich wahrscheinlich sogar eher 50-60%.

[Platos]

Was wäre denn, wenn sie diese 4x mehr Rohpower doch auf die Straße kriegen würden?

Das wäre eine Zerstörung nie gekannten Ausmaßes... Das wäre richtig krass. Oh Gott...

Freunde, ich bin echt gehyped!

Ich hoffe wirklich, dass du das nicht ernst meinst ;D

[amdfanuwe]

Falls die Leaks stimmen, so ist das eigentliche Wunder Navi33.

Im Vergleich zu Navi22:

Wie sehen denn die Vergleiche zu N23 bzw. N24 aus?
Zu N23 sind es immerhin
.) 100% mehr FP32 Einheiten
.) Bei gleicher Speicherbandbreite

N24 ist praktisch ein halber N23, jedoch schon in 6nm mit 107mm² https://www.techpowerup.com/gpu-specs/amd-navi-24.g965.

[basix]

Ich würde noch nicht von so tollen Leistungen reden, wenn noch gar nix in Sachen Verbrauch klar ist und das alles nur Gerüchte sind. Mit hochtakt könnte n33 am Ende auch nicht effizienter als n21 werden, dafür aber günstiger zu fertigen für amd.

Natürlich sind das alles "wenn es so kommt" Überlegungen. Ist ja immerhin ein Speku-Thread ;)

Ebenso wissen wir noch kein Stück, ob die Leistung wirklich Richtung 6900 geht. Wenn N31 4x FP32 braucht die 2,7x Leistung, dann sehe ich nicht das N33 N21 Leistung schafft. Kann am Ende auch nur 6800 werden. Das ist mir hier wieder viel zu viel hypetrain.

Rohleistung != Performance. Und umso breiter das Design (mehr Recheneinheiten) desto weniger Performance kommt pro TFLOP raus. Ein schmaleres Design wird pro FLOP immer besser dastehen.

CB hat das bei RDNA2 sehr schön getestet: Selbst in 4K kommt nur 70% der zusätzlichen Rohleistung von breiteren GPUs an. N31 soll 3.75x breiter als N33 sein (240 vs. 64 CU). Skaliert RDNA3 gleich wie RDNA2 (unbekannt ob dem so ist), dann wäre N31 genau 2.72x so schnell wie N33 (bei gleichen Taktraten). Dann landen wir wieder genau bei 6900XT Performance für N33, wenn N31 wirklich 2.7x so schnell wie N21 ist. Angenommen in dem konkreten Fall sind natürlich identische Taktraten für N33 und N31.
https://www.computerbase.de/2021-03/amd-radeon-rdna2-rdna-gcn-ipc-cu-vergleich/2/#abschnitt_cuskalierung_in_3840__2160_ultra_hd

Wie sehen denn die Vergleiche zu N23 bzw. N24 aus?
Zu N23 sind es immerhin
.) 100% mehr FP32 Einheiten
.) Bei gleicher Speicherbandbreite

N24 ist praktisch ein halber N23, jedoch schon in 6nm mit 107mm² https://www.techpowerup.com/gpu-specs/amd-navi-24.g965.
Bei N24 fällt noch ein grosser Teil der Video Engine weg. Schwer zu sagen, wie viel das ausmacht, aber 1/2 N23 (232mm2) ist wohl nah dran.

Der Vergleich von N33 mit N23 bietet sich eigentlich sehr gut an:
- 128bit SI --> N33
- PCIe x8 --> N33
- 16 WGPs --> N33
- 32 MByte IF$ --> N33 hat hier 2-4x mehr

Nehmen wir 10% Scaling durch N6 an, landet man bei ~210mm2. Jetzt kommen da noch ein paar CUs und Infinity Cache für N33 dazu, das wars. Da könnten 64CU + 128MB IF$ in ziemlich genau 400mm2 Platz haben. Ist die Frage, ob die RDNA3 CUs mehr Platz brauchen oder nicht und wie der neue WGP Aufbau reinspielt. Ich vermute ja immer noch, dass man auf 64MB IF$ geht aber wer weiss, ob AMD die ~50mm2 für die zusätzlichen 64MB Cache investieren will oder nicht

[AffenJack]

Normalerweise würde ich an der Stelle die Navi33 auch anzweifeln aber wenn man das Ganze von 4-5 Ecke über Monate verteilt hört, dann wird da wahrscheinlich was dran dran sein. Eine Zeit lang wurde Navi33 ja sogar 20-30% über der 6900 XT eingeschätzt aber ich denke das war noch mit 20 WGPs.

Nur weil die Gerüchteküche etwas die ganze Zeit erzählt, heißt das nix. Das geht nur im Kreis, schließlich waren auch die shaderzahlen für N31, N32 für alle sicher und nun?


12288
8192
4096
🤔

https://twitter.com/greymon55/status/1521045114231017472?t=IrSfQaFwHt5IMurpieWKEQ&s=19

Wenn das stimmt, waren seit Monaten alle angeblichen Quellen falsch.

Und 92 Tflops wären es auch nicht mehr, sondern wieder 74 Tflops. 3,2x zu N21
Da sind wir dann auch wieder im Bereichen, bei denen ich mir vorstellen kann, dass in den CUs das meiste gedoppelt ist. Bei 4x FP32 glaube ich daran einfach nicht.

Auch die Lücke N32, N33 kann man dann mit 6000 shadern schön schließen.

[WedgeAntilles]

Was wäre denn, wenn sie diese 4x mehr Rohpower doch auf die Straße kriegen würden?

Das wäre eine Zerstörung nie gekannten Ausmaßes... Das wäre richtig krass. Oh Gott...

Freunde, ich bin echt gehyped!

;D
Ein Meisterwerk, dieser Post IMO

(Ja, ich weiß, dass das Satire ist - da ich dich hier im Forum kenne. Das ist das geniale: Der Post ist gerade so geschrieben, dass das durchaus jemand mit vollem ernst so schreiben könnte. Wirklich gut gemacht :) )

[Gipsel]

Ich vermute ja immer noch, dass man auf 64MB IF$ geht aber wer weiss, ob AMD die ~50mm2 für die zusätzlichen 64MB Cache investieren will oder nichtWie groß ist gleich nochmal das in 7nm produzierte 64MB Cache-Die (das dort bis 4,5GHz Takt mitmacht) für den 5800X3D und Milan-X? Ich vermute mal in 6nm und für etwas geringere Taktraten ausgelegt läßt sich da sogar noch minimal was quetschen. ;)

[davidzo]

Wie groß ist gleich nochmal das in 7nm produzierte 64MB Cache-Die (das dort bis 4,5GHz Takt mitmacht) für den 5800X3D und Milan-X? Ich vermute mal in 6nm und für etwas geringere Taktraten ausgelegt läßt sich da sogar noch minimal was quetschen. ;)

41mm2

https://www.hardwareluxx.de/images/cdn02/uploads/2022/Feb/faster_fork_gv/isscc-2022-amd-zen3-05_1920px.png

Wobei der nur 600gb/s hat, also 32bytes/clock pro Core bzw 256bytes/clock total, was für einen GPU Cache deutlich zu mickrig ist.
Die GPU Cache Taktraten sind bisher ja auch noch niedriger als bei CPUs, das muss man auch bedenken bei der Bandbreite.

Navi21 hat mit 1024bytes/clock das Vierfache, nicht mehr und nicht weniger erwarte ich von Navi33. Das sind also dieselben 256bit pro 32mb wie beim CPUcache. Kleiner wird der GPUcache also kaum.

Das heißt der Cache wird wohl gut die vierfache Fläche verbrauchen wie die 32mb bei Rembrandt, wegen der größeren Anbindung. Wahrscheinlich schraubt man bei assoziativität und line size zurück um die Größe zu optimieren und vielleicht hat man auch das CU-pillar layout optimieren können im Flächenverbrauch.



Hat schon jemand einen Rembrandt Dieshot analysiert? Das wären ja 6nm Zellen.

[basix]

Wie groß ist gleich nochmal das in 7nm produzierte 64MB Cache-Die (das dort bis 4,5GHz Takt mitmacht) für den 5800X3D und Milan-X? Ich vermute mal in 6nm und für etwas geringere Taktraten ausgelegt läßt sich da sogar noch minimal was quetschen. ;)

Wobei der V-Cache ein hochoptimiertes Cache Chiplet ist. Ich bezweifle, dass man das bei einem monolithischen Die ebenfalls so optimieren kann. Bei RDNA2 sprach AMD von 27mm2 für 32MByte. Ergo ~50mm2 in N6 für 64MByte. Im Endeffekt sind 40 vs. 50mm2 kein riesen Unterschied. Aber es sind in beiden Fällen >=10% Die Size von N33. Ist eben die Frage, ob man es braucht. Je nach IF$-Bandwidth Multiplier Rechnerei eben nicht ;) Zumindest nicht <=1440p

Wenn man es braucht und/oder 4K das Ziel sind: Ja, dann machen 128MB mehr Sinn. +10% Die Size sind kein Beinbruch.

Edit:
Die MCDs von N31 und N32 sind eine andere Geschichte. Dort erwarte ich eher was von der Density her wie beim V-Cache.

Edit 2:
Man muss sich auch bei N31 & N32 fragen, ob die 384MB & 512MB Gerüchte wahr sind. 512MByte wären auch bei V-Cache Densities im Bereich ~300mm2. NUR Cache. Da wäre 1/3 der gesamten GPU nur L3-Cache, das ist doch schon etwas absurd.

[basix]

Nur weil die Gerüchteküche etwas die ganze Zeit erzählt, heißt das nix. Das geht nur im Kreis, schließlich waren auch die shaderzahlen für N31, N32 für alle sicher und nun?


https://twitter.com/greymon55/status/1521045114231017472?t=IrSfQaFwHt5IMurpieWKEQ&s=19

Wenn das stimmt, waren seit Monaten alle angeblichen Quellen falsch.

Und 92 Tflops wären es auch nicht mehr, sondern wieder 74 Tflops. 3,2x zu N21
Da sind wir dann auch wieder im Bereichen, bei denen ich mir vorstellen kann, dass in den CUs das meiste gedoppelt ist. Bei 4x FP32 glaube ich daran einfach nicht.

Auch die Lücke N32, N33 kann man dann mit 6000 shadern schön schließen.
Wäre wirklich eine deutliche Änderung. Prinzipiell sind die FLOPs ja egal. Die 2.7x Performance sind das, worauf es drauf ankommt ;)


Noch ein anderes Thema: Matrix Acceleration
Nimmt man die Abschätzungen von Turing (https://www.reddit.com/r/nvidia/comments/baaqb0/rtx_adds_195mm2_per_tpc_tensors_125_rt_07/) und die ML Accelerator (https://www.freepatentsonline.com/y2022/0101179.html) Patente (https://www.freepatentsonline.com/y2021/0026686.html), dann könnte man mit ~40mm2 (10mm2 pro MCD) auf die etwa doppelte Anzahl ML-Accelerators wie TU102 kommen (bei 4x MCDs). Nehmen wir mal 1024 "Tensor-Core" äquivalent an, 256 pro MCD. Bei ~2.5 GHz Takt der MCDs käme man auf ~330 TFLOPs FP16 / ~660 TOPS INT8. Zusammen mit den 4*92 = ~360 TOPS der Shader-CUs würde man aggregated 1.0 PetaOPS INT8 erreichen :D

[Gipsel]

Wobei der nur 600gb/s hat, also 32bytes/clock pro Core bzw 256bytes/clock total, was für einen GPU Cache deutlich zu mickrig ist.Wieviele Datenleitungen man da parallel ins SRAM-Array reinlegt, ist nicht so schwierig zu ändern (und kostet auch nicht so viel Fläche). Bandbreite ist bei SRAM-Arrays im Prinzip recht einfach zu skalieren. Und da es um den (monolithischen) N33 ging, spart man auch noch die Kontakte für das Interface zum anderen Die, daß ja gemäß Deinem Screenshot auch nicht unwesentlich zur Fläche beiträgt. Somit hilft das schon dabei, die zusätzlichen Datenleitungen zu (über-)kompensieren. Zumal der Infinitycache ja nur mit grob der halben Taktrate vom V-Cache läuft (<~2GHz bei RDNA2, Takt ist entkoppelt, Latenz sekundär; 4,5GHz bei V-Cache, Latenz ist kritisch).

========================

Wobei der V-Cache ein hochoptimiertes Cache Chiplet ist. Ich bezweifle, dass man das bei einem monolithischen Die ebenfalls so optimieren kann.Warum? Da die Designregeln kompatibel sind, kann man die SRAM-Makros da praktisch rüberkopieren (und dann sehen, was man wegen 7nm=>6nm und den geringeren Taktanforderungen noch optimieren kann). Sprach AMD nicht mal davon, daß man die Erfahrungen bezüglich der Caches zwischen GPU-und CPU-Abteilung geteilt hätte, um die Lösungen (Infinity-$ und V-$) umzusetzen?
Bei RDNA2 sprach AMD von 27mm2 für 32MByte. Ergo ~50mm2 in N6 für 64MByte.Da wäre die erste Frage, was da Alles mit dabei ist. Nicht Alles muß bei einer reinen Kapazitätsverdopplung auch verdoppelt werden. Hat nicht irgendwer (mit einem recht schlechten Bild) bei Navi21 nachgemessen und kam auf <90mm² für die 128MB?

Zumindest von Navi22 gibt es ja einen passablen echten/selbstgemachten Dieshot (von OCBurner/Fritzchens Fritz), wo die 96MB der SRAM-Arrays für den Infinity-$ sehr gut auszumachen sind und ~56mm² belegen (https://www.reddit.com/r/Amd/comments/r25ew2/rdna2_navi_22_annotation_from_fritzchensfritz_and/) (die dort markierten Bereiche enthalten offenbar auch schon die Tags, man hat da also sehr wohl locker die Dichte vom V-Cache-Die).

[Lehdro]

Wobei der nur 600gb/s hat, also 32bytes/clock pro Core bzw 256bytes/clock total, was für einen GPU Cache deutlich zu mickrig ist.
Die GPU Cache Taktraten sind bisher ja auch noch niedriger als bei CPUs, das muss man auch bedenken bei der Bandbreite.

AMD selbst spricht aber von deutlich mehr Bandbreite zwischen den Dies:
Das TSV-Interface bietet eine Bandbreite von mehr als 2 TBit/s pro Slice. Der Ringbus des L3-Caches kommt ebenfalls auf mehr als 2 TB/s in beide Richtungen und ermöglicht somit das Bereitstellen der maximalen L3-Cache-Bandbreite für die Kerne – auch mit dem zusätzlichen 3D V-Cache.
Quelle (https://www.hardwareluxx.de/index.php/news/hardware/prozessoren/58174-isscc-2022-amd-nennt-details-zum-3d-v-cache-und-ringbus-update.html)

Der begrenzende Faktor bei der Bandbreite scheint demnach derzeit der L3 vom CCD zu sein, nicht der vom 3D V-Cache.

[basix]

Warum? Da die Designregeln kompatibel sind, kann man die SRAM-Makros da praktisch rüberkopieren (und dann sehen, was man wegen 7nm=>6nm und den geringeren Taktanforderungen noch optimieren kann). Sprach AMD nicht mal davon, daß man die Erfahrungen bezüglich der Caches zwischen GPU-und CPU-Abteilung geteilt hätte, um die Lösungen (Infinity-$ und V-$) umzusetzen?.

Klar kann man Erfahrungen übertragen, wenn die Anforderungen ähnlich sind. 100%ig wird das aber nicht ganz funktionieren, da CPUs auf Latenz und GPUs auf Bandbreite getrimmt sind. Von der Anordnung / Dichte des Caches geht es aber in erster Näherung sicher.

Da wäre die erste Frage, was da Alles mit dabei ist. Nicht Alles muß bei einer reinen Kapazitätsverdopplung auch verdoppelt werden. Hat nicht irgendwer (mit einem recht schlechten Bild) bei Navi21 nachgemessen und kam auf <90mm² für die 128MB?

Zumindest von Navi22 gibt es ja einen passablen echten/selbstgemachten Dieshot (von OCBurner/Fritzchens Fritz), wo die 96MB der SRAM-Arrays für den Infinity-$ sehr gut auszumachen sind und ~56mm² belegen (https://www.reddit.com/r/Amd/comments/r25ew2/rdna2_navi_22_annotation_from_fritzchensfritz_and/) (die dort markierten Bereiche enthalten offenbar auch schon die Tags, man hat da also sehr wohl locker die Dichte vom V-Cache-Die).

Dann die Frage, wieso man nicht schon bei RDNA2 den Cache so dicht gepackt hat oder zumindest genannt hat ;) Beim V-Cache hat man von "specialized SRAM process" gesprochen, deswegen die Annahme dass "normale" Prozesse diese Density nicht erreichen werden. Evtl. ist es aber auch gar nicht die Density sondern andere Paramter (Vf curve, Leakage, ...).

Die 56mm2 für 96 MByte hören sich aber sehr gut an. Das wäre wirklich im Rahmen der V-Cache Density. Dann hören sich 128MByte wieder realistischer an. Overhead für Infinity Cache (Control Logic + Infinity Fabric) ist mir aber nicht klar.
Mit diesen Parametern dürfte N33 ~400mm2 gross sein bei 64 CU und 128MB IF$ in N6.

[Gipsel]

Dann die Frage, wieso man nicht schon bei RDNA2 den Cache so dicht gepackt hat oder zumindest genannt hat ;)Wie am Beispiel von Navi22 gezeigt, hat man die Caches doch genau so dicht gepackt. Ich kann mich wie schon erwähnt daran erinnern, daß bei einer Präsentation explizit gesagt wurde, daß die GPU- und CPU-Teams bei den Caches zusammengearbeitet haben (weiß bloß nicht mehr, ob es beim V-Cache oder Infinity-Cache gesagt wurde).
Beim V-Cache hat man von "specialized SRAM process" gesprochen, deswegen die Annahme dass "normale" Prozesse diese Density nicht erreichen werden. Evtl. ist es aber auch gar nicht die Density sondern andere Paramter (Vf curve, Leakage, ...).1. Marketing
2. Der eigentliche Prozess an sich ist gleich
Man benutzt aber eine andere (dichteoptimierte) SRAM-Bibliothek. Und was eventuell beim V-Cache-Die etwas optimiert wurde (gegenüber dem CPU-Die), ist wohl der Metal-Stack (man benötigt ja Dichte und Takt [4.5GHz]). Aber da benutzen GPUs traditionell ja sowieso andere Setups, die von vornherein mehr auf hohe Dichte (statt Takt) getrimmt sind. Bei einer GPU geht die Dichte des Infinity-Caches/V-Caches also offenbar ohne weitere Anpassungen (und der läuft ja auch nur mit maximal 2GHz).

[Leonidas]

Die 92 TFlops waren ein Irrtum. Alte HW-Specs mal neuer Taktraten-Angabe = falscher Wert.

Reales Design-Ziel für N31 soll wohl 75 TFlops gewesen sein. AMD hatte dabei zwei Wege:
1) 15'360 FP32 x 2.4 GHz
oder
2) 12'288 FP32 x 3.0 GHz
... Lösung 1 war ein früherer Entwurf, zum Tape-Out ist nun aber Lösung 2 gegangen.
https://www.3dcenter.org/news/geruechtekueche-aktualisierte-niedrigere-hardware-spezifikationen-zu-amds-navi-31-32

[HOT]

Jo das klingt doch sehr plausibel. Und das gefällt mir auch besser, denn so dürfte das Design deutlich effizienter arbeiten. NV hat sicherlich wieder deutlich mehr TFLOPs, da ja 128Bit pro SM.

Es gab ja Anfangs auch Gerüchte um 20WGP N33, welche sich jedoch sehr früh als 16WGP auflösten.

N33 -> 16WGP
N32 -> 32WGP
N31 -> 48WGP

statt
N33 -> 20WGP
N32 -> 40WGP
N31 -> 60WGP

Daraus könnte man nen ganze Arsch an Produkten machen. Ich hab langsam den Verdacht, dass man deutlich weiter unten anfängt mit N33 als bisher gedacht. Vielleicht gibts ja auch nur einen N23S und ein N22S war ne Ente, der passt eigentlich nicht ins Portfolio. Und N23 zu refreshen ist ja allein schon deshalb sinnvoll, weil Tesla den verbaut. Übrigens ergibt das auch so mehr Sinn, dass N33 mit nur 8GB kommen soll - für ne 7600 wäre das akzeptabel. Vielleicht gibts ja auch ne 16GB-Variante des 7600XT.

N24 -> 7100-7400XT
N23S -> 7500(XT)
N33 -> 7600(XT)
N32 1 Chiplet -> 7700
N32/1 1 Chiplet -> 7700XT
N32 2 Chipet -> 7800
N32/1 2 Chiplet -> 7800XT
N31 2 Chiplet -> 7900XT(X)

[TheAntitheist]

Takt kostet halt nur den Konsumenten Geld. Dann bringt übertakten auch noch weniger. Kann dennoch gut werden!

[Linmoum]

Variante 1 ergibt für mich aber wenig Sinn, wenn tatsächlich schon 3GHz grundlegend als Referenz ohne noch extra zu selektieren stabil genug sind. Da gehe ich von Anfang an auf zweiteres und spare mir alles andere, weil's enorm Die Size spart.

[HOT]

Takt kostet halt nur den Konsumenten Geld. Dann bringt übertakten auch noch weniger. Kann dennoch gut werden!
Für die 0,001% die das Ding übertakten vielleicht.

[TheAntitheist]

Für die 0,001% die das Ding übertakten vielleicht.
okay dann für dich auch noch das: Taktboost der automatisch von der GPU gesteuert wird fällt geringer aus.

Außerdem übertakten viele passiv, weil sie übertaktete Modelle kaufen. Ergo betrifft es bestimmt 30-50% der Käufer. Und das Takt immer mehr Saft zieht betrifft ALLE. Keine Ahnung was dein Post überhaupt soll.

[HOT]

Sry, blödsinn. Die sind halt so leistungsfähig bei xW wie sie eben sind. Das ändert sich nicht, wenn der Zieltakt beim Design dann höher liegt. Außer Übertakter hat niemand Nachteile.

Bei Wattbereichen von 500-600W ist es übrigens eh nicht mehr sinnvoll übertaktete Modelle zu bringen, weil man dafür dann 100W+ einkalkulieren müsste, um da was von zu haben. MMn wird diese Praxis eh noch irrelevanter werden als sie jetzt schon ist.

[Neurosphere]

Bei Wattbereichen von 500-600W ist es übrigens eh nicht mehr sinnvoll übertaktete Modelle zu bringen, weil man dafür dann 100W+ einkalkulieren müsste, um da was von zu haben. MMn wird diese Praxis eh noch irrelevanter werden als sie jetzt schon ist.

Jain. Die normalen Modelle werden nur sehr stark bei den OC-Möglichkeiten begrenzt um die anderen Serien OC-Modelle gut verkaufen zu können.

Leider krasses Beispiel ist meine EVGA 3080 XC3 Ultra die einen harten 330 Watt lock hat und maximal ein paar Prozent mehr zulässt. Ein Kumpel hat dagegen die Asus Strix und kann mit 400 Watt (450 Watt ist maximum) gut 5-10% mehr raus kitzeln.

Ist nicht viel, aber bis auf den VRam spielt man damit schon nahe an einer 3090, dank des geringen Abstandes.

Ob man das braucht sei jedem selbst überlassen, aber das ist nunmal der Unterschied. Die Spannungsversorgung der Karten wird aufgeblasen obwohl es unnötig ist und der Preis dementsprechend hoch angesetzt nur um mit Potentialen zu protzen.

[Achill]

Jain. Die normalen Modelle werden nur sehr stark bei den OC-Möglichkeiten begrenzt um die anderen Serien OC-Modelle gut verkaufen zu können.

Leider krasses Beispiel ist meine EVGA 3080 XC3 Ultra die einen harten 330 Watt lock hat und maximal ein paar Prozent mehr zulässt. Ein Kumpel hat dagegen die Asus Strix und kann mit 400 Watt (450 Watt ist maximum) gut 5-10% mehr raus kitzeln.

Ist nicht viel, aber bis auf den VRam spielt man damit schon nahe an einer 3090, dank des geringen Abstandes.

Ob man das braucht sei jedem selbst überlassen, aber das ist nunmal der Unterschied. Die Spannungsversorgung der Karten wird aufgeblasen obwohl es unnötig ist und der Preis dementsprechend hoch angesetzt nur um mit Potentialen zu protzen.

Das gilt halt für NV aber bisher nicht für AMD (die hatten/haben eine gute Ausstattung und man kann die Limits via Wattman ausfahren, daher gut für WaKüs nutzbar - wenn man will, die +400W müssen nur gekühlt werden), und da wir hier bei der Specu zu AMD's RDNA3 sind .. die Info zur EVGA hat keinerlei Relevanz hier oder Spekuliert ihr, dass AMD seine Strategie ändern?

Ansonsten ggf. einfach in einen anderen Thread weiter führen ..

[Berniyh]

Die 92 TFlops waren ein Irrtum. Alte HW-Specs mal neuer Taktraten-Angabe = falscher Wert.

Reales Design-Ziel für N31 soll wohl 75 TFlops gewesen sein. AMD hatte dabei zwei Wege:
1) 15'360 FP32 x 2.4 GHz
oder
2) 12'288 FP32 x 3.0 GHz
... Lösung 1 war ein früherer Entwurf, zum Tape-Out ist nun aber Lösung 2 gegangen.
https://www.3dcenter.org/news/geruechtekueche-aktualisierte-niedrigere-hardware-spezifikationen-zu-amds-navi-31-32
Ist das wirklich realistisch? Ist ja schon sehr spät in der Entwicklung, baut man da den Chip noch mal so drastisch um?
Und behält zudem noch die Benennung bei statt das Teil dann Navi34/35 oder so zu nennen?

Bin da etwas skeptisch. Klingt für mich eher nach einem Versuch alles mit Spekulation unter einen Hut zu bringen.

[Platos]

Jo das klingt doch sehr plausibel. Und das gefällt mir auch besser, denn so dürfte das Design deutlich effizienter arbeiten. NV hat sicherlich wieder deutlich mehr TFLOPs, da ja 128Bit pro SM.



Ah ja? Seit wann ist weniger SM und dafür deutlich mehr Takt effizienter?

[Leonidas]

Ist ja schon sehr spät in der Entwicklung, baut man da den Chip noch mal so drastisch um?

Wir wissen nicht, wann AMD diese Änderung realisiert hat. Wir haben nur *jetzt* die Info dazu bekommen. Die Änderung könnte vor längerer Zeit erfolgt sein - es ist nur nicht durchgedrungen.



Ah ja? Seit wann ist weniger SM und dafür deutlich mehr Takt effizienter?

Auf gleicher Rohleistung ist mehr Takt immer vorzuziehen. Denn Auslastung von HW-Einheiten ist immer ein Problem, während Takrate 1:1 skaliert.

[Platos]

Ja ok, man muss natürlich dann sagen, was für eine Effizienz und aus wessen Perspektive. Aber Energieeffizienter wird es wohl kaum sein.

Aber effizienter im Sinne von billiger für den Chipentwickler, ist natürlich immer die Taktrate vorzuziehen und nicht niedrig takten und mehr SM.

[WedgeAntilles]

Auf gleicher Rohleistung ist mehr Takt immer vorzuziehen. Denn Auslastung von HW-Einheiten ist immer ein Problem, während Takrate 1:1 skaliert.

Ich stehe auf dem Schlauch - aber wenn ich meine GraKa um 10% übertakte bekomme ich doch nicht 10% mehr Frames? :confused:
Daher doch auch die Attraktivität beim Untertakten, ich spare viel Strom und verliere nur relativ wenig Leistung?

[Linmoum]

Takt skaliert deutlich linearer. Aus 20% mehr Shadern wirst du immer weniger Performance rausholen als aus 20% mehr Takt.

Und beim UV hast du oftmals ja sogar einen höheren Takt als @Stock. Das ist ja der Witz daran.

[Neurosphere]

Das gilt halt für NV aber bisher nicht für AMD (die hatten/haben eine gute Ausstattung und man kann die Limits via Wattman ausfahren, daher gut für WaKüs nutzbar - wenn man will, die +400W müssen nur gekühlt werden), und da wir hier bei der Specu zu AMD's RDNA3 sind .. die Info zur EVGA hat keinerlei Relevanz hier oder Spekuliert ihr, dass AMD seine Strategie ändern?

Ansonsten ggf. einfach in einen anderen Thread weiter führen ..

Dein bisher einziger Beitrag in diesem Thread, Glückwunsch.

Wir wissen nicht, wann AMD diese Änderung realisiert hat. Wir haben nur *jetzt* die Info dazu bekommen. Die Änderung könnte vor längerer Zeit erfolgt sein - es ist nur nicht durchgedrungen.


Es wird vermutlich noch einige Nebelkerzen geben.


N31 XTX = 7970XT
N31 XT = 7950XT
N31 XL = 7900XT
N32 XTX = 7800XT
N32 XT = 7800
N32 XL = 7700XT
N33 XT = 7600XT
N33 XL = 7600


N31 XTX 48WGP/96 CU/12288FP32
N31 XT 42WGP/84CU/10752FP32
N31 XL 36WGP/72CU/9216FP32

N32 XTX 32WGP/64CU/8192FP32
N32 XT 28WGP/56CU/7168FP32
N32 XL 24WGP/48CU/6144FP32

N33 XT 16WGP/32CU/4096FP32
N33 XL 14WGP/28CU/3584FP32

Wobei ich mich hier Frage ob das wirklich so aussieht. Warum sollte AMD das Ganze nicht mischen, also zB. bei N31 ein komplettes Chiplet nicht nutzen und dadurch eine Variante mit nun 6144 CUs bringen? macht natürlich nur begrenzt Sinn volle Chips nicht für was anderes zu nutzen, aber vom Prinzip her wäre das nicht unmöglich. Evtl. sogar teildeaktivierte N31 auf N32 Karten.

[Lurtz]

Warum sollten AMD und nVidia überhaupt Karten bringen, die so einen großen Sprung machen? 2022 400% mehr Leistung und 2023 dann wieder nur 25% mehr? ;D Oder Noch mal so viel und dann 1.000 W Verbrauch? :ugly:

[Linmoum]

AMD verdoppelt mit RDNA4 dann halt die Anzahl der GCD. ;)

Mit Chiplets größere Leistungssprünge zu erzielen ist in jedem Fall deutlich einfacher, als noch mit monolithischen Dies.

[HOT]

GCDs haben den gigantomanischen Vorteil, dass man günstig 1000mm²+ verbauen könnte, wenn man möchte.

[basix]

Wobei ich mich hier Frage ob das wirklich so aussieht. Warum sollte AMD das Ganze nicht mischen, also zB. bei N31 ein komplettes Chiplet nicht nutzen und dadurch eine Variante mit nun 6144 CUs bringen? macht natürlich nur begrenzt Sinn volle Chips nicht für was anderes zu nutzen, aber vom Prinzip her wäre das nicht unmöglich. Evtl. sogar teildeaktivierte N31 auf N32 Karten.

Weil das evtl. aufgrund des Aufbaus einfach nicht sinnvoll geht, ohne dass man 1x komplettes N31 GCD salvagen muss? Und 2x N32 GCD + 3x MCD werden günstiger als salvaged 2x N31 GCD + 4x MCD sein. Das Packaging von N31 wird auch anders aussehen, das gäbe also eine ziemliche Spezial-Karte ohne wirklichen Mehrwert.

[iamthebear]

Nur weil die Gerüchteküche etwas die ganze Zeit erzählt, heißt das nix. Das geht nur im Kreis, schließlich waren auch die shaderzahlen für N31, N32 für alle sicher und nun?


https://twitter.com/greymon55/status/1521045114231017472?t=IrSfQaFwHt5IMurpieWKEQ&s=19

Wenn das stimmt, waren seit Monaten alle angeblichen Quellen falsch.

An den Zahlen war gar nichts falsch. Die ursprüngliche Planung von AMD waren 5K/10K/15K und das wurde auch korrekt berichtet.
AMD hat sich vor dem Tapeout jedoch entscheiden um ca. 20% zurück zu fahren.
Dass solche Dinge nicht sofort leaken, sondern erst nach einer gewissen Zeit sollte klar sein und dass sich über ein halbes Jahr vor Release noch einiges ändern kann sollte klar sein.

Und 92 Tflops wären es auch nicht mehr, sondern wieder 74 Tflops. 3,2x zu N21

Klar die 92TFlops ergeben sich ja direkt aus FP32 Anzahl und Taktrate. An sich ist die FP32 Anzahl aber egal. Wichtig ist das Performanceziel und das ist weiterhin gültig bzw. passt nun auch wieder mit der Navi33 Performance zusammen bzw. macht das Lineup generell so deutlich mehr Sinn.

Da sind wir dann auch wieder im Bereichen, bei denen ich mir vorstellen kann, dass in den CUs das meiste gedoppelt ist. Bei 4x FP32 glaube ich daran einfach nicht.

Die 3.75x waren genauso realisierbar gewesen nur hat sich AMD dagegen entschieden vermutlich weil das dann keiner mehr bezahlen will.

Auch die Lücke N32, N33 kann man dann mit 6000 shadern schön schließen.

Ich glaube nur nicht, dass die besonders oft verkauft werden, denn so schlecht sind die Yieldraten nicht, dass man 1/4 weg schnipseln muss. Das ist dann die neue 6800.

41mm2

Ich weiß nicht wie aussagekräftig das ist, denn ein Teil der Kontrolllogik dürfte bereits in den darunter liegenden 32MB vorhanden sein.

Zum Vergleich: Bei Navi22 sind es 58mm² für 96MB also 1,65MB/mm² siehe
https://semianalysis.substack.com/p/nvidia-ada-lovelace-leaked-specifications?s=r

Wobei der nur 600gb/s hat, also 32bytes/clock pro Core bzw 256bytes/clock total, was für einen GPU Cache deutlich zu mickrig ist.
Die GPU Cache Taktraten sind bisher ja auch noch niedriger als bei CPUs, das muss man auch bedenken bei der Bandbreite.

Wenn man das Ganze dann aber 6 Mal verbaut (6x64 = 384MB), dann sind wird auch wieder bei ca. 3.5TB. Zum Vergleich: Navi21 hatte 2TB also liegen wird da nicht so weit daneben.
Ich weiß aber nicht, ob man das überhaupt sinnvoll vergleichen kann. Der L3 einer CPU hat in erster Linie den Sinn die Latenz zu senken. Bei GPUs geht es eher mehr darum den effiektiven Durchsatz bei Speicherzugriffen zu erhöhen. Das wird vermutlich intern ganz anders organisiert sein.

Navi21 hat mit 1024bytes/clock das Vierfache, nicht mehr und nicht weniger erwarte ich von Navi33. Das sind also dieselben 256bit pro 32mb wie beim CPUcache. Kleiner wird der GPUcache also kaum.

Navi33 ist ja noch monolithisch. Ich denke da wird der Cache ziemlich ähnlich zu Navi21 sein. Ich denke da werden die Optimierungen eher wo anders liegen, dass man den Bandbreitenbedarf generell etwas drosselt.
AMD muss ja keine Wunder wirken. Es reicht wenn man auf das Niveau von Nvidia heran kommt.

Hat schon jemand einen Rembrandt Dieshot analysiert? Das wären ja 6nm Zellen.

Ich glaube das würde ziemlich stark verfälschen, da die Gesamtmenge an Cache deutlich geringer ist.
SRAM ist meines Wissens nach von N7 auf N6 nicht nennenswert geschrumpft.


Man muss sich auch bei N31 & N32 fragen, ob die 384MB & 512MB Gerüchte wahr sind. 512MByte wären auch bei V-Cache Densities im Bereich ~300mm2. NUR Cache. Da wäre 1/3 der gesamten GPU nur L3-Cache, das ist doch schon etwas absurd.

Vor 1-2 Wochen hat Red Gaming Tech ein Video gebracht wo er von einem "cut down" Navi31 Die mit 24WGP/GCD erzählt hat. Ich schätze einmal das wird in Wahrheit der Full Die gewesen sein.

Seine Aussage war, dass dieser entweder 192MB oder 384MB hat, wobei ich dann 192MB ausschließen würde.

Jo das klingt doch sehr plausibel. Und das gefällt mir auch besser, denn so dürfte das Design deutlich effizienter arbeiten. NV hat sicherlich wieder deutlich mehr TFLOPs, da ja 128Bit pro SM.

Bei Nvidia dürften es in Summe ca. 2.7 GHz werden, was bei 144SM und 128FP32 dann um die 100TFlop ergibt. Damit wären beide wieder ca. gleich schnell nur AMD deutlich energieeffzienter, was in erster Linie an der Architektur an sich liegt.
Kepler L2 meinte zwar, dass auch 192 FP32 möglich sind, da ursprünglich für GH202 geplant. Das wäre mit einem 2.5x Transistorbudget zwar möglich (1.7x Shader * 1.5x SM Erweiterung = 2.55x) jedoch würde das bedeuten, dass Nvidia einen Weg gefunden hat die Taktrate ohne Transistoreinsatz 1.4x zu erhöhen was ich für eher unwahrscheinlich halte. Was man bei dem Ganzen Hype nicht vergessen darf: Die geplanten >3x von GH202 waren mit MCM unter 3nm geplant. Das wird monolithisch in 4N nicht klappen.

Es gab ja Anfangs auch Gerüchte um 20WGP N33, welche sich jedoch sehr früh als 16WGP auflösten.

Das liegt wohl daran, dass Navi33 einfach schon etwas näher am Launchtermin dran ist wodurch schon mehr Leute in die Spezifikationen eingeweiht sind.

Daraus könnte man nen ganze Arsch an Produkten machen. Ich hab langsam
den Verdacht, dass man deutlich weiter unten anfängt mit N33 als bisher gedacht. Vielleicht gibts ja auch nur einen N23S und ein N22S war ne Ente, der passt eigentlich nicht ins Portfolio. Und N23 zu refreshen ist ja allein schon deshalb sinnvoll, weil Tesla den verbaut. Übrigens ergibt das auch so mehr Sinn, dass N33 mit nur 8GB kommen soll - für ne 7600 wäre das akzeptabel. Vielleicht gibts ja auch ne 16GB-Variante des 7600XT.

N24 -> 7100-7400XT
N23S -> 7500(XT)
N33 -> 7600(XT)
N32 1 Chiplet -> 7700
N32/1 1 Chiplet -> 7700XT
N32 2 Chipet -> 7800
N32/1 2 Chiplet -> 7800XT
N31 2 Chiplet -> 7900XT(X)

Laut Gerüchten wird Phoenix Anfang nächsten Jahres als Mobile + APU vorgestellt mit RDNA3 und 6WGPs. Wenn man das hochrechnet wäre das bei ausreichend TDP (was AM5 ja liefern kann) ca. in der Größenordnung von 6600 und 6600 XT. Da wird es nicht mehr viel Sinn ergeben GPUs in dieser Performancekategorie aufzulegen. Zur Not wird man von Navi33 etwas mehr wegschnipseln.

Was die 7700/7700 XT angeht: Es gibt bisher keine Hinweise darauf, dass Varianten mit nur 1 GCD geplant sind bzw. ist nicht klar, ob das überhaupt möglich ist.
Da jetzt aber nur mehr 2x zwischen Navi33 und Navi32 liegen (so viel wie zwischen Navi21 und 22) ist das auch nicht wirklich notwendig.
Navi31 und 32 liegen sowieso nur 1.5x auseinander. Da braucht es auch kein Mischen von großen/kleinen GCDs. Da verwendet man einfach 2 teildefekte Navi31.

Ist das wirklich realistisch? Ist ja schon sehr spät in der Entwicklung, baut man da den Chip noch mal so drastisch um?
Und behält zudem noch die Benennung bei statt das Teil dann Navi34/35 oder so zu nennen?

Die Änderungen sind schon vor einigen Monaten passiert und hat es solange gedauert bis es durchgesickert ist. An sich ist es eher überraschend wie viele Informationen schon bekannt sind. Bei Ampere haben wir erst 2 Tage vor der Vorstellung von den 128 FP32 erfahren. Aber da waren sie auch nicht bei TSMC. Ob das ein Zufall ist :freak:

Die Namenskonvention ist auch fix vorgegeben:
Die erste Ziffer bezeichnet die Generation (z.B. 3 für RDNA3)
Die zweite Ziffer bezeichnet die Performance: x1 ist der größte Die, x2 der zweitgrößte usw.
Nvidia hat da ein ähnliches System nur mit Buchstaben für die Generation und die Nummern dann meistens 02, 03, 04, 06 und 07.

Bin da etwas skeptisch. Klingt für mich eher nach einem Versuch alles mit Spekulation unter einen Hut zu bringen.

Ich sehe das eher umgekehrt. Vorher hat es wenig Sinn ergeben, da die Performance von 2.5x-3x nicht zur FP32 Anzahl von 3.2x-3.75x gepasst hat.

Auf gleicher Rohleistung ist mehr Takt immer vorzuziehen. Denn Auslastung von HW-Einheiten ist immer ein Problem, während Takrate 1:1 skaliert.

Das halte ich für eine sehr theoretische Diskussion, denn es ist nicht bekannt mit welchem Transistor/TDP Einsatz z.B. eine 20%ige Steigerung des Taktes möglich ist.

Es wird vermutlich noch einige Nebelkerzen geben.

Das ist gut möglich. Nur weil es jetzt einigermaßen sinnvoll erscheint muss das noch nicht viel heißen.

Wobei ich mich hier Frage ob das wirklich so aussieht. Warum sollte AMD das Ganze nicht mischen, also zB. bei N31 ein komplettes Chiplet nicht nutzen und dadurch eine Variante mit nun 6144 CUs bringen? macht natürlich nur begrenzt Sinn volle Chips nicht für was anderes zu nutzen, aber vom Prinzip her wäre das nicht unmöglich. Evtl. sogar teildeaktivierte N31 auf N32 Karten.

Bisher ist noch nichts davon bekannte, dass es Varianten mit nur 1 GCD geben wird. Navi31 und 32 zu mischen macht meiner Ansicht nach keinen Sinn. Da kann man gleich 2 Salvage Navi31 verbauen (oder 1 guten und 1 halb defekten Die).
Einen Navi31 statt 2x teildeaktivierte Navi32 zu verbauen würde bedeuten, dass man zusätzlich blindes Silizium braucht. Ist die Frage, ob sich das wirklich lohnt. Bisher ist die Lücke zwischen der 6800 XT und der 6700 XT auch kein großes Problem.

[Berniyh]

Die Änderungen sind schon vor einigen Monaten passiert und hat es solange gedauert bis es durchgesickert ist.
Natürlich, wenn es passiert ist, dann schon vor längerem.
Trotzdem bleibe ich bei der Einschätzung: ich halte es auch einigen Monate vor Tape-Out für unrealistisch.
Meine Skepsis bleibt daher.
An sich ist es eher überraschend wie viele Informationen schon bekannt sind.
Zu Navi2x wussten wir schon früher deutlich mehr. Die einzige wirkliche Unbekannte da war der IF bzw. dessen Größe und die Art des Speicherinterfaces.
Die Namenskonvention ist auch fix vorgegeben:
Die erste Ziffer bezeichnet die Generation (z.B. 3 für RDNA3)
Die zweite Ziffer bezeichnet die Performance: x1 ist der größte Die, x2 der zweitgrößte usw.
Das kannst du nicht sicher wissen. Navi 1x war komplett anders beziffert und passt auch nicht wirklich in das Schema.
Bei Navi 2x war es nun so wie bei dir beschrieben, aber einmal ist nunmal keine Serie. Es gibt keine Garantie, dass AMD das wieder so macht.
Eigentlich würde man auch eher erwarten, dass die Nummern nach Designnummern vergeben werden, d.h. man hat halt mit dem Top Produkt angefangen und später dann die anderen beiden Chips entworfen.
Da die größten Chips die kompliziertesten sind macht das natürlich Sinn, aber das gibt dir nicht zwingend eine Garantie, dass die Nummerierung so ablaufen muss. Schon gar nicht, nur weil Nvidia das so macht.

Und ich würde wirklich erwarten, dass man ein neues Design auch unter neuer Chipnummer rausbringt und nicht eine Bezeichnung recycled.
Das macht aus Perspektive der Chipentwicklung einfach keinen Sinn, weil es nur für Fehler intern sorgt, wenn jemand das durcheinander bringt.

[AffenJack]

Ist das wirklich realistisch? Ist ja schon sehr spät in der Entwicklung, baut man da den Chip noch mal so drastisch um?
Und behält zudem noch die Benennung bei statt das Teil dann Navi34/35 oder so zu nennen?

Bin da etwas skeptisch. Klingt für mich eher nach einem Versuch alles mit Spekulation unter einen Hut zu bringen.

Ist auch kompletter BS. Die gleiche Behauptung gab es auch bei Lovelace vor dem Treiber Leaks. Jetzt reden sich die Leute nur damit raus, dass sich die Sachen geändert haben und machen sich damit erst recht lächerlich. Entwicklung funktioniert so nicht, dass du kurzerhand nochmal so eine Änderung vornimmst. Das würde den Chip zumindest 6 Monate verzögern.

Zeigt eher, dass die einfach nur paar Schnipsel am Infos haben, ein großer Teil aber schlicht von den "leakern" erfunden wird.

[Zossel]

Zeigt eher, dass die einfach nur paar Schnipsel am Infos haben, ein großer Teil aber schlicht von den "leakern" erfunden wird.

Gerüchte und Wahrheit kann man schon mal verwechseln.
Und wenn die neuen GPUs demnächst nicht mehr sinnvoll zu kühlen sind werden Vergleiche sowieso obsolet.

[mboeller]

wenn jetzt N33/N32/N31 genau die 1/2/3-fache Anzahl an CU haben, warum gibt es dann nicht nur 1 GCD? Wäre IMHO doch logisch. Warum ist N33 laut Leakern monolithisch? N31 hätte dann aber dann eine 384bit Speicheranbindung (3x 128bit)

[Linmoum]

Ist auch kompletter BS. Die gleiche Behauptung gab es auch bei Lovelace vor dem Treiber Leaks. Jetzt reden sich die Leute nur damit raus, dass sich die Sachen geändert haben und machen sich damit erst recht lächerlich. Entwicklung funktioniert so nicht, dass du kurzerhand nochmal so eine Änderung vornimmst. Das würde den Chip zumindest 6 Monate verzögern.

Zeigt eher, dass die einfach nur paar Schnipsel am Infos haben, ein großer Teil aber schlicht von den "leakern" erfunden wird.Jop, das ist auch völliger Quatsch. Dass Takt X möglich ist, weißt du nicht erst kurz vor Schluss und entscheidest dich auch gleich von Anfang an für weniger CUs und mehr Takt.

Keine Ahnung, wie man überhaupt darauf kommt, dass AMD sich spontan dazu entscheidet, 20% CUs zu streichen und dafür den Takt um 25% anzuheben. Wenn, dann hat AMD so von Anfang an geplant und die 240 CUs waren nie ernsthaft ein Thema. Aber nicht umgekehrt.

[vinacis_vivids]

@mboeller
Weil die Positionierung von N33 sehr wichtig ist. Entweder super Preis-Leistung, um alle Karten der Konkurrenten zu kassieren, durch kleinere Fläche, wenig Verbrauch und extrem hohe Ausbeute. Oder super-Leistung, viel Cache, viel Takt, hoher Preis, viel Fläche, um sich als Nr.1 zu positionieren.

[HOT]

Irgendwie ist hier glaub ich was durcheinander geraten.

N33 -> 16WGPs
N32 -> 2x 32WGPs
N31 -> 2x 48WGPs

Klar ist N33 monolithisch, der ist ja auch der standard mobile-chip.


Ansonsten stimme ich zu, N32/1 sind schon so konzeptioniert worden, bevor sie in die Chipentwicklung gegangen sind. Es kann sein, dass es vorher Konzepte von 60 WGPs gab, immerhin geistert N31 ja schon seit Frühjahr 2020 herum. Ich bin sogar davon überzeugt, dass sich die Leaker N32 komplett zusammengesponnen haben, das einzige, was daran stimmte, war, dass es einen N32 gibt. Die jetzigen Daten werden jedoch stimmen. Dass man die CUs weiter integriert ist auch nur logisch, denn mit RDNA1 fing man dieses ja mit der CU-Spieglung in einem WGP an, RDNA3 setzt diese Entwicklung fort.

[Iscaran]

Ich möchte hier mal grad auf meine Spekulation von OKTOBER 2021 verweisen (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12808278#post12808278), als ich schon meinte, dass es nur 1 Form GCD geben wird und die Ausgestaltung dann sein wird:

MCD/GCD (N33)
MCD/GCD+1GCD (N32)
MCD/GCD+2GCD(N31)

EDIT: MCD/GCD ist bei mir die "Basis"-Einheit.

Nach allem was wir NUN wissen sieht es doch genau so aus:
N33 wird das "monolithische" Die sein der MCD (der auch schon einen Basis-GCD enthält)
N32 und N31 sind dann Chiplets die zu dieser BASIS +1 GCD (16WGPs) und +2 GCD (+2x16WGPs) hinzuaddieren.
Das ergibt also ganz zwanglos:
N33 = 16 WGP (2 SEs zu je 8 WGP)
N32 = 32 WGP (16 + 16) (4SEs (2x2))
N31 = 48 WGP (16 + 2x16) (6SEs (3x2))

Und ob N33 damit wirklich "monolithisch" ist lass ich mal offen, anhand der nun geleakten Infos, wäre es eher plausibel, dass AMD hier vielleicht sogar komplett in "Chiplets" denkt.
GPU-Core (Chiplet (vermutlich aber jeweils speziell für N31/N32/N33)
GCD 16 WGPs (Chiplet für alle identisch)
Das ganze wird dann nur noch durch den "Cache" verklebt.

Fragt sich nur ob der "Kleber", also der Cache ein extra "chiplet" ist oder TEIL des GCD oder MCD sein muss.

Ich vermute fast, da der Cache ja in der Architektur von RDNA so eine wesentliche Rolle spielt, das dieser daher Teil des GCDs ist.

Wenn wir also annehmen N33 ist der GPU-Kern + die BASIS-GCD-Einheit und der Cache muss teil der GCD sein dürfte N33 mit 128 MB cache daherkommen.

Entsprechend N32 mit 2x128 und N31 mit 3x128.

Die Speicheranbindung ist mir nicht 100% klar und ob dann das SI "mitwächst" (also z.B. 128 Bit bei N33, 192 Bit bei N32 und 256 Bit bei N31), aber Basix kann uns dazu sicher mehr Spekus liefern :-).

EVtl. ist das SI aber eben als Teil des GPU-Core welcher ja für jeden Chip hier anders ist eh einfach individuell und wird halt an die Notwendige Breite angepasst.

Vielleicht sollte ich einen Twitter Account erstellen und mich AMD-Leaks nennen :-).

[HOT]

Jetzt alles komplett wieder aufzuschnüren ist einfach nicht zielführend. Ich würd mich an die Infos halten, die momantan herumlaufen und die sprechen von 12k Shadern bei N31.

[amdfanuwe]

Irgendwie ist hier glaub ich was durcheinander geraten.

N33 -> 16WGPs
N32 -> 2x 32WGPs
N31 -> 2x 48WGPs


Bringst du da nichts durcheinander?
N32 -> 2x 16WGPs = 32WGPs
N31 -> 2x 24WGPs = 48WGPs

[HOT]

Stimmt

[fondness]

Nur weil die Gerüchteküche etwas die ganze Zeit erzählt, heißt das nix. Das geht nur im Kreis, schließlich waren auch die shaderzahlen für N31, N32 für alle sicher und nun?


https://twitter.com/greymon55/status/1521045114231017472?t=IrSfQaFwHt5IMurpieWKEQ&s=19

Wenn das stimmt, waren seit Monaten alle angeblichen Quellen falsch.

Und 92 Tflops wären es auch nicht mehr, sondern wieder 74 Tflops. 3,2x zu N21
Da sind wir dann auch wieder im Bereichen, bei denen ich mir vorstellen kann, dass in den CUs das meiste gedoppelt ist. Bei 4x FP32 glaube ich daran einfach nicht.

Auch die Lücke N32, N33 kann man dann mit 6000 shadern schön schließen.

Wie soll man die 12288 ALUs von N31 bzw. 8192 ALUs von N32 mit angeblich 2 WPG-Dies anbieten? Dann müsste es drei WPG Dies sein mit jeweils 4096 ALUs. Und N33 könnte dann auch ein MCM sein mit einem WPG-Die?!

[HOT]

Ein GCD wird sicherlich auf 2 MCDs gestapelt sein mMn.

[amdfanuwe]

dass es nur 1 Form GCD geben wird und die Ausgestaltung dann sein wird:

MCD/GCD (N33)
MCD/GCD+1GCD (N32)
MCD/GCD+2GCD(N31)

EDIT: MCD/GCD ist bei mir die "Basis"-Einheit.

N33 ist 6nm. Macht doch keinen Sinn da 5nm GCD Chiplets dranzuhängen.

--------

Ich versteh euer Problem nicht.
Beim ursprünglichem Entwurf hat man mit 10WGP / SE geplant.
Neuere Erkenntnisse durch Simulation, 5nm Testchips etc. haben dann ergeben, dass 8WGP / SE bei gleicher TDP durch höheren Takt sinnvoller sind.

Also geht
N31 2 * 3SE * 8 WGP = 2*24WGP = 2 * 3SE * 2048 Shader = 12288 Shader
N32 2 * 2SE * 8 WGP = 2*16WGP = 2 * 2SE * 2048 Shader = 8192 Shader
in Produktion.

Nur meine Meinung.

[HOT]

Bei GCN waren 10 CUs pro Shaderengine am effizientesten. Die WGPs sind ja erheblich größer, das wird so sein, dass da 8 am effizientesten sind pro SE.

[basix]

Ein GCD wird sicherlich auf 2 MCDs gestapelt sein mMn.

Und wie soll das dann bei N32 funktionieren?

[nordic_pegasus]

Ich versteh euer Problem nicht.
Beim ursprünglichem Entwurf hat man mit 10WGP / SE geplant.
Neuere Erkenntnisse durch Simulation, 5nm Testchips etc. haben dann ergeben, dass 8WGP / SE bei gleicher TDP durch höheren Takt sinnvoller sind.


das wäre erstmal zu beweisen. Wie bereits hier mehrfach geschrieben wurde, dürfte mehr Takt die Kosten für Kühlung und den Verbrauch steigen lassen, welche durch die AiB Partner und den Kunden zu tragen sind. Hingegen spart AMD mit jedem mm² eingespartem Silizium.

Ferner wird damit tendenziell die finale SKU näher an die Kotzgrenze bzw. weiter weg vom Sweet-Spot betrieben. Ohne konkretes Wissen über Navi3x finde ich die aktuellen Leaks keine positive Entwicklung.

[Linmoum]

Richtig, ohne konkretes Wissen kann man nicht beurteilen, ob 3GHz überhaupt schon Kotzgrenze wären.

Das hat man damals schon bei der PS5 gedacht, als nach und nach deren Takt bekannt wurde. Wie wir mittlerweile wissen, ist der Takt der PS5 sogar noch konservativ angesetzt im Vergleich zu dem, was möglich ist.

[vinacis_vivids]

N6 erlaubt bereits mit RDNA2 - 6500XT rund ~ 2,9Ghz ohne Mühe:
https://abload.de/img/6500xtcoreclockyckb7.png

Mit einer internen uArch Verbesserung bei RDNA3 sind sicherlich auch konservative 3,1Ghz drin beim Single-Chip N33.
Die Taktrange für ne einfache Luftkühlung wird so konservativ 2,9-3,1Ghz sein.
Optimistisch 3,0-3,2Ghz.
Super Optimistisch 3,1-3,3Ghz :eek:

N33 XTX @ 4096SP @ 3,3Ghz ~ 27,03 Tflop/s fp32 :eek:

N21 XTX @ 5120SP @ 2,6Ghz ~ 26,62 Tflop/s fp32

So ein N33 @ 3,3Ghz fegt so ziemlich alles weg was zurzeit auf dem Markt ist :D

[HOT]

Und wie soll das dann bei N32 funktionieren?
Na dann gibts halt nur ein MCD ;).

Erste Lage:

MCD - Com+I/O - MCD

darauf gestapelt

GCD1 GCD2

Ich kann mir nicht vorstellen, dass das Ganze nur ein MCM wird.

[Leonidas]

Wie gesagt soll N33 rein monolithisch und nur in 6nm daherkommen. Daher auch die kürzeste Zeitspanne zwischen Tape-Out und Release. In der Frage würde ich den Leakern durchaus vertrauen.

[HOT]

N33 kommt aber mMn nicht als erstes. N31 und 33 werden gleichzeitig vorgestellt werden, später kann N32 noch nachfolgen, solange können teildeaktiviert N31 die Aufgabe übernehmen.

[amdfanuwe]

das wäre erstmal zu beweisen. Wie bereits hier mehrfach geschrieben wurde, dürfte mehr Takt die Kosten für Kühlung und den Verbrauch steigen lassen,
Nein. TDP ist das Designziel.
Da kann ich nun viele Einheiten mit geringem Takt oder weniger Einheiten mit mehr Takt betreiben um auf die gewünschte TDP zu kommen.
Hat beides seine Vor- und Nachteile.
Der maximale Takt ist durch den Prozess und die Architektur vorgegeben. Da will man nichts verschenken.
Also, Ziel TDP geteilt durch den Verbrauch einer Einheit bei max Takt = Anzahl der möglichen Einheiten.
Eventuell hat sich AMD beim Verbrauch der Einheiten oder bei den Möglichkeiten die der Prozess bietet anfänglich verschätzt und rudert nun etwas zurück.

Vielleicht haben sie auch schon am N23 mit 2*8 WGPs gesehen, dass dieser fürs Gaming Effizienter als N22 mit 2*10 WGPs ist.

Sieht man ja auch bei den CPUs. Der 5950 wird bei All Core Last durch die TDP ausgebremst, fürs Gaming wiederum ist ein 5800X3D besser.

Seien wir mal sicher, dass AMD alle Möglichkeiten kalkuliert und die Absicht hat ein Produkt in den Markt zu bringen, dass ihnen den maximalen Gewinn bringt.
Das klapt halt nur, wenn man gegenüber der Konkurrenz punkten kann.

[Iscaran]

Wie gesagt soll N33 rein monolithisch und nur in 6nm daherkommen. Daher auch die kürzeste Zeitspanne zwischen Tape-Out und Release. In der Frage würde ich den Leakern durchaus vertrauen.


Das ergibt ja auch Sinn und passt zu den Überlegungen die ich selbst im Oktober 2021 angestellt hatte.

N33 ist der "Kern" eine vollfunktionsfähige GPU mit wie wir nun wissen wohl 16 WGP.

Der Cache dient dabei als "Kleber" und Datentransferleitung. Deswegen wird Cache an Cache gestackt beim Chiplet-Design für die notwendigen Kommunikationsbrücken.

Ich hatte mir das so vorgestellt.
N33 ist der monolithische Kern der aufgrund seiner Notwendigkeit eben "extra" gefertigt werden muss.
N32 ist dann N33+1GCD
N31 = N33+2GCD

Das SI könnte dabei sogar mitskalieren, wenn man es an der einen Seite anbringt. Ebenso wie in dem Design der Cache "mitwächst".

So könnten dann die 3 "Basis-Chips" so aussehen:
N33 128Bit SI und 128 MB Cache
N32 128+64=192 Bit SI und 128+64 MB =192 MB Cache
N31 128+2x64=256 Bit SI und 128+2x64 = 256 MB Cache

Die Cache-Größe könnte natürlich anders aussehen, wenn z.B. der N33 seinen "eigenen" Cache in seinem "Kern GCD" mitbringt, und die beiden "Brückencaches" dann komplett zu den "Chiplet-GCDs" gehören.

Mit so etwas könnte man dann z.B. 64+128+128 realisieren oder 128+128+128 oder...

Ebenso die Frage des SIs ob das so einfach wie hier skizziert "mitwachsen" kann.

Auf jeden Fall passt diese Anordnung zum Leak
N33 = 16 WGP
N32 = 32 WGP
N31 = 48 WGP
und besteht faktisch aus 2 Bauteilen (Kern-GCD und Chiplet-GCD).

[Gipsel]

Sieht man ja auch bei den CPUs. Der 5950 wird bei All Core Last durch die TDP ausgebremst,OT-Nitpick: Normalerweise durch das TDC-Limit, das PPT (Standard 1.35*TDP) erreicht er unter Volllast auf allen Kernen meist gar nicht (weswegen ein 5950X unter All-Core-Last auch oft etwas weniger verbraucht als z.B. ein 5900X).
/OT

[basix]

OT-Nitpick: Normalerweise durch das TDC-Limit, das PPT (Standard 1.35*TDP) erreicht er unter Volllast auf allen Kernen meist gar nicht (weswegen ein 5950X unter All-Core-Last auch oft etwas weniger verbraucht als z.B. ein 5900X).
/OT

Jepp, die guten und spannungsarmen Chiplets lassen die Ströme steigen.

[Gipsel]

Jepp, die guten und spannungsarmen Chiplets lassen die Ströme steigen.Ein 5950X hat hat einfach mehr schaltende Transistoren, durch die der Strom fließt (16 parallele Kerne halt). Da kommt dann einfach mehr zusammen (auch wenn der Takt etwas leicht niedriger liegt), sogar ohne extra Binning dafür. ;)

[iamthebear]

Natürlich, wenn es passiert ist, dann schon vor längerem.
Trotzdem bleibe ich bei der Einschätzung: ich halte es auch einigen Monate vor Tape-Out für unrealistisch.
Meine Skepsis bleibt daher.

Das ist ganz normal, dass alle möglichen verschiedensten Varianten simuliert werden und dann entscheidet man sich für eine davon. Einige Monate vor Tape out ist da noch alles offen.
Dass bestehende Pläne geändert werden ist auch vollkommen normal. Man muss sich schließlich den Marktanforderungen anpassen z.B. wieviel Kapazität hat man zur Verfügung, wie werden sich die Preise von VRAM und anderen technischen Komponenten entwickeln, wie wird sich das allgemeine Preisniveau entwickeln (ohne Miner eher niedriger) und natürlich auch: was macht der Mitbewerber.

Das beste Beispiel ist hier der VCache: Am Anfang war der noch für den 5900X präsentiert inkl. Benchmarks, später jedoch nur für den 5800X released weil man gemerkt hat, dass es da am Sinnvollsten ist.

Zu Navi2x wussten wir schon früher deutlich mehr. Die einzige wirkliche Unbekannte da war der IF bzw. dessen Größe und die Art des Speicherinterfaces.

Also "mehr" würde ich auf keinen Fall sagen. Man wusste einiges aber da war noch viel falsch z.B. 400W TDP, Performance ca. auf 3070 Ti Niveau, 512Bit Speicherinterface (auch über HBM wurde spekuliert) inkl. Taktraten um die 2.7 GHz.

Das kannst du nicht sicher wissen. Navi 1x war komplett anders beziffert und passt auch nicht wirklich in das Schema.
Bei Navi 2x war es nun so wie bei dir beschrieben, aber einmal ist nunmal keine Serie. Es gibt keine Garantie, dass AMD das wieder so macht.

Natürlich kann das AMD jederzeit ändern aber das werden sie werden nur weil sich die Spezifikationen früh in der Designphase leicht geändert haben neue Nummern vergeben.

Eigentlich würde man auch eher erwarten, dass die Nummern nach Designnummern vergeben werden, d.h. man hat halt mit dem Top Produkt angefangen und später dann die anderen beiden Chips entworfen.

Es wird intern sicher Designnummern geben aber die Bezeichnungen richten sich aktuell nach Generation und Performance nicht nachdem welcher Chip früher angefangen wurde, wobei "angefangen" ist relativ weil das Grundkonzept von Navi31/32 wurde ja schon entworfen lange bevor klar war, ob das nun 1, 2 oder 3 Dies werden.

Und ich würde wirklich erwarten, dass man ein neues Design auch unter neuer Chipnummer rausbringt und nicht eine Bezeichnung recycled. Das macht aus Perspektive der Chipentwicklung einfach keinen Sinn, weil es nur für Fehler intern sorgt, wenn jemand das durcheinander bringt.

Im gesamten Entwicklungszyklus einer GPU gibt es tausende von Versionen und Änderungen bis da am Schluss ein fertiges Produkt daraus wird. Da erfindet man doch nicht jedes Mal neue Produktnamen nur weil sich eine Kleinigkeit ändert.

Ist auch kompletter BS. Die gleiche Behauptung gab es auch bei Lovelace vor dem Treiber Leaks. Jetzt reden sich die Leute nur damit raus, dass sich die Sachen geändert haben und machen sich damit erst recht lächerlich. Entwicklung funktioniert so nicht, dass du kurzerhand nochmal so eine Änderung vornimmst. Das würde den Chip zumindest 6 Monate verzögern.

Wieso sollte sich die Entwicklung des Produktes verzögern wenn VOR Tapeout die Anzahl der WGPs angepasst wird. In der Phase existieren sowieso noch zig verschiedene Designvarianten alle parallel mit verschiedenen Speicherinterfache/VRAM/Cache und WGP Varianten und vor Tapeout wird dann die endgültige Entscheidung getroffen welche Varianten schlussendlich an den Start gehen.

Das war bei RDNA 2 auch nicht anders. Da wurden auch alle möglichen Cachevarianten simuliert von 5 bis 150MB um die durchschnittlichen Hitrates zu bestimmen und irgendwann ist die Entscheidung gefallen welche Karte wieviel bekommt.

Bei Nvidia wurden sogar fertige SKUs wie die 3070 Ti 16GB mit AD103 weil man festgestellt hat, dass das im aktuellen Markt keinen Sinn ergibt.

Zeigt eher, dass die einfach nur paar Schnipsel am Infos haben, ein großer Teil aber schlicht von den "leakern" erfunden wird.

Es sind Leaks und Spekulationen in der Regel immer klar ersichtlich. Wenn diverse Newsseiten und Youtuber dann jedoch einen Post mit 3 Fragezeichen als "Fakten" darstellen, dann ist das nicht die Schuld der Leaker.
Wenn etwas falsch ist, dann sind es zu 99% veraltete Informationen.

wenn jetzt N33/N32/N31 genau die 1/2/3-fache Anzahl an CU haben, warum gibt es dann nicht nur 1 GCD? Wäre IMHO doch logisch. Warum ist N33 laut Leakern monolithisch? N31 hätte dann aber dann eine 384bit Speicheranbindung (3x 128bit)

Da gibt es mehrere Gründe:
.) Das Packaging bei MCM ist teuer und bei Navi33 wahrscheinlich nicht mehr rentabel
.) Das Ganze macht wenig Sinn wenn man 2 kleine N6 Dies miteinander kombiniert
.) Das Konzept sieht so aus, dass die MCMs die Bridges zwischen 2 GCDs sind. Mit 1 GCD wird das vermutlich genauso funktionieren, mit 3 jedoch wahrscheinlich nicht in der Form
.) 384 Bit mit 384MB+ Infinity Cache wäre zu viel.

Ein weiterer Faktor ist, dass AMD gar nicht so viel 5nm Kapazität hat um alle GPUs damit zu fertigen. Bei Nvidia ist das anders. Die haben die Kapazzitätserweiterungen von TSMC vorfinanziert. AMD hat das Geld noch nicht.

Jop, das ist auch völliger Quatsch. Dass Takt X möglich ist, weißt du nicht erst kurz vor Schluss und entscheidest dich auch gleich von Anfang an für weniger CUs und mehr Takt.

Die Entscheidung fällt vor dem Tape out welche Variante verwendet wird.
Den Takt kann man in dieser Phase nur grob simulieren aber ob das dann im fertigen Produkt auch so funktioniert sieht man erst am Schluss wenn man die ersten Prototypen im Haus hat.
Die 2.5GHz waren die simulierten Werte und vermutlich hat man hier erstmal den Worst case angesetzt.
Doe 3GHz sind nun die realen Werte.

Keine Ahnung, wie man überhaupt darauf kommt, dass AMD sich spontan dazu entscheidet, 20% CUs zu streichen und dafür den Takt um 25% anzuheben. Wenn, dann hat AMD so von Anfang an geplant und die 240 CUs waren nie ernsthaft ein Thema. Aber nicht umgekehrt.

Wie kommst du denn darauf? Die 25% mehr Takt haben doch nichts mit den 20% weniger WGPs zu tun. Das ist reiner Zufall, dass das sich das in etwa deckt. Die 25% hätte AMD auch genauso mit den vollen 60 WGPs erreicht jedoch dann eher mit 450W statt 375W. Oder eben 15-20% mehr Takt mit den vollen 60 WGPs und selber TDP.

Ich möchte hier mal grad auf meine Spekulation von OKTOBER 2021 verweisen (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12808278#post12808278), als ich schon meinte, dass es nur 1 Form GCD geben wird und die Ausgestaltung dann sein wird:

MCD/GCD (N33)
MCD/GCD+1GCD (N32)
MCD/GCD+2GCD(N31)

Navi33 ist N6 und monolithisch.
Wenn AMD dasselbe GCD verwenden wollte, dann hätten sie z.B. mit 16/24/48 WGPs released statt mit 16/32/48.

EDIT: MCD/GCD ist bei mir die "Basis"-Einheit.

N32 und N31 sind dann Chiplets die zu dieser BASIS +1 GCD (16WGPs) und +2 GCD (+2x16WGPs) hinzuaddieren.

MCM funktioniert komplett anders. Die "Basis" ist nur mehr der IO Die. Dazu kommen dann GCDs in 5nm die nur mehr die Rechenlogik enthalten) und die MCDs, die Bridge zwischen den MCDs spielen und das Speicherinterface beinhalten, wobei ich mir bei der Bridgefunktion nicht ganz sicher bin. Diese könnte auch in den IO Doe gewandert sein. Dieser kam im Patent noch nicht vor).

Und ob N33 damit wirklich "monolithisch" ist lass ich mal offen, anhand der nun geleakten Infos, wäre es eher plausibel, dass AMD hier vielleicht sogar komplett in "Chiplets" denkt.
GPU-Core (Chiplet (vermutlich aber jeweils speziell für N31/N32/N33)
GCD 16 WGPs (Chiplet für alle identisch)
Das ganze wird dann nur noch durch den "Cache" verklebt.

Wäre vermutlich möglich und wird möglicherweise auch in späteren Architekturen so kommen aber im Moment sind sich eigentlich alle Quellen bei Navi33 einig und die Daten sind schon sehr genau bekannt:
.) Monolithisch in N6
.)16 WGPs
.) 128MB Cache
.) 128 Bit Speicherinterface
.) 8GB RAMe Hin
.) Um die 400mm² Chipfläche (+/- 50mm²)
.) ca. 200W (+/- 25W) wobei sich dies noch ändern könnte
.) >= 3GHz, vermutlich Richtung 3.2-3.3GHz

Natürlich besteht immer noch die Möglichkeit, dass davon irgendetwas falsch sein sollte aber solange es keine Hinweise dafür gibt, dass die 8nformationen falsch sind und das Gesamtkonzept schlüssig ist macht es wenig Sinn über andere theoretische Varianten zu spekulieren.

Ich vermute fast, da der Cache ja in der Architektur von RDNA so eine wesentliche Rolle spielt, das dieser daher Teil des GCDs ist.

Nein der generelle Trend bei MCM geht dazu Cache extern drauf zu stacken, da SRAM seit 7nm deutlich schlechter als Logik skaliert. Abgesehen davon: Die grundsätzliche Funktionsweise von RDNA3 ist ja bekannt. Da gibt es ein öffentliches Patent dazu.

Einmal abgesehen:
MCD = Multi Cache Die
GCD = Graphics Compute Die

Wo wird der Cache da wohl sitzen ;-)

EVtl. ist das SI aber eben als Teil des GPU-Core welcher ja für jeden Chip hier anders ist eh einfach individuell und wird halt an die Notwendige Breite angepasst.

Das Speicherinterface in die GCDs zu stecken ergibt nicht viel Sinn. Nach meinen aktuellen Informationen sitzt dies in den MCMs, wobei auch die Variante denkbar wäre, dass das Speicherinterface im IO Die sitzt und die MCMs direkt drauf gestacked sind.
In den GCDs wäre Unfug, da:
.) Das Speicherinterface schlecht mit 5nm skaliert
.) Ein GCD sonst zur RAM Ansteuerung immer den kompletten Weg zum anderen GCD nehmen müsste
.) Vom RAM gelesene Daten ja nicht nur an das GCD geliefert werden müssen, sondern auch an das MCD (der Cache soll ja aktuell verwendete Daten speichern)

N33 kommt aber mMn nicht als erstes. N31 und 33 werden gleichzeitig vorgestellt werden, später kann N32 noch nachfolgen, solange können teildeaktiviert N31 die Aufgabe übernehmen.

Navi31 hatte als erstes den Tape out aber aber Navi33 wird früher launchen. Navi31 braucht auf Grund des komplexeren Systems mehr Zeit.

Ich vermute:
Die Produktion von Navi31 und Navi32 startet parallel. Navi31 macht einen Paperlaunch (bei 2000€ wird die Auflage sowieso nicht allzu groß sein) und Navi32 wird dann etwas vorproduziert, dass man bis zum richtigen Launch genug auf Lager hat.

[amdfanuwe]

Ein weiterer Faktor ist, dass AMD gar nicht so viel 5nm Kapazität hat um alle GPUs damit zu fertigen. Bei Nvidia ist das anders. Die haben die Kapazzitätserweiterungen von TSMC vorfinanziert. AMD hat das Geld noch nicht.

Unsinn.
Erstens hätte AMD das Geld
Zweites muß AMD als guter Kunde nicht vorfinanzieren
AMD wird sicherlich die benötigten 5nm Kapazitäten bekommen. Da ja nur kleine Chiplets mit gutem Yield in 5nm von AMD gefertigt werden, brauchen sie auch nicht die große Menge.
Was würde zudem ein N33 in 5nm bringen?
Etwas kleiner, etwas effizienter, etwas schneller dafür einiges teurer.
I/O skaliert halt schlecht bei Fläche und Verbrauch.
Als Mainstream Chip kommt es vor allem auf BILLIG an.
Und ich schätze mal, da wird AMD mit N33 Preis/Leistungsmäßig im Desktop und Mobil punkten, wenn auch nicht gerade mit Effizienz.

[horn 12]

Vor Allem durch den Refresh gehe ich November/ Dezember oder Jänner/ Februar 2023 mit dem Navi 33 Karten einher, sprich dessen Release!
6950XT bringt wohl gute 10 bis max. 15% Mehrleistung

[WedgeAntilles]

Unsinn.
Und dann kommt so was von dir:


Erstens hätte AMD das Geld
Zweites muß AMD als guter Kunde nicht vorfinanzieren


Unglaublich.
Sorry, aber DU bist derjenige, der keine Ahnung hat.
Ich mache mir jetzt gar nicht die Mühe das weiter zu erklären, google wenn du willst das Thema Nvidia / TSMC.
Willst du natürlich nicht, sonst hättest du nicht so einen Quark rausgehauen.

[gedi]

Vor Allem durch den Refresh gehe ich November/ Dezember oder Jänner/ Februar 2023 mit dem Navi 33 Karten einher, sprich dessen Release!
6950XT bringt wohl gute 10 bis max. 15% Mehrleistung

Im Schnitt 5%! Unter 4k Max. 8%! Wenn der Preis gleich bleibt, oder besser 100€ in der UVP nach unten korrigiert wird, okay. Traurig trotzdem der Vergleich zu jeder (!) 6900 XTXH, welche es es zum Teil für etwas weniger als 1100€ zu kaufen gibt! Beinahe jeder kann eine XTXH dank MPT die GPU dahin tweaken, dass se für viel mehr Leistung, weniger Saft benötigt!

Zum Thema: Die geleakten neuen Infos sind wohl alles XL-, oder XT-Produkte! Keine davon erscheint mir als XTX wahrscheinlich!

[Berniyh]

Das ist ganz normal, dass alle möglichen verschiedensten Varianten simuliert werden und dann entscheidet man sich für eine davon. Einige Monate vor Tape out ist da noch alles offen.
Dass bestehende Pläne geändert werden ist auch vollkommen normal. Man muss sich schließlich den Marktanforderungen anpassen z.B. wieviel Kapazität hat man zur Verfügung, wie werden sich die Preise von VRAM und anderen technischen Komponenten entwickeln, wie wird sich das allgemeine Preisniveau entwickeln (ohne Miner eher niedriger) und natürlich auch: was macht der Mitbewerber.
Nein, man ändert Pläne nicht einfach mal so. Nicht bei Produkten die so eine lange Planungszeit vorab haben.
Das ist ziemlich unrealistisch.
Viel realistischer ist, dass diverse Leaker einfach falsche Informationen haben (oder jetzt haben, wie auch immer …).
Das beste Beispiel ist hier der VCache: Am Anfang war der noch für den 5900X präsentiert inkl. Benchmarks, später jedoch nur für den 5800X released weil man gemerkt hat, dass es da am Sinnvollsten ist.
Im Gegenteil, das ist das denkbar schlechteste Beispiel, da die Entwicklung der beiden Produkte sicherlich gekoppelt ist (man braucht ja schließlich die Verbindungsmöglichkeiten), aber die finale Zusammenführung ist weitgehend unabhängig vom ursprünglichen Design.
Der VCache funktioniert prinzipiell auf jedem Zen 3 Chiplet, was spielt es da schon eine Rolle um man nun einen 5600X, 5800X, 5900X oder 5950X nimmt? Das ist sich – bezogen aufs Design – gleich.

[amdfanuwe]

google wenn du willst das Thema Nvidia / TSMC.

Google selbst mal, dann wüßtest du, dass Nvidia die aktuelle Generation bei Samsung fertigen läßt weil TSMC sich nicht ausspielen ließ.
https://www.tomshardware.com/news/amd-becomes-tsmc-third-largest-customer
AMD hat letztes Jahr einiges mehr zu TSMCs Umsatz beigetragen als Nvidia.
AMD wächst, Xilinx kommt hinzu.

[Linmoum]

Aktuelles Video von RGT:

- Die 12288 ALUs beziehen sich laut zwei seiner Quellen auf 1 GCD
- Die Size: "high 300 to low 400"
- ggf. sogar 384MB Cache/384bit SI, wobei er da unterschiedliches hört
- Nicht 3D-Stacked
- Takt 3GHz+
- Performance weiterhin ~2.5x auf N31
- "compute heavy games" mehr, RT ebenfalls (deutlich) mehr
- Bzgl. N33: "Clock frequency is ridiculous", "WELL north of 3000 MHz"

[mboeller]

Aktuelles Video von RGT:

- Die 12288 ALUs beziehen sich laut zwei seiner Quellen auf 1 GCD


Aha... sind wir jetzt also schon bei 120-150TFlops...

wo ist das Bild vom Hypetrain wenn man es braucht...

[Linmoum]

Wie kommst du auf so viele TFLOPs? Er sprach nicht davon, dass es dann auch 2 GCDs sein würden. ;)

Davon ab würden die 2.5x Performance dann auch gar nicht mehr passen.

[fondness]

- Bzgl. N33: "Clock frequency is ridiculous", "WELL north of 3000 MHz"

Da startet jetzt die CPu-Abteilung offensichtlich so richtig durch mit ihrem Takt-knowhow. Nachdem ja schon N2x im selben Prozess die Frenquenzen um ~30% angehoben hat. Bin gespannt ob NV da Taktmäßig mitgeht.

[HOT]

Aha... sind wir jetzt also schon bei 120-150TFlops...

wo ist das Bild vom Hypetrain wenn man es braucht...

Oh das war noch gar nichts, die nächsten Monate werden dahingehend echt lustig, auch bei NV ;). Allerdings wird der Hype eben teuer mit 600W bezahlt.

[davidzo]

- Die 12288 ALUs beziehen sich laut zwei seiner Quellen auf 1 GCD

Das wären dann ja aber wieder 60WGP pro DIE.
Oder eine Vervierfachung der Alus pro WGP. Die Verdopplung hatten wir ja aber aus Treiberleaks, da wird also etwas dran sein, glaube kaum dass sich das noch ändert.


- Die Size: "high 300 to low 400"
Das ist imo schon recht großes DIE für N5. N21 in N5 wäre klar unterhalb von 300mm2 und der hat 40WGP, wenn auch ohne die ALuverdopplung.

[HOT]

Schon lustig, dass man uns diese Generation so einen gigantischen Sprung spendiert. Wer hätte damit rechnen können. Ob Intel was damit zu tun hat? Vielleicht hatten AMD und NV ja tatsächlich panik davor, dass Intel mit modernsten Prozessen doch nen Stich landen könnte und schaukelten sich intern immer weiter hoch mit den Produktaussichten.

[dildo4u]

Muss das nicht die Roadmap sein damit man Exacale in 2023 erreichen kann die Zwei Die Lösung kommt ja von der AMD Server Sparte.

[mboeller]

Wie kommst du auf so viele TFLOPs? Er sprach nicht davon, dass es dann auch 2 GCDs sein würden. ;)

Davon ab würden die 2.5x Performance dann auch gar nicht mehr passen.


N31 sind aber angeblich 7 Die (Greymon55). Wahrscheinlich 2x GCD, 1x I/O, 4x MCD

[basix]

Grundsätzlich macht 1x GCD, 1x I/O und 4x MCD sehr viel Sinn. Ist im Prinzip eine Auslagerung der schlecht skalierenden und/oder über mehrere SKUs shared Funktionsblöcke (L3$, GDDR6 SI, PCIe, Video & Display) und das GCD bleibt separat. Das Ding wird sich auch wie eine monolithische GPU verhalten, da hätte ich gar keine Zweifel und all die schwierigen Dinge bezüglich GCD <-> GCD Kommunikation, L2$ usw. entfallen komplett. Prinzipiell ist es ja immer noch eine monolithische GPU. Meiner Meinung nach ein smartes Design mit nur 1x Nachteil: Mehrere und damit kleinere GCDs funktionieren damit nicht.

Edit:
Es könnten auch 6x MCDs mit je 64MByte und 64bit SI sein. Ohne IO-Die. Dann landet man auch wieder bei 7 Chiplets. Wäre doch lustig, wenn AMD während des Designprozesses die CUs auf 80% reduziert hätte (80->64 bei N33, 240->192 bei N31), das Speicherinterface um +50% aufgebohrt wurde und dann folgendes Lineup rauskäme:
- N31: 12'288 Shader, 3.0+ GHz, 384bit, 384MByte IF$ (6x MCD)
- N32: 8'192 Shader, 3.0+ GHz, 256bit, 256MByte IF$ (4x MCD)
- N33: 4'096 Shader, 3.0+ GHz, 192bit, 128MByte IF$ (monolithisch oder doch 2x MCDs? ;))

I/O, Display & Video kann auf dem GCD sein, muss aber nicht. Auslagerung könnte mMn Sinn machen.

6x MCDs + 1x IOD wären von der Fläche her 350...400mm2 gross. Wenn das N31 GCD laut Gerüchten nun ebenfalls 400mm2 gross wird, wären also ~50% der Chipfläche ausgelagert. Und trotzdem bleibt man bei einer ~monolithischen GPU. Irgendwie kann ich mich gut mit diesem Konzept anfreunden.

Im Endeffekt:
Die Leaker und z.T. wir produzieren viel heisse Luft und am Schluss kommt es dann doch anders :D

Edit 2:
Und noch was zum nachdenken: 384bit + 384 MByte ergeben auf ziemlich genau der selben N6 Chipfläche ~1.3x an effektiver Bandbreite verglichen zu 256bit + 512 MByte. Bei dann vermutlich zwar auch ~1.4x Stromverbrauch für SI + Infinity Cache aber pro Bit Bandbreite sind beide Varianten auf sehr ähnlichem Niveau.

Edit 3:
Und was wäre mit der Idee, dass N33 am Desktop mit nur 96bit/21Gbps und dafür 12 GByte antritt? Für 1080p/1440p sollte das noch knapp reichen. Im Notebook oder entsprechende "Lower End SKUs" am Desktop mit 128bit/16Gbps und 8GByte. Bei beiden Konfigurationen liegt die GDDR6 Bandbreite bei ~250 GByte/s.
- N33 v1: 64 CU, 96bit, 21Gbps, 12 GByte --> Salvaged MCDs? ;)
- N33 v2: 64 CU, 128bit, 16Gbps, 8 GByte --> Tiefere VRAM Kosten

~150mm2 in N5 + ~150mm2 in N6 ist vermutlich auch ähnlich teuer oder sogar günstiger wie N33 als monolithisches 400mm2 N6 Die. Ich sehe da auch kein Hindernis.

[davidzo]

Eine sehr interessante und in sich schlüssige Überlegung, aber das widerspricht halt allen bisherigen Gerüchten und Treiberleaks.

Es hat ein paar Schwächen:
- N33 ist mit größter Wahrscheinlichkeit monolitisch. (Leaks und der Umstand dass es N6 ist und der Rest der Familie N5).
- Ein 64bit MCD macht am meisten Sinn, wenn man auch 64bit Abstufungen hat, also 256bit und 192bit für N31 und N32. Bei 384, 256 und 128 wäre der kleinste gemeinsame Nenner aber 128bit. Die Dies wären schon winzig in N6 und yields vermutlich sehr gut, insofern lastet man sich da sicher nicht ohne Not noch extra Packagingauffwand auf.
- Yields sprechen eher dafür dass der N6 Teil kein problem wird und gerne groß sein kann, während es mehr sinn macht das komplexe 5nm GCD aufzuteilen.
- Wenn der Cache nicht mit auf dem N5 DIE ist, dann ist die gesamte benötigte Bandbreite Off-DIE, braucht also viel breitere Interconnects, als wenn ein großer ON-DIE Cache vorhanden ist. Müsste ich eine Multichip GPU designen und dabei mit off-die Bandbreite haushalten, dann würde ich caches auf jedes Compute-DIE mit draufpacken um Bandbeite und damit interconnect density zum SI Chiplet und DRAM zu sparen.

96bit / 12GB N33 ist eine spannende Idee, das fände ich attraktiver als 128bit/8gb, obwohl letzteres vermutlich in den meisten Benches aktuell noch besser abschneiden würde.

[basix]

Klar ist das was anderes als die Gerüchteküche kocht. Aber wie man an den letzten Tagen sieht wissen selbst die "gut informierten" Leute nicht, wie RDNA3 schlussendlich genau aussieht.


64 MByte + 64bit werden inkl. interconnect zum GCD ~50...60mm2 gross sein. Passt mMn für ein Chiplet. Wenn was beim Packaging bei einem einzelnen MCD schiefläuft --> Salvage SKU mit 320/192bit SI
4x MCDs für N31 und 3x MCDs für N32 ginge sicher auch. Bei N32 wäre dann eines der MCD stirnseitig angeordnet. Ein breiteres SI und dafür etwas weniger Cache wäre aber wie gesagt bezüglich Bandbreite/Chipfläche besser
RDNA3 nur in N5 wäre generell nicht so dumm (N31, N32, Phoenix, usw. --> alles N5). N33 als extra Rückport auf N6 fand ich schon immer etwas eigenartig. Egal wie "eindeutig" das aus der Gerüchteküche kam
Yields in N6 sehe ich auch nicht als grosses Problem an. Da bin ich bei dir. Aber kostenmässig wird es eben auch nicht wirklich günstiger als 3-4 chiplets in gemischt N5/N6. Vor allem, wenn man normales Packaging ohne 2.5D oder gar 3D Ansätze verfolgt.
Offchip Bandbreite ist nicht zwingend problematisch: 0.25pJ/bit (UCIe mit Info_LSI) = 2W pro TByte/s. 4W mit UCIe Standard Package (Substrat only). Selbst N31 mit potentiell ~6 TByte/s hinter dem Infinity Cache wäre mit 24W noch unproblematisch bezüglich Interconnect zwischen den Chiplets.
Interconnect Density ist vermutlich noch das grösste Problem. UCIe Standard Package ist bei 22...125 GB/s. 6 TByte/s = 48...272mm2. Ich denke aber, dass 2-3 TByte/s für die Performance von N31 reichen sollten --> 16...136mm2. 3TB/s bei 24 GT/s UCIe würde dann 32mm2 bedeuten. Das wäre ca. 10% Chipfläche-Overhead für den Interconnect. Jeweils auf beiden Seiten (MCD und GCD). Bei RDNA4 kann man ja dann auf InFO_LSI oder EFB umsteigen.


Edit:
Mir sagt der oben beschriebene Ansatz vor allem wegen folgendem zu: Wegen der Einfachheit. Ist einfach viel simpler als alle 2x GCD Lösungen, GCD <-> GCD Interconnects fallen weg und kein RDNA3 Rückport auf N6.

Und der wirklich einzige Nachteil ist, dass die GCDs etwas grösser werden, als wenn man sie halbieren könnte. Das würde ich dann potentiell bei RDNA4 sehen. Man kann das auch als schrittweise Entwicklung ansehen:

RDNA1 als Initialdesign
RDNA2 mit Infinity Cache
RDNA3 mit ausgelagertem Infinity Cache + SI, Single-GCD
RDNA4 mit ausgelagertem Infinity Cache + SI, Multi-GCD (6x GCDs max.) --> Gerüchte sprechen von N41 - N45 --> 6 / 4 / 2 / 1 Chiplets (N41 - N44) + 1x Chiplet dediziert für Mobile (N45) --> Sogar Re-Use von RDNA3 MCDs + (allfälligem) IO-Die wäre denkbar --> Nur die kleinen GCDs müssten für RDNA4 neu entwickelt werden

[mboeller]

Prinzipiell ist es ja immer noch eine monolithische GPU. Meiner Meinung nach ein smartes Design mit nur 1x Nachteil: Mehrere und damit kleinere GCDs funktionieren damit nicht.


ich hatte mir vorgestern nach den neuen Leaks mal den Die-Shot des N21 nochmal angeschaut.

für mich schaut es so aus, als ob die Shader, L2, IF$ und Speicher schon ziemlich "dezentral" sind. Alles ist in mehrfacher, meistens 4facher Form vorhanden. Nur der Command-Processor/Geometry-Processor ist nur 1x vorhanden.

Aus den alten Diskussionen über GPU-Chiplet-Design habe ich immer mitgenommen, dass vor allem der Polygonsetup nicht teilbar ist. Bin mir jetzt nicht sicher, ob ich das richtig formuliere aber vor allem der Anfang der Grafikpipeline ist nur sehr schwierig aufteilbar weswegen AFR auch nie so gut funktioniert hat.

Das mit dem I/O-Die hat mich auf die Idee gebracht, dass AMD diese Klippe vielleicht dadurch umschifft hat, indem sie diesen Teil der Pipeline in den zentralen I/O-Die verfrachtet haben. Der Rest der Grafikpipeline ist vielleicht viel einfacher auf kleine Einheiten aufzuteilen ohne das die Kommunikation der Teile untereinander die Effizienz vernichtet

[basix]

ich hatte mir vorgestern nach den neuen Leaks mal den Die-Shot des N21 nochmal angeschaut.

für mich schaut es so aus, als ob die Shader, L2, IF$ und Speicher schon ziemlich "dezentral" sind. Alles ist in mehrfacher, meistens 4facher Form vorhanden. Nur der Command-Processor/Geometry-Processor ist nur 1x vorhanden.

Aus den alten Diskussionen über GPU-Chiplet-Design habe ich immer mitgenommen, dass vor allem der Polygonsetup nicht teilbar ist. Bin mir jetzt nicht sicher, ob ich das richtig formuliere aber vor allem der Anfang der Grafikpipeline ist nur sehr schwierig aufteilbar weswegen AFR auch nie so gut funktioniert hat.

Das mit dem I/O-Die hat mich auf die Idee gebracht, dass AMD diese Klippe vielleicht dadurch umschifft hat, indem sie diesen Teil der Pipeline in den zentralen I/O-Die verfrachtet haben. Der Rest der Grafikpipeline ist vielleicht viel einfacher auf kleine Einheiten aufzuteilen ohne das die Kommunikation der Teile untereinander die Effizienz vernichtet

+1 bezüglich deiner Analyse, ich hatte die gleichen Gedanken. Aber ob RDNA3 schon das alles bringen kann? Oder evtl. erst RDNA4?

[Linmoum]

Früher oder später würde man sicher trotzdem nicht um >=2 GCDs herumkommen.

Aber die Idee mit einem, dafür aber "beefigerem" GCD und X MCDs + I/O hat aber irgendwie was. Vielleicht hat sich auch schlicht ergeben, dass das für Gaming aktuell noch sinnvoller ist als auf mehrere GCDs zu gehen. Aber selbst damit wäre man unglaublich flexibel und kann bei der Rohleistungssteigerung pro Gen größere Sprünge machen. Zumal ~400mm2 jetzt auch alles andere als riesig wären. Da wäre man insgesamt wahrscheinlich irgendwo bei der Die Size von Hopper (vielleicht sogar etwas weniger) und das aber gepaart mit sehr guten Yields und die eine Hälfte auch noch ausgelagert auf einen kostentechnisch deutlich günstigeren und etablierteten Prozess.

[WedgeAntilles]

Google selbst mal, dann wüßtest du, dass Nvidia die aktuelle Generation bei Samsung fertigen läßt weil TSMC sich nicht ausspielen ließ.
.
Und deswegen sollen die Verträge zwischen Nvidia und TSMC plötzlich ungültig sein?
Soll das ein Witz sein?

Ne, lass gut sein, du hast von der Materie 0 Ahnung und bist völlig überfordert wenn es um das Thema Verträge, Finanzierung, Produktionskapazitäten und ähnliches geht.

Das ist natürlich nicht schlimm, muss man nicht.
Aber es ist schon verwunderlich, wie du mit solcher Überzeugung völlig verquere Statements zu Dingen, von denen du nichts weißt, raushaust.

[HOT]

Grundsätzlich macht 1x GCD, 1x I/O und 4x MCD sehr viel Sinn. Ist im Prinzip eine Auslagerung der schlecht skalierenden und/oder über mehrere SKUs shared Funktionsblöcke (L3$, GDDR6 SI, PCIe, Video & Display) und das GCD bleibt separat. Das Ding wird sich auch wie eine monolithische GPU verhalten, da hätte ich gar keine Zweifel und all die schwierigen Dinge bezüglich GCD <-> GCD Kommunikation, L2$ usw. entfallen komplett. Prinzipiell ist es ja immer noch eine monolithische GPU. Meiner Meinung nach ein smartes Design mit nur 1x Nachteil: Mehrere und damit kleinere GCDs funktionieren damit nicht.

Edit:
Es könnten auch 6x MCDs mit je 64MByte und 64bit SI sein. Ohne IO-Die. Dann landet man auch wieder bei 7 Chiplets. Wäre doch lustig, wenn AMD während des Designprozesses die CUs auf 80% reduziert hätte (80->64 bei N33, 240->192 bei N31), das Speicherinterface um +50% aufgebohrt wurde und dann folgendes Lineup rauskäme:
- N31: 12'288 Shader, 3.0+ GHz, 384bit, 384MByte IF$ (6x MCD)
- N32: 8'192 Shader, 3.0+ GHz, 256bit, 256MByte IF$ (4x MCD)
- N33: 4'096 Shader, 3.0+ GHz, 192bit, 128MByte IF$ (monolithisch oder doch 2x MCDs? ;))

I/O, Display & Video kann auf dem GCD sein, muss aber nicht. Auslagerung könnte mMn Sinn machen.

6x MCDs + 1x IOD wären von der Fläche her 350...400mm2 gross. Wenn das N31 GCD laut Gerüchten nun ebenfalls 400mm2 gross wird, wären also ~50% der Chipfläche ausgelagert. Und trotzdem bleibt man bei einer ~monolithischen GPU. Irgendwie kann ich mich gut mit diesem Konzept anfreunden.

Im Endeffekt:
Die Leaker und z.T. wir produzieren viel heisse Luft und am Schluss kommt es dann doch anders :D

Edit 2:
Und noch was zum nachdenken: 384bit + 384 MByte ergeben auf ziemlich genau der selben N6 Chipfläche ~1.3x an effektiver Bandbreite verglichen zu 256bit + 512 MByte. Bei dann vermutlich zwar auch ~1.4x Stromverbrauch für SI + Infinity Cache aber pro Bit Bandbreite sind beide Varianten auf sehr ähnlichem Niveau.

Edit 3:
Und was wäre mit der Idee, dass N33 am Desktop mit nur 96bit/21Gbps und dafür 12 GByte antritt? Für 1080p/1440p sollte das noch knapp reichen. Im Notebook oder entsprechende "Lower End SKUs" am Desktop mit 128bit/16Gbps und 8GByte. Bei beiden Konfigurationen liegt die GDDR6 Bandbreite bei ~250 GByte/s.
- N33 v1: 64 CU, 96bit, 21Gbps, 12 GByte --> Salvaged MCDs? ;)
- N33 v2: 64 CU, 128bit, 16Gbps, 8 GByte --> Tiefere VRAM Kosten

~150mm2 in N5 + ~150mm2 in N6 ist vermutlich auch ähnlich teuer oder sogar günstiger wie N33 als monolithisches 400mm2 N6 Die. Ich sehe da auch kein Hindernis.

Cooles Konzept, gefällt mir. Ist das IOD gestackt? In dem Fall wäre es aber Blödsinn die MCDs nicht zu stacken. Und N33 ist unlgisch, der ist vor allem monolithisch, weil das das Massenprodukt ist und auch der mobile-Topchip für AMD ist. Der muss eigentlich monolithisch sein.

[Leonidas]

Aktuelles Video von RGT:
- Die 12288 ALUs beziehen sich laut zwei seiner Quellen auf 1 GCD


Es sollte ihm klar sein, dass dies nicht zu allen anderen Angaben passt. Man kann 20% weniger HW schlucken, ohne das sich grob was ändert. Aber 100% mehr HW sind einfach eine Illusion.



Grundsätzlich macht 1x GCD, 1x I/O und 4x MCD sehr viel Sinn ...

Die Anzahl der CU in der Grafik stimmt nicht. RDNA3 hat 128 FP32 pro CU.

PS: Insofern Du auf 12'288 FP32 für den gesamten Chip hinauswolltest. Wenn Du dagegen 24'576 FP32 abbilden willst, passt es.

[basix]

Ist das IOD gestackt? In dem Fall wäre es aber Blödsinn die MCDs nicht zu stacken.
Kein Stacking. "IOD" ist entweder Teil des GCD selbst oder wie die MCDs neben dem GCD, als MCM. Letzteres wüde ich bevorzugen.


Und N33 ist unlgisch, der ist vor allem monolithisch, weil das das Massenprodukt ist und auch der mobile-Topchip für AMD ist. Der muss eigentlich monolithisch sein.
Ich verstehe das Argument. Was ist aber gegen N5 einzuwenden?
- N6 monolithisch, standard packaging = ~400mm2
- N6 / N7 mixed, standard MCM packaging = ~150mm2 N5 + ~150mm2 N6, wobei N6 auf 3x Chiplets aufgeteilt wäre

MCM Packaging ist jetzt nicht extrem aufwändig, macht man bei Zen schon seit 5 Jahren. Kostentechnisch würde ich beide Lösungen auf Augenhöhe verorten, wenn nicht sogar mit leichtem Vorteil für die Chiplet Lösung. Und N5 wird die Effizienznachteile vom Chiplet-Aufbau wohl kompensieren können.


Die Anzahl der CU in der Grafik stimmt nicht. RDNA3 hat 128 FP32 pro CU.

PS: Insofern Du auf 12'288 FP32 für den gesamten Chip hinauswolltest. Wenn Du dagegen 24'576 FP32 abbilden willst, passt es.
Ah sorry, dann wären es richtigerweise 96, 64, 32 CUs. Ich habe noch in RDNA1/2 CUs gedacht.

[reaperrr]

Ich hatte mir das so vorgestellt.
N33 ist der monolithische Kern der aufgrund seiner Notwendigkeit eben "extra" gefertigt werden muss.
N32 ist dann N33+1GCD
N31 = N33+2GCD

Das glaube ich aus einem einfachen Grund nicht, nämlich weil man dann für N31+N32 den unschätzbaren Vorteil der höheren Effizienz und Taktbarkeit von N5(P) quasi über Bord werfen würde, da die GCDs sicherlich alle mit dem gleichen Takt laufen müssen und somit vom kleinsten gemeinsamen Nenner, dem N33, ausgebremst werden würden.
Außerdem würden 3 GCDs die Komplexität der Kommunikation der GCDs untereinander bei N31 deutlich erhöhen.

AMD wird zwischen N33 und den 6nm-IO/MCD-Chips der anderen beiden sicher viel Copy-Paste betrieben haben, um möglichst viel Design-Arbeit einzusparen, aber das werden schon separate Chips sein.

[robbitop]

Müsste ich eine Multichip GPU designen und dabei mit off-die Bandbreite haushalten, dann würde ich caches auf jedes Compute-DIE mit draufpacken um Bandbeite und damit interconnect density zum SI Chiplet und DRAM zu sparen.
Oder man macht es wie bei Zen 3 VCache. Eine gewisse Menge Cache im GCD und VCache einfach drauf gestapelt. Das scheint praktisch keine Energie und extra Fläche zu kosten.

[HOT]

Das ergibt nur beim L2 überhaupt Sinn. Also größerer L2 und kleinerer LLC. Das glaub ich aber nicht. Beim MCM würde man sicherlich alles so verpacken, aber ich glaube nicht, dass das so klappt. Ich bleib beim Stacking. Das wär nämlich noch ein Grund mehr, warum N33 monolithisch ist.

Eines ist auf jeden Fall klar, RDNA4 wird viele kleine Chiplets sein und sicherlich PonteVeccio in kleiner und billiger ähneln. Von daher wäre es auch logisch für AMD bei RDNA3 klein anzufangen und da auch nur bei den High-End-Produkten.

[davidzo]

Was ist aber gegen N5 einzuwenden?

- Disaggregation (nicht alle Eier in einem Korb)
- Time to market (N33 soll erheblich früher kommen)
- Verfügbarkeit
- Kapazitäten

Oder man macht es wie bei Zen 3 VCache. Eine gewisse Menge Cache im GCD und VCache einfach drauf gestapelt. Das scheint praktisch keine Energie und extra Fläche zu kosten.
Wird thermisch ein Alptraum bei 450W. Klar, die Energiedichte ist noch unterhalb vom 5800x3d, aber die Energie-/Abwärme-dichte die dort auf dem IHS verteilt ist wäre bei einer solchen GPU fünfmal höher.

Wenn MCD+Cache in einem 60nm DIE sind, dann wäre es thermisch+elektrisch besser die unter den GCD zu legen, nicht drüber.

[TheAntitheist]

Unsinn.
Erstens hätte AMD das Geld
Zweites muß AMD als guter Kunde nicht vorfinanzieren
AMD wird sicherlich die benötigten 5nm Kapazitäten bekommen. Da ja nur kleine Chiplets mit gutem Yield in 5nm von AMD gefertigt werden, brauchen sie auch nicht die große Menge.
Was würde zudem ein N33 in 5nm bringen?
Etwas kleiner, etwas effizienter, etwas schneller dafür einiges teurer.
I/O skaliert halt schlecht bei Fläche und Verbrauch.
Als Mainstream Chip kommt es vor allem auf BILLIG an.
Und ich schätze mal, da wird AMD mit N33 Preis/Leistungsmäßig im Desktop und Mobil punkten, wenn auch nicht gerade mit Effizienz.
Beeindruckend das du die ganzen Verträge kennst ;D Soweit wir wissen muss man die Wafer vorfinanzieren, damit TSMC schneller entwickeln und ausbauen kann.

[basix]

- Disaggregation (nicht alle Eier in einem Korb)
- Time to market (N33 soll erheblich früher kommen)
- Verfügbarkeit
- Kapazitäten

Alles valide Argumente. Kann man aber auf verschiedene Weisen sehen:


Disaggregation: Hat man mit N6 und N5 Chiplets bereits gewissermassen. Komplexität MCD + GCD Chipletkonstrukt sinkt bei Single-GCD drastisch
Time to market: Zum einen ja, andereseits ist N5 bereits seit Mitte 2020 HVM am laufen und Dual-Design von RDNA3 IP in zwei verschiedenen Prozessen kostet R&D Zeit. Wenn RDNA3 nicht in anderen Produkten in N6 kommt wäre das mMn verschwendeter Aufwand.
Verfügbarkeit & Kapazität: N5 gibt es wie gesagt bereits lange. Waferkapazität kann ein Thema sein, aber Zen 4 benötigt N6 fürs IOD und Zen 2/3 & V-Cache & RDNA2 gibt es auch noch in N6/7. Man klaut also anderen Produkten Kapazität weg. Und wenn es MCM wird (kein 2.5D oder 3D-Stacking), dann ist auch die Packaging-Kapazität sehr wahrscheinlich nicht limitierend

[robbitop]

Wird thermisch ein Alptraum bei 450W. Klar, die Energiedichte ist noch unterhalb vom 5800x3d, aber die Energie-/Abwärme-dichte die dort auf dem IHS verteilt ist wäre bei einer solchen GPU fünfmal höher.

Wenn MCD+Cache in einem 60nm DIE sind, dann wäre es thermisch+elektrisch besser die unter den GCD zu legen, nicht drüber.
VCache läge doch nur über dem planaren Cache wo nicht all zu hohe Energiedichte zu erwarten ist. Dort wo die Logiktransistoren sind wäre doch kein weiterer Die darüber.

[davidzo]

VCache läge doch nur über dem planaren Cache wo nicht all zu hohe Energiedichte zu erwarten ist. Dort wo die Logiktransistoren sind wäre doch kein weiterer Die darüber.

Und gerade dort kommt doch dann das support silicon drauf. Sowas wie stepped IHSe gibts nicht, wäre viel zu ungenau. Und jede Zwischenlage wie das support silicon ist ein erneuter Materialübergang und sowas kostet viel an Wärmewiderstand. Beim 5800x3d sind es 15-20°C unter Last.

https://www.hardwareluxx.de/images/cdn02/uploads/2022/Feb/worth_signal_y6/isscc-2022-amd-zen3-09_1920px.png

[amdfanuwe]

hier stand Müll

[amdfanuwe]

Beeindruckend das du die ganzen Verträge kennst ;D Soweit wir wissen muss man die Wafer vorfinanzieren, damit TSMC schneller entwickeln und ausbauen kann.
Scheint nicht weit her zu sein mit eurem "Wissen"
AMD and MediaTek are the two other preferred TSMC customers. They are mostly exclusive on the leading edge and therefore they do not deal with having to prepay large amounts for capacity.
....
Due to Nvidia’s opportunistic switching between TSMC and Samsung, Nvidia doesn’t receive the same terms. ...
To secure this supply, Nvidia is prepaying billions to TSMC, something the previous 3 customers have not had to deal with.

https://semianalysis.substack.com/p/tsmc-the-drug-dealer-is-trying-to?s=r
Lesen bildet.

[iamthebear]

Unsinn.
Erstens hätte AMD das Geld

Und wo soll das auf einmal hergekommen sein? So viel Gewinne hat man noch nicht gemacht. Man muss jetzt nicht mehr jeden Tag fürchten pleite zu gehen aber Reserven sind noch keine großen da.
Übernahmen wie bei Xilinx sind etwas Anderes. Hier wird zum Großteil nicht mit Geld bezahlt, sondern mit Aktien am neuen gemeinsamen Unternehmen also aus Investorensicht mehr eine Zusammenlegung von 2 Unternehmen statt einem Kauf.

Zweites muß AMD als guter Kunde nicht vorfinanzieren
AMD wird sicherlich die benötigten 5nm Kapazitäten bekommen. Da ja nur kleine Chiplets mit gutem Yield in 5nm von AMD gefertigt werden, brauchen sie auch nicht die große Menge.

AMD MUSS natürlich nichts vorfinanzieren. Aber dann wird es halt etwas teurer wenn man eine große garantierte Kapazität haben will, denn dann muss TSMC entweder auf eigene Kosten ausbauen oder andere Kunden verärgern. Wer soll das sein? Apple als Hauskunde? Intel die eine Mörderkohle für N3 zahlen? Qualcomm?

Nein, man ändert Pläne nicht einfach mal so. Nicht bei Produkten die so eine lange Planungszeit vorab haben.
Das ist ziemlich unrealistisch.
Viel realistischer ist, dass diverse Leaker einfach falsche Informationen haben (oder jetzt haben, wie auch immer …).

Ich glaube du verstehst hier eher den Ablauf nicht:
Zuerst wird die Architektur designed bzw. man kümmert sich um so grundsätzliche Designfragen wie "wie sind GCD und MCD aufgeteilt, was sitzt wo usw."
In dieser Phase ist noch völlig offen wieviele WGPs man nun auf einen GCD packt, wieviel Cache/VRAM usw. drauf kommt.

Danach werden die verschiedensten Simulationen gefahren.

Vor Tape out fällt dann die endgültige Entscheidung welche Dies nun endgültig ins Rennen gehen. Die werden dann an TSMC gesendet und kommen einige Zeit später zurück.

Danach werden die Chips intensiv getestet. Man sieht welche ataktraten man tatsächlich erreicht, was die Verlustleistung sein wird usw.

Deutlich später fällt dann die emdgültige Entscheidung welche konkreten SKUs man veröffentlichen wird und erst ganz kurz vor Release fällt die Entscheidung wie diesen heißen und welchen Preis diese haben werden.

Im Gegenteil, das ist das denkbar schlechteste Beispiel, da die Entwicklung der beiden Produkte sicherlich gekoppelt ist (man braucht ja schließlich die Verbindungsmöglichkeiten), aber die finale Zusammenführung ist weitgehend unabhängig vom ursprünglichen Design.
Der VCache funktioniert prinzipiell auf jedem Zen 3 Chiplet, was spielt es da schon eine Rolle um man nun einen 5600X, 5800X, 5900X oder 5950X nimmt? Das ist sich – bezogen aufs Design – gleich.

Nein das ist sogar ein sehr gutes Beispiel. Genauso wie der VCache grundsätzlich mit jeder CPU funktioniert wird auch RDNA3 mit verschiedensten Kombinationen aus WGP Anzahl, Cache usw. funktionieren, da die Architekturen skalierbar designed werden.

Google selbst mal, dann wüßtest du, dass Nvidia die aktuelle Generation bei Samsung fertigen läßt weil TSMC sich nicht ausspielen ließ.
https://www.tomshardware.com/news/amd-becomes-tsmc-third-largest-customer
AMD hat letztes Jahr einiges mehr zu TSMCs Umsatz beigetragen als Nvidia.
AMD wächst, Xilinx kommt hinzu.

Sieh es von der anderen Seite. Nvidia macht nur mit seinen Datacenter GPUs fast so viel Umsatz bei TSMC wie AMD mit CPU, GPU und Konsolen gemeinsam.
Klar AMD hat da sie sich exklusiv für TSMC entschieden haben gewisse Vorzüge aber auch Nvidia ist wichtig als Kunde, wenn auch nicht immer einfach.

Was den Samsung Deal angeht: So viel ich weiß ist das Ganze zwar am Preis gescheitert aber nachträglich betrachtet hätte TSMC sowieso nicht einmal annähernd die Kapazitäten liefern können die Nvidia gebraucht hätte. Nvidia hat sich da schon richtig entschieden und TSMC hat es auch nicht geschadet, da sie trotzdem immer noch nicht mit dem Bedarf mithalten konnten.

Aktuelles Video von RGT:

- Die 12288 ALUs beziehen sich laut zwei seiner Quellen auf 1 GCD
- Die Size: "high 300 to low 400"
- ggf. sogar 384MB Cache/384bit SI, wobei er da unterschiedliches hört
- Nicht 3D-Stacked
- Takt 3GHz+
- Performance weiterhin ~2.5x auf N31
- "compute heavy games" mehr, RT ebenfalls (deutlich) mehr
- Bzgl. N33: "Clock frequency is ridiculous", "WELL north of 3000 MHz"

Da es nur wenige Quellen sind, die sich bei den Daten gegenseitig widersprechen denke ich nicht, dass dies die Variante ist, die tatsächlich released wird.
Ich denke das ist eher AMDs Plan B falls sie das 3D Stacking nicht rechtzeitig in den Griff bekommen. Gut möglich, dass dies auch nur als Entwurf existiert und beim Tape out nicht übermittelt wurde.

Eine andere Möglichkeit wäre, dass es tatsächlich diese 2 Varianten gibt und auch getestet werden, diese jedoch für unterschiedliche Märkte gedacht sind (z.B. Gaming vs. Professional vs. Mobile) oder dass z.B. nur Navi31 mit 2 GCDs und 3D Stacking kommt, Navi32 jedoch nur mit einem ohne 3D Stacking. Wir nehmen immer an, dass Navi32 lediglich ein kleinerer Navi31 ist aber sicher wissen tun wir es nicht.

Schon lustig, dass man uns diese Generation so einen gigantischen Sprung spendiert. Wer hätte damit rechnen können. Ob Intel was damit zu tun hat? Vielleicht hatten AMD und NV ja tatsächlich panik davor, dass Intel mit modernsten Prozessen doch nen Stich landen könnte und schaukelten sich intern immer weiter hoch mit den Produktaussichten.

Ich denke das hat eher damit zu tun, dass man gemerkt hat, dass am Markt auch ein Bedarf an hochpreisigeren Modellen existiert. Gleichzeitig sind wir in einer Situation wo die neuen Fertigungen bessere Yieldraten als die alten haben und man deswegen wieder einmal auf die aktuellste Fertigung setzt bzw. Nvidia hat gemerkt, dass es besser ist hier etwas mehr Geld in die Hand zu nehmen alleine schon um stabile Lieferketten zu garantieren.

Es sollte ihm klar sein, dass dies nicht zu allen anderen Angaben passt. Man kann 20% weniger HW schlucken, ohne das sich grob was ändert. Aber 100% mehr HW sind einfach eine Illusion.

Laut dem Leak wird es nur mehr 1 GCD geben mit den 48 WGPs + die MCDs. IO Die muss dann auch im GCD integriert sein. Das ist also eine Mischung zwischen monolithisch und dem bekannten MCM Ansatz.

Er hat auch nicht behauptet, dass er glaubt, dass die Spezifikationen so kommen. Er hat lediglich darüber berichtet, dass es diese Alternativen Spezifikationen gibt, damit er nicht denselben Fehler macht wie bei der 48 WGP Variante, dass er etwas verschweigt weil er denkt es stimmt wahrscheinlich nicht und alle sind die ganze Zeit auf dem Holzweg.

[Linmoum]

https://pbs.twimg.com/media/FR8RWmlWQAE0rS8?format=png&name=small
From everything I have seen, RDNA2 -> RDNA3 looks like a bigger jump than Vega -> RDNA1. I'm very impressed.
https://twitter.com/Kepler_L2/status/1521954389942054912/photo/1

Nachdem RDNA2 ja als große Neuerung primär den IF$ (und wahnwitzige Taktraten) hatte, die IPC aber weiterhin unverändert ggü. RDNA blieben, hat man bei RDNA3 bisher irgendwie das Gefühl, dass AMD keinen Stein auf dem anderem gelassen hat. :freak:

[basix]

Zur Decompression: https://gpuopen.com/learn/dcc-overview/
Compressing is only half of the story, as data is typically read much more often than written. To get the bandwidth-saving benefits there as well, the shader core has been given the ability to read the new compressed color as well as all the existing compressed surfaces. This allows decompress operations do be skipped entirely for render-to-texture scenarios – that is, a barrier which transitions from render-target to texture is effectively a no-op and does not trigger a costly decompression.
Bezogen, wann Decompression auf RDNA1/2 passiert:
Even when you’ve followed all the rules above, DCC may sometimes get disabled as not all parts of the GPU can read and write compressed data yet. In these cases, the barrier will result in a decompression. It is important to understand when those cases may occur: ...Liste

Dann noch mehr, allerdings prä-RDNA: https://www.khronos.org/assets/uploads/developers/presentations/06-Optimising-aaa-vulkan-title-on-desktop-May19.pdf
But in this particular game title, we observed speed-ups on all tested AMD GPUs, ranging between ~5 – 10%
DCC only works for float XOR integer formats

Schlussendlich würde das für RDNA3 eine effizientere Bandbreitennutzung bedeuten, wenn "gar" keine Decompression mehr nötig ist. Nur wäre hier meine Frage: Wie viel?

Edit:
AMD ist gerade generell viel am raushauen. Developer SDKs & Tools, Code Examples, User Guides & Best Practices, etc.

Neuestes Ding ist Tress FX 5.0: https://gpuopen.com/

[TheAntitheist]

Scheint nicht weit her zu sein mit eurem "Wissen"

https://semianalysis.substack.com/p/tsmc-the-drug-dealer-is-trying-to?s=r
Lesen bildet.
Da stehen doch NULL Fakten... erst denken bitte.
Als ob jeder Spinner im Internet die Verträge kennen würde... das sind alles Vermutungen und ICH sagte, "soweit wir wissen", das bedeutet auch nur reine Vermutung aber die Gerüchte haben dies immer so besagt.

[Leonidas]

RDNA3 secret sauce: Oreos
https://twitter.com/Kepler_L2/status/1521941071277793280

RDNA3 can now make breakfast, NVIDIA dead
https://twitter.com/SquashBionic/status/1521863878753517568

https://pbs.twimg.com/media/FR6_IdSaMAENn-h?format=png&name=small

[M4xw0lf]

RDNA3 secret sauce: Oreos
https://twitter.com/Kepler_L2/status/1521941071277793280

RDNA3 can now make breakfast, NVIDIA dead
https://twitter.com/SquashBionic/status/1521863878753517568

https://pbs.twimg.com/media/FR6_IdSaMAENn-h?format=png&name=small
;D

[Neurosphere]

Steht das da wirklich drin oder dichtet das jemand dazu? Manchmal hat AMD ja Humor, aber das wäre schon etwas drüber.

[Linmoum]

Es scheint jetzt tatsächlich nur noch die NGG pipeline zu geben und sie haben die legacy geometry pipeline entfernt.

https://mobile.twitter.com/Locuza_/status/1521917087496687616/photo/1

[mboeller]

da wurden anscheinend ein paar alte Zöpfe abgeschnitten:

https://forum.beyond3d.com/threads/amd-rdna-3-speculation-rumours-and-discussion.62092/page-62#post-2251712


https://gitlab.freedesktop.org/mesa...t_id=1a01566685c3d2651bbfc72738de6a1e38ba8251

Notes for GFX11 changes above:

CMASK/FMASK removed - RIP VK_AMD_shader_fragment_mask and MSAA in general

CB_RESOLVE removed - MSAA resolve is now done in software with the compute pipeline

NGG pipeline is always enabled - No fallback legacy geometry pipeline

Image descriptors are now just 32 bytes in size - Older HW generations used to have an option as high as 64 bytes to store FMASK information

Biggest change seems to be DCC functionality:
DCC for storage images is always enabled
Arbitrary DCC format reinterpretation applies to all formats
Does this mean DCC decompression never happens anymore on GFX11 ?
Obvious byproduct is that all D3D resources/VK image views can be respectively kept typeless/mutable for API usage convenience without performance impact

Does this mean we can finally ditch D3D resource states and VK image layouts so that explicit APIs become simpler to use ?

[WedgeAntilles]

Was den Samsung Deal angeht: So viel ich weiß ist das Ganze zwar am Preis gescheitert aber nachträglich betrachtet hätte TSMC sowieso nicht einmal annähernd die Kapazitäten liefern können die Nvidia gebraucht hätte. Nvidia hat sich da schon richtig entschieden und TSMC hat es auch nicht geschadet, da sie trotzdem immer noch nicht mit dem Bedarf mithalten konnten.

Was viele nicht verstehen - es ist im Geschäftsleben ein ziemlich normaler Vorgang, dass man mal mit der einen Firma, mal mit der anderen Firma Verträge hat.
Natürlich gibt es auch Beziehungen die jahrzehntelang gehen.
Aber die Firmen sind keine Fanatiker wie die Fans - wenn sich Nvidia und TSMC für Ampere nicht einigen konnten, ist dadurch nicht ihre Geschäftsbeziehung kaputt oder so.
Das ist Kindergarten / und AMD Fan Fantasie: "Du hast mein Schäufelchen weggenommen, mit dir spiele ich nieeee wieder" (wobei die Kinder 30 Minuten später ja doch wieder zusammen spielen.)

Zwei Firmen auf Augenhöhe verhandeln natürlich hart - aber das ist das Geschäft.
Beim nächsten Mal verhandelt man wieder, es spielt keine große Rolle ob man beim letzten Mal zueinander kam oder nicht.

Anders sieht es aus, wenn die beiden Firmen sehr unterschiedlich sind.
Paradebeispiel sind da Zulieferer in der Automobilbranche (wobei es da auch Unterschiede gibt - manche Zulieferer sind so speziell, dass sie ebenfalls mächtig sind. Weil der Autobauer gar nicht zu einem anderen Zulieferer gehen kann) und im Lebensmittelbereich.
Denen wird von Daimler, Aldi und Co gerne mal die Pistole auf die Brust gesetzt und gesagt: "Ihr macht das jetzt so - oder gar nicht."
Ich zitiere mal eine wahre Begebenheit: Ein Mitarbeiter kommt zur Verhandlung mit einer großen Lebensmittelfirma und sagt "guten Morgen" - daraufhin erwidert der Chef der Lebensmittelfirma: "Das entscheiden aber nicht Sie."

[DrFreaK666]

Ein Mitarbeiter kommt zur Verhandlung mit einer großen Lebensmittelfirma und sagt "guten Morgen" - daraufhin erwidert der Chef der Lebensmittelfirma: "Das entscheiden aber nicht Sie."

Was für ein Scheißchef

[mboeller]

Was für ein Scheißchef

Soweit ich das verstanden habe war das ja nicht sein Chef sondern der Chef der Firma mit der Verhandlungen geführt wurden... fällt unter "Schneid abkaufen" bzw. "auf Konfrontation gehen"

[basix]

Es scheint jetzt tatsächlich nur noch die NGG pipeline zu geben und sie haben die legacy geometry pipeline entfernt

Macht das viel aus? Features? Performance? Die-Fläche?

[vinacis_vivids]

Was weg ist kann kein Strom verbrauchen.

Die Trennung bzw. der Schalter zwischen "Graphics" und "Compute" gibt es bei Polaris und Vega. Seit RDNA gibs das nicht mehr.

[WedgeAntilles]

Soweit ich das verstanden habe war das ja nicht sein Chef sondern der Chef der Firma mit der Verhandlungen geführt wurden... fällt unter "Schneid abkaufen" bzw. "auf Konfrontation gehen"
Richtig, so war es. (Und es war nicht ich persönlich, dem das passiert ist.)

[iamthebear]

Macht das viel aus? Features? Performance? Die-Fläche?

Viel interessanter ist die Frage "kann das eventuell zu Problemen mit älteren Spielen führen?"

[Tangletingle]

Viel interessanter ist die Frage "kann das eventuell zu Problemen mit älteren Spielen führen?"

Gibt dann 190 statt 230 FPS.

[aufkrawall]

Wahrscheinlich wurde der alte Pfad eh schon nicht mehr im Treiber genutzt, zumindest für RADV ist NGG Culling mit RDNA2 seit einiger Zeit standardmäßig aktiviert:
https://gitlab.freedesktop.org/mesa/mesa/-/commit/52413a93afe408fe7841b641fcfa2ac9cae4c349

Man schmeißt den Legacy-Pfad aus der Hardware, weil er offenbar nur noch unnützer Gammel ist. Sollte die Performance nirgendwo verschlechtern:
https://www.phoronix.com/scan.php?page=article&item=radeon-radv-nggc&num=2

[Leonidas]

Mehrere GCDs bei Navi 31/32 haben sich wohl erledigt + genaue Größen des IF$ von Navi 31/32
https://www.3dcenter.org/news/geruechtekueche-amds-navi-31-mit-angeblich-nur-noch-einem-gcd-samt-6-mcds

[w0mbat]

Ich finds witzig, wie anscheinend niemand Ahnung hat wie RDNA3 oder Lovelace wirklich aussehen.

[r3ptil3]

Wie kommt eigentlich die Prognose für September/Oktober 2022 für Navi33 zustande?

[Leonidas]

Wie kommt eigentlich die Prognose für September/Oktober 2022 für Navi33 zustande?

Allgemeiner Stand der Gerüchteküche. Insbesondere Greymon55 reitet auf dieser Terminlage sehr deutlich rum.

[AffenJack]

Mehrere GCDs bei Navi 31/32 haben sich wohl erledigt + genaue Größen des IF$ von Navi 31/32
https://www.3dcenter.org/news/geruechtekueche-amds-navi-31-mit-angeblich-nur-noch-einem-gcd-samt-6-mcds

Naja, erledigt? Kopite7kimi schreibt selbst immer wieder, dass er bei AMD eher weniger Quellen hat und nicht weiß was kommt. Er schreibt sogar, dass es nur eine Meinung ist, da er den Sinn in 2 GCD nicht sieht.

Die ganze gerüchteküche ist sich nur darin einig komplett keinen Plan zu haben, wie w0mbat schon schreibt.

[Unicous]

Na irgendwie muss Leonidas doch einen clickbaitigen Artikel schreiben können um auf Twitter zitierfähig zu sein. :uponder:

Darum geht es doch heutzutage, nicht wahr.:rolleyes:

[Leonidas]

Naja, wenn 2 (eigentlich 3 inkl. Greymon) sagen, dass keine mehreren GCDs mehr kommen, dann muss man das irgendwann Ernst nehmen. Genügend abschwächende Worte á "Gerüchteküche" und "angeblich" sind auch vorhanden.

Zugegebenermaßen wollte ich die Liste der N31/32/33 Specs auch updaten, nachdem Kopite sich übers WE einen Spaß gemacht hat, auf deren Unaktualität hinzuweisen. Blöd halt, wenn irgendeiner Tweets vom letzten Oktober zitiert.

[Unicous]

Du vergisst immer wieder gerne, dass beide öfter mal ein :uponder: Emoji oder I think/guess hinzufügen (hier ist es das Stichwort "opinion"), wenn sie ihre eigenen Spekulationen, die nicht auf Quellen basieren, in den Äther posten. Ist ja nicht das erste Mal, dass du eine Spekulation/Gedankenspiel von Greymon und Co. als 90% bestätigtes Gerücht verkaufst.:rolleyes:

[basix]

Naja, wenn 2 (eigentlich 3 inkl. Greymon) sagen, dass keine mehreren GCDs mehr kommen, dann muss man das irgendwann Ernst nehmen. Genügend abschwächende Worte á "Gerüchteküche" und "angeblich" sind auch vorhanden.

Ach was, das mit 1x GCD und 6x MCD haben die von hier geklaut. Inkl. 384MByte IF$ für N31 ;D
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12995133#post12995133

@Leo: Bei 6x MCDs funktioniert 256bit nicht
- 48bit (wth wäre das für ein MCD) --> 192bit / 288bit
- 64bit (besser ;)) --> 256 / 384bit

[Linmoum]

Und du hast es von RGT geklaut. :tongue:

Aber immer wieder faszinierend, wie schnell das dann die Runde macht. Wobei ich dieses Mal trotzdem irgendwie so ein Gefühl habe, dass RGT damit recht hat(te).

[basix]

Und du hast es von RGT geklaut. :tongue:
Psst, nicht so laut :D

[Unicous]

Denkst du wirklich du bist die einzige Person mit originären Gedanken?:confused:

[basix]

Denkst du wirklich du bist die einzige Person mit originären Gedanken?:confused:

Verstehst du auch einen kleinen Witz zwischendurch? ;)

Edit:
Vielleicht nochmals auf die Auslegung der Chips zu kommen. 16WGP / 128bit / 128MByte / 2x SE könnte anhand einiger Gerüchte, eigener Überlegungen und der Auflistung von Leo eine Art "Building Block" sein.
- N31: 48 WGP / 384bit / 384 MByte / 6x SE
- N32: 32 WGP / 256bit / 256 MByte / 4x SE
- N33: 16 WGP / 128bit / 128 MByte / 2x SE

Anhand der Auflistung könnte ich mir irgendwie einen massiven Jebait von AMD vorstellen:
- MCD = 64bit / 64 MByte
- GCD = 16 WGP / 2x SE

Ha, das wär doch was :D

Prinzipiell ist zu RDNA3 nämlich eines zu sagen: Niemand, auch nicht die "bekannten" Leaker, haben von irgendwas eine Ahnung. Irgendwie kann alles oder nicht kommen, spannend :)

[Unicous]

Im Zusammenhang war da jetzt der "Witz" nicht zu erkennen.*Schulterzuck*

Im Zweifel ist eh alles aus chinesischen Foren geklaut und da ist es ca. 90% Getrolle und 10% "echte" Quellen.

[HOT]

Exakt.

Damit wird das tatsächlich ein GCD, evtl. einem I/O-Die für die ganzen Anschlüsse (oder auch nicht, je nachdem) und 4-6 MCDs, welche mit je 64MB und 64Bit ausgerüstet sind. AMD hat also lediglich alles ausgelagert, was einen N5-gefertigten Chip unnötig groß machen würde.

N33 kann aber trotzdem monolithisch sein, weil der selbst N6 werden könnte. Dann lohnt sich das mit den MCDs evtl. nicht.

Übrigens werden nicht unterschiedlich viele MCDs auf ein Produkt bauen. Dafür kostet der MCD einfach nicht genug und das würde das Packaging komplizierter machen, da man mit irgendwelchen Dummys arbeiten müsste. Es wird mMn bei allen N31-Produkten 24GB geben und allen N32-Produkten 16GB. Man wird das nicht verändern. Man sieht es ganz gut an N21, es wäre ein leichtes gewesen, die 6800 mit 192MB Cache und 192 Bit zu bringen. Hat man nicht gemacht. Man hätte die 6600 mit 92Bit und 6GB bringen können, hat man nicht gemacht. Und Salvage bei MCD ergibt keinen Sinn, die Dinger sind eh winzig und für den salvage des N31 bringt das nix.

[vinacis_vivids]

Also wieder ne neue Runde Spekulazius:

N33 - 128bit SI - 256MB IF$ - 8GB VRAM - 4096SP - 3,0Ghz - 200W ?
N32 - 192bit SI - 384MB IF$ - 12GB VRAM - 8192SP - 2,8Ghz - 300W ?
N31 - 256bit SI - 512MB IF$ - 16GB VRAM - 12228SP - 2,6Ghz - 400W ?

Vor Allem N33 mit 256MB IF$ ist extrem interessant. 128MB IF$ bei N33 lockt keine Sau vorm Ofen nach fast 2 Jahren N21 im Rechner.
256MB IF$ und nur 8GB VRAM, das ist ne ganz gewöhnungsbedürftige Konfiguration für die Mittelklasse. AMD spart da extrem viel VRAM ein, welches ein wesentlicher Kostenfaktor ist. :freak:

Wenn N21 refresh jetzt kommt und N33 256MB IF$ in 4-5 Monaten. Wer kauft da noch N21? Da sieht man wie wichtig Geheimhaltung ist.

N33, 256MB IF$, 8GB wird allerdings Aufgrund der extrem hohen Leistung sehr sehr viele Käufer finden.

[davidzo]

Ach was, das mit 1x GCD und 6x MCD haben die von hier geklaut. Inkl. 384MByte IF$ für N31 ;D
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12995133#post12995133

@Leo: Bei 6x MCDs funktioniert 256bit nicht
- 48bit (wth wäre das für ein MCD) --> 192bit / 288bit
- 64bit (besser ;)) --> 256 / 384bit

Ich glaube auch nicht so an 6MCDs, denn die 256bit gelten doch als relativ gesichert. Das 384bit Gerücht ist doch wirklich erst vor kurzem hier im Forum entstanden.

Allerdings würde die Auflösung mit single GCD auch endlich das Mysterium um N32 auflösen, also wieso das kein salvage von N31 ist oder wenigstens ein paar gleiche GCD Chiplets verwendet.

Aber gab es nicht eine Aussage von AMD mit "2 times the density of Apples M1 Ultra interconnect"? oder verwechsle ich das mit Intel / Nvidia?
Wäre halt komisch wenn man da dieselbe Density wie beim 5800x3d hat und die cache Dies einfach zusammenzählt.

[iamthebear]

Greymon hat noch einmal bestätigt, dass die 2GCD+1IO+4MCM geraten waren. Er weiß nur, dass es 7 Dies sind also macht 1 GCD + 6 MCDs durchaus Sinn

https://twitter.com/greymon55/status/1523732671943245824?s=20&t=pE1mfy5JGwUjfIkCQqpWtg

[basix]

Anhand der letzten paar Tage würde ich auch nicht allzuviel auf "gesicherte" Informationen zum Thema RDNA3 geben. Bei Nvidias Lovelace sieht das aufgrund des Hacks ganz anders aus.

Übrigens werden nicht unterschiedlich viele MCDs auf ein Produkt bauen. Dafür kostet der MCD einfach nicht genug und das würde das Packaging komplizierter machen, da man mit irgendwelchen Dummys arbeiten müsste. Es wird mMn bei allen N31-Produkten 24GB geben und allen N32-Produkten 16GB. Man wird das nicht verändern. Man sieht es ganz gut an N21, es wäre ein leichtes gewesen, die 6800 mit 192MB Cache und 192 Bit zu bringen. Hat man nicht gemacht. Man hätte die 6600 mit 92Bit und 6GB bringen können, hat man nicht gemacht. Und Salvage bei MCD ergibt keinen Sinn, die Dinger sind eh winzig und für den salvage des N31 bringt das nix.

Ich glaube auch nicht, dass bei MCDs Dummy Die zum Einsatz kommen. Was aber dennoch kommen könnte: Irgendwo 32bit SI oder gar ein ganzes MCD wegknipsen. Es kann auch beim Packaging was schief gehen --> Packaging Yield Erhöhung. Oder man will sich die 2-4 GByte GDDR6 sparen. Rein für die Segmentierung wäre ein N31 mit 20 GByte wohl immer noch üppig genug ausgestattet. Salvaged SI ist aber nicht zwingend gleichbedeutend mit geringerer Infinity Cache Kapazität. Ausser man knipst ein ganzes MCD weg.

[amdfanuwe]

Greymon hat noch einmal bestätigt, dass die 2GCD+1IO+4MCM geraten waren. Er weiß nur, dass es 7 Dies sind also macht 1 GCD + 6 MCDs durchaus Sinn


oder 1 MCD und 6 GCD.
Ähnlich Epyc.
N32 dann eigenes kleineres MCD + 4 GCD.

Die kleinen GCDs kann man gut selektieren und entsprechend auf die Produkte verteilen.

[basix]

Wäre auch denkbar. Und würde rein aus Kosten sowie Yield Sicht recht viel Sinn machen. N6 ist relativ günstig, sehr stabil und Cache hat eigentlich 100% Yield, da Redundanzen eingebaut sind. Da wäre ein grosses Die eigentlich fast egal. Aus Kostensicht würde das also mehr Sinn machen als 6x kleine MCDs und 1x grosses GCD. Ausserdem kann man den gesamten IO-Krempel (GDDR, Video, Display) auch zentral im günstigen N6 Die unterbringen. Hmm, wieso nicht, das hat was ;) Das wäre dann 1x SE mit 2048 FP32-Units pro GCD, das würde auch passen.

Was ich aber schlecht abschätzen kann: Wie viel müssem die kleinen GCDs miteinander schwatzen? Wo ist der Control Core, auf dem zentralen Die? Wo ist der L2$ oder sind die jeweils sliced auf den kleinen GCDs? Wie sind die SI-PHY angeordnet, dass man das schlau aus dem Package bringt?

Edit:
Einzelne fette MCDs zu designen wäre evtl. auch mit weniger R&D Aufwand verbunden als verschieden grosse GCDs. Die Cache Makros anzuordnen sollte nicht allzu schwer sein ;)

[Linmoum]

Ich glaube im Endeffekt, dass die Lösung mit 1xGCD und YxMCM noch "smarter" und zumindest aktuell sinnvoller ist, als der ganze Aufwand mit 2xGCD.

Dadurch, dass das einzelne GCD dann größer ist als potentiell zwei kleinere, steht mehr Kühlfläche zur Verfügung. Das hilft gerade bei deutlich oberhalb von 300W. Dazu sparst du dir etwaigen zusätzlichen Aufwand bei der Kommunikation zwischen zwei GCDs. Das einzelne GCD verhält sich dann immer noch wie ein monolithischer Die und du vermeidest so etwaige Probleme, gerade für Spiele könnte das IMO der größte Vorteil sein. Probleme von Multi-GPU kennt man ja gut genug. Zudem kriegst du trotzdem in noch einem potentiellen, einzelnen GCD mit ~400mm2 48WGP/12288SP/192CUs unter. Das ist noch immer eine ganze Menge auf verhältnismäßig kleiner Fläche. AD102 hat nur 144SM (-25%), dürfte aber trotzdem sicherlich (deutlich) über 500mm2 liegen und das alles auch noch in N5 (oder 4N whatever, trotzdem alles N5-Devirate).

Ich glaube auch nicht, dass AMD sich erst kurzfristig für 1xGCD entschieden hat. Das war sicherlich von Anfang an so gedacht. Desktop/Gaming ist halt auch noch mal was anderes als HPC. Dass das bei letzterem einfacher umzusetzen ist, hatte Wang iirc schon vor ein paar Jahren in einem Interview geäußert. Und ob ein oder zwei GCDs, der Vorteil mit ausgelagertem IO-Gedöns in einem kostengünstigen Prozess bleibt weiterhin bestehen. So schlägt man immer noch zwei Fliegen mit einer Klappe.

[basix]

Single-GCD und ausgelagerte MCDs sind im Endeffekt die "einfachste" Lösung, wenn man eine GPU mit Chiplets aufbauen will. All die "Multi-GPU" Fragen stellen sich dann erst gar nicht. Und dennoch hat man Netto einen guten Kostengewinn.

Ich finde die vorhin von amdfanuwe genannte Lösung, welche GCD <-> MCD abtauscht, aber eigentlich auch ganz attraktiv.

Edit:
Beim fetten MCD kam mir spontan Ponte Vecchio in den Sinn. Wer weiss, vielleicht stacked AMD die GCDs auf das grosse MCD. Ist ja dann kein 3D-Stacking sondern 2.5D Stacking und RGTs Aussage dazu wäre immer noch valide ;)

[iamthebear]

Was man bei der GCD Anzahl beachten sollte:
Wenn man 2 oder mehr unterschiedliche GCDs miteinander kombinieren will, dass braucht man entweder einen eigenen IO Die (bevorzugt in N6) oder man hat eine Menge totes Silizium auf den GCDs.

Falls es mehr als 2 GCDs sein sollten (wofür aber im Moment noch gar nichts spricht), so muss man sich auch über den Datentransfer Gedanken machen. Bei 2 GCDs reicht es wenn die MCDs einfach Bridge zwischen den 2 GCDs spielen. Mit mehr als 2 GCDs bräuchte man schon eine Art Ringbus, da man die Daten nicht direkt an das Ziel GCD senden kann, sondern zuerst den Weg über ein 3. nehmen muss.

[basix]

Wenn in den GCDs nur eine einzelne Shader Engine liegt und mit einem einzelnen MCD verbindest, hättest du all diese Probleme nicht. Das MCD selbst stellt den Interconnect her. IO, IF$, Geometry & Graphics Command Processor, ACEs und HWS wären im MCD. Allenfalls auch noch der L2$.

Noch weiter ginge die 2.5D Variante dieser Idee, wo die GCDs oben aufs MCD gestacked werden. L2$ dann definitiv im MCD. Das vermeidet die grosse x-y Distanz zwischen GCDs und dem Command Core, der Cache ist näher und der Flächenoverhead für den Interconnect zwischen MCD und GCDs wird minimiert. Zudem die energetisch effizienteste Variante des Interconnects ohne 3D-Stacking. Und GCDs auf MCD käme wie gesagt Ponte Vecchio sehr nahe. N31, 32, (33) haben dann ein eigenes separates MCD und teilen sich die GCDs. Vorteile sollten hier die Kosten als auch das GCD Binning sein.

[amdfanuwe]

Was ich aber schlecht abschätzen kann: Wie viel müssem die kleinen GCDs miteinander schwatzen? Wo ist der Control Core, auf dem zentralen Die? Wo ist der L2$ oder sind die jeweils sliced auf den kleinen GCDs? Wie sind die SI-PHY angeordnet, dass man das schlau aus dem Package bringt?

Wieviel müssen die Einheiten in einer GPU überhaupt miteinander schwatzen?
Ich hab da keinen Plan. Ich weiß nur, dass es bei einer GPU nicht vergleichbar mit einer CPU ist.
https://www.rastergrid.com/blog/gpu-tech/2021/01/understanding-gpu-caches/
Dennoch, auf den L2 Cache dürfte häufig von einer SE benötigt werden und sollte schnell im Zugriff sein, da würde ich eher darauf tippen, dass der L2 bei der SE auf dem GCD liegt.
Die Control Cores könnte ich mir gesplittet vorstellen: einen lokalen CC auf dem GCD, damit dieses unabhängig wie eine kleine eigenständige GPU arbeiten kann, einen Globalen CC Teil auf dem MCD zur Koordination des ganzen.
Das SI mit 256 Bit sollte nicht das Problem sein bei der Größe des MCD.
Die Anbindung der GCDs an das MCD hängt vom Bandbreitenbedarf zwischen L2 und IF$ ab. Ich denke nicht, dass da einfache Verbindungen auf dem Träger wie bei EPYC reichen. Würde da eher auf EFOBs tippen. Damit hat man ja schon Erfahrung beim MI200 gesammelt. So ein GCD sollte ja auch nicht größer wie ein HBM werden.
Wäre zumindest billiger als mit TSV und Stacking zu arbeiten.
Wie sind eigentlich die zwei GCDs beim MI250 miteinander gekoppelt? Aus den Schaubildern geht nur hervor, dass die HBMs per EFOBs angebunden sind.

[iamthebear]

Der Infinity Cache muss einmal über die gesamte GPU geshared weden wenn man auf vernünftige Hitrates kommen will, da hier zu einem großen Teil gemeinsam genutzte Resourcen liegen z.B. die im aktuellen Frame sichtbaren Texturen. Das waren bei Navi21 2TB/s alos würde ich hier bei Navi31 eher von ca. 6TB/s ausgehen.
Dazu kommt dann noch das Speicherinterface, das auch über die gesamte GPU geshared sein muss damit auf alle Daten zugegriffen werden kann.

Den Ansatz "jedes GCD hat seinen eigenen RAM und Cache" gab es auch schon einmal vor 10-15 Jahren mit den ganzen Dual GPUs. Das muss dann aber über SLI/Crossfire angebunden werden mit all den Problemen und ist seit DX12 ohne aktive Anpassungen der Spieleentwickler sowieso nicht mehr möglich.

[HOT]

Wie wäre es denn wenn die GCDs einfach auf das MCD gestapelt würden wie beim X3D? Dann gäbe es gar keine Probleme, auch mit den Latenzen nicht. Dann wäre der eigentlich Grafichip in N6 und nur die energiefressenden Shader in N5.

[amdfanuwe]

Den Ansatz "jedes GCD hat seinen eigenen RAM und Cache" gab es auch schon einmal vor 10-15 Jahren mit den ganzen Dual GPUs. Das muss dann aber über SLI/Crossfire angebunden werden mit all den Problemen und ist seit DX12 ohne aktive Anpassungen der Spieleentwickler sowieso nicht mehr möglich.
Da lag damals auch das Problem, es waren 2 eigenständige GPUs und SLI/Crossfire lieferten nicht wirklich die benötigte Bandbreite.
Wo wäre denn der Unterschied ob nun die SE ausgelagert wären oder ob sie mit auf dem Die sind? In beiden Fällen hat der Control Prozessor dafür zu sorgen, dass die SE ausgelastet werden. Das gab es bei den DUAL GPUs nicht.

Unser Problem liegt darin, dass wir den Bandbreitenbedarf EINER SE nicht kennen. Bisher haben wir es nur mit dem Gesamtpaket von mehreren SE auf dem Chip und dem Speicherinterface zu tun.

Die Ingenieure bei Intel, Nvidia und AMD kennen das Datenaufkommen und damit die benötigten Bandbreiten zwischen den Einheiten. Und manchmal kommen dann neue Ideen auf wie Datenkomression, IF$ etc. die das Problem verlagern und neue Möglichkeiten bieten
Letztendlich geht es nur darum, schneller als die Konkurrenz bei geringeren Herstellungskosten zu werden um im entsprechendem Segment ein maximum an Gewinn zu erwirtschaften.

[mboeller]

Der Infinity Cache muss einmal über die gesamte GPU geshared weden wenn man auf vernünftige Hitrates kommen will, da hier zu einem großen Teil gemeinsam genutzte Resourcen liegen z.B. die im aktuellen Frame sichtbaren Texturen. Das waren bei Navi21 2TB/s alos würde ich hier bei Navi31 eher von ca. 6TB/s ausgehen.
Dazu kommt dann noch das Speicherinterface, das auch über die gesamte GPU geshared sein muss damit auf alle Daten zugegriffen werden kann.


beides, IF$ und Speicherinterface sind zB. beim N21 ziemlich "vereinzelt" und am Rand des Die verteilt. Auch beim N22 sieht man sehr schön, dass der IF$ als 4MB "Happen" über das Die verteilt ist.

Wenn wirklich so viele Daten zw. den einzelnen Einheiten ausgetauscht werden müssten würde man das auf dem Die anders verteilen, weil ansonsten der Aufwand (Verdrahtung/Power) viel zu groß werden würde.

Für mich schaut es so aus, als ob nur der Command/Geometry-Prozessor wirklich zentral ist und alles andere verteilt werden kann.

[basix]

Wie sind eigentlich die zwei GCDs beim MI250 miteinander gekoppelt? Aus den Schaubildern geht nur hervor, dass die HBMs per EFOBs angebunden sind.

Soweit ich das verstanden habe sind das standard Infinity Fabric Links. Einfach halt gleich 8x Stück davon.

Wie wäre es denn wenn die GCDs einfach auf das MCD gestapelt würden wie beim X3D? Dann gäbe es gar keine Probleme, auch mit den Latenzen nicht. Dann wäre der eigentlich Grafichip in N6 und nur die energiefressenden Shader in N5.

Siehe meinen Vorschlag von oben. X3D oder besser gesagt 3D_SoIC halte ich aber für zu teuer. Normales 2.5D (Base Die / MCD = "Interposer Funktion") sollte reichen. Latenzen sind hier sowieso nicht das Problem, sondern Kosten vs. Bandwidth Density vs. Energieverbrauch.

[HOT]

Das ist für so ein Produkt garantiert nicht zu teuer. Das wird ja mittelfristig sowieso ein Massenprodukt werden. Die Frage ist, ob sie dafür ne Fertigungskapazität haben.

[davidzo]

Dadurch, dass das einzelne GCD dann größer ist als potentiell zwei kleinere, steht mehr Kühlfläche zur Verfügung.

Wieviel Kühlfläche ist doch abhängig von der density, nicht von der Anzahl der DIEs.
Es ist genau umgekehrt, zwei DIEs die etwas auseinander liegen sind kühltechnisch immer besser als ein einzelner DIE bei gleicher Fertigungsdichte. Die decken einfach eine größere Fläche auf dem Kühler ab, dass heißt mehr Heatpipes, weniger Energiedichte etc.


Falls man wirklich auf schon auf 3D Packaging geht und die MCDs oben auf den GCD drauf stackt wie beim 5800x3d kann das richtig problematisch werden.
Denn dann kommt auf den GCD sowohl ein hauchdünnes support silicon dort wo kein MCD ist, sowie womöglich dadrüber noch eine dicke Schicht structural silicon wie bei Epyc.
400Watt kann man damit schwerlich per Lukü abführen, selbst wenn das DIE mehr als 400mm2 groß wird.

Thermisch wäre eine Anbindung nebeneinander im Package bzw. ein großer Interposer ala Vega sicher besser.

MCDs unten, GCD oben drauf wäre wieder eine komplett andere Packagingtechnologie, die AMD bisher so noch nicht im Einsatz hatte. Bisher gab es nur passive DIEs von unten auf die wafer top side/ global interconnect layer aufgesetzt oder per wafer thinning von der wafer back side, also oben auf die logic layer aufgeklebte DIEs.

Dass MCDs und GCDs direkt verbunden werden ist also eher unwahrscheinlich. Nebeneinander: Flipchip MCM hat nicht genug Density, ein ganzer Interposer ist teuer, bleibt nur noch EFB oder eine ähnliche local silicon inerposer Technik.

[amdfanuwe]

Das ist für so ein Produkt garantiert nicht zu teuer.
Wenn es andere günstigere Methoden gibt die den Zewck erfüllen, ist es zu teuer. In der Industrie zählt gerade in der Masse jeder Cent den man einsparen kann.
TSV für Stacking erfodert zusätzliche Arbeitsschritte und jeder Arbeitschritt verteuert das ganze. Löcher anlegen, mit CU verfüllen, abschleifen...
Bei Vermeer würde ich mal tippen, das nur bei den Chips, die für den 3D-Cache vorgesehen sind, diese zusätzlichen Arbeitsschritte auch ausgeführt werden.

[HOT]

Da zählt doch nicht nur der kurzfristige Profit. Wenn man die entsprechenden Packaginganlagen aufgebaut hat ist das auch nicht mehr teuer, und man muss irgendwo anfangen. Kosten sind hier einfach kein Faktor dafür. Erst recht nicht bei eine 650$+-Produkt.
Angefangen hat man mit dem X3D, dann könnte mit RDNA3 noch eine neue Fertigung hinzukommen und mit Zen4 X3D noch ne 3. Bei Zen5 ist das dann für alles Standard, da will man doch hin. Für Intel ist das ab Meteor Lake Brot und Butter-Technologie. Und bei AMD ist das jetzt die große Ausnahme für immer oder was? Seid doch nicht so kleinkariert im Denken.

[iamthebear]

beides, IF$ und Speicherinterface sind zB. beim N21 ziemlich "vereinzelt" und am Rand des Die verteilt. Auch beim N22 sieht man sehr schön, dass der IF$ als 4MB "Happen" über das Die verteilt ist.

Wenn wirklich so viele Daten zw. den einzelnen Einheiten ausgetauscht werden müssten würde man das auf dem Die anders verteilen, weil ansonsten der Aufwand (Verdrahtung/Power) viel zu groß werden würde.

Für mich schaut es so aus, als ob nur der Command/Geometry-Prozessor wirklich zentral ist und alles andere verteilt werden kann.

Was mir bei den Navi21.Die shots auffällt:
Alles an IO wie Displayausgänge und Speicherinterface ist am Rand des Chips angeordnet. Das macht auch Sinn, da die Leiterbahnen ja vom Chip weg zu den einzelnene RAM Bausteinen oder den Schnittstellen führen.

Der Infinity Cache ist direkt hinter dem jeweiligen Speicherinterface positioniert. Das macht auch Sinn, da alle vom VRAM kommenden Daten ja gleich sofort im L3 eingelagert werden müssen.

Die Shader Engines sind per Infinity Fabric an den Infinity Cache angebunden. Es ist doch nur logisch hier eine Art Ringbus einzusetzen. Chipintern ist das ja kein großes Thema. Das wird es nur wenn man ständig von einem Chip zum anderen springen muss.

Was die Datenmengen angeht: Die Bandbreite des Speicherinterface kann man sich ja einfach ausrechnen. Die 2TB/s für den Infinity Cache kommen von AMD, wobei das auch der Hausverstand sagen sollte, dass die Cache Bandbreite höher sein muss als die des Speicherinterface.

Wieviele Daten vom Geometrie Processor an die Shader Engines fließen kann ich nicht sagen.

Ampere hat übrigens eine ähnliche Anordnung der Speicherinterfaces an der Außenseite. Lediglich der L2 ist zentral aber diesen sollte man sich auch nicht unbedingt als Vorbild nehmen ;-)

[basix]

Wieviele Daten vom Geometrie Processor an die Shader Engines fließen kann ich nicht sagen.

Siehe Navi 10 Präsentation auf der ISSCC 2020 ;)

Und noch der Die Shot dazu: https://www.reddit.com/r/Amd/comments/er9gkx/navi_10_ir_die_shot_from_fritzchen_fritz_link/

2x Shader Engines -> L2$ = 8x 2048bit Bus
2x Shader Engines -> Command / Geometry = 4x 2048 bit Bus

Ich habe jeweils von End-to-End gezählt, SE zu L2$-Slice oder Command / Geometry Processor. Im Endeffekt aber ganz einfach und egal wie man zählt: Ungefähr 1/2 der L2$ Bandbreite. Zumindest ist das meine Interpretation des ersten Schaubildes.

Deutlich mehr geht aber innerhalb der Shader Engines ab. Da werden viel mehr Daten hin- und hergeschaufelt.

[Linmoum]

Zwar nicht alles neu, aber aktuelles Video von RGT:

Keine 256MB/512MB IF$, sondern 384MB bzw. 192MB. Von ersterem hat er zuletzt vermehrt gehört, vereinzelt auch "nur" 192MB - womöglich aber schlicht SKU-abhängig.
Dementsprechend auch keine 16 GiB, sondern 24 GiB und 384 bit SI. Er ist zuversichtlich, dass das auch die tatsächlichen Specs sein werden bzw. sind.

Ansonsten das, was man schon zuletzt mitbekommen hat. 1xGCD + 6x MCD, 6SE/8WGP = 48WGP, >2.1-2.5x (konservativ) Rasterizer Performance, >3.5x RT-Performance, >3GHz Game Clock, >75 TFLOPs, 375-450W (letzteres bezogen auf AiB).

[Der_Korken]

Bei 384bit bräuchte man in der Tat keine 512MB Caches mehr. Das wären mit 18Gbps knapp 70% mehr Bandbreite als eine 6900XT. Selbst 192MB wären da nicht völlig abwegig, wenn die Hitrate minimal höher als bei 128MB ist (man muss ja bedenken, dass Spiele mehr VRAM brauchen und somit auch das Working Set wächst bzw. der Cache größer werden muss, um die alte Hitrate zu halten). Jedenfalls hatte ich nicht das Gefühl, dass die Bandbreite bzw. der 128MB große Cache ein Bottleneck für N21 war. Wenn man ohnehin mehrere Cache-Dies verwendet, könnte man den Salvage auch gut dadurch abgrenzen, dass er nur den halben Cache bekommt.

[iamthebear]

Also kurz zusammengefasst:
Navi33: 16WGP/128MB/128Bit/8GB
Navi32: 32WGP/256MB/256Bit/16GB
Navi31: 48WGP/384MB/384Bit/24GB

Somit ist es eine ziemlich einfache 1/2/3 Aufteilung und alles skaliert linear mit inkl. wahrscheinlich auch dem Preis z.B. 500$/1000$/1500$

Der Cache muss deswegen linear mitskalieren, da schnellere Karten auch höhere Auflösungen als Target haben und somit mehr Cache brauchen um dieselbe Hitrate zu erreichen

[horn 12]

Navi 33 bis 3440 x 1440 175+ Frames

Navi 32 - Ideale 4K Karte Sprich 80+ bis 120 Fps

Navi 31 - 8K Karte oder 4K mit Größer 144 Hz / oder 5120 x 2160

[mboeller]

Ansonsten das, was man schon zuletzt mitbekommen hat. 1xGCD + 6x MCD,

Das macht aber keinen Sinn, wenn sowieso alles 1/2/3 skaliert ist.

Da wären dann 1/2/3 größere MCD mit 128MB IF$ und 128bit Speicheranbindung besser


Deshalb mal mein Ratespiel (mehr ist es ja momentan nicht):

N33 = 1x I/O (in N6 incl. Command/Geometry Processor) + 1x GCD (=4096CU + 4-8MB L2$;N5) + 1x MCD (128bit/128MB IF$; N6)
N32 = 1x I/O + 2x GCD + 2x MCD
N31 = 1x I/O + 3x GCD + 3x MCD (=7 Chips)

Beim I/O muss zw. N31/32/33 vielleicht der Takt des Geometrie Prozessors angepasst werden also vielleicht 1GHz für N33; 2GHz für N32; 3GHz für N31 (wäre aber bei N6 schon mehr als grenzwertig)

Ansonsten kommt man mit 3 Chips aus um die ganze Bandbreite abzudecken.

[Redneck]

Zwar nicht alles neu, aber aktuelles Video von RGT:

Keine 256MB/512MB IF$, sondern 384MB bzw. 192MB. Von ersterem hat er zuletzt vermehrt gehört, vereinzelt auch "nur" 192MB - womöglich aber schlicht SKU-abhängig.
Dementsprechend auch keine 16 GiB, sondern 24 GiB und 384 bit SI. Er ist zuversichtlich, dass das auch die tatsächlichen Specs sein werden bzw. sind.

Ansonsten das, was man schon zuletzt mitbekommen hat. 1xGCD + 6x MCD, 6SE/8WGP = 48WGP, >2.1-2.5x (konservativ) Rasterizer Performance, >3.5x RT-Performance, >3GHz Game Clock, >75 TFLOPs, 375-450W (letzteres bezogen auf AiB).

Sources von RGT : 3DCenter (und andere).... Rofl
Nicht , das ich unser 3DCenter nicht toll finden würde... aber die Spekulationen hier als Quelle zu nennen ist für mich eine wässrige Suppe noch dünner zu machen.

[Linmoum]

Nein, er nennt 3dcenter nicht als Quelle. Vielleicht mal richtig zuhören. ;)

Die 384MB/384bit hatte er übrigens letzte Woche schon einmal angerissen. In den letzten Tagen hat sich das für/bei ihm weiter verfestigt

[Lurtz]

AMD will 2023 nicht ernsthaft eine 8 GB-Karte mit ihrem VRAM-Management bringen? Wahrscheinlich noch mit 8x PCIe 5.0, damit ein Großteil der Käufer doppelt gef**** ist :ulol:

[Sunrise]

Sources von RGT : 3DCenter (und andere).... Rofl
Nicht , das ich unser 3DCenter nicht toll finden würde... aber die Spekulationen hier als Quelle zu nennen ist für mich eine wässrige Suppe noch dünner zu machen.
Die Specs insbesondere von N31 sind aus meiner Erfahrung mit den Jahren extrem realistisch. Die 24GB ergeben hinsichtlich der Konkurrenz Sinn und dementsprechend skaliert das SI… womit auch andere Fragen indirekt beantwortet werden können.

Etwas weniger Roh-Einheiten als ursprünglich vermutet und sehr hoher Takt, den AMD ja schon vorher stark steigern konnte, da sie mittlerweile unglaublich gute Arbeit bei der Optimierung leisten (CPU-Erfahrungen).

Passt für mich.

[BlacKi]

AMD will 2023 nicht ernsthaft eine 8 GB-Karte mit ihrem VRAM-Management bringen? Wahrscheinlich noch mit 8x PCIe 5.0, damit ein Großteil der Käufer doppelt gef**** ist :ulol:
vl ergänzt man das portfolio um eine neue leistungsklasse nach oben und dann würde der n33 chip eher als 7700xt mit 16x anbindung für 700-800€ uvp an den start gehen.



würde dann halt nichts an den 8gb ändern die so im raum stehen.

[Iscaran]

Deshalb mal mein Ratespiel (mehr ist es ja momentan nicht):

N33 = 1x I/O (in N6 incl. Command/Geometry Processor) + 1x GCD (=4096CU + 4-8MB L2$;N5) + 1x MCD (128bit/128MB IF$; N6)
N32 = 1x I/O + 2x GCD + 2x MCD
N31 = 1x I/O + 3x GCD + 3x MCD (=7 Chips)

Beim I/O muss zw. N31/32/33 vielleicht der Takt des Geometrie Prozessors angepasst werden also vielleicht 1GHz für N33; 2GHz für N32; 3GHz für N31 (wäre aber bei N6 schon mehr als grenzwertig)

Ansonsten kommt man mit 3 Chips aus um die ganze Bandbreite abzudecken.

Auf den Gedanken kam ich auch schon - hattes nur im Kommentar zu einer News gepostet:
EDIT: Allerdings in der Kombination CCD + n*(GCD +2 MCDs)
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12999911#post12999911

[unl34shed]

vl ergänzt man das portfolio um eine neue leistungsklasse nach oben und dann würde der n33 chip eher als 7700xt mit 16x anbindung für 700-800€ uvp an den start gehen.

N33 wird aktuell als drittgrößter Chip gehandelt, der Vorgänger N23 wird als 6600XT verkauft, warum sollte N33 jetzt für die 7700XT her halten, vor allem wenn man damit argumentiert, dass der Chip ja "abwertet" wird, wenn man auch noch eine zusätzliche Leistungsklasse darüber einführt?

Als 7600 oder 7500XT wäre die Karte mit 8GB zum entsprechenden Preis ok...

[Thunder99]

Effektiv gibt es ja nur zwei "Chips". MCM und Mono, Rest ist Ausführunsgart.
Die Unterschiede müssen aber groß genug sein, dass Salvage Lösungen dazwischen passen.

Langsam wären echt 1.5/3GB RAM Module sehr hilfreich damit die Karten "richtige" VRAM Menge bekommen. Ansonsten wird es oder kann es so schräg werden wie beim Nvidia mit der 3060/Ti/70/Ti/80

[BlacKi]

N33 wird aktuell als drittgrößter Chip gehandelt, der Vorgänger N23 wird als 6600XT verkauft, warum sollte N33 jetzt für die 7700XT her halten, vor allem wenn man damit argumentiert, dass der Chip ja "abwertet" wird, wenn man auch noch eine zusätzliche Leistungsklasse darüber einführt?

Als 7600 oder 7500XT wäre die Karte mit 8GB zum entsprechenden Preis ok...


mcm bietet die möglichkeit weniger bzw. gar nicht mehr salvagen zu "müssen". ist dass nicht das keyfeature? und wenn man salvaged, kostet das salvagen weniger.



akutell:
(ohne refresh)
n21 6800, 6800xt und 6900xt

n22 6700xt
n23 6600, 6600xt


rdna3:

n31 7900xt
n32 7800xt (wobei n32 ja n33 ist mit weniger chiplets)

n33 7700xt

[Dural]

So wenig wie man es bei den aktuellen CPUs sieht? Stichwort 5900x und co.

So hohe ersparnisse wie man es bei den hbm gpus gesehen hat?

Abgespeckte Varianten wird es immer geben, schon alleine deswegen weil es der Markt verlangt.

[Redneck]

Nein, er nennt 3dcenter nicht als Quelle. Vielleicht mal richtig zuhören. ;)

Die 384MB/384bit hatte er übrigens letzte Woche schon einmal angerissen. In den letzten Tagen hat sich das für/bei ihm weiter verfestigt

naja, er bezieht sich aber auf Twitter Konversationen von Greymon, Kopi und 3dcenter (1:55), weil sich ein paar Leute auf Diskussionen von genannten 3 Quellen angesprochen haben. Und dann sagt er : "Essentually what they have stated..."
Das ist für mich nur das weitertragen von Spekulationen. Wer das schon bei Twitter oder woanders gelesen hat, kann sich den Beitrag eigentlich sparen (es sei denn man steht auf Pauls Art der Vorträge :-)

[mboeller]

hat jemand schon bei Beyond3d geschaut?

RDNA3 kann anscheinend dual-Issue!

"Has VOPD dual issue wave32 instructions"

die diskutieren da ziemlich intensiv darüber

[robbitop]

Naja wenn die CUs doppelt so breit sind braucht man auch mehr scheduler resources.

[HOT]

Irgendwie stört mich diese 6 MCDs gewaltig. Die Chiplets sind dann N6 und das monolithische Teil dann N5? Das ergibt einfach keinen Sinn. Ich würd soviel wie möglich in N6 unterbringen wollen und versuchen das zum monolithischen Die zu machen und die N5-Chips dann in kleine Chiplets, die insgesamt wenig Fläche brauchen, allein schon aus Kostengründen. Da die WGPs den Löwenanteil der Leistungsaufnahme erzeugen würde ich N5 auch auf die WGPs beschränken, denn da wirkt das am besten. Und ich würd, wenn ich das sowieso schon zur Verfügung hab, das Ganze per X3D stacken. Der Move auf N6 für das MCD als monolithisches Die und N5 als kleine Chiplets spart doch viel viel mehr als das Stacking kosten würde, das steht in keinem Verhältnis - zumal das Stacking eh zum Standard-Packaging-Verfahren entwickelt werden wird und man erwarten kann, dass alle Zen5 so gefertigt werden.

Mein N3x bestünde aus 3 N6-Dies, N31, N32 und N33. N32 und N31 sind dann Basedies, auf die ich einfach die WGPs stacken als einzelne GCDs pro Shaderengine. Das löst alle Probleme. 7 Chips perfekt eingesetzt und problemlos fertigbar für diese Generation. Eigentlich ist das ne N6-Generation, aber man spart eben massiv Strom ein, indem man nur die WGPs in N5 fertigen kann. Ist doch total elegant. Nur bei N33 lohnt sichs halt nicht, da packt man die WGPs einfach mit in das Basedie und verwendet einfach die N21-I/O-Implementation weiter. Das hieße, der Brot und Butter-Chip N33 ist dann einfach weiter mit kassischem Packaging zu fertigen, sodass man nicht in Kapazitätsengpässe läuft. Die großen sind dann ja eh nur hochpreisig und Desktop, das sind im Verhältnis ja dann eh deutlich weniger.

[AffenJack]

Das dürfte daran liegen, dass die MCD nicht soviel miteinander kommunizieren müssen. Daher kommst du da mit begrenzten Bandbreiten zwischen den Chipteilen klar. Beim GCD gibts dagegen die klassischen GPU Probleme, weshalb man es als Singlechip behält, damit das Ding sich auch wie ein Singlechip verhält.

Wieso man nicht zu X3D greifen sollte ist mir aber auch schleierhaft. GCD auf die MCDs stacken macht für mich am meisten Sinn.

[HOT]

Das stimmt ja nicht, wenn die GCDs nur die WGPs enthalten und pro Shaderengine bestückt werden. Der Grafikchip wäre der N6-Chip. Die GCDs enthalten nur die WGPs. Das X3D ermöglich halt die ganze Konstruktion mit geringen Latenzen. Es gibt keine Nachteile und du brauchst super wenig N5 und kannst die "Dickfisch-Dies" unproblematisch in N6 fertigen. Die Wärmeabfuhr sitzt dann ja auf den N5-Dies, die ja am meisten Strom verbrauchen, also auch hier kein Problem.

[Gipsel]

Das stimmt ja nicht, wenn die GCDs nur die WGPs enthalten und pro Shaderengine bestückt werden. Der Grafikchip wäre der N6-Chip. Die GCDs enthalten nur die WGPs. Das X3D ermöglich halt die ganze Konstruktion mit geringen Latenzen. Es gibt keine Nachteile und du brauchst super wenig N5 und kannst die "Dickfisch-Dies" unproblematisch in N6 fertigen. Die Wärmeabfuhr sitzt dann ja auf den N5-Dies, die ja am meisten Strom verbrauchen, also auch hier kein Problem.Und die schlecht skalierenden Teile wie Speicherinterface und IO sowie Cache (die SRAM-Zellen schrumpfen in N5 ja keine 30% gegenüber N7 [für N6 gibt es von TSMC dazu keine Zahlen, oder?]) sitzen im relativ billigen N6-Die. klingt eigentlich nicht so schlecht.

[HOT]

AFAIK ist der SRAM bei N6 gleich zu N7 und bei N5 ist er nur 15% dichter als bei N7/6 IIRC jedenfalls. Wikipedia sagt
N7 0,027µm²
N5 0,021µm²

was eher deinen 30% entspricht.


Edit falsch erinnert. Es waren 35% bei N7 vs. N5.

[Berniyh]

Wieso man nicht zu X3D greifen sollte ist mir aber auch schleierhaft.
Ich denke der Name deines Diskussionspartners ist ein Hinweis. ;)

[AffenJack]

Das stimmt ja nicht, wenn die GCDs nur die WGPs enthalten und pro Shaderengine bestückt werden. Der Grafikchip wäre der N6-Chip. Die GCDs enthalten nur die WGPs. Das X3D ermöglich halt die ganze Konstruktion mit geringen Latenzen. Es gibt keine Nachteile und du brauchst super wenig N5 und kannst die "Dickfisch-Dies" unproblematisch in N6 fertigen. Die Wärmeabfuhr sitzt dann ja auf den N5-Dies, die ja am meisten Strom verbrauchen, also auch hier kein Problem.

Dann brauchst du doch eine riesige Bandbreite zwischen den WGPs und dem Basedie?

Vorher war der Gedanke, man trennt Infinity Cache, weil der als L3 auch nicht mehr solche Bandbreiten braucht. Die Shader Engines und WGPs können auch aber den L2 Daten hin und herschieben. In deiner Lösung müsste auch der L2 aufs Basedie. Aber die nötige Bandbreite steigt dadurch deutlich an.

Ich glaube für solche Lösungen ist es noch zu früh. 2024 mit der nächsten Gen kann ich mir sowas eher vorstellen.

[HOT]

Hast du doch problemlos über die TSVs. L1 und L0-Cache bleiben natürlich in den WGPs, aber L2$? Wo ist das Problem? Und nein, es geht auch beim 5800X3D. Warum soll das hier anders sein? Ich seh da keine Hindernisse. Sicherlich ist es so herum etwas komplexer als nur ein Passiver L3-Cache, aber das ist halt der nächste Schritt. Das Packaging ist doch im Prinzip dasselbe, nur x6 - aber dazu brauchst ja auch nur ne entsprechende Maschine. Kann ja sein, dass ich total Wunschdenke grade, aber das mit den 6 N6-Chiplets passt mMn einfach nicht. Sinnvoll wäre es doch vor allem die N5-Chips in Chiplets zu verwandeln. Ansonsten kannst doch auch einfach einen N5-Die mit einem N6-Die verbinden und fertig. Das wär dann ja auch nicht so riesig. Warum sich das dann beim billigeren N6-Dies so kompliziert machen?

[basix]

Für mich gibt es zwei mögliche Varianten. Beide haben ihre Vor- und Nachteile:

Variante 1 = 1x GCD, 6x MCD:

"GPU wie heute", einfach GDDR6 SI und Infinity Cache ausgelagert (MCDs)
Einfache Skalierbarkeit des Speicherinterfaces und Infinity Caches. N31 = 6 MCD, N32 = 4 MCD
Alles mit viel Datenaustausch auf dem monolithischen GCD
Display und Video dann auch auf dem GCD (viel Logik und IO Anteil ist relativ gering, nicht so tragisch)
Mit Standard Package und 2.5D denkbar (InFO_LSI, EFB). 3D in Form von 3D_SoIC ist mMn nicht nötig, 2.5D optional aber vermutlich vorteilhaft
Falls mit 1x MCD während dem Packaging was nicht OK wäre --> Salvage (N31 = 5x MCD; N32 = 3x MCD) --> 320bit; 192bit


Variante 2 = 1x MCD, 6x GCD:

"GPU wie heute", aber Shader Engines ausgelagert (GCDs)
Einfache Skalierbarkeit der Shader Engines. N31 = 6 SE, N32 = 4 SE
SRAM, SI, Video, Display, Command Processor, Geometry Engine auf dem MCD als Base Die ("monolithisch")
GCD Chiplets kommen obendrauf
GCDs = Shader Engines only inkl. L1$
L2$ sitzt vermutlich auch im MCD, direkt unter den GCDs an deren "Eckpunkten" und/oder Chiplet-Kanten (Datentransfer zwischen den L2-Slices somit energieeffizient) und wie bei N21 maximal 2-geteilt. Bei N32 mit 4x GCDs könnte man ihn sogar 1-teilig anorden
2.5D Packaging (InFO_LSI?). 3D in Form von 3D_SoIC ist denkbar, mMn aber nicht nötig (und teuer).
Falls 1x GCD während dem Packaging was nicht OK wäre --> Salvage (N31 = 5x GCD; N32 = 3x GCD) --> 192->160 CU; 128->96 CU --> Passt (N31 = 160...192 CU; N32 = 84...128 CU)


Ich kann mich ehrlich gesagt nicht für eine Variante entscheiden. Ich sehe aber desto länger ich darüber nachdenke den Vorteil tendenziell bei Variante 2:

Variante 1 ist näher am bestehenden Konzept der monolithische GPUs. Wenn es um "minimalen" Engineering Effort geht, wäre das vermutlich die richtige Variante.
Variante 2 hat das Potential, performanter, energieffizienter und kostengünstiger zu sein. Die Sexyness ist hier: Das grosse Die ist im günstigeren Prozess. Das MCD besteht zum grössten Teil aus Cache, welcher faktisch 100% Yield hat. Das MCD wäre trotz der Grösse also relativ günstig zu fertigen (günstiger als ein vergleichbar grosser RDNA2 Chip). Alles was nur 1x pro GPU vorhanden sein muss, schlecht auftrennbar ist, nicht maximale Density und Energieeffizienz verlangt oder schlecht skaliert, ist hier untergebracht (Command + Geometry Engine, ACEs, L2/3-Caches, Video/Display, I/O). Und man minimiert die N5-Die Sizes (Waferkapazität), maximiert den N5 Yield sowie bekommt den Chiplet Binning Vorteil dort wo er am meisten ausmacht (Performance, Energieeffizienz). Nachteil ist, dass man entweder bei L2$-Zugriff auf das MCD gehen muss oder geteilte L2-Caches hat (falls doch auf den GCDs). Je nach Anordnung kann der L2$-Aber direkt unter dem L1-Cache sitzen, womit rämlich sehr nah wäre (=energieeffizient). Ich würde den L2$ im MCD präferieren, da Cache langfristig einfach nicht so gut mitskaliert wie Logik.
Variante 2 ähnelt eigentlich stark Ponte Vecchio

[Thunder99]

Ist niemand geschockt von der Twitter Meldung "I am disappointed" von kopi? Könnte man meinen es gibt eine 2900XT reloaded :D Aussen hui innen pfui also was dabei raus kommt.

Könnte auch einfach nur nichts sein um die wahre Leistung von N31 zu verschleiern. :confused:

[Blediator16]

Ist niemand geschockt von der Twitter Meldung "I am disappointed" von kopi? Könnte man meinen es gibt eine 2900XT reloaded :D Aussen hui innen pfui also was dabei raus kommt.

Könnte auch einfach nur nichts sein um die wahre Leistung von N31 zu verschleiern. :confused:

Der hat einfach keine Ahnung.

[r3ptil3]

Der hat einfach keine Ahnung.

Zumindest mehr als du.

Vieles was er "geleakt" hat, war nicht selten sogar genau richtig.

[Nightspider]

Sehr kleine GPU Tiles würden bei einem neueren Prozess auch mehr Sinn ergeben.

Jetzt kommt ja sogar Nvidia schon eher mit riesigen monolithischen Chips um die Ecke.

Wenn dann müsste AMD den zeitlichen Vorsprung durch kleine Tiles bei einem frischeren Prozess nutzen. AMD muss mal versuchen _vor_ NV etwas auf den Markt zu bringen. Vielleicht kriegen sie es bei N3 und RDNA4 auf die Reihe.

[Unicous]

Zumindest mehr als du.

Vieles was er "geleakt" hat, war nicht selten sogar genau richtig.

Er "leaked" so gut wie nur zu Nvidia (und "genau richtig" ist schamlos übertrieben) und hat sein messaging auf einmal extrem geändert während andere Leute die eher AMD und Intel leaken sein fear mongering bislang nicht unterstützen. Da er auch nicht konkret warum er so endlos enttäuscht ist :rolleyes:, scheint das bislang unbegründetes Übertreiben zu sein. Viel schlimmer ist auch, dass er seit ein paar Wochen bei seinen "geleakten" specs und sonstigen Daten zurückrudert und immer wieder die "Leak-Pfosten" verschiebt. Ich habe eher das Gefühl das seine Quellen ihn verarscht haben und er jetzt krampfhaft versucht den Scherbenhaufen zusammenzukehren.

Diese dämliche Wichtigtuerei geht mir eh auf den Sack. Fast alle Leaker, sei es YT, Twitter, reddit etc., nehmen sich extrem wichtig und reagieren extrem pampig wenn sie auf Diskrepanzen hingewiesen werden.:rolleyes:

[r3ptil3]

Verhalten, eigene Meinung... würde ich nichts drauf geben.

Die Menge an tatsächlichen reinen Infos zählt und da war er nicht übel.

Dass er enttäuscht ist, darauf würde ich nichts geben. Kann genau so gemeint sein, dass wie du sagst man ihn verarscht hat oder die Karten einfach zu spät kommen und das was dieses Jahr kommt, vielleicht gerade mal in vereinzelten Szenarien auf 6900 XT Niveau liegt, bei natürlich besserer Effizienz.

[Blediator16]

Zumindest mehr als du.

Vieles was er "geleakt" hat, war nicht selten sogar genau richtig.

https://docs.google.com/spreadsheets/d/1oLA4RgOVlXa3_GWkFIcgUCnLzdQbADHkaXSOtN1UxRo/edit#gid=1477841742

Und das ist bereits ein Jahr alt. Anhand seiner "leaks"d die er dieses mal hatte, sind wir sicherlich noch weiter unten.

Er ist einer der schlechtesten Leaker.

[Unicous]

@bardh

Bezüglich Lovelace hat er offensichtlich ordentlich ins Klo gegriffen und lässt seine Frustration darüber an RDNA3 aus ohne das auch nur ansatzweise zu begründen.:freak:

Dieses Verhalten zeigt mir, dass er nicht so integer ist wie er in der Vergangenheit wahrgenommen wurde.

Nochmals, er hat keinerlei Informationen zu RDNA3 außer dem was schon von anderen in die Welt gebracht wurde und auch hier weiß er nicht ob das richtig ist. Denn hier ändern sich auf einmal auch alle paar Tage die Specs die von den Leakern schon als 99% bestätigt angesehen wurden. Das ist alles ein einziger clusterfuck und lässt mich eher vermuten, dass alle verarscht wurden.

Dass du jetzt spekulierst weswegen er überhaupt enttäuscht ist, finde ich auch sehr putzig wenn es doch keinerlei Anhaltspunkte gibt, nur vages shitposting ohne Substanz.


@Blediator16

Diese Liste ist total Banane. Denn sie führt unter anderem auch eigene Überlegungen als "leaks"/claims und wurde im Übrigen seit fast einem Jahr nicht geupdatet. Der Typ der die Liste gemacht hat ist auch nicht ganz knusper. Typischer reddit keyboard warrior.

[Linmoum]

Kopite hat vor Wochen selbst noch sinngemäß geschrieben, dass er zu AMD/RDNA3 keine eigenen Infos hat. Merkt man ihm auch an. Dass PCGH und Co. alles noch so offenkundig absurde trotzdem groß propagieren, ist einfach nur erschreckend.

[Unicous]

Ein Glück ist 3DCenter da anders... oh wait.:redface:

[r3ptil3]

https://docs.google.com/spreadsheets/d/1oLA4RgOVlXa3_GWkFIcgUCnLzdQbADHkaXSOtN1UxRo/edit#gid=1477841742

Und das ist bereits ein Jahr alt. Anhand seiner "leaks"d die er dieses mal hatte, sind wir sicherlich noch weiter unten.

Er ist einer der schlechtesten Leaker.

Haha, genial, danke.

Aber zu den schlechtesten gehört er ja nicht.
Man muss es auch in Relation zur Gesamtzahl der Leaks setzen.

Aber Recht hast du, dass er doch einige Fehler/Falschinfos aufweist.

[OgrEGT]

Ich finde das alles gar nicht schlimm... dass wir es bei den Leaks nicht mit seriösem Journalismus zu tun haben ist uns allen klar
... von daher finde ich es auch nicht schlimm wenn andere über die Leaks informieren...
Ist ja auch jedes mal das gleiche Spiel...

[HOT]

Zumindest mehr als du.

Vieles was er "geleakt" hat, war nicht selten sogar genau richtig.

Bis auf die 7 Chips lag er mMn bei allem falsch. Er hatte eben nur diese eine Info: Es sind 7 Chips, Ende. Alles andere hat er sich zusammengesponnen.
Irgendjemand hat dann noch in Erfahrung bringen können, dass es nur 48 bzw. 32 WGPs sind und nicht die zusammengesponnenen 60.
Und N33 war schon bekannt evtl, mal sehen ob das stimmte, da hab ich nämlich auch Zweifel.

Und das "enttäuscht" wird einfach nur durch die weniger WGPs als angenommen resultieren.

[Dampf]

Kopite hat vor Wochen selbst noch sinngemäß geschrieben, dass er zu AMD/RDNA3 keine eigenen Infos hat. Merkt man ihm auch an. Dass PCGH und Co. alles noch so offenkundig absurde trotzdem groß propagieren, ist einfach nur erschreckend.

Chill doch. Es ist für AMD sogar besser, wenn jetzt die Gerüchte ins negative gehen.

Denn wenn sie dann überraschend doch richtig abliefern, wird die positive PR umso größer sein.

[Linmoum]

Man sollte als seriöses Medium nicht jeden Furz an Gerücht mit einem Artikel wertschätzen. Das kann WTFtech gerne machen, aber auf das Niveau sollte man sich als großes deutsches Hardwaremagazin nicht begeben.

Bei RDNA2 hieß es nach dem Launch von Ampere damals schon, eine 3080 sei für AMD außer Reichweite und man landet ja sowieso nur auf 3070/2080Ti-Niveau. Ist insofern ja nichts Neues. Gerüchteküche halt.

Trotzdem sollte man die Leaker und Gerüchteküche mittlerweile auch zuordnen können. Kopite hat seine Quellen bei NV und jemand wie MLID hat mit Intel seine Treffer, dafür bei den anderen Herstellern eher... nunja. Einfach bekanntermaßen wenig vorzuweisen.

To be honest, I don't have much information about AMD.
Hat er vor ein paar Wochen erst geschrieben. Hat halt seinen Grund, warum er quasi ausschließlich was zu NV schreibt. Für die Bild-Presse wäre es aber schon eine Berichterstattung wert, wenn man Jensen auf die Toilette gehen sehen würde. ;D

[Thunder99]

3DC ist besser, da ihr es ja schön widerlegt habt :D

[OgrEGT]

Wie komplex ist eigentlich das Muster an TSVs wenn man Cache auf Cache oder Logik auf Logik stackt? Ich würde meinen dass ersteres wesentlich einfacher ist und nicht so fehleranfällig da es hier regelmäßige(re) Strukturen hat...
Könnte mir auch vorstellen dass es im zweiten Fall deutlich mehr Kontaktverbindungen braucht... wie muss man sich da das Alignment von beiden Chiplets vorstellen dass da auch alle Kontaktverbindungen geschlossen werden?