AMD gibt erste Details zu Milan bekannt: Zen 3 mit neuem CCD-Aufbau

[HWL News Bot]

Auf der HPC-AI Advisory Council UK Conference sprach Martin Hilgeman, verantwortlich für HPC Applications bei AMD, über die aktuellen EPYC-Prozessoren auf Basis von Rome, gab dabei aber auch einen Ausblick auf den Nachfolger Milan.Der von ihm gezeigten EPYC-7000-Series-Roadmap zufolge haben die Milan-Prozessoren ihren ersten Tape-Out schon hinter sich gebracht. Aktuell befindet sich das Design demnach in der Qualification-Phase und wird geprüft. AMD hat bereits bestätigt, dass die ... weiterlesen

 

[Tzk]

Kommt jetzt nicht unerwartet, das man die CCX umbaut und statt 2x4 auf 1x8 geht...

 

[XTR³M³]

gehe von 48MB L3 aus...

 

[Tzk]

Die größere Fragen die sich stellen:
1. Bastelt AMD das Design und TSMC den Prozess um, damit mehr Takt drin ist?
2. Gibts noch mehr IPC?

 

[Shevchen]

Da sich am generellen Aufbau nur wenig ändert, wird wohl etwas mehr "unter der Haube" optimiert, um bestehende Ansätze effizienter auszunutzen. Der globale L3 Cache is interessant, da dort der Sprung der zwischen den L3 Segmenten wegfällt. Es scheint wohl so zu sein, dass eine längere Registersuche im L3 effizienter ist, als die lokale CCD Verarbeitung mit Überlauf. Ist wohl der allg. Softwareoptimirung geschuldet (aka Windows Scheduler) und diversen anderen... sprunghaften Berechnungsalgos.

Ich sehe es als Schutzwall gegen überoptimierte Intel-Software an. Und who knows, wenn AMD die Anbindung optimiert bekommen hat, sollte der Leistungsverlust durch die größeren Registersuchläufe vernachlässigbar sein. Wäre halt schöner, wenn Software so geschrieben wird, dass sie agnostisch agiert - aber davon können wir uns wohl verabschieden.

 

[XTR³M³]

Die größere Fragen die sich stellen:
1. Bastelt AMD das Design und TSMC den Prozess um, damit mehr Takt drin ist?
2. Gibts noch mehr IPC?

klar wird es mehr IPC geben, aber der sprung wird eher klein sein(gehe von 5% bis max. 10% aus).

 

[DeckStein]

Produktion 3 quartal 2020? Also erdt 2021 zu kaufen?

 

[sch4kal]

Ich sehe es als Schutzwall gegen überoptimierte Intel-Software an. Und who knows, wenn AMD die Anbindung optimiert bekommen hat, sollte der Leistungsverlust durch die größeren Registersuchläufe vernachlässigbar sein. Wäre halt schöner, wenn Software so geschrieben wird, dass sie agnostisch agiert - aber davon können wir uns wohl verabschieden.

Wird Sie, zumindest kenne ich außer Spezialfällen kaum jemand, der in seiner Software noch hart codierten Assemblercode mit Intel-spezifischen Befehlen an einer Stelle stehen hat.
Ist alles eine Sache des Compilers, da wäre ein größeres Engagement seitens AMD natürlich auch begrüßenswert.
Wüsste auch keine Software die per se auf Intel optimiert ist, die bisherigen x86-CPUs waren eben meist monolithischer Natur.
Da AMD mit ihrem Chiplet Design einen anderen Ansatz verfolgt müssen sie halt auch zusehen, das die meiste Software auf ihrer Plattform performant läuft.

 

[fdsonne]

Da AMD mit ihrem Chiplet Design einen anderen Ansatz verfolgt müssen sie halt auch zusehen, das die meiste Software auf ihrer Plattform performant läuft.

Das ist halt das Problem an der Geschichte - AMD fährt mit Zen bis auf die APUs nen anderen Ansatz. Die Eypc mit MCM und mehreren NUMA Nodes brauchen Support in Software für anständige Skalierung, die CCX Geschichte unter der Decke muss/sollte beachtet werden usw. Das gibts zwar bei Intel auch, nur ist es vollkommen logisch sich bei Software am Markt auszurichten anstatt den Experimenten, die eine AMD da hin und wieder mal bringt. TR ist ein ziemlich gutes Beispiel. Die 1000er mit zwei NUMA Nodes im Desktop sind so ziemlich das unüblichste, was man mache kann. Die 2000er mit vollen vier DIEs und 4x NUMA Nodes setzen sogar noch einen drauf -> weil NUMA Node ohne eigenen Speicher war vorher schlicht "Schuld eigene" des Systembauers durch Falschbestückung der RAM Bänke, nie aber ein gewünschtes Szenario.
Und jetzt 2-3 Jahre später wirft man den Kram komplett über Board. Den 64C Epyc, den ich bis dato gesehen hatte, kam mit 2x NUMA Nodes. Für 64C mMn OK. Hatte allerdings nicht sonderlich viel Zeit um da groß zu suchen ob das anders gegangen wäre. War einfach OotB mit Windows Server auf irgend einem SM Board.

Genau sowas möchte man als Software Entwickler nicht. Und das ist/war ja nichtmal das erste mal. Bei den GPUs lief/läuft das ähnlich -> mal Navi außen vor. Mit Bulldozer und dem CMT Ansatz wollte man auch schon einen Support wissen für anständige Skalierung. Die Opterons damals mit 2x NUMA pro CPU tanzten ebenso schon aus der Reihe usw.




Mal schauen was das hier mit dem CCX bedeutet. Das klingt mir nach einer Möglichkeit dann in dieser Generation auch ne APU mit 6-8C anbieten zu können... Vllt sehen wir das aber auch schon mit den Zen2 APUs nächstes Jahr? Wobei AMD wohl verneinte, dass es nen Chiplet Ansatz bei der APU gibt. (zumindest vorerst)

 

[Shevchen]

Wobei AMD wohl verneinte, dass es nen Chiplet Ansatz bei der APU gibt. (zumindest vorerst)

Was daran liegt, dass APUs spott billig auf den Markt geworfen werden. Niemand würde 700€ für ne APU ausgeben. (Mit angenommenem Vollausbau von HBM, Navi und CPU Chiplets) Es wäre zwar effizient, da GPUs aber schneller altern als CPUs, möchte der Durchschnitts-Systembauer die Möglichkeit zum Wechseln haben. Ergo bleibt nur die "Standard" APU übrig und die soll vor allem billig sein.

Deswegen 12nm, deswegen kein zusätzlicher I/O Die, deswegen alles auf einen kleinen Chip gepresst. Daran wird sich in naher Zukunft auch erstmal nix ändern. Intel versucht das zwar mit Foveros, die Teile werden aber auch nahe an die 1.000€ kosten. Da ist der Rest vom Laptop und die Gewinnmargen der OEMs noch nicht mit drin.

 

[JohnnyBGoode]

[...] Wobei AMD wohl verneinte, dass es nen Chiplet Ansatz bei der APU gibt. (zumindest vorerst)

Das war ja, wenn ich mich recht erinnere, eine Korinthen-Antwort von Lisa Su, wo sie in einem Interview zu der Zen 2-Präsentation, bei der AMD nur nur 'ne CPU mit einem Chiplet vorgestellt hatte, gefragt wurde, ob sich der Aufbau mit diesem I/O-Die auch für eine APU mit 8 Kernen eignen würde, verneinte.

Der Knackpunkt war "dieser" im Sinne von genau diesem Typ von I/O-Die, dadurch konnte sie das objektiv wahrheitsmäßig verneinen, um keine negative PR für den anstehenden Picasso-Launch zu ernten.

Ich gehe mit 99 % davon aus, dass kommendes Jahr bei den 4000er APUs GPU- und Zen 2 oder gar 3-Chiplets kommen, um auch im mobilen Bereich bei >4 Kernen Intel voll angreifen zu können.

Natürlich braucht eine APU für ein GPU-Chiplet eine andere Art von I/O-Die als einen, der dafür gedacht ist, zwei gleiche CPU-Kern-Chiplets anzubinden. Als Laie gehe ich vom Bauchgefühl davon aus, dass GPU- und I/O-Die auf einem Stück sind und so bei den APUs keine 8 PCIe-Lanes mehr "verschwendet" werden und eben ein Zen 2/3-CPU-Kerne-Chiplet. Der "freie" Platz des dritten Chiplets könnte vielleicht für HBM genutzt werden (?), so dass GPU-I/O-HBM-Kombi-"Chiplet" ein L bilden und "rechts oben" das Zen 2/3-CPU-Kerne-Chiplet hinkommt.

Dann könnten sie das Teil mit HBM, USB 4 (also auch mit Thunderbolt) in MacBook (Pros) packen und hätten ein Halo Product, Apple soll ja mittlerweile mit Intel nicht sooo glücklich sein, auch wenn es noch keine NVIDIA-Ausmaße hat.

Persönliche Meinung: Der Grund, dass das bisher nicht ging (APUs CPU-seitig "veraltet"), waren/sind zu wenig Ingenieure (da AMD finanziell zu schlecht aufgestellt war), um alles gleichzeitig fertig zu bekommen

 

[fdsonne]

Der Knackpunkt war "dieser" im Sinne von genau diesem Typ von I/O-Die, dadurch konnte sie das objektiv wahrheitsmäßig verneinen, um keine negative PR für den anstehenden Picasso-Launch zu ernten.

Ich gehe mit 99 % davon aus, dass kommendes Jahr bei den 4000er APUs GPU- und Zen 2 oder gar 3-Chiplets kommen, um auch im mobilen Bereich bei >4 Kernen Intel voll angreifen zu können.

Ehrliche Frage, welchen Sinn haben dann noch diese Aufbauten wenn eh für jeden Marktbereich die Chips neu entwickelt werden müssen?
Der Spaß würde Sinn ergeben, wenn man die GPU, die es jetzt nicht gibt, mit einem vorhandenen IO DIE und einem (oder mehreren) Compute DIEs paart. Aber nicht, wenn man für die APU nen neuen IO DIE bräuchte.

Das Problem was ich vor allem darin sehe ist eben, dass AMDs aktueller Aufbau riesig ist. Der IO DIE auf den AM4 CPUs ist schweine groß. Klar die Chips kosten jetzt nicht die Welt, weil alte Fertigung, aber sie kosten. Nen großen IO DIE, der eben für mehr als nur ein Produkt her halten soll, damit es Sinn macht und man durch mehr Stückzahl sinkende Kosten pro Stück verbucht kostet am Ende aber trotzdem einen Flächenpreis -> wo sich dann die Frage stellt, ob eine native Ausrichtung eines Produkts für eben einen Markt(bereich) nicht die sinnigere Version ist. AMD wird über kurz oder lang nicht an GPUs vorbei kommen. Sie fluten im Moment den Desktop Markt mit Manycore CPUs. Aktuell gibts noch ne Menge Intel und alt AMDler abzuholen. Aber was ist in 3-5 Jahren? Keiner interessiert sich für Leistungsupgrades von 10% oder so. Da muss mehr passieren. Sie brauchen die GPUs um im Mobilegeschäft endlich punkten zu können.

Schaue ich mir aber nur mal die Fläche einer GPU mit sagen wir ~1,5x der aktuellen Picasso (den GPU Teil davon) Fläche an um entsprechend mehr Leistung zu bringen, paare das mit der CPU und stecke dann noch nen riesigen IO DIE zu -> da kommt ein Monster von Chipfläche bei rum. Wer soll das zahlen??? Vor allem ist es ja immernoch ein Thema, dass die schnellen CPUs nur mit viel GPU Leistung bei AMD kommen... Bleibt das dann auch? Oder gibts sogar dedizierte Fertigungen für verschieden große GPU DIEs?? (was den Spaß kostenseitig noch aufwendiger macht). Selbst bei Intel, die Faktor 5-10 mehr Einheiten absetzen, gibts nicht für jedes Produkt ne dedizierte Fertigung. Sondern man fertigt die Massenware möglichst nativ um dann die weniger gebräuchlichen Modelle zu teildeaktivieren. Zumal es bei Intel keine TSMC gibt, die die Hand auf halten und auch verdienen wollen. TSMC (oder vllt Samsung auch) tut sicher einen Teufel um 7nm Kapazitäten an AMD zu verschleudern, wenn andere Unternehmen Schlange stehen und mehr zahlen -> vor allem auch lange nicht den finanziellen Druck einer AMD haben
AMD macht zwar atm keinen Verlust - aber wirklich was hängen bleibt nicht... Auch ist der Umsatz irgendwie so lala. Seit 2005 das selbe Niveau. Ziemlich strich 1,5Mrd. +- paar hundert Millionen. Trotz Ryzen! im nun dritten Anlauf. MMn ist das bezeichnend, wie wenig man im Desktop Markt überhaupt holen kann.

 

[Oberst]

Ehrliche Frage, welchen Sinn haben dann noch diese Aufbauten wenn eh für jeden Marktbereich die Chips neu entwickelt werden müssen?

Also ich hatte es so verstanden, dass es keine APU mit einem Zen-Chiplet, einem GPU-Chiplet und dem bekannten IO-Die geben wird. Aber was vorstellbar wäre, wäre ein Standard Zen-Chiplet für die CPU Kerne (Zen2 wie bei Matisse) und ein angepasstes IO Die mit integrierter GPU.
In späteren Generationen wird man wohl versuchen, das IO Die ohne IGP zu bauen und die IGP dann per IF an den IO zu hängen (so könnte man alle 3 DIEs komplett unabhängig entwickeln und auch tauschen). Vielleicht versieht man die IGP noch mit Sideport-Ram, um die GPU Leistung zu erhöhen, aber das ist bei LPDDR4X whl nicht mehr nötig.
Aber aktuell geht man wohl zunächst den Weg mit eigenem IO Die für die APUs, in dem dann die IGP verbaut ist und auch ein abgespecktes Featureset zu finden ist (weniger PCIe Lanes, weniger USB), um den Verbrauch zu drücken. Der IO Die müsste vermutlich grob 1/3 des aktuellen verbrauchen, um im Mobile Bereich auch entsprechende Laufzeiten zu erreichen, das ist wohl aktuell die Aufgabe, die es zu meistern gilt. Aber ich habe es schon so verstanden, dass das Zen DIE dem der Desktop CPUs entspricht.

 

[JohnnyBGoode]

Glaube, dass AMD nicht herum kommt, den I/O-Die ebenfalls in 7 nm fertigen zu lassen, nicht weil es leistungstechnisch sinnvoller ist, sondern einfach nur um physischen Platz zu sparen, damit entsprechende APUs überhaupt möglich werden.

Vielleicht ein von den Abmessungen her kleiner (=günstiger) in 7 nm gefertigter I/O-Die, der an einer Seite eine "breites" Universal-GPU-Interface hat und so mit verschiedenen, separat gefertigten GPU-Chiplets kombiniert werden kann? Dann bräuchte man für Desktop- und Mobile-APUs nur einen Typ von I/O-Die fertigen, nach dem gleichen Prinzip wie die Zen-CPU-Kern-Chiplets?

Könnte man es irgendwie als Feature verkaufen, HBM über den i/O-Die auch für die CPU mitzuverwenden? Beispielsweise ein 32 GB-8C-APU-Monstrum für mobile Workstations, wo das eigentliche Mainboard/Logic Board mit APU die Abmessungen einer 2,5"-SSD hat und der Rest des Gehäuses wird für Akku, Massenspeicher und Kühlung verwendet?

 

[DTX xxx]

Ehrliche Frage, welchen Sinn haben dann noch diese Aufbauten wenn eh für jeden Marktbereich die Chips neu entwickelt werden müssen?
...

Ganz einfach. Zwischenschritte und oder andere Schritte werden begangen, wenn benötigte Entwicklungen sich verzögern und oder noch Zeit brauchen.

 

[Shevchen]

Der Grundgedanke ist ja, alle Siliziumelemente, die derzeit noch verteilt im Rechner hängen auf einen Interposer zu verbinden. Ich denke, dass es kostentechnisch durchaus Sinn machen kann - denn zusammen ist das Package günstiger, als wenn ich es dediziert Schritt für Schritt in ein Extra Produkt packe.

AMD könnte hierfür den Segmentations-Schritt gehen (so wie bei den CPUs auch) teildeaktivierte Elemente mit dem billigsten HBM den sie finden können auf einen Interposer zu kloppen und dann für "relativ" wenig Geld rauszukloppen. Besser wäre aber eine Art "Sockel" Stecklösung - wo ich die einzelnen Elemente (I/O Die, CPU Dies, GPU Dies und HBM) draufstecken kann. Das wäre aber die Hölle für die Mainboardhersteller, die dann komplett überdimensionierte Mobos für den "Fall der Fälle" entwickeln müssen - wo am Ende ne billige APU Versorgung von heute schon ausreichen würde. Es wurde schon von einigen Youtubern gemunkelt, dass man auch eine Art "Build to order" Version als Kompomiss schließen könnte.

Problem bleibt in allen Varianten (außer der Sockellösung) aber die GPU. Die Halbwertszeit der GPU ist wesentlich geringer als die, der anderen Komponenten und wenn ein Chip von diesem Sammelsurium hops geht, kann ich das ganze Teil wegschmeißen.

 

[Holt]

Ist alles eine Sache des Compilers, da wäre ein größeres Engagement seitens AMD natürlich auch begrüßenswert.

So ist es, AMD fährt da aber einen Schlingerkurs, früher hat man auf den Open64 Compiler gesetzt, jetzt ist es wohl AOCC v2.0 auf Basis von Clang, aber beide nur für Linux.

Wüsste auch keine Software die per se auf Intel optimiert ist, die bisherigen x86-CPUs waren eben meist monolithischer Natur.
Da AMD mit ihrem Chiplet Design einen anderen Ansatz verfolgt müssen sie halt auch zusehen, das die meiste Software auf ihrer Plattform performant läuft.

Nun den Chiplet Design scheint AMD die Nachteile des vorherigen Designs der Zen(+) CPUs mit mehreren Dies (TR und Naples) nun ja deutlich verringert zu haben und bei den RYZEN bis einschließlich 8 Kerne gibt es ja auch nur ein Chiplet, aber wie man am Beispiel des 3900X sieht, scheint es mit zwei Chiplets nicht mehr die Einschränkungen wie vorher noch bei den TR zu geben. Wenn eine Software auf den AMD CPUs nicht so gut performt wie auf Intel CPUs, dann liegt dies einfach an der Architektur und dies sieht man ja auch beim Vergleich zwischen unterschiedlichen Intel CPUs, die Skylake-X mit ihrem Mesh und den Änderungen beim Cache, performen bei einigen Anwendungen wie z.B. Games auch schlechter als man im Vergleich zu den S.1151 Skylake aufgrund der Taktraten und Kernzahl hätte erwarten können und dafür bei anderen Anwendungen besser, obwohl die Architektur der eigentlichen Kerne hier sogar identisch ist.

Bei den AMD Fans muss aber immer jemand anderes Schuld sein, wenn etwas nicht so läuft, entweder die Boardhersteller (warum baut AMD dann nicht selbst Boards wenn die anderen dies angeblich nicht können?) oder eben die OS- und sonstigen Softwarehersteller. Bei Bulldozer war die FPU Performance mies, pro Modul gab es ja auch nur eine FPU und da Cinebench ein reiner FPU Benchmark ist, waren die CB Werte entsprechend mies, da wurden in den Foren immer behauptet der wäre Intel optimiert und daher wären die Werte schlecht. Bei Zen und erst recht nun bei Zen2 sind die FPUs nun sehr schnell und die CB Werte entsprechend gut, also redet keiner mehr von der angeblichen Intel Optimierung und Cinebench ist der Benchmark auf den alle AMD Fans verweisen, dabei ist er eben wegen der extremen FPU Lastigkeit nicht wirklich repräsentativ für die Realworld Performance einer CPU.

Und jetzt 2-3 Jahre später wirft man den Kram komplett über Board.

Eben und wer hat die Zeit (die kostet bei kommerzieller SW Geld und Entwickler sind knapp, gute kaum zu bekommen) oder Lust (bei Open Source) alle paar Jahre wieder auf was Neues zu optimieren? Der Aufwand ist zu hoch und die Unterstützung durch Compiler durch AMD ist eben auch mies und nur auf Linux beschränkt.

Den 64C Epyc, den ich bis dato gesehen hatte, kam mit 2x NUMA Nodes.

Es können 1, 2 oder 4 sein und dies sollte im BIOS konfigurierbar sein.

Der "freie" Platz des dritten Chiplets könnte vielleicht für HBM genutzt werden (?)

Wo ist denn dieser freie Platz? Außerdem braucht man für HBM eine andere Verbindungstechnik wie einen klassischen Interposer oder eben Intels EMIB, welches im Grund ja nur ein Interposer ist der aber nur unter einem Teil der Dies steckt. Beim klassischen Interposer sitzen alle Dies auf dem Interposer und der muss daher entsprechend groß sein, was ihn teuer macht, deshalb sitzen die Dies da ja auch immer so dicht gedrängt drauf und schon beim Bild der RYZEN 3000 und Rome war wegen der Abstände der Dies klar, dass hier keine Interposer verwendet werden.

Dann könnten sie das Teil mit HBM, USB 4 (also auch mit Thunderbolt) in MacBook (Pros) packen

Apple und nicht AMD entscheidet, was sie in ihre MacBooks packen.

Persönliche Meinung: Der Grund, dass das bisher nicht ging (APUs CPU-seitig "veraltet"), waren/sind zu wenig Ingenieure (da AMD finanziell zu schlecht aufgestellt war), um alles gleichzeitig fertig zu bekommen

Die aktuellen APUs basieren auf Zen(+), dies soll schon veraltet sein? Bisher hat nur Intel bei den Kaby Lake-G HBM für die GPU auf der Platine der CPU verwendet, APUs nennt nur AMD so ein Konstrukt und dies waren groß, teuer und haben daher keine große Verbreitung gefunden. Die Alternative eine getrennte GPU/Graka zu verbauen, ist dann auch nicht teurer und dafür flexibler, braucht nur eben etwas mehr Platz. Das ist eine kleine Nische und AMD hat sicher nicht die Reourcen um solche Nischen abzudecken, sondern konzentriert sich zu recht auf Produkte mit denn Geld zu verdienen ist.

Ehrliche Frage, welchen Sinn haben dann noch diese Aufbauten wenn eh für jeden Marktbereich die Chips neu entwickelt werden müssen?
Der Spaß würde Sinn ergeben, wenn man die GPU, die es jetzt nicht gibt, mit einem vorhandenen IO DIE und einem (oder mehreren) Compute DIEs paart. Aber nicht, wenn man für die APU nen neuen IO DIE bräuchte.

Eben, der Markt für APUs ist nicht der für Systeme mit hoher Performance, sondern der Low-Cost Bereich, schon weil man eben niemals leistungsmäßig gegen die Kombination von CPU und getrennter Graka ankommen wird, dafür sind die Resourcen in nur einem Sockel zu beschränkt, was Leistungsaufnahme, Kühlung und auch die RAM Bandbreite angeht. Letztere kann man mit HBM umgehen, aber das treibt die Kosten gewaltig in die Höhe. Selbst wenn man nun so eine Monster APU bauen würde, so kann man die schon wegen der erforderlichen Kühlung gar nicht in sehr kompakte Gehäuse verbauen, was aber gerade der einzige Vorteil davon wäre.

Ein großer Nachteil wäre, dass man dann CPU und GPU zusammen ersetzen muss, aber die Entwicklung bei den GPUs ging in den letzten Jahren immer noch viel schneller als bei den CPUs, eine 5 Jahre alte CPU ist zum Spielen noch weitaus besser als eine ebenso alte Graka, aber bei fast jeder Kaufberatung wollen die Leute immer ein zukunftsfähiges System und so eine teure, leistungsstarke APU wäre das genaue Gegenteil davon.

Der Markt für APUs ist im Low-End und da müssen die Kosten im Rahmen bleiben. Wenn AMD wirklich ein Die für die APUs braucht, dann wird dies eher eines für eine monolithische APU wie bisher sein als ein neues I/O Die, denn dies wäre günstiger. Entweder hat das I/O Dies schon heute die nötigen Verbindungen für eine APU, dann werden wir auch APUs mit einem CPU und einem GPU Chiplet sehen oder es wird ein 7nm(?) APU Die geben.

Aber was vorstellbar wäre, wäre ein Standard Zen-Chiplet für die CPU Kerne (Zen2 wie bei Matisse) und ein angepasstes IO Die mit integrierter GPU.

Dafür ist der I/O Chip aber jetzt schon sehr groß, entweder wird der auch auf 7nm Fertigung umgestellt, was dann auch zu den neusten GPUs passen würde oder es bleibt nur wieder eine 12nm GPU Version für die wenig Platz verfügbar ist, eigentlich nur so viel wie man einsparen kann, wenn man auf die Option zur Anbindung eines zweiten Chiplets verzichtet, denn viel größer kann der I/O Chip nicht mehr werden, sonst passt er nicht mehr unter den HS.

In späteren Generationen wird man wohl versuchen, das IO Die ohne IGP zu bauen

Der aktuelle I/O Chip ist doch schon ohne GPU, oder was meinst Du mit IGP?

Glaube, dass AMD nicht herum kommt, den I/O-Die ebenfalls in 7 nm fertigen zu lassen, nicht weil es leistungstechnisch sinnvoller ist, sondern einfach nur um physischen Platz zu sparen, damit entsprechende APUs überhaupt möglich werden.

Das Problem sind die Verbindungen zwischen den Dies, dies ist ja schon bei den CPU Chiplets ein Problem:

One of the key points AMD spoke about with relation to packaging is how each of the silicon dies are attached to the package. In order to enable a pin-grid array desktop processor, the silicon has to be affixed to the processor in a BGA fashion. AMD stated that due to the 7nm process, the bump pitch (the distance between the solder balls on the silicon die and package) reduced from 150 microns on 12nm to 130 microns on 7nm. This doesn’t sound like much, however AMD stated that there are only two vendors in the world with technology sufficient to do this. The only alternative would be to have a bigger bit of silicon to support a larger bump pitch, ultimately leading to a lot of empty silicon (or a different design paradigm).

Damit ist man schon sehr am Limit und der nächste Schritt wäre ein Interposer, aber die kosten eben auch einiges an Geld. Eine GPU im I/O Chip wäre sicher unter Aspekt interessant, dass man dafür im Verhältnis zur Chipfläche nur wenige zusätzliche Anschlüsse bräuchte, denn für die I/O Funktionen braucht man zu viele und kann daher kaum noch Chipfläche einsparen, da man diese einfach braucht um die Anschlüsse unterzubringen. Ich fände es interessant so eine kleine iGPU zu haben, die für Windows und Multimedia reicht, aber für die größte Zielgruppe, die Gamer, dürfte die uninteressant sein und keiner wird deswegen eine größeren Aufpreis zahlen wollen. Die Xeon waren bis Haswell bei Gamern u.a. beliebt, weil manche nicht für eine iGPU bezahlen wollte die sie sowieso nicht nutzen werden.

Vielleicht ein von den Abmessungen her kleiner (=günstiger) in 7 nm gefertigter I/O-Die, der an einer Seite eine "breites" Universal-GPU-Interface hat und so mit verschiedenen, separat gefertigten GPU-Chiplets kombiniert werden kann?

Dann müsste man aber wohl auf Interposer setzen, eben wegen der Dichte der Anschlüsse.

Könnte man es irgendwie als Feature verkaufen, HBM über den i/O-Die auch für die CPU mitzuverwenden? Beispielsweise ein 32 GB-8C-APU-Monstrum für mobile Workstations, wo das eigentliche Mainboard/Logic Board mit APU die Abmessungen einer 2,5"-SSD hat und der Rest des Gehäuses wird für Akku, Massenspeicher und Kühlung verwendet?

HBM braucht immer Interposer und so ein Monster mit 32GB wäre sehr teuer und ein absolutes Nischenprodukt. Der einzige Vorteil wäre, weniger Platz dafür zu brauchen, aber der wäre wegen der Kühlung, gerade bei einer mobilen Workstation sollte diese schon leistungsstärker sein, dann wieder zunichte gemacht, da kann man gleich die Teile wie bisher getrennt verbauen und hat außerdem viel mehr Konfigurationsmöglichkeiten. HBM als CPU RAM ist außerdem nur bei sehr speziellen Anwendung wirklich für die Performance relevant.

 

[Goldeneye007]

Bin auch gespannt, wann die zur Auslieferung kommen.

 

[Holzmann]

Bin auch gespannt, wann die zur Auslieferung kommen.

Naja Produktion laut Roadmap Q3 2020.

In Q4 sollte es dann soweit sein.

 

[Pickebuh]

Produktion 3 quartal 2020? Also erdt 2021 zu kaufen?

Es handelt sich um die EPYC-CPUs und haben nichts mit dem Desktop-Markt zu tun, wenn du das meinen solltest.

Ich gehe stark davon aus, dass AMD die Ryzen4000er im Q2 nächstes Jahr bringen wird. Aber es wird sich wohl vermutlich nur um reine Optimierung handeln, sprich, kleinere Engpässe beseitigen und etwas mehr Takt, dafür aber noch den selben Sockel AM4.

 

[RAZ0RLIGHT]

So wie sich bestimmte Zen 2 Produkte verzögern und es teilweise wohl Lieferengpässe wegen der Nachfrage gibt, glaube ich nicht an Q2, mMn. wird es wieder Q3 für Zen 3.

 

[barnacle2k]

Wird Sie, zumindest kenne ich außer Spezialfällen kaum jemand, der in seiner Software noch hart codierten Assemblercode mit Intel-spezifischen Befehlen an einer Stelle stehen hat.

Kaum? die Intel Math Kernel Library währe der erste Kandidat der mir einfällt und auch breit eingesetzt wird und AMD Prozesoren MASSIV ausbremst.
Siehe zum beispiel Ryzen Matlab Benchmarks.

 

[Holt]

barnacle2k, hast Du auch Belege für die Behauptung? Sonst ist sie wertlos. Wenn ich danach google, komme ich auf solche Aussagen:

It depends if the used libraries call FMA3 commands. If so, the Ryzen crashes very fast.

Wenn dem so ist, kann man Intel auch nicht vorwerfen, dass sie bestimmte Befehlserweiterungen nur bei Intel CPUs aktivieren, oder sollen sie auch noch die ganzen AMD CPUs durchtesten um zu sehen was da schneller ist und stabil funktioniert?

Im übrigen ist es ja wohl so, dass man die Intel Math Kernel Library (MKL) explizit in Mathlab einbinden muss. Der richtige Weg wäre, dass AMD selbst eine solche Lib rausgibt die auf die eigenen CPUs optimiert ist und der Hersteller der Software dann eine Möglichkeit schafft auch diese AMD Lib einzubinden. Wenn AMD so eine Lib hat, beschwere Dich beim Hersteller von Mathlib und wenn AMD keine solche lib anbietet, beschwere Dich bei AMD!

The performance will depend on your programs.
....
If you'll be using MATLAB with general routines, without parallel pool, you'll be getting a worse performance than a slow core i3 since 1 core of Ryzen 7 is a lot weaker than 1 intel core.

Das war noch auf die RYZEN der ersten Generation bezogen, aber es zeigt eben, dass offenbar die Singlethreadperformance bei Mathlab oft wichtig ist und ebenso was genau das Programm macht.

 

[barnacle2k]

Pugetsystems hat da einige schöne Benchmarks veranstaltet und das Ergebnis ist EINDEUTIG.

Numpy norm eines Matrixprodukts bei verwendung der Intel MKL:
Intel Xeon 2175W: 16,1 Sekunden
AMD 3900x: 124,9 Sekunden 775% Langsamer!

Ja der Ryzen braucht fast ACHT mal so lang wie der Intel Prozessor.

die selbe Berechnung unter verwendung der OpenBLAS Bibliothek:
Intel Xeon 2175W: 35,1 Sekunden
AMD 3900x: 39,9 Sekunden nur noch 13% langsamer, normale Differenz für 12 vs 14 Kerne.

Quelle:
AMD Ryzen 3900X vs Intel Xeon 2175W Python numpy - MKL vs OpenBLAS

 

[Holt]

ja und?

MKL provides tremendous performance optimization on Intel CPU's The test job is definitely benefiting from AVX512 optimizations which are not available in this OpenBLAS version.

Alleine durch AVX512, der Xeon-W 2175 hat zwei AVX512 Einheit pro Kern, kann schon ein großer Performancevorsprung entstehenm siehe hier die Ergebnisse des Cannon Lake i3-8121U bei 3D Particle Movement v2.1 mit AVX512. Intels libs sind natürlich auf Intels CPUs optimiert, was niemanden wundern dürfte und umgekehrt wird auch niemand von AMD eine Optimierung auf Intel CPUs erwarten. Keiner wird die CPUs des anderen testen um solche Fehler zu finden und zu vermeiden:

if the used libraries call FMA3 commands. If so, the Ryzen crashes very fast.

Was wäre das Geschrei groß, wenn Intel Libs dann bei AMD CPUs gar zu Abstürzen führen.

Die Antwort von AMD muss eine eigene, auf die eigene CPUs optimierte Lib sein, so eine Lib scheint es ja auch zu geben:

Note: I also tried to setup a numpy linked with AMD BLIS lib but it did not work correctly (very poor performance).

Das deren Performance total mies ist, dafür kann doch wohl EINDEUTIG Intel nichts, sondern da muss AMD sich an die eigene Nase fassen und sollte eine Version bringen die auch eine ordentliche Performance bietet!

 

[Sockrattes]

Hätte nicht gedacht daß sich soviele für Serverprozessoren interessieren.

 

[JohnnyBGoode]

@Sockrattes

Das Interesse dürfte daran liegen, dass AMD nicht unterschiedliche CPU-Kerne-Chiplets für Server/High End/Desktop/Low End entwickelt sondern diese Chiplets den kleinsten gemeinsamen Nenner bilden, der sich durch alle Familien von der günstigsten APU bis zum hochpreisigsten Epyc durchzieht. Dadurch kann man sich von Neuigkeiten zu den Server-Produkt-Entwicklungen potenziell Leistungsverbesserungen für den Bereich, der einen persönlich betrifft, ableiten.

Ich wünsche mir ja, dass AM4 zumindest etwas mehr im SOHO-Bereich ankommt (wo Epycs übertrieben wären), das einzige Mainboard mit BMC/IPMI bislang ist das ASRock Rack X470D4U(2-2T), dessen aktuellstes öffentliches BIOS (3.20) von der Qualität her eine Katastrophe ist und beispielsweise noch nicht einmal AGESA 1003 ABB von Ende Juli/Anfang August hat, d. h. RDRAND ist kaputt, was je nach OS dazu führt, dass man es gar nicht erst booten kann.

Die BMC-Firmware ist ebenso mangelhaft, nach etwa einer Woche lässt sich das IPMI nicht mehr erreichen, bis man einen Power Cycle macht.

Dazu ignoriert ASRock Rack Anfragen dazu - als ob die Mainboards von Laien betreut werden.

 

[Holt]

sondern diese Chiplets den kleinsten gemeinsamen Nenner bilden, der sich durch alle Familien von der günstigsten APU bis zum hochpreisigsten Epyc durchzieht.

Nein, bisher gibt es noch keine APUs mit den Chiplets, denn so benennt AMD erst seit Zen2 die 7nm Chip auf denen die CPU Kerne sind. Es gibt aber noch keine APU damit, die 2000er APUs basieren auf Zen (14nm) und die 3000er auf Zen+ (12nm).

 

[JohnnyBGoode]

Jaaa, no shit - ich denke aus dem Kontext dieses Threads geht hervor, dass um künftige Produkte spekuliert wird und dass hier AMD für die APUs 2020 nochmal einen monolithischen Die, diesmal mit Zen 2-Kernen und Grafikkarte herausbringt, dürfte zu 99,9 % ausgeschlossen sein.

Daher auch meine Kritik an "veralteten" APUs, in Anführungszeichen da ich Zen+ in Relation zu Zen 2 durchaus als "veraltet" betrachte, auch wenn bei den dieses Jahr erschienenen Picasso-APUs wie bei den Matisse-CPUs 3000 im Namen steht.

 

[barnacle2k]

ja und? Alleine durch AVX512, der Xeon-W 2175 hat zwei AVX512 Einheit pro Kern, kann schon ein großer Performancevorsprung entstehenm siehe hier die Ergebnisse des Cannon Lake i3-8121U bei 3D Particle Movement v2.1 mit AVX512. Intels libs sind natürlich auf Intels CPUs optimiert, was niemanden wundern dürfte und umgekehrt wird auch niemand von AMD eine Optimierung auf Intel CPUs erwarten. Keiner wird die CPUs des anderen testen um solche Fehler zu finden und zu vermeiden: Was wäre das Geschrei groß, wenn Intel Libs dann bei AMD CPUs gar zu Abstürzen führen.

Die Antwort von AMD muss eine eigene, auf die eigene CPUs optimierte Lib sein, so eine Lib scheint es ja auch zu geben:
Das deren Performance total mies ist, dafür kann doch wohl EINDEUTIG Intel nichts, sondern da muss AMD sich an die eigene Nase fassen und sollte eine Version bringen die auch eine ordentliche Performance bietet!

Die Frage war gibt es da draussen noch verbreitete und verwendete Software gibt die systematisch AMD Prozessoren benachteilt.
Die Antwort ist - Ja im bereich der Mathematiksoftware. (Matlab, Numpy/scipy, Mathematika usw.)

>> aber MKL crasht auf AMD Ryzen Prozessoren
Keine ahnung was der Nutzer im Mathworksforum da zusammenfantasiert, deckt sich nicht mit meiner Erfahrungen mit modifizierten MKL binaries in denen der Dispatcher verändert wurde sodass er auch AMD Prozessoren FMA verwenden lässt.
Muss Intel für AMD optimieren?
Nein aber die Codepfade die SIMD Instruktionen verwenden sollten auf allen Prozessoren die diese Instruktionen beherrschen auch verwendung finden.
Gepatchte MKL:
GitHub - fo40225/Anaconda-Windows-AMD: optimized numpy, numexpr, scipy, scikit-learn for AMD CPU with patched Intel MKL+compiler