News AMD Zen 6 CCD: 50 Prozent mehr Kerne auf nahezu gleicher Fläche?

bogge101 schrieb:
wie weit soll der denn runter?
Dein Bild ist unvollständig, denn es zeigt nur einen Teil der CPU. Die Kerne brauchen nicht viel Watt, da ist Dein Bild korrekt. Aber es geht mir um die gesamte CPU. Beispielsweise hier mein Ryzen 5 7500F im Idle (keine 3 W für die 6 Kerne im Idle, aber trotzdem 22 Watt für die CPU :(

1770234576264.png
 
  • Gefällt mir
Reaktionen: Volker und qiller
Piktogramm schrieb:
@stefan92x
https://old.chipsandcheese.com/2025/10/31/37437/
Nochmal nachgeschaut. GMI mit 32B/clk scheint es zu geben und bei Strix Halo in Richtung CCD verbaut zu sein mit ~60GB/s Bandbreite bei 2GHz IF(?). Die iGPU von Strix Halo hat GMI mit 64B/clk wie auch die CCDs der größeren Plattformen.
Ok, 32B/clk GMI für die CCDs fürs Pro-/Consumerkram scheint realistisch.
Wobei mir die Bandbreiten (~60GB/s) für CCDs mit zukünftig 12Kernen etwas wenig erscheint.

Du kannst es auch aus der anderen Seite betrachten:
An SP8 hängen 8 CCDs und 8 MRDIM DDR5-12800. Jedes DIMM hat eine maximale Bandbreite von 102 GB/s. Das geht mit 32B/clock nicht. 64B/clock ist das Minimum wenn man die Verbindung nicht als Flaschenhals haben will.

Bei SP8 sind es 2 MRDIMM DDR5-12800 je CCD. Das ergibt 204 GB/s. Da wird 64B/clock zum Flaschenhals.

Piktogramm schrieb:
@ETI1120
Ich habe die Bezeichnungen von Chips and Cheese übernommen, damit klar wird worauf ich mich beziehe.
Bei der Beschreibung von Phoenix haben sie Port verwendet, was ich finde sehr viel besser für den Anschluss an einen Ringbus passt.
https://chipsandcheese.com/p/hot-chips-2023-amds-phoenix-soc

Da gab es auch diese nette Graphik von Phoenix, da ist mir sehr viel klar geworden:
1770245158391.png

sie ist aus der Präsentation zu Phoenix von AMD auf der Hot Chips 2023. Foliensatz und Link zum Video sind bei der Hot Chips Website unter Archiv zu finden.
Piktogramm schrieb:
So richtig verständlich ist mir das mit dem IF nicht. Wenn bei StrixHalo die IGPU einfach mal 8 Ports haben kann, dann kann da intern nicht nur ein geduplexter Ringbus a 64B/clk liegen. So ein Ringbus bekommt ja nicht mehr Bandbreite, nur weil mehr Ports dranhängen. Mindestens bei StrixHalo, intern muss das Ding nochmals anders aufgebaut sein.
Das ist die eine Seite, wenn man 8 Ports an einen Bus hängt sollte er die Daten auch liefern bzw. weiterschieben können.

Und es geht nicht nur um den Trafic zur CPU oder zum Speicher. Auch die Display Engine hängt am Infinty Fabric. Das Infinity Fabric on Chip ist ein Bussystem dass an das alle IP-Blöcke des SoC angeschlossen sind.

Das Infinty Fabric gibt es natürlich auch in den GPUs, nur ein bisschen Breiter: 1024 Byte/clock
1770246229408.png

https://chipsandcheese.com/p/amds-rdna4-gpu-architecture-at-hot

Und bei einem 1024 Byte oder 8092 bit breiten Bus ist wohl zu verstehen warum AMD bisher keine Gaming GPU mit mehren GPU Chiplets gebracht hat.

Ganz so fett wird der Infinity Fabric in den IODs von SP7 und SP8 nicht sein. Aber wenn der Inifinity Fabric im IOD den Datenverkehr zwischen CCds, Speichercontroller und IO bewältigen soll, muss das Infinity Fabric im IOD mehr Bandbreite haben als die Ports zu den CCDs.
 
  • Gefällt mir
Reaktionen: Piktogramm
ETI1120 schrieb:
Die Gerüchte besagen
Zu Medusa
Aus meiner Sicht muss Medusa mindestens PCI-E 5.0 bringen. Auch sehen die maximal nur 4 schnellen Kerne schlecht aus gegen Panther.
 
@Alesis Mehr wie PCIe 5.0 bringt nichts.

In Notebooks bringt PCIe 5.0 nur was in Sonderfällen. Im Desktop ist es allerdings dringend notwendig um Grafikkarten anbinden zu können.

Die Gerüchte gehen von bis zu 16 Classic Kernen aus. Alle SKU über 8 Kernen sollen per Chiplet gemacht werden.

Für Notebooks ist es wichtiger, dass die Frequenz der Dense Kerne ein bisschen höher kommt als mehr Classic Kerne. Alle gehen nur davon aus dass es nur das mit 12 Classic Kernen gibt.

Außerdem muss AMD mit Zen 6 mehr vom Potential der 6 ALUs auf die Piste bringen. Zen 5 überzeugt bei der Floating Point Leistung bei der Integer allerdings nicht so Recht.
 
@ETI1120
Strix Point = Gorgon Point haben kein PCI-E 5.0. GPUs wie 5060/5070 erleiden obendrauf einen zusätzlichen Leistungsverlust durch die PCI-E 4.0 Anbindung.

Ich denke aber auch, dass 8 schnelle Kerne völlig ausreichen im Notebook. Ich bin jedenfalls gespannt, was kommen wird.
 
Alesis schrieb:
@ETI1120
Strix Point = Gorgon Point haben kein PCI-E 5.0. GPUs wie 5060/5070 erleiden obendrauf einen zusätzlichen Leistungsverlust durch die PCI-E 4.0 Anbindung.
Wenn im Notebook 8 Lanes zur Kopplung mit der GPU verwendet werden ist PCIe 4.0vollkommen ausreichend.

Wenn im Desktop nur 4 Lanes übrig bleiben ist PCIe 4.0 zu wenig.

Aber ganz ehrlich fände ich 20 Lanes PCIe 4 sinnvoller als 16 Lanes PCIe 5.0.

Alesis schrieb:
Ich denke aber auch, dass 8 schnelle Kerne völlig ausreichen im Notebook. Ich bin jedenfalls gespannt, was kommen wird.
8 Classic Kerne im Notebook bringen nur dann was wenn sie höher takten als es die Dense Kerne. Und dann verbrauchen sie auch überproportional viel.

Was der Laufzeit ohne Netz nicht gut tut. Man muss 10 Stunden ohne Netz mit einem Notebook arbeiten können. Die Peak Performance in Benchmarks ist nicht das auf was es ankommt.

Es ist die Effizienz. Und da gibt hoch takten im Notebook keine Sinn, weil es automatisch bedeutet dass der Kern im ineffizientesten Betriebspunkt arbeitet. Das ist beim Desktop oder Desktop Replace Laptop OK, aber nicht bei einem Notebook das auch ohne Netz funktionieren soll.
 
  • Gefällt mir
Reaktionen: Miuwa
ETI1120 schrieb:
8 Lanes zur Kopplung mit der GPU verwendet werden ist PCIe 4.0vollkommen ausreichend.
Ja, bei einer GPU mit ausreichend Speicher. Doch wenn Daten in den RAM müssen, verliert man zusätzlich Leistung, durch den Flaschenhals 4.0
 
@Alesis
Wenn die GPU Speicher im Ram auslagern muss, ist so oder so das Ende der Fahnenstange erreicht.

ETI1120 schrieb:
Das ist die eine Seite, wenn man 8 Ports an einen Bus hängt sollte er die Daten auch liefern bzw. weiterschieben können.
Das geht ja fast schon als Binsenweisheit durch :).
Das der BUS bei Strix Halo überhaupt 8x 64B/clk schieben kann, müsste bedeuten, dass das Ding 512bit breit ist. Das mag sinnvoll sein zwischen InfinityCache und iGPU. An sich wäre es aber Irre, so einen breiten Bus zu allen anderen Blöcken zu ziehen, wenn die je nur 1x 64B/clk bzw. 32B/clk können.
Imho ist das an der Stelle kein "simpler" Ringbus.
 
Alesis schrieb:
Ja, bei einer GPU mit ausreichend Speicher. Doch wenn Daten in den RAM müssen, verliert man zusätzlich Leistung, durch den Flaschenhals 4.0
Im Notebook hat man IMO zu aller erst den Flaschenhals Power. Wenn man nur an der Batterie hängt so oder so aber auch sonst wird es schwer auf dauer die Wärme aus dem kompakten Gehäuse zu bekommen.

Wenn der GPU der Speicher ausgeht wird sie ausgebremst. Das kann man nicht mit PCIe 5.0 kompensieren. Mit PCIe 5.0 ist man nur ein bisschen weniger ausgebremst.
 
Piktogramm schrieb:
Das geht ja fast schon als Binsenweisheit durch :).
Klar ist es eine Binsenweiheit. Auf der anderen Seite hat man in der Technik immer irgendwo einen Flaschenhals.
Piktogramm schrieb:
Das der BUS bei Strix Halo überhaupt 8x 64B/clk schieben kann, müsste bedeuten, dass das Ding 512bit breit ist. Das mag sinnvoll sein zwischen InfinityCache und iGPU. An sich wäre es aber Irre, so einen breiten Bus zu allen anderen Blöcken zu ziehen, wenn die je nur 1x 64B/clk bzw. 32B/clk können.
8 x 64B gibt 512B, oder?

