AMD - Zen 4 /4c - 5 nm/4 nm - Genoa, Bergamo, Siena, Raphael, Phoenix Point

pipin

Administrator
Teammitglied
Mitglied seit
16.10.2000
Beiträge
24.384
Renomée
9.729
Standort
East Fishkill, Minga, Xanten
  • SIMAP Race
  • QMC Race
  • RCN Russia
  • Spinhenge ESL
  • Docking@Home
  • BOINC Pentathlon 2019
  • SETI@Home Intel-Race II
  • THOR Challenge 2020
  • BOINC Pentathlon 2021
  • BOINC Pentathlon 2023
14 Tage bis was offizielles von AMD zu Zen 3 kommt, da wird es Zeit für nen Zen 4 Thread. ;)

Bislang offiziell von AMD bestätigt sind nur 5nm, Genoa als Codename der Serverprozessoren, sowie ein Erscheinen bis spätestens 2022.

AMD_Corporate_August_2020_15.png


AMD_Corporate_August_2020_33.png
 
Damit wären dann GPU-Chiplets nötig, um die GPU unterzubringen. Spannend in welcher Fertigung diese dann kommen. Ich kann mir vorstellen AMD nutzt einen 7nm weiter für die GPU.
 
Nicht wenn man dem I/O Chip eine verpasst.
 
Naja, wenn RDNA3 GPUs auf Chiplets basieren sollen, dann wäre es nur logisch die gleichen Chiplets auch für APU-Produkte zu verwenden. Im besten Fall braucht man dann nur ein einziges GPU-Chiplet für alle erdenklichen Produktvarianten.
 
Für viele Käufer die eine 8-16C APU kaufen, würden aber wohl 4-8 CUs reichen.
So kleine GPU-Chiplets werden wohl kaum kommen, da wäre es für mich nahe liegend eine kleine Mini-iGPU in die I/O-Die zu verfrachten.

Ein Gamer der sich dann diese APU nimmt, würde doch eh wieder eine dGPU nehmen!
 
Nur ist der Sinn eines Chiplets der, diese mit anderen identischen Chiplets zu einer großen GPU zu verbinden an einen IO-Die. Siehe EPYC oder Threadripper bei CPUs als Vergleich. Ist das nicht möglich, kann man das mit den Chiplets auch bleiben lassen. Um nur eine iGPU zu kreieren braucht man kein Chiplet, da das mit APUs deutlich effizienter in dieser Größenordnung ist.
 
Mit Zen4 kommt DDR5, und damit höhere Bandbreite. Damit kann man die iGPU besser auslasten, und mehr CUs als Option machen Sinn. Wobei man gut teildefekte GPU-Chiplets für eine APU nutzen könnte, und die heilen Chiplets für die dGPUs. Ich schätze am Ende kommt man vermutlich auf 20-32 CUs pro Chiplet, wobei dann für die APUs selten mehr als 16 CUs aktiv sein werden.

Wirklich interessant wären aber Optionen wo man nicht nur simple GPU-Chiplets nutzt, sondern auch noch HBM oder 3D Stacked Memory (Siehe X3D Packaging), auch vor allem auf Package-Größen wie bei TR4/SP3, wo man so eine vollwertige GPU unterbringen könnte.

Sagen wir das Stacked Memory würde funktionieren, dann könnte man problemlos eine APU mit 8c/16t, 32 CUs und 8 GB High Speed Speicher bauen, und zusätzlich noch DDR5 als Second Tier Grafikspeicher nutzen.
 
Naja, wenn RDNA3 GPUs auf Chiplets basieren sollen, dann wäre es nur logisch die gleichen Chiplets auch für APU-Produkte zu verwenden. Im besten Fall braucht man dann nur ein einziges GPU-Chiplet für alle erdenklichen Produktvarianten.
Theoretisch ja, aber in der Praxis wird man davon wohl zumindest vorerst absehen. Dagegen spricht ja auch die Existenz von Rembrandt als mutmaßliche AM5 APU.
Zumindest für mobile Anwendungen wird es wohl auf absehbare Zeit bei monolithischen Designs bleiben, da man so eben die sparsamsten Chips bauen kann.
Am Desktop ist das weniger entscheidend und entsprechend könnte es tatsächlich sein, dass man hier komplett auf Chiplets setzt.

Wobei es in dem Fall dann wünschenswert wäre, dass AMD das Hybrid-GPU Konzept weiter optimiert, so dass man im Desktop-Betrieb die dedizierte GPU komplett abschalten kann (wenn denn eine genutzt wird).
 
Mit dem richtigen Design glaube ich halt wäre es möglich dass man auch für anspruchsvollere Spiele in Zukunft keine dGPU mehr braucht, und das würde vor Allem NVidia schaden und ordentlich das Niedrigpreissegment umkrempeln, auch gerade im Notebook-Bereich.

Die Leistung einer Xbox Series X sollte auf einem Package in der Größe von AM4 sicher möglich sein mit der kommenden Generation (Zen4 + RDNA3 + Stacked Memory).
 
Ein Gamer der sich dann diese APU nimmt, würde doch eh wieder eine dGPU nehmen!
Nach meinem Gusto sollten die minimal GPUs in Desktop CPUs gerade genug CUs für TrueAudio Next (TAN) oder Physik Berechnungen mitbringen. Dinge die nicht im VRAM liegen aber schon mal via GPGPU berechnet werden. TAN könnte z.T. bei Raytracing mitberechnet werden... Solange die SIMD viel potenter ausfallen als die AVX Leistung eines Zen Chiplet bestünde Potential dass darauf Software angepasst würde.
 
Was AMD da machen wird, das wird auf jeden Fall spannend.
Die Zen 3 APU Rembrand soll ja angeblich auch schon 11 12 CUs haben.
 
Zuletzt bearbeitet:
Eine weitere Variante wäre tatsächlich ein separates FFU-Chiplet das aus den GPUs extrahiert wird im Zuge der Umstellung auf Chiplets. Das wäre dann mit UVD und VCE, sowie Audio FFUs ausgestattet und gerade so vielen zusätzlichen benötigten Teilen ausgestattet damit diese minimalistisch wie möglich bleiben , so wie das E555user bevorzugen würde. Ein solches FFU-Chiplet würde auch schnellere Upgrades für Codecs/Funktionen ermöglichen und systematisch einem CPU-IO-Die mit USB/SATA/PCIe etc. entsprechen.

Die SKUs könnten dann CPU only, CPU+FFU und CPU+FFU+GPU modular bereitstellen und lediglich bei Nachfrage die jeweiligen Packaging-Balance für den gewünschten Zielmarkt erhöhen oder verringern. Man reduziert weiter den Bedarf an fortschrittlichen Prozessnodes 7nm/5nm für die jeweiligen SKUs und kann gesteigerte Stückzahlen anbieten mit den verfügbaren Wafern bei TSMC.

APUs als Basis bis 8-Kernen monolithisch könnten auch mit weiter reduzierten CUs angeboten werden - bis 1080p Leistung max. 60 fps mit DDR5
 
Ein Gamer der sich dann diese APU nimmt, würde doch eh wieder eine dGPU nehmen!
Nach meinem Gusto sollten die minimal GPUs in Desktop CPUs gerade genug CUs für TrueAudio Next (TAN) oder Physik Berechnungen mitbringen. Dinge die nicht im VRAM liegen aber schon mal via GPGPU berechnet werden. TAN könnte z.T. bei Raytracing mitberechnet werden... Solange die SIMD viel potenter ausfallen als die AVX Leistung eines Zen Chiplet bestünde Potential dass darauf Software angepasst würde.
Seh ich genauso.

Für richtige Spiele wird eine dedizierte GPU nicht zu ersetzen sein. Dafür bringt das in Bezug auf die Abwärme einfach zu viele Vorteile, da man selbige auf mehrere Spots verteilt.
Am Desktop sowieso, aber auch im Notebook sehe ich da Vorteile.

Dennoch, wenn man die dGPU komplett deaktivieren kann im reinen Desktopbetrieb ist das für die Leistungsaufnahme des Systems ein massiver Vorteil.
Entsprechend gibt es ja auch schon Systeme die sowas machen, aber gerade bei AMD halt nicht wirklich optimal.
 
Solange die SIMD viel potenter ausfallen als die AVX Leistung eines Zen Chiplet bestünde Potential dass darauf Software angepasst würde.
Warum buddelt AMD nicht wieder seinen HSA-Ansatz aus? Klar, sie brauchen es jetzt nicht unbedingt, aber könnte doch Nischen (HPC, Wissenschaft/Workstation, Spiele?) geben 8bzw. geschaffen werden), in welchen das massive Vorteile bringt.
 
Solange die SIMD viel potenter ausfallen als die AVX Leistung eines Zen Chiplet bestünde Potential dass darauf Software angepasst würde.
Warum buddelt AMD nicht wieder seinen HSA-Ansatz aus? Klar, sie brauchen es jetzt nicht unbedingt, aber könnte doch Nischen (HPC, Wissenschaft/Workstation, Spiele?) geben 8bzw. geschaffen werden), in welchen das massive Vorteile bringt.

Die HSAFoundation sieht aber ziemlich leblos aus:

 
Die HSAFoundation sieht aber ziemlich leblos aus:
Ja. Seit Zen in APUs ist HSA Geschichte. Mir hatte die Entwicklung von HSA sehr gefallen, aber AMD hat bislang nur mit 64bit eine Softwarerevolution auslösen können. Falls sich SYCL durchsetzt und nach einer Dekade etwa genug Software entwickelt wurde könnte aus den HSA Ansätzen vielleicht noch mal etwas werden.
 
Ich bin mir mittlerweile ziemlich sicher, dass wir neben dem ganzen Update auf DDR5 usw. auch erste Interconnects ala Gen-Z sehen werden.
 
Natürlich ist SYCL nicht tot, das ist Entwicklungsperspektive für moderneres C++.
 
Das "nicht tot" war auf pipins "leblos" bei Khronos bezogen und ergänzend zu dir gemeint mit dem SYCL-Link :)
 
Ja - zur Orientierung:

Bei HSA geht es für den "Runtime-Stack" darum, dass man bottom up eine gemischte Architektur mit harmonisierter Speicherverwaltung 64bit anbietet und gegenüber der Software einen Treiber auf dem Host als Schnitstelle anbietet. Dort werden dann die Jobs auf die für die Threads passenden Subsysteme verteilt und abgearbeitet.
Bildschirmfoto 2020-11-22 um 10.11.35.png
Damit das mit HSA funktioniert musste die MMU in der APU die Kompatibilität gewährleisten, damti Kohärenz verwaltet werden kann. Im Treiber wäre dan entschieden worden was bei Kohärenz wo berechnet wird.


Bei SYCL geht es darum den Runtime-Stack top-down zu betrachten. Es wird von der Applikation selbst im Code ein passendes Compiler-Modell jeweils über Templates für die HW-spezifischen Libraries genutzt und übersetzt. Die Programmierung bleibt dabei generisch genug und wird parallelisiert, damit Mischformen von HW möglich sind. Aber es wird dann schon für ein bestimmtes Setup compiliert - in OpenCL. Aber so, dass der CL Code auch für die jeweilige HW optimiert ist in Bezug auf ISA, Caches und Durchsatz.

Bildschirmfoto 2020-11-22 um 10.22.23.png
Die Verteilung der Jobs wird schon im Compilat auf ein HW-Modell hin übersetzt. Nicht die HW kümmert sich um Kohärenz, die Verwaltung der Datenflüsse steckt im Code selbst, der für neue HW Setups mit anderen Templates neu übersetzt wird.

Wenn SYCL genügend Verbreitung findet wird sich dann auch wieder jemand Gedanken machen wie man die unterschiedlichen Beschleuniger noch besser zusammen arbeiten lassen könnte. Das könnte ein Revival für HSA geben.

Wenn AMD und ARM dann noch in diesem Bereich zusammen arbeiten wollen. ;)
 
IMHO spricht die TDP Erhöhung für ein GPU-Chiplet - das Powerbudget kann dann dynamisch auf CPU verteilt werden und es könnten GPUs bis zu 75 W verbaut werden bei 95W für die CPU. wenn CPU+GPU Vollast anliegt. Hier würde es erstmalig zu einer APU-Leistung kommen, die GPUs bis zu 75W-100W ersetzen kann, je nach Workload.
 
Zurück
Oben Unten