Diskussion zu: AMDs Navi 31 mit 384-Bit-Interface, 192 MB Infinity Cache und ...

[Leonidas]

Link zur News:
https://www.3dcenter.org/news/geruechtekueche-amds-navi-31-mit-384-bit-interface-192-mb-infinity-cache-und-optional-192-mb-3d

[Gast Ritis]

Wenn am Ende "nur" das Speicherinterface mit dem LL-Cache auf separate Chiplets ausgelagert wird würde ich auch nur bedingt von einer Multi-Chiplet GPU sprechen. Also so lange nicht Shader-Units oder andere zentrale Elemente der Grafik-Pipeline auf mehrere Chiplets verteilt sind.

Mit solch einer Auslagerung wird der GPU-Chip um rd 40% der Fläche eines entsprechenden Monolithen verkleinert. Das ist ne menge Spannung die man sparen kann und Taktpotential zu gewinnen.

Wenn die CUs doppelt so viele Stream-Prozessoren bzw. SIMD Einheiten verbaut sind, dann passt das doch mit weniger Shader-Units, dafür mehr Takt. Die Auslastung wird da eh schwieriger, besser die arbeiten Schneller, so lange der IF-Cache nachkommt....

Frage mich nur wann dann endlich die Multi-GPU Chiplet Lösung kommen soll.

[iamthebear]

Also ich kann mir das noch nicht ganz vorstellen wie das mit der Segmentierung funktionieren soll. Bei den Salvage Modellen word sicher eher das SI+RAM reduziert statt dem IC.
Wenn dann macht das nur beim Topmodell Sinn. Das könnte man als 384MB 8K Edition vermarkten aber ich kann mir nicht vorstellen, dass AMD einen Navi32 mit 256MB bringt und dann ein Navi31 Modell mit 192MB auch wenn das SI und Shader dicker sind.

Ich denke, dass der VCache eher etwas für die Pro Varianten wird.
Im Gegensatz zum 5800X3D sehe ich keine gezielte Kundengruppenwie Gamer, die sonst unbedingt mehr Cache benötigen würden.

Auch möglich, dass im Treiber beide Varianten implementiert wurden aber nur eine davon wirklich kommt.

Was mich etwas wundert: 32MB L3 als VCache Die sind schon verdammt klein. Das wären um die 20mm². Das sich das noch auszahlt...

[Gast]

Ich denke, dass der VCache eher etwas für die Pro Varianten wird.

Viele "Pro" Anwendungen profitieren nur wenig von den Cache-Massen.

Cache hilft nur dann wenn die selben Daten oft gebraucht werden, sehr viele HPC Anwendungen greifen die selben Daten aber nur 1x an, verarbeiten aber Unmengen davon.

Da hilft Cache wenig bis gar nichts und nur rohe Bandbreite, weshalb es für diese Anwendungsfälle ja auch die HBM-Varianten gibt.

[Lehdro]

Das könnte man als 384MB 8K Edition vermarkten aber ich kann mir nicht vorstellen, dass AMD einen Navi32 mit 256MB bringt und dann ein Navi31 Modell mit 192MB auch wenn das SI und Shader dicker sind.
Vielleicht gibt es N32 nur dann mit IF$ Erweiterung wenn dieses als N30 als Doppelpack herhalten soll?
Im Portfolio dann so:
2x N32 + IF$ Chiplets
N31 + IF$ Chiplets
N31 (Salvage?)
N32
N32 (Salvage?)
N33
...

Ich denke, dass der VCache eher etwas für die Pro Varianten wird.
Im Gegensatz zum 5800X3D sehe ich keine gezielte Kundengruppenwie Gamer, die sonst unbedingt mehr Cache benötigen würden.
Sicher? Ist der Nutzen von IF$ anders als bei CPUs nicht eher gering bei non Gaming Workloads? RDNA2 war zumindest trotz dickem IF$ nicht so die Wucht in Tüten was die professionellen Benchmarks angeht iirc.


Was mich etwas wundert: 32MB L3 als VCache Die sind schon verdammt klein. Das wären um die 20mm². Das sich das noch auszahlt...
Wie groß sind denn die MCDs? Muss ja auch irgendwie physikalisch draufpassen.