Wenn man sich den IOD von Strix Halo anschaut dann sind die Memory controller auf beiden Seiten der GPUs. Braucht man einen Ring um die GPU um die Daten zu den Memory Controllern zu bringen? Würden es auch zwei Ringe tun? an denen jeweils 4 port und die zugehörigem memory controler hängen?

Klar bei den CPUs oder der NPU müssen die Ports mit den memory controller auf beiden Seiten kommunizieren können. also muss man beide Ringe koppeln.
Piktogramm schrieb:
Imho ist das an der Stelle kein "simpler" Ringbus.
Die Frage ist, was ist simpel.


eines der Papiere die erwähnt werden: https://pages.cs.wisc.edu/~yxy/pubs/hring.pdf

Es muss ja nicht diese Implementierung sein. Aber wenn man Ringbusse hierarchisch koppelt, schrumpfen die Latenzen, ...
 
ETI1120 schrieb:
8 x 64B gibt 512B, oder?
Ja, Einheitenfuckup bei mir -.-

ETI1120 schrieb:
Wenn man sich den IOD von Strix Halo anschaut dann sind die Memory controller auf beiden Seiten der GPUs. Braucht man einen Ring um die GPU um die Daten zu den Memory Controllern zu bringen? Würden es auch zwei Ringe tun? an denen jeweils 4 port und die zugehörigem memory controler hängen?
Wenn die GPU zwei Ringe a 4 CMs hätte, die über je 8CS-Ports gingen,, wäre immernoch die Frage, wie alle anderen Ports (CCDs, NPU, ..) Zugriff auf die je volle Anzahl an CS-Ports bekommen. Einfach nur an die GPU-Ringe hängen ginge nicht, da wäre dann jeweils die Hälfte vom Speicher nicht sinnvoll erreichbar.


1770370023057.png

Quelle: https://chipsandcheese.com/p/evaluating-the-infinity-cache-in
ETI1120 schrieb:
Klar bei den CPUs oder der NPU müssen die Ports mit den memory controller auf beiden Seiten kommunizieren können. also muss man beide Ringe koppeln.
Der MemoryController braucht doch eher keine Kommunikation seiner beiden Teile. Die MemoryController verwaltet ja "nur" jeweils 50% vom Speicher. Alles was da wild zwischen Speicheradressen als copy oder move läuft sollte eh über Load/Store von CPU, GPU etc. gehen. Das ist ja auch der Trick der ganzen Speicherkanäle und der Slices vom Infinityfabric. Die kennen nur jeweils ihren Speicherbereich, was u.a. Lookup deutlich vereinfacht.
Da würde ich es für wahrscheinlicher halten, dass die GPU zwei Ringe zu je 50% der Speichercontrollern hat. aller "Kleinkram" dann auf einem extra Ring a 32B/s hockt und der kleine Ring dann je einen Interconnect mit den großen Ringen nutzt.
 
Piktogramm schrieb:
Da würde ich es für wahrscheinlicher halten, dass die GPU zwei Ringe zu je 50% der Speichercontrollern hat. aller "Kleinkram" dann auf einem extra Ring a 32B/s hockt und der kleine Ring dann je einen Interconnect mit den großen Ringen nutzt.
Ja, da ist was ich mit koppeln gemeint habe.
Da Kleinkram auch Mist macht muss der Verbindungsring nicht unbedingt schmaler sein. Bei der Anzahl der Bridges würde ich auch 4 also je zwei zu den äußeren Ringen nicht ausschließen.


Bei dem Papier das ich verlinkt habe hat auch Gabriel Loh mitgewirkt und mit dem Zeitrahmen 2014 fällt es in den Zeitraum an dem AMD das Infinity Fabric konzipiert hat.

Nachdem AMD auch die Arbeit mit finanziert hat. Wurden die Ergebnisse IMO bei der Arbeit am Infinity Fabric mit berücksichtigt.
 
@ETI1120
Der beschriebene kleine Ring, wäre kein Verbindungsring für die großen Ringe, es wäre der Ring für den "Kleinkram" von dem ja keiner mehr als 32B/clk kann. Der kleine Ring braucht die Interconnects dann "nur" um an den Hauptspeicher heranzukommen.
 
@Piktogramm Deine Sicht ist funktional meine Sicht ist topologisch.

Der Kleinkram sind 16 CPU Kernen, 16 Lanes PCIe Gen 4.0, Display Engine, Video En- und Decoding, USB Controller, NPU.

Was mir auch nicht klar ist macht man die fetten Ringe breiter oder macht man auf jeder Seite zwei Doppelringe.
 
Der ziemlich potente "Kleinkram" hat dennoch maximal je einen 32B Port. Da mehr als Doppelring mit 256bit Breite vorzusehen wäre halt zu viel. Im Zweifelsfall kommt es halt zu Engpässen, wenn CCD, NPU, PCIe/USB alle Bandbreite fordern. Strix Halo ist ja aber sowieso eine eskalierte APU und da wäre das Imho zu verkraften.

Fette Ringe, auf denen maximal breite 64B Ports hängen, auf 512B (4096bit) Breite auszulegen wäre irgendwie sinnig. Jeder Port müsste dennoch auf allen Signalleitungen hängen und entsprechend Logik implementieren um dann 1/8tel vom Bus nutzen zu können. Die Ports vom Cache/Memory mit ihren 32B/clk entsprechend nur 1/16tel. Das Ganze wird um den Faktor zwei schlimmer, weil es sinnvollerweise ein Doppelring sein sollte um die Latenzen klein zu halten (8CM + 16CS sind ja allein 24 Hops nur für die GPU).

Edit: Oder es ist ein großer Doppelring mit 4x64B (2048bit), dann wäre es halt ohne den Faktor zwei. Die gemessene Bandbreite der GPU zum Cache[1] wäre dann aber verdächtig nahe am theoretischem Maximum des Bus.

[1] https://open.substack.com/pub/chipsandcheese/p/strix-halos-memory-subsystem-tackling
 
Zuletzt bearbeitet:
Zurück
Oben