[Gast]

Was mich etwas wundert: 32MB L3 als VCache Die sind schon verdammt klein. Das wären um die 20mm². Das sich das noch auszahlt...

Es wird ja wohl Cache + Memory Interface sein.

[Leonidas]

Es wird ja wohl Cache + Memory Interface sein.

Das sind die MCDs. Aber in den extra Chiplets mit 3D V-Cache ist dann nur noch IF$ drin. Die werden in der Tat klein.

[Gast]

Sicher? Ist der Nutzen von IF$ anders als bei CPUs nicht eher gering bei non Gaming Workloads? RDNA2 war zumindest trotz dickem IF$ nicht so die Wucht in Tüten was die professionellen Benchmarks angeht iirc.
Wie groß sind denn die MCDs? Muss ja auch irgendwie physikalisch draufpassen.
Kommt auf den Bench an. In 3dsmax ist eine A5000 grob 10% schneller als eine W6800, in CREO und MAYA ist der Unterschied eklatant bis groß (+50% bis +20%), in Solidworks ist dafür die W6800 eklatant vor NVidia. Mehr hatte Igor nicht getestet. Klar, wenn man die A6000 nimmt, ist viel Abstand. Aber die braucht halt auch viel mehr und ist vermutlich dreimal so teuer. Wenn man bedenkt, dass die W6800 mit 17,8TFlops FP32 gegen eine A5k mit 27,7TFlops FP32 antritt, dann finde ich das Ergebnis nicht so schlecht.

Und bezüglich des 3D Cache: Ich fände es komisch, wenn AMD hier keine 64MB verwendet. Was bringt einem ein Chiplet Ansatz, wenn man dann schon 3 verschiedene Cache Chiplets fertigen muss? Außer, AMD will bei Zen4 32MB Cache Chiplets einsetzen. Ich würde aber schon vermuten, dass man hier zwischen CPU und GPU die gleichen Chiplets verwenden will, IC ist ja auch technisch der L3 aus den Zens. Insofern wird man hier sicher eine Kompatibilität anstreben. Vielleicht packt man daher ja 2 MCs in ein Gehäuse und die teilen sich dann L3 und 3D Cache.

[Leonidas]

U.U. lassen sich die 32-MB-Cache-Bausteinen koppeln, so dass sie 64 MB ergeben. Oder bei Zen 4 benutzt man halt generell diese kleineren Cache-Bausteine.

Oder die These der Zweitverwendung ist komplett falsch und jeder Cache-Baustein wird extra hergestellt. In jedem Fall ist es Wahnsinn, was sich AMD inzwischen an unterschiedlichen Chips leisten kann. Früher musste man noch als wenigen einzelnen Chips das komplette Produkt-Programm schnitzen, weil einfach nicht mehr Geld für eine breiter aufgestellten Entwicklung da war.

[BlacKi]

Bei den Salvage Modellen word sicher eher das SI+RAM reduziert statt dem IC.


wirds das denn überhaupt geben? ich mein, vl vom n33, aber n32 und n31 sind doch so komplex, das wenn man chiplets weglässt zwecks marktsegmentierung ist das doch kein richtiger salvage... ist ein 5800x eine salvage cpu?

[basix]

Also ich kann mir das noch nicht ganz vorstellen wie das mit der Segmentierung funktionieren soll. Bei den Salvage Modellen word sicher eher das SI+RAM reduziert statt dem IC.
Wenn dann macht das nur beim Topmodell Sinn. Das könnte man als 384MB 8K Edition vermarkten aber ich kann mir nicht vorstellen, dass AMD einen Navi32 mit 256MB bringt und dann ein Navi31 Modell mit 192MB auch wenn das SI und Shader dicker sind.

Ich denke, dass der VCache eher etwas für die Pro Varianten wird.
Im Gegensatz zum 5800X3D sehe ich keine gezielte Kundengruppenwie Gamer, die sonst unbedingt mehr Cache benötigen würden.

Auch möglich, dass im Treiber beide Varianten implementiert wurden aber nur eine davon wirklich kommt.

Was mich etwas wundert: 32MB L3 als VCache Die sind schon verdammt klein. Das wären um die 20mm². Das sich das noch auszahlt...

V-Cache ist mMn Bauernfängerei. Wie du sagst: Gibt viele Dinge, die dagegen sprechen. Aus meiner Sicht hat ein MCD entweder 32MByte oder 64MByte IF$ - ohne Option auf V-Cache. Was es dann wird ist eine Frage der Auslegung, aus meiner Sicht sollten 32MByte und somit 192MByte für N31 aber ausreichen.

@Leo:
Das 1x GCD + 6x MCD Konzept gab es hier im Forum schon ziemlich früh zu sehen, nach einem Video von RGT ;)
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12995133#post12995133

Aber auch viele, viele andere Konzepte (nur um auch meine "Fehlschläge" aufzuzeigen ;))
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12976392#post12976392
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12976725#post12976725
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12976842#post12976842

Das interessante daran: Umso einfacher das Konstrukt, desto höher empfand ich dessen Wahrscheinlichkeit.

[Convertible]

Ich würde aber schon vermuten, dass man hier zwischen CPU und GPU die gleichen Chiplets verwenden will.

MCD ist in 6nm
Zen 4 CPU-Chiplet ist in 5nm

TSMC hat öffentlich angekündigt 7/6nm auf 7/6nm und 5nm auf 5nm

Wenn also der gleiche Cache-Die zwischen Zen4-CPU und GPU verwendet werden soll, dann muss der 3D-Cache auf dem GCD liegen, denn nur dieser ist in 5nm und damit kompatible mit 5nm 3D-V-Cache.

Andernfalls müsste man den 3D-Cache vom Zen 3 verwenden, der ja auch 7nm ist und der ist ja bekanntlich nicht 32MB groß.

Es würde mit dem 64MB 3D-Cache von Zen 3 also nur in der beschriebenen Menge funktionieren, wenn man keine 6x64bit-MCDs hätte, sondern 3x128bit-MCDs, dann könnte man eben 3x64MB=192 drauf packen.

[Leonidas]

@Leo:
Das 1x GCD + 6x MCD Konzept gab es hier im Forum schon ziemlich früh zu sehen, nach einem Video von RGT ;)
https://www.forum-3dcenter.org/vbulletin/showthread.php?p=12995133#post12995133

:up:

(kannte ich natürlich, habe es auf 3DC und Twitter verlinkt)



@Convertible

Sofern Deine technischen Ausführungen stimmen, dann ist es also eine extra Linie an 3D V-Cache: 6nm-Bausteine á 32MB - nur gedacht für die 6nm MCDs. Denn nur dort passt der 3DVC hin, nicht auf den GCD.

[Gast Ritis]

Ich dachte die SRAM Zellen von Cache sind doch ein so simples Design dass man das für die neuen Fertigungstechniken mal eben auflegt damit man etwas zum testen hat.
Solange die Stückzahlen bei AMD steigen haben die m.M. überhaupt keinen Anlass nur ein einziges Cache-Chiplet Modell zu fertigen sondern können für Zen und RDNA jeweils optimierte Designs in unterschiedlichen Fabs produzieren.

AMD hatte auch nicht behauptet der InfinityCache wäre mit dem des Zen identisch, die Aussage war IMHO, dass man vom Cachedesign bei Zen2 und Zen3 gelerntes auch beim RDNA InfinityCache umsetzen konnte. Das müsste meiner Meinung nach mit der Cache-Grösse und den erreichbaren Latenzen zu tun haben, sowie der relativen Fläche pro Cache-Size.
Wäre interessant jemand hätte da einen Vergleich ob normalisiert über die Fertigungs-Nodes die schnellen grossen Caches von AMD über die Zeit auch relativ pro MB kleiner geworden sind, "more dense".

Wie gross ein Cache werden kann bzw. soll besagt die Cache-Hitrate. Bei dem Schaubild von AMD damals zum Thema war bei FHD mit 64MB die Kurve flach geworden, bei 1440 mit 128MB. Ich vermute bei 4k braucht es mindestens 192MB Infinity Cache bzw. einfach das 4fache vom FHD Cache abzüglich ein paar Prozentpunkte für Shader-Code.

Ob jetzt 256MB oder mehr wirklich etwas bringen kann man von dem Schaubild schwer sagen, weil die damals sicherlich keine Raytracing-Games analysiert hatten. Aber für Games ohne RT gebaut wie in 2020 und davor wird man vermutlich nicht mehr Cache brauchen können.

Wenn die CUs wirklich mehr/doppelte Stream-Prozessoren vorhalten werden die auch häufiger Hits im lokalen Cache haben, es wird weniger oft vom gleichen über das SI bzw. den InfinityCache gespeichert und gelesen.

[Gast]

Wenn die CUs wirklich mehr/doppelte Stream-Prozessoren vorhalten werden die auch häufiger Hits im lokalen Cache haben, es wird weniger oft vom gleichen über das SI bzw. den InfinityCache gespeichert und gelesen.

Wenn die CUs doppelte Streamprozessoren haben, werden sich vor allem auch die Speicherzugriffe enorm erhöhen. Ob diese von den unteren Cacheleveln abgefangen werden ist sehr fraglich.

Eher ist es, je schneller der Kern wird, umso mehr Speicherzugriffe werden erzeugt, umso mehr Bandbreite, bzw. alternativ eben Cache der die Zugriffe abfangt, braucht es.

Das Cache-Schaubild mit einer doppelt so schnellen Grafikkarte sieht mit sicherheit deutlich anders aus, als das was AMD gezeigt hat, und die Kurven werden früher, sprich bei geringeren Cachemengen abflachen.

[Leonidas]

Zu diesen Cache-Schaubildern hätte ich gern reale Daten. Ich denke, dass hierbei AMD reichlich PR einfließen läßt - so, dass es das jeweils aktuelle Produkt gutaussehen läßt.

[Iscaran]

Wie gross ein Cache werden kann bzw. soll besagt die Cache-Hitrate. Bei dem Schaubild von AMD damals zum Thema war bei FHD mit 64MB die Kurve flach geworden, bei 1440 mit 128MB. Ich vermute bei 4k braucht es mindestens 192MB Infinity Cache bzw. einfach das 4fache vom FHD Cache abzüglich ein paar Prozentpunkte für Shader-Code.

Ob jetzt 256MB oder mehr wirklich etwas bringen kann man von dem Schaubild schwer sagen, weil die damals sicherlich keine Raytracing-Games analysiert hatten. Aber für Games ohne RT gebaut wie in 2020 und davor wird man vermutlich nicht mehr Cache brauchen können.


Ich würde mal ganz spekulativ behaupten man braucht für 4k ~ 4x den Cache wie bei FHD also 256 MB damit die Kurve abflacht.

Betrachtet man den Trend Pixel/Cache MB gibt sich nämlich folgendes
1920x1080/64 MB = 32.400 Pixel / MB
2560x1440/128 MB = 28.800 Pixel / MB (=FHD/1.125)

Theoretisch erwartet also:
3840x2160/192 MB = 43.200 Pixel / MB
oder
3840x2160/256 MB = 32.400 Pixel / MB

Setze ich den Pixel/MB Trend von FHD => WQHD => 4k nochmals linear fort ergäben sich als "optimum" 25.600 Pixel / MB

=> 3840x2160/25.600 = 324 MB

Aber ist nur eine Idee...ich vermute daher fast dass man 256 MB Cache brauch oder sogar ein ticken mehr.

[Gast]

Zu diesen Cache-Schaubildern hätte ich gern reale Daten.


Die kann dir aber höchstens AMD liefern. Und dann kann man gleich den Grafiken glauben, oder eben nicht.

[Leonidas]

Genau das meinte ich: Hier ist man gezwungen, den Hersteller-Angaben zu glauben.

[Gast]

So ist es, eine externe Möglichkeit die Cache Hitrate zu messen wird es höchstwahrscheinlich nicht geben.