Zen 2, 7nm, PCIe 4.0, 2019 (Matisse, Renoir, Castle Peak, Rome), Matisse-Refresh 2020

[HOT]

Es wär total idiotisch, der APU keine 8 Kerne zu verpassen, wenn der neue CCX grad mal 60mm² groß ist :freak:. Da spart man sich halt wieder die Hälfte an L3$ und gut ist.
Und Da könnte i.Ü. auch das Navi14 herkommen, 14CUs. Ist eine brauchbare Größe mMn.

[dargo]

Es wär total idiotisch, der APU keine 8 Kerne zu verpassen, wenn der neue CCX grad mal 60mm² groß ist :freak:.
Wo steht, dass ein CCX 8 Cores hat? Bisher wissen wir immer noch nicht ob ein Die aus einem oder doch zwei CCX besteht.

[Opprobrium]

Wo steht, dass ein CCX 8 Cores hat? Bisher wissen wir immer noch nicht ob ein Die aus einem oder doch zwei CCX besteht.

Jupp. Eine 8-Core CCX würde aber Sinn ergeben um die Anbindung einzelner Cores nicht noch um ein weiteres Level zu verkomplizieren.

[w0mbat]

Das sehe ich anders. Der Grund für die CCX Aufteilung war ja der exponentielle Anstieg der benötigten Vebindungen wenn man 8 Kerne direkt verbinden will. Ich kann mir gut vorstellen, dass jedes chiplet weiterhin aus zwei 4C CCX besteht. Vor allem hat AMD ja stark am IF gearbeitet, d.h. es wäre ja schön doof wenn man diese Verbesserungen nicht auch direkt für die CCX anwendet.

Wir sehen ja welche Wege AMD geht um die 7nm Dies klein zu halten, ich kann mir nicht vorstellen dass man dann anfängt für 8C direkte Verbindungen in 7nm zu packen.

[HOT]

Ich tippe auf nen IF-Ringbus, wie schon bei den V20.

[Xonotron]

Wo steht, dass ein CCX 8 Cores hat? Bisher wissen wir immer noch nicht ob ein Die aus einem oder doch zwei CCX besteht.
Ja, leider noch nirgendwo.

1 Chiplet = 2x 4-Core CCX würde aber dem Ziel widersprechen, IO-Kram auf ein separates Die auszulagern, oder? Die beiden CCX müssten dann ja Chiplet intern über eine zusätzliche Infinity Fabric miteinander verbunden sein.

1 Chiplet = 1x 8-Core CCX mit nur einem IF Interface zum IO-Die wäre da doch viel eleganter.

Bei einem kleinen IO-Die mit zwei IF-Interfaces wären dann tolle Kombos möglich, 16 Core Ryzen3000 und 8 Core Ryzen3000G :biggrin:

[AffenJack]

Es wär total idiotisch, der APU keine 8 Kerne zu verpassen, wenn der neue CCX grad mal 60mm² groß ist :freak:. Da spart man sich halt wieder die Hälfte an L3$ und gut ist.
Und Da könnte i.Ü. auch das Navi14 herkommen, 14CUs. Ist eine brauchbare Größe mMn.

Meinst du teildeaktiviert oder eigenes Die mit der Hälfte L3?

In meinen Augen macht bei so einem kleinen DIE ein Extradie keinen Sinn mehr. Die Designkosten in 7nm sind zu hoch. Ich stelle mir das Lineup so vor:

Zen 2 16 Core: 2 8Core Die + Desktop IO Chip (dieser wird bei allen Produkten verwendet)
Zen 2 12 Core 2x 6 Core + IO
Zen 2 8 Core, 2x4 Core + IO
APU 8 Core Zen2 chiplet (vll halber L3 um Chiplets mit kaputten L3 zu nutzen) + GPU Die + IO
APU salvage ...

So hat man nur 1 mal die 7nm Designkosten bei der CPU gehabt und 1 mal beim IO Die. APU braucht nur noch eine GPU extra.

[Opprobrium]

Und für den UltraLowBudget Bereich (Athlons) wäre dann sogar eine extra aufgelegte monolithische 4 Kern APU denkbar. Aber nicht vor 2020

[HOT]

AffenJack, ich meine ein monolithisches Die mit einem CCX und halbiertem L3 um etwas Platz zu sparen.

[tm0975]

Und für den UltraLowBudget Bereich (Athlons) wäre dann sogar eine extra aufgelegte monolithische 4 Kern APU denkbar. Aber nicht vor 2020

dafür kann man genauso den bisherigen 14/12nm Kram weiterverwenden. da lohnt der ganze aufwand nicht.

grundsätzlich finde ich das konzept klasse. die neuen HEDT/Workstation Prozessoren werden definitiv kostengünstiger herstellbar sein als bisher. das ermöglicht es AMD, bei bedarf im bereich der 12-16 Kerner den Druck auf Intel oder die eigene Marge deutlic zu erhöhen.

[w0mbat]

1 Chiplet = 1x 8-Core CCX mit nur einem IF Interface zum IO-Die wäre da doch viel eleganter.
Eleganter auf jeden Fall. Aber im Fokus von AMD steht ja nicht "elegant", sondern praktisch, wie man am 8+1 Ansatz sehen kann.

Wie gesagt, 8C mit einer Art "Ringbus" zu verbinden benötigt sehr viele direkte Leitungen, das braucht Platz und Energie. Die Idee hinter dem CCX Ansatz von Zen1/+ war ja, dass man einen einfachen core-cluster mit nur 4C aufbaut. Hier braucht man max. 6 direkte Verbindungen. Und dann "klebt" man diese, auf dem selben Die, mit IF zusammen. Also 2x 6 Verbindungen + 1x IF ergeben 8C.

Wenn jetzt jedes Chiplet nur aus einem 8C CCX besteht muss man extrem viele direkte Verbindungen legen, bzw. so eine Art "IF Ringbus" wie HOT meinte, braucht bestimmt Platz und viel Strom. Zen1/+ fährt mit dem 4C CCX Ansatz sehr gut und jetzt, wo das IF noch besser arbeitet, soll AMD plötzlich auf diese Vorteile verzichten? Wo es in 7nm um jeden mm² geht? Ich glaube nicht.

Natürlich ist es gut möglich, dass jedes Chiplet wirklich nur ein 8C CCX hat, vielleicht hat AMD auch eine andere Lösung gefunden. Ist nur Spekulation meinerseits. Aber wenn man sich die Richtung ansieht, die AMD einschlägt, machen zwei 4C CCX pro Chiplet mMn deutlich mehr Sinn. Das kann die Komplexität der Chiplets ernorm reduzieren.


Was ich mich auch frage: wieso wird das I/O Die in 14nm hergestellt und nicht in 12nm, wenn er von GloFo kommen soll?

[basix]

Die Idee mit dem Ringbus ist ja gar nicht schlecht. Und mehr Strom sollte der eigentlich nicht verbrauchen. Es gab Messungen dazu, wo der Ringbus deutlich effizienter war als IF und das neue Intel-Mesh-Netzwerk. Siehe hier https://www.anandtech.com/show/13124/the-amd-threadripper-2990wx-and-2950x-review/4

Zur irgendwann kommenden Zen 2 APU: Ich bezweifle sehr, dass diese mehr als 4C bekommen wird, außer AMD vermarktet diese nicht mehr nur im Low-End/Mainstream Markt.
Momentan sehe ich absolut keinen Grund, nicht auf 8C zu gehen. Mit dem 8C Chiplet hat man das ja schon. Bei Workstations im beruflichen Umfeld kann das wertvoll sein (ich warte z.B. meinerseits auf eine >=6C Maschine). Eventuell wird es aber für den Lowend Markt noch eine dedizierte APU geben mit 4C und kleiner GPU. Das Ding wird vermutlich dann nur knapp 100m2 gross sein und somit stimmt dann auch die Marge.

[S940]

Was ich mich auch frage: wieso wird das I/O Die in 14nm hergestellt und nicht in 12nm, wenn er von GloFo kommen soll?Weil 12nm bei nem I/O Chip mit 1000++ Pins so gut wie keinen Vorteil bieten.

[BoMbY]

Ich gehe sehr stark davon aus, dass das IF Ethernet-PHY basiert ist, und das der IO-Die wie ein Ethernet-Switch funktionieren wird um die unterschiedlichen Komponenten zu verbinden. Es gibt viele Patente die in die Richtung gehen, und Paketorientierte Datenübermitteilung macht auch im Hinblick auf die kürzliche eingeführten QoS-Funktionen Sinn. Und das ist über alle Ebenen beliebig skalierbar mit mehr Switches, man könnte zum Beispiel 4 Sockel problemlos mit einem 4x Switch realisieren.

[BoMbY]

Kommt Euch z.B. der Aufbau bekannt vor:

https://i.imgur.com/ukTOxsv.png

Das kommt aus folgendem Patent:


Contended lock request elision scheme (http://www.freepatentsonline.com/20170371787.pdf)

A system and method for network traffic management between multiple nodes are described. A computing system includes multiple nodes connected to one another. When a home node determines a number of nodes requesting read access for a given data block assigned to the home node exceeds a threshold and a copy of the given data block is already stored at a first node of the multiple nodes in the system, the home node sends a command to the first node. The command directs...

Im Detail kann man dann zum Beispiel die Paketorientierung sehen.

[Thunder99]

Das haben sie doch schon, dehalb verkauft sich Ryzen ja auch so gut.

Nein, sie nähern sich aber Gleichstand und annähernd Gleichstand herrscht bisher nicht ;) Oder ist ein Ryzen 2600x so schnell wie ein 8700k? Beide haben gleiche Anzahl Core und SMT

[davidzo]

Kommt Euch z.B. der Aufbau bekannt vor:

https://i.imgur.com/ukTOxsv.png

Das kommt aus folgendem Patent:



Im Detail kann man dann zum Beispiel die Paketorientierung sehen.

Eigentlich nichts neues, methoden für cache-kohärenz von Multiprozessorsystemen gibt es seit den 90ern, z.B. der Stanford Directory Architecture for Shared Memory (DASH).

Das ist auch lediglich eine Patent Application, also noch nicht erteilt. Normalerweise sind die Patent Claims am Ende dermaßen zusammengekürzt, dass von der Schutzwirkung nur noch wenig übrig bleibt. Dass ein Patent mit starken Claims durchkommt ist wirklich die Ausnahme, meistens gibt es prior art und man zieht sich dann auf ein Nischenzenario zurück um die Kosten des ganzen Anmeldeprozesses nicht völlig in den Sand gesetzt zu haben...
Deswegen auch der Seitenlange Abstract, zur Not zieht man sich einen spezifischen Claim dann hier heraus, je mehr Text man abgeliefert hat desto mehr Auswahl hat man am Ende.

Das sieht aber so aus als wenn AMD bei der Topologie also bei CCX mit 4 Cores und 3x core zu core Verbindungen pro core bleibt. Also keine 8fach CCXes mit multiplem oder gegenläufigen Ringbus oder so. Schade.

SGI hatte damals die Hypercube Topologie für 16 Cores entwickelt bei der nur vier Verbindungen pro Core notwendig sind um jeden Core in durchschnittlich 2 Hops zu erreichen (max. 4) und dreifacher Leitungsbündelung (Bandbreite) bei gleichem Timing (Hops). Das auf einem Chip wieder zu beleben wäre mal was Spannenderes gewesen!

[Opprobrium]

dafür kann man genauso den bisherigen 14/12nm Kram weiterverwenden. da lohnt der ganze aufwand nicht.

Wieso nicht? Ein kleiner Chip für einen nicht unerheblichen Markt aufzulegen kann sich schon lohnen, vor allem wenn das gleiche Design auch für Embedded genutzt werden kann. Und gerade da sollten dann auch die Energieeffizienzvorteile des 7nm Prozesses nicht unterschätzt werden.

[Windi]

Kann man eigentlich abschätzen, wie groß der 14nm Chip für Ryzen mindestens sein muss?
Ich meine das jetzt vor allem wegen den Anschlusspins und nicht den Transistoren. Eine bestimmte Fläche braucht man ja mindestens, um die ganzen Leitungen hinaus zu führen.

Und bleibt dabei dann noch Platz für weitere Dinge frei?
z.B. die Display Engineer oder die Multimedia Engineer.

[Savay]

Hmm...Wenn man das Ding von den I/Os und den IF Links viertelt sollte das super grob überschlagen auch mit nem 4tel der Fläche hinhauen. (wenn es jetzt 400mm² sind...dürften 100mm² nicht komplett unrealistisch sein)
Werden dann halt 2 IMCs statt 8, 24 (32) PCIe Lanes statt 128 etc. pp. (mehr gibt AM4 afair eh nicht her)

Vielleicht ja auch mit etwas weniger als einem Viertel...je nachdem wie die benötigte Fläche für das IF mit der Anzahl der Teilnehmer skaliert.

[Ravenhearth]

Und bleibt dabei dann noch Platz für weitere Dinge frei?
z.B. die Display Engineer oder die Multimedia Engineer.
Ich bin mir nicht sicher, ob Ingenieure in so nen Chip passen? :uponder:

[BoMbY]

Ahh, hier, das dürfte der grobe Aufbau sein:

https://i.imgur.com/oOV3udj.png

Dynamic configuration of inter-chip and on-chip networks in cloud computing system (http://www.freepatentsonline.com/20180077228.pdf)

The on-chip network for the chip 300 includes a crossbar switch 320 that routes information between entities on the chip 300 and entities that are connected to the chip 300. For example, the crossbar switch 320 can route packets between the cores 301-304 based on information stored in routing tables 321, 322, 323, 324, 325 that are collectively referred to herein as “the routing tables 321-325.” Although the routing tables 321-325 shown in FIG. 3 are implemented in the cores 301-304 and the crossbar switch 320, some variations implement routing tables in more or fewer locations within the chip 300. For example, the crossbar switch 320 can implement a single routing table 325 and use this information to route packets that are received by the crossbar switch 320 from the cores 301-304, the memory controller 310, the interfaces 311-314, or the I/O bridge 315. As discussed herein, the crossbar switch 320 can be dynamically configured based on relative priorities of workloads that are executing on the cores 301-304.

[Windi]

OK, Danke

Ich Frage mich halt gerade, ob man auf dem IO-Chip noch etwas Platz für eine mini-GPU übrig hätte. Also Bildausgabe und Multimedia, keine wirkliche Spieleleistung.

Ich bin mir nicht sicher, ob Ingenieure in so nen Chip passen? :uponder:
:D Autokorrektur

[amdfanuwe]

Kann man eigentlich abschätzen, wie groß der 14nm Chip für Ryzen mindestens sein muss?
Nein, ich kann aber sagen, wie groß er maximal sein muss. Ein Zeppelin Die mit 213 mm² hat alle Anschlüsse drauf. Ein paar Pins werden nicht benötigt. Inwieweit man aber weitere Pins weglassen kann ohne die Signalintegrität zu gefärden ????
Vom Silizium würden also 213 - 2*CCX a 44mm² = 125mm² ausreichen.

[amdfanuwe]

OK, Danke

Ich Frage mich halt gerade, ob man auf dem IO-Chip noch etwas Platz für eine mini-GPU übrig hätte.
Die Chipgröße wird bestimmt durch die Anzahl der Pins. Wenn da die Größe nötig ist wie bei Zeppelin oder RavenRidge, dann sollte noch Platz für GPU sein.

Ich hoffe drauf, das RavenRidge 2018 noch etwas überarbeitet wurde und als I/O dient oder eine kleine APU die als Athlon GE dienen kann.

[amdfanuwe]

Ahh, hier, das dürfte der grobe Aufbau sein:

Jup, seh ich auch so.
Dazu noch das Verzeichnis für die Cachecohärenz und die Latency Tabellen.
Braucht schon seinen Platz.
Hier für RavenRidge auf Seite 3 haben sie mal die Switches eingezeichnet:
https://fuse.wikichip.org/news/1596/hot-chips-30-amd-raven-ridge/3/

[Ravenhearth]

Sorry, aber kann es sein, dass Rome im C-ray Benchmark etwas "langsam" war? Man vergleiche:

https://images.anandtech.com/graphs/graph11544/78012.png

Rome war 7% schneller als zwei 8180M. Die takten mit 2,5GHz Basistakt, also wenn man mal einen auf Milchmädchen macht und das auf das Ergebnis der 8176 umrechnet und dann auch noch die 7% drauf, landet man für Rome hier bei 433. Nicht schlecht, aber trotzdem deutlich langsamer als die 2 Epyc 7601 mit 526, auch mit 64 Kernen. Bandbreite/IF dürfte hier nicht limitieren, das passt eigentlich in den L1. Also woran kann es liegen, dass Rome anscheinend schlechter als 2 x Naples abschneidet (weswegen man evtl auch nicht mit Epyc verglichen hat)? Insbesondere weil C-ray FP-lastig ist und Zen 2 ja auch noch den bis zu zweifachen FP-Durchsatz hat. :confused: Ok wenn man das Ergebnis von Rome mit 28,1s auf "renders per hour" umrechnet, kommt man nur auf 128, generell scheint das Niveau also deutlich niedriger zu liegen als bei anandtech. Komplexere Szene, höhere Auflösung? Aber hätte das einen so starken Einfluss, dass Rome deutlich näher an den Xeons liegt und hätte AMD dann nicht eine andere Szene/Auflösung gewählt, sodass der Abstand größer wäre? Fragen über Fragen.

[Locuza]

AMD bot außerhalb der Präsentation auch einen Vergleich mit Naples an:
Das freut AMDs Rome-CPU, die mit ihren 64 Zen-2-Kernen über große Leistungsreserven verfügt. C-Ray ist darauf nach 27,7 Sekunden fertig - und weil der Server nur luftgekühlt arbeitet, nicht übertaktet ist und die Treiber obendrein noch nicht final optimiert sind, soll laut AMD noch mehr Leistung möglich sein. Spoiler-Alarm: Damit ist Rome 9,2 Prozent schneller als der schon erwähnte Intel-Server.

Bei diesem brauchen zwei Xeon-Platinum-8180M-Prozessoren der Konkurrenz für den gleichen Benchmark-Durchgang 30,5 Sekunden. Zum Vergleich ließ AMD am Nachmittag C-Ray noch auf einem dritten Server laufen: Darin tickten zwei Epyc-7601-CPUs, die auf der aktuellen ersten Zen-Generation basieren (Codename Naples) - und mit 28,4 Sekunden immerhin noch rund 6,9 Prozent flinker als die Intel-Vertreter waren.
http://www.pcgameshardware.de/AMD-Zen-Architektur-261795/Specials/Benchmark-Showdown-1268843/

Pro Kern schneidet Rome nicht stark ab, aber wir kennen die Taktraten und die Leistungsaufnahme nicht.

[fondness]

AMD bot außerhalb der Präsentation auch einen Vergleich mit Naples an:

http://www.pcgameshardware.de/AMD-Zen-Architektur-261795/Specials/Benchmark-Showdown-1268843/

Pro Kern schneidet Rome nicht stark ab, aber wir kennen die Taktraten und die Leistungsaufnahme nicht.

Wenn die TDP pro Socket gleich bleibt (was nicht unwahrscheinlich ist, denn ansonsten wären einfache CPU-Wechsel nicht möglich bzw. es bräuchte wieder neue Serverdesigns), wäre das mehr als doppelte Perf/Watt vs. Naples.

[Ravenhearth]

Okay, die Werte sind natürlich deutlich handfester als meine Rechnungen. Und wenn man bedenkt, dass Rome noch nicht final ist, liegt das durchaus im Rahmen der Erwartungen. Der bis zu doppelte Durchsatz bei FP bedeutet ja auch nicht, dass sämtliche Berechnungen nun doppelt so schnell ausgeführt werden, kann C-ray davon überhaupt Gebrauch machen?

Es bleibt für mich jedoch die Frage, warum die Xeons im Benchmark von anandtech so weit hinter die Epycs zurück fallen, sich bei AMDs eigenen Benchmarks jedoch quasi ein Kopf-an-Kopf-Rennen liefern. :uponder:

[Complicated]

Ahh, hier, das dürfte der grobe Aufbau sein:


Der Aufbau ist doch das Schema eines monolithischen Dies. Chip 300 ist alles was auf dem Bild zu sehen ist.

[BoMbY]

Ja, der aktuelle Aufbau. Für Zen2 sehe ich den Crossbar-Switch im IO-Chiplet, und halt noch einen Cache vor den MCs.

[Gipsel]

Ahh, hier, das dürfte der grobe Aufbau sein:

https://i.imgur.com/oOV3udj.png

Dynamic configuration of inter-chip and on-chip networks in cloud computing system (http://www.freepatentsonline.com/20180077228.pdf)Hmm, das ist einfach nur irgendeine CPU, in der sich vier Kerne einen L3-Cache teilen und die einen IMC, ein paar Chipsatzfunktionen (IO-Bridge) und externe Interfaces (z.B. PCIe) enthält. Mehr oder weniger ein Platzhalter für eine CPU. Da kannst Du meiner Meinung nach gar nichts dran ablesen (ein single CCX Ryzen könnte man auch so aufmalen).

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

Nein, ich kann aber sagen, wie groß er maximal sein muss. Ein Zeppelin Die mit 213 mm² hat alle Anschlüsse drauf. Ein paar Pins werden nicht benötigt. Inwieweit man aber weitere Pins weglassen kann ohne die Signalintegrität zu gefärden ????
Vom Silizium würden also 213 - 2*CCX a 44mm² = 125mm² ausreichen.Ganz schön viele Kontakte werden nicht benötigt (Stromversorgung/Masse für die CPU-Kerne). Und die sitzen bevorzugt im Inneren der Diefläche.
Die Chipgröße wird bestimmt durch die Anzahl der Pins.
Naa, traditionell wird die Kantenlänge des Dies durch die Anzahl (Größe) der benötigten externen Verbindungen bestimmt (gibt ein unteres Limit), nicht unbedingt die Fläche selber (früher mit wire bonding sowieso, bei flip chip wegen Routing auf dem Package). Externe Interfaces platziert man eher am Rand. Inzwischen legt man das aber auch zumindest etwas weiter vom Rand weg, bzw. layoutet man die Interfaces auch in zwei Reihen am Rand (siehe z.B. das Speicherinterface beim Zeppelin-Die). Aber wenn man viele Interfaces hat, versucht man immer noch, den Abstand der Kontakte zum Außenrand des Dies zu minimieren. Es scheint aber vielleicht nicht mehr ganz so kritisch wie früher zu sein. Trotzdem dürfte auch das einer der Gründe sein, warum der IO-Die von Epyc2 so langgestreckt ist (Maximierung der Kantenlänge).

Der Platzbedarf der externen Interfaces korreliert übrigens nur schwach mit der Anzahl der benötigten Kontakte. Diese kann man nämlich notfalls sehr dicht setzen. Allerdings benötigt die Elektronik der PHYs eventuell beträchtlich Platz pro Pin, insbesondere wenn hochfrequente Signale vom Package runter gehen sollen. Ein HBM-PHY mit 1024 Kontakten für die Daten (+ noch ziemlich viele mehr zur Adressierung) ist nur ~50% größer als ein PCIe 3.0 x16 PHY mit lediglich 16 Paaren von Kontakten für die Daten.

[BoMbY]

So, hier noch einmal anschaulich:

https://i.imgur.com/Uvs5YQG.png

[Gipsel]

Und was soll uns das jetzt sagen?

[BoMbY]

Also langsam tut es echt weh ... Infinity Fabric ist Netzwerk-basiert, genauso wie es Hyper Transport bereits war. Das IO-Chiplet enthält einen Crossbar Switch. Die CPU-Chiplets sind mit dem Crossbar Switch verbunden, ebenso wie die MCs, und der Rest des IOs. Das ist über weitere Switches beliebig skalierbar. Nix Ringbus oder dergleichen.

[r-or]

Das ist nicht korrekt, Zen2 hat mehrere Caches welche mit der 'crossbar' verbunden sind. Die Frage ist eher, wie das umgesetzt wurde + welche Nachteile es für die latency haben könnte.

[amdfanuwe]

Ganz schön viele Kontakte werden nicht benötigt (Stromversorgung/Masse für die CPU-Kerne). Und die sitzen bevorzugt im Inneren der Diefläche.

Naa, traditionell wird die Kantenlänge des Dies durch die Anzahl (Größe) der benötigten externen Verbindungen bestimmt (gibt ein unteres Limit), nicht unbedingt die Fläche selber (früher mit wire bonding sowieso, bei flip chip wegen Routing auf dem Package).
Ja, ein paar weniger dürften es schon sein, aber wieviele?
Klar, die Chips sind per FlipChip auf dem Träger gelötet. Hast du Daten zum Abstand der Kontakte? Wenn ich die Fläche von Zeppelin nehme komme ich bei 1331 Kontakten für AM4 auf 0,4mm Raster. Denke mal, die Größenordnung passt, sind ja keine µBumps.
Da wird dann auch klar, dass der ROME I/O so groß ist.

[Gipsel]

Ja, ein paar weniger dürften es schon sein, aber wieviele?Sehr viele. Die meisten Kontakte eines Dies sind für Stromversorgung und Masse gedacht. Und man kann einen Pin (oder Kontakt bei LGA) auch zu mehreren Bumps des Dies leiten. ;)
Klar, die Chips sind per FlipChip auf dem Träger gelötet. Hast du Daten zum Abstand der Kontakte? Wenn ich die Fläche von Zeppelin nehme komme ich bei 1331 Kontakten für AM4 auf 0,4mm Raster. Denke mal, die Größenordnung passt, sind ja keine µBumps.
Da wird dann auch klar, dass der ROME I/O so groß ist.Der Pitch von C4 Flipchip bumps ist wohl üblicherweise so um die 200µm. Das ist also die vierfache Dichte im Vergleich zu 400µm (BGA-Packages haben oft schon 400µm Pitch der Lötstellen zum Board). Und die Packaging-Firmen bieten sogar bis runter auf 130µm/100µm an (gerade noch mal nachgesehen, 100µm am Rand des Dies, 130µm im Inneren), wenn man es haben will. µBumps dagegen gehen auch mit 40µm Abstand oder gar noch drunter (auch auf speziellen organischen Packages, nicht nur Si-Interposer).

Die IO-Chip von Rome ist auch so groß, weil die PHYs für 128 PCIe-Lanes, für 8x72Bit DDR4, dann noch USB, der Legacy-Kram und dann jetzt noch die IF-Links zu den Core-Chiplets Einiges an Platz einnehmen. Die Anzahl der Kontakte ist da ziemlich nebensächlich (insbesondere bei den Highspeed GPIO-Lanes [darüber gehen PCIe, SATA oder auch xGMI/IFIS also off-package infinity fabric], die bei Rome ja vermutlich sogar 25GT/s können]). Schau Dir doch mal einen Zeppelin-Die (wo die GPIO-Lanes nur 12,5GT/s können) oder auch einen intel Xeon HCC-Die an!

[gravitationsfeld]

Also 1x CPU Chiplet, 1x I/O Chip und 1x GPU auf einem Träger?

Ggf. dann aber für low cost etwas teuer? Auch für besonders dünne Notebooks ggf von der Größe des Package etwas zu viel?
7nm ist teurer pro Transistor als 14nm. Groessere Dies haben zudem schlechtere Yields. Die Kosten-Kalkulation ist nicht mehr so einfach.

[amdfanuwe]

Und man kann einen Pin (oder Kontakt bei LGA) auch zu mehreren Bumps des Dies leiten. ;)

Hat der Die also noch mehr Kontakte als der Sockel.
Dürfte die Die Größe für den I/O doch schon weitestgehend durch die Anzahl der Kontakte bestimmt sein.

[Gipsel]

Hat der Die also noch mehr Kontakte als der Sockel.
Dürfte die Die Größe für den I/O doch schon weitestgehend durch die Anzahl der Kontakte bestimmt sein.Immer noch nicht. Kontakte sind im Normalfall nicht limitierend. Die Größe der PHYs liegt erheblich über dem, was man für die Kontakte benötigt. Schau Dir doch mal einen 16x PCIe-PHY im Vergleich zu den GMI/IFOP-PHY auf einem Zeppelin-Die an. Das eine sind 16 Datenverbindungen jeweils hin und zurück, jeweils differentiell, also nur 64 Highspeed-Kontakte (für insgesamt 32Bit pro Takt). Das andere sind zwei unidirektionale 32Bit Links (auch jeweils hin und zurück), aber single ended und somit ebenfalls 64 Kontakte für Daten (die aber 64Bit pro Takt übertragen). Das PCIe-PHY ist aber locker 4 mal so groß, falls das überhaupt reicht. Die Anzahl der Kontakte ist für diesen Fakt völlig nebensächlich.

TLDR:
Die Größe eines Interfaces bzw. dessen PHY wird im Allgemeinen nicht durch die Anzahl der dafür nötigen Kontakte bestimmt. Die mögliche Dichte der Bumps auf dem Die ist dafür normalerweise völlig unkritisch. Ausnahme sind sowas wie HBM-Interfaces mit Tausenden von Kontakten für verhältnismäßig niedrig getaktete Signale auf sehr gut definierten Leitungsbahnen (also Si-Interposer/EMIB), wofür dann µBumps zum Einsatz kommen.

[LadyWhirlwind]

7nm ist teurer pro Transistor als 14nm. Groessere Dies haben zudem schlechtere Yields. Die Kosten-Kalkulation ist nicht mehr so einfach.

Der I/O Chip ist in 14nm und daher wohl nicht so teuer in Verhältnis. Wenn die GPU vorderhand auf 12 nm bleibt, sehe ich das nicht als unmöglich an. Auch weil es eine gute Möglichkeit ist, Teildefekte Chips los zu werden.

[mczak]

Der I/O Chip ist in 14nm und daher wohl nicht so teuer in Verhältnis. Wenn die GPU vorderhand auf 12 nm bleibt, sehe ich das nicht als unmöglich an. Auch weil es eine gute Möglichkeit ist, Teildefekte Chips los zu werden.
Die GPU bleibt sicher nicht auf 12nm, wie kommt man bloss auf solche komischen Ideen? Auf dem Desktop ginge das schon, aber mobil ist das keine Option.

[Setsul]

Die großen Fragen sind doch folgende:
1. Wie sieht die Latenz aus?
2. Wie sehen die Yields aus?
3. Was will AMD alles anbieten?

Wenn die Latenz fürchterlich ist, wird AMD für den Desktop wohl oder übel einen anderen Die brauchen. Aber ich denke, dass das seinen Grund hat wieso die Chiplets in Paaren direkt nebeneinander liegen. Das Ding soll eben nicht völlig anders sein als Zen1. Ich vermute die Paare sind jeweils direkt verbunden. Die Latenz dürfte sich bei der praktisch nicht vorhandenen Entfernung zumindest in ähnlichen Bereichen bewegen wie zwischen CCX auf demselben Die. Damit ist Rome dann Naples nicht nur thermisch ähnlich sondern es gibt auch wieder 4 Nodes mit ähnlicher Latenz zwischen den CCX innerhalb des Nodes nur dass es jetzt jeweils 4 statt 2 CCX sind. Oder größere CCX, aber daran glaube ich immernoch nicht wirklich.

Entsprechend könnte das für den Desktop machbar sein, wenn man ein Chiplet direkt neben einen 1/4 IOX Chip setzt. Die nächste Frage ist wie sind die Yields auf 7nm? Wenn man aus 4 Kern Dies zuverlässig genügend 4 Kern APUs bekommt dann wären 6 Kerne kaum sinnvoll, wenn man keinen großen Markt für 6 Kern APUs hat. AMD hat ja nicht den Anspruch den gesamten Markt abzudecken. Also dann entweder nur 4 (und dann einen mit 8 ohne GPU) oder einen Die mit 4 und einen mit 8 Kernen. Damit wäre der Desktop abgedeckt. Wenn die Yields nichts so umwerfend sind, dann könnte man das ähnlich lösen, eine APU mit 6-8 Kernen und damit deckt man dann das meiste ab. Ein Rückschritt auf weniger als 8 Kerne wird kaum akzeptabel sein und ULP 2 Kern APUs wird man nicht wirklich mit 6 oder 8 Kern Dies abdecken wollen, also läuft es eigentlich garantiert auf mindestens 2 Dies hinaus.

Die Frage ist dann was will AMD alles anbieten? 4 Kern APU + 8 Kern Desktop lässt sich sicherlich monolithisch machen und braucht nur 2 Dies. APUs von 2 bis 6 oder 8 Kernen und Desktop bis 8 verlangt wahrscheinlich nach 3 oder der gesamte Desktop wird von 8 Kern APUs abgedeckt. Aber was ist mit mehr Kernen? Will AMD warten auf EUV und dann erst die Kernzahl erhöhen oder lieber direkt angreifen während Intel auf 10nm wartet und nicht wirklich antworten will?
Wenn die Latenzen bei niedriger Entfernung erträglich sind könnte ein I/O Die zusammen mit einem 8C Chiplet und einer GPU mit IF alles außer ULP abdecken. Für ULP wäre wahrscheinlich ein separater 7nm 4C APU Die angebracht, einfach weil bei der TDP, Größe der Geräte und Preis ein MCM etwas ungünstig wird. Aber die großen APUs (falls vorhanden) und 8C Desktop, die mindestens einen, wenn nicht zwei 7nm Dies gebraucht hätten, und sogar 16C Desktop (wenn man sowieso 2x IF hat für 8C Chiplet + GPU) wären abgedeckt ohne einen einzigen 7nm Die zu brauchen.

[Brillus]

Mein momentaner Tip:


Das Server-CPU Chilplet
Ein GPU Chiplet mit 10-16 CU, quasi nur das 3D Zeugs
Ein IO Chiplet mit 2 Ports das auch Encoder/decoder und Display-Engine drin hat. Potential noch ein Mini GPU mit 1-2 CUs.
Ein dGPU IO Chiplet
Später (evtl. erst mit 7nn EUV) ein kleine APU 80-120mm mit 4 cores ~10CU 12-20 PCIe, 1-2 RAM interfaces.


Damit kann man dann sehr viel abdecken:

CPU mit 4-16 Cores(<=8 cores muss man dann nur 1 Chiplet anschliessen somit wenig "Verschnitt". Die hätte dann auch schon eine kleine GPU drin was für OEM auch ganz nett ist auf Desktop hat man den viel zitieren Programmierer und riesen Execl Freund. Im Notebookbereich hätte man endlich ein Top CPU mit "Optimus like" Feature. Für Heimbastler hätte man immerhin damit auch ein FreeSync-passthrough im gehobenen Markt.

Eine 4-8 Core APU im Mittelfeld, für den normalen Nutzer und Standard-Notebooks.

Einen P12 Ersatz. (Die hat aktuell auch weniger CUs als die APU).

Und das alles mit nur einem weitern 7nm Chip und 2 14nm Chips. Bonus man braucht erstmal keine 7nm PCIe, Speicherinterface, USB Logik zu entwerfen.

Später dann wenn es sich mit den Yields lohnt hat man dann noch was für kleinere Notebooks und embedded Market. Wie bei den Katzen würde ich nicht zwangsweise davon ausgehen das die auf den Desktop Sockel kommen.

[Ravenhearth]

Speku: https://twitter.com/chiakokhua/status/1060505685480206336

[LadyWhirlwind]

Die GPU bleibt sicher nicht auf 12nm, wie kommt man bloss auf solche komischen Ideen? Auf dem Desktop ginge das schon, aber mobil ist das keine Option.

Auf dem Desktop sehe ich das durchaus, wenn es kostengünstig sein soll. Auf Mobile würde sich natürlich eine 7nm GPU empfehlen. Wobei ich jetzt auch nicht weiss, wie gross der Ubterschied wirklich ist, wenn eh nur Office uns Internet und vielleicht noch Netflix genutzt wird.

[Benutzername]

Speku: https://twitter.com/chiakokhua/status/1060505685480206336

der darunter verlinkte Beitrag auf reddit bringt eine einfacheres Testen der I/O und Rechenchips ins Spiel. Auf diese Weise kann man diese unabhängig testen oder auch austauschen ohne alles neu machen zu müssen. Klingt schlüssig.

https://www.reddit.com/r/Amd/comments/9vbdhn/an_obscure_aspect_of_zen2s_discrete_io_chip_seems/


Ich erinnere Mich gelesen zu haben, daß dmaals in den siebzigern durchaus CPUs auf mehrere Chips verteilt wurden, weil das einfacher zu bauen war als alles auf einen die zu packen. Andererseits macht ein einzelner die die Produktion einfacher, weil man weniger Verbindungen knüpfen muss.

[Windi]

Wenn AMD das mit den Chiplets wirklich auch im Desktop durchziehen will, dann bräuchten sie für den Start eigentlich nur ein neues IO-DIE.
Wenn darin auch schon eine Mini GPU integriert ist, dann hat man Prozessoren mit vier bis sechszehn Kernen, die ohne Grafikkarte laufen.

Später kann man dann noch ein Chiplet mit 4C + 16CU bauen. Ein größerer Grafikteil lohnt sich kaum, da die Speicherbandbreite fehlt und ohne Kerne wäre es verdammt klein.
So braucht man dann für 4 Kerne + starker Grafik und 8 Kerne + Office Grafik nur ein Chiplet. Mit einem weiteren kann man das Ganze dann noch einmal um 8 Kerne erweitern.

Den Billig Bereich würde ich weiterhin mit Raven Ridge abdecken. Bei GF muss man eh Wafer abnehmen und 7nm ist erst einmal deutlich teurer.
Mit einer Umstellung kann man vielleicht sogar so lange warten, bis GF selbst 7nm fertigen kann. Die entwickeln den Prozess zwar nicht mehr selbst, aber die werden ihn sicherlich irgendwann einmal lizenzieren. Z.B von Samsung.

[w0mbat]

@Windi: GloFo hat 7nm komplett aufgegeben, da wird also nichts mehr kommen. Und vor allem im Mobil Bereich ist der Energieberbrauch extrem wichtig. Wenn AMD hier frphzeitig mit 7nm kommt, könnte das ordentlich Marktanteile bedeuten.

[LadyWhirlwind]

@Windi: GloFo hat 7nm komplett aufgegeben, da wird also nichts mehr kommen. Und vor allem im Mobil Bereich ist der Energieberbrauch extrem wichtig. Wenn AMD hier frphzeitig mit 7nm kommt, könnte das ordentlich Marktanteile bedeuten.

Wie hoch ist der Anteil der GPU am Stromverbrauch überhaupt, wenn man mal davon ausgeht, dass nur Inrernet und Office genutzt wird?

[aufkrawall]

Bei AMD bislang höher als bei Intel. ;)

[dargo]

Bei AMD bislang höher als bei Intel. ;)
Aber auch nur weil der GPU-Part bei AMD deutlich schneller ist. AMD braucht noch performancemäßig was vergleichbares wie Intel (wenn die Kundschaft mit der Mehrleistung vom GPU-Part nichts anfangen kann) dann sollte der Stromverbrauch vergleichbar sein.

[HOT]

@Windi: GloFo hat 7nm komplett aufgegeben, da wird also nichts mehr kommen. Und vor allem im Mobil Bereich ist der Energieberbrauch extrem wichtig. Wenn AMD hier frphzeitig mit 7nm kommt, könnte das ordentlich Marktanteile bedeuten.
Die werden irgendwann 7nm EUV bringen, genau wie UMC irgendwann 7 EUV bringen wird. GloFo fällt halt in die 2. Reihe zurück.

[Windi]

GloFo wird ja wohl nicht auf alle Zeit bei 12/14nm festhängen. Die haben die Entwicklung des eigenen 7nm Prozesses eingestellt, aber man kann sich ja was fremdes lizenzieren. Machen andere Auftragsfertiger wie UMC auch so.
Wie der neue Prozess dann genau heißt ist doch egal, ob nun 7nm oder 7nm ULV oder 5,67nm interessiert eh keinen. Natürlich ist man damit dann Jahre hinter Samsung, TSCM und Intel.

Der höhere Stromverbrauch im Office Betrieb liegt doch wohl nicht am Herstellungsprozess, bei Intel ist es ja dort auch besser. Und die höhere 3D Rechenleistung wird im Office Betrieb hoffentlich deaktiviert oder in den Energiesparmodus versetzt. AMD muss dort wohl einfach mehr optimieren.

Die Möglichkeiten im Mobilmarkt würde ich auch nicht überschätzen. Das sind alles OEMs, die langfristige Verträge haben. Die werden nicht alle sprunghaft wechseln, nur weil man einmalig einen Fertigungsvorsprung hat. Da muss man sich über Jahre hinweg wieder zurück kämpfen. Auch dürfte der Stromverbrauch nicht so extrem davon abhängen, ob der 2D-Teil des Grafikchips nun in 14nm oder 7nm gefertigt ist.

[Complicated]

GlFo hat den 7nm Prozess von IBM bekommen und noch Geld dafür...
Die werden keine 7nm Lizenzen bezahlen. Komplett EUV wird dann 5nm oder kleiner werden..und da forscht GloFo ebenfalls weiter. Sie verkaufen ja mit dem 14nm I/O mehr Wafer als mit Ryzen-Dies. (Fläche ist alles was da zählt neben den Yields)

Hier ist einfach noch nicht klar wie der Output dwr EUV Maschinen von ASML aussehen wird in 2 Jahren. GF wird wohl dann wieder Geld investieren wenn das Geschäft etwas besser planbar wird und die Verschiebungen anderer nicht gleich Milliarden kostet.

[aufkrawall]

Aber auch nur weil der GPU-Part bei AMD deutlich schneller ist..
Nö, weil das Energiesparen bei Teillast ziemlich mittelmäßig funktioniert. Ist für Desktop natürlich wayne und wird wohl schon mit Picasso besser.

[Ravenhearth]

GlFo hat den 7nm Prozess von IBM bekommen und noch Geld dafür...
Die werden keine 7nm Lizenzen bezahlen. Komplett EUV wird dann 5nm oder kleiner werden..und da forscht GloFo ebenfalls weiter. Sie verkaufen ja mit dem 14nm I/O mehr Wafer als mit Ryzen-Dies. (Fläche ist alles was da zählt neben den Yields)

Hier ist einfach noch nicht klar wie der Output dwr EUV Maschinen von ASML aussehen wird in 2 Jahren. GF wird wohl dann wieder Geld investieren wenn das Geschäft etwas besser planbar wird und die Verschiebungen anderer nicht gleich Milliarden kostet.

Das klang vor drei Monaten anders.
Along with the cancellation of the 7LP, GlobalFoundries essentially canned all pathfinding and research operations for 5 nm and 3 nm nodes.
https://www.anandtech.com/show/13277/globalfoundries-stops-all-7nm-development

[HOT]

Jo passt doch dazu. Klar cancelt man dahingegehend erst mal alles, solange man 7nm nicht verwendet. Sobald die 7nm verwenden, werden die auch kleinere Nodes erforschen, aber eben erst weit nach den Topfertigern. Auch UMC und andere Fertiger kommen halt 2-5 Jahre nach TSMC bei dem entsprechenden Node an. Bei GloFo ist das jetzt eben ähnlich.

[victore99]

2 Jahre hinterher ist also wieder dasselbe - praktisch für I/O chips undso, aber alles was Performance und Effizienz braucht, muss zu TSMC, Samsung oder Intel.
vielleicht kommt GloFo ja hinterher und holt auf, aber das dauert...

[Leonidas]

2200U?! ;)


Hast natürlich Recht. An den hab ich nicht mehr gedacht.




Was ich mich auch frage: wieso wird das I/O Die in 14nm hergestellt und nicht in 12nm, wenn er von GloFo kommen soll?


Nimmt sicherlich den Teil der Fertigung, den GloFo nicht auf 12nm umstellt. Sprich Ryzen I, was dann ausläuft. 12nm wird dagegen von Polaris 30 und Ryzen II blockiert, was man noch eine Zeitlang mitlaufen lassen muß.




PS zu GloFo 7nm:
Die werden möglicherweise 7nm dann benutzen, wenn sie die 7nm-Anlagen anderer Fertiger gebraucht einkaufen können.




So, hier noch einmal anschaulich:


Ob man dies auf Zen 2 anwenden kann, ist eher unschlüssig. Der Gag bei Zen 2 soll ja sein, das Memory Controller und I/O-Einheit aus dem Core-Chiplet herausgehen.

[HOT]

12nm dürfte bei einem rienen I/O-Chip eh kaum Vorteile bieten. Der wird kaum kleiner sein und die Leistung ist eh egal, weniger Leistungsaufnahme auf niedrigem Leistungsniveau wird 12nm auch nicht haben. Zudem hätte man die Option bei extrem hoher Nachfrage auf Samsung ausweichen zu können.

[Windi]

Mir ging es vor allem darum, das man Raven Ridge oder dessen Refresh ruhig noch einige Jahre im Billig Segment nutzen kann.
14nm wird noch lange günstiger als 7nm sein. Auch die Leistung von CPU und GPU ist vollkommen ausreichend und ist mit dem vorhandenen Speicher eh kaum steigerbar.

Wenn es richtig billig werden soll, könnte AMD sogar noch eine zweite deutlich kastrierte Version auf den Markt bringen. Nur 2 Kerne, Mini Grafik, ein Speicherkontroller, 4 x PCIe und vielleicht noch weitere Einsparungen. So dass man auf ungefähr die Hälfte kommt. Eine Art Duron 200GE.



Und zum Thema Energiesparen meinte ich es so: Wenn das Chiplet Design im Desktop funktioniert, dann würde ich keinen Extra Chip für den Mobilbereich bringen. Entweder man hat die Probleme beim Infinity Fabric mit den Latenzen und dem Stromverbrauch in den Griff bekommen oder das Design taugt eh nicht für den Desktop. Ich würde mich nur nicht wegen ein paar Prozent Effizienzverlust verrückt machen lassen.
AMD wird viel Zeit brauchen, um im Mobilbereich wieder größere Marktanteile zu gewinnen, da braucht das Produkt noch nicht von Anfang an perfekt zu sein. Das kann über die Jahre noch etwas reifen.

[Complicated]

, aber alles was Performance und Effizienz braucht, muss zu TSMC, Samsung oder Intel.

Umd was soll man bei Intel fertigen lassen? Die hängen bei 14nm fest und warten ebenso auf ASML bis Full EUV gefertigt werden kann.

[Complicated]

PS zu GloFo 7nm:
Die werden möglicherweise 7nm dann benutzen, wenn sie die 7nm-Anlagen anderer Fertiger gebraucht einkaufen können.
Sie haben doch IBMs Anlagen für 7nm bekommen inkl. Forschung und das waren die mit dem ersten 7nm Tapeout.
IBM wusste wohl warum sie GF noch 2 Mrd. Überweisen mussten damit diese das Geschäft machen.

[Ravenhearth]

Es ist schon etwas verblüffend, wie stark das Chiplet-Design bzw. die Spekulationen für die AM4-Version auf den ersten Blick Clarkdale ähneln.

https://images.anandtech.com/reviews/cpu/intel/Clarkdale/clarkdaledie.jpg

Da enthielt der CPU-Teil auch nur das nötigste und war in einem kleineren Prozess (32nm) gefertigt als das GMA Die (45nm), das I/O und Grafik enthielt. Durch den ausgelagerten Speicherkontroller waren Speicherlatenz und -bandbreite jedoch wesentlich schlechter als bei anderen Nehalem-CPUs. Ich bin gespannt, ob sich etwas ähnliches auch bei Zen 2 feststellen lässt. Das könnte sich schon im Server zeigen (wieso hat man C-ray als Benchmark genommen? der passt praktisch in den L1) und im Desktop umso mehr, falls AMD nicht den monolithischen Weg geht, um solche Probleme zu vermeiden. Oder sie habens irgendwie hinbekommen, dass der negative Effekt extrem klein ausfällt...

[Savay]

Hmmm....ändert sich denn für die Signalwege nun wirklich soviel?

Die IMCs sind afair doch auch jetzt schon per IF angebunden!
Gut rein physikalisch werden die Wege evtl. etwas länger, aber der Verwaltungs- und Schaltungsaufwand sollte sich ja nicht zwingend eklatant vergrößern, wenn die Signalqualität nicht zu sehr darunter leidet.
Und wenn bei den Latenzen bisher schon eher der Verwaltungsaufwand dominiert könnte extrem optimistisch gedacht vlt. sogar eine Verbesserung eintreten. (Wenn sie das IF allgemein noch verbessern konnten und höher takten o.ä.)

[Setsul]

Zwei Klarstellungen:
1. Eine GPU auf dem I/O Die ist wenig sinnvoll. Dann schleppt man die größte GPU mit auch auf SKUs die gar keine haben oder man braucht mehrere I/O Dies die sich nur in der GPU unterscheiden. Außerdem ist der I/O Die bei Rome 14nm weil 7nm für I/O nichts bringt, aber für GPUs bringt es sehr viel. GPUs auf 14nm verschwendet Strom, mehrere I/O Dies mit 100mm² I/O und <50mm² GPU auf 7nm statt 14nm sind der Höhepunkt der Geldverschwendung.
MCM mit GPU ist an sich kein Problem (siehe KBL-G), das einzige Problem das man lösen muss ist der Speicher. Hat die GPU eigenen Speicher braucht man nur PCIe, wenn nicht braucht man Kohärenz, aber mit IF sollte das gehen. Ein IFOP Link ist recht klein, das auf eine GPU zu packen ist nicht gerade teuer. Die Bandbreite reicht per Definition aus, 2x DDR4 hat Takt x 2 (DDR) x 2 (2 Channels) x 8B = Takt x 32B Bandbreite, IF läuft mit dem selben Takt und hat auch Takt x 32B Bandbreite.
Das Ganze ist natürlich wenig sinnvoll wenn man nur eine winzige 25mm² GPU integrieren will, aber wenn AMD wie bei Raven Ridge 100mm² investieren will, dann lohnt es sich schon darüber nachzudenken stattdessen auf den Polaris 11/12 Nachfolger ein IFOP draufzusetzen und bei APUs den GDDR Controller sinnlos mitzuschleppen bzw. bei GPUs IFOP, anstatt einen komplett neuen Die aufzulegen.

2. GF ist nicht einfach nur im Winterschlaf. Die sind raus. Aus und vorbei. Die haben jetzt 8 Jahre lange keinen leading edge process mehr so abgeliefert und zu der Zeit wie angekündigt und seit 5 Jahren gar keinen eigenen leading edge process mehr selbst entwickelt. 20nm wurde gestrichen, 14nm wurde gestrichen und dann 14LPP von Samsung lizenziert, 14HP kommt von IBM, 12LP ist auch nur 14LPP+ mit kleineren Libs, 10nm wurde gestrichen, 7nm wurde jetzt auch gestrichen. Die tauchen nicht 2020 aus der Versenkung auf und haben plötzlich einen guten 5nm Prozess.
Die haben einfach die Entscheidung getroffen, dass es sich nicht lohnt. Die Kosten steigen mit jedem Node, da braucht man einfach die Stückzahlen, selbst wenn alles funktioniert. IBM hat an GF verkauft weil sie diese Stückzahlen nicht mehr hatten. Aber anscheinend reicht das auch nicht mehr oder die Anforderungen von IBM, AMD und den restlichen Kunden gehen zu weit auseinander und für getrennte Prozesse reichen die Stückzahlen wieder nicht. Das ist nicht fürchterlich überraschend. UMC hat sich auch bei 14nm verabschiedet. Toshiba/NEC sind nur bis 32nm, Fujitsu und TI sind bei 45nm raus.
Rein aufgrund der Größe war GF der nächste Kandidat, IBM hat das leider nicht verzögern können. AMD und IBM hätten ohne diese Pseudo Nodes eher Half-Nodes sind gut leben können und wären mit 14nm -> 14+ (aka 12nm) -> 7nm (eigentlich nur ein Node, nicht 2 Unterschied) -> 7+ mit EUV -> 5/3nm (wie auch immer es deine genannt worden wäre) -> 5+/4/3+/2,5 (was auch immer) -> usw
zufrieden gewesen, aber es funktioniert wohl trotzdem nicht. Ob das Problem jetzt auf technischer oder finanzieller Seite liegt ist egal. Fakt ist, dass GF kein Geld in die Forschung wirft, wenn dabei aus Unvermögen oder aus finanzieller Unmöglichkeit nie wieder Profit rauskommt.
Nein, die kommen nicht einfach irgendwann nach. Alle die schon vorher das Handtuch geworfen haben kommen auch nicht mehr. UMC war bei 14nm etwas spät dran, aber die haben auch angekündigt nicht mehr auf gehen 10/7nm zu wollen. Der Rest den ich aufgezählt habe, hat in den letzten Jahren auch nichts mehr gemacht. Die produzieren fröhlich weiter mit 45nm und das was 20/16/12/10/7nm braucht oder wo es sich lohnt wird bei TSMC bestellt. GF bastelt vielleicht an 12+ ansonsten gibts viele tolle neue SOI-, RF- und was sonst noch alles- Prozesse im Bereich 16-30nm, aber bei 7nm gibts für sie nichts mehr zu holen.

[Brillus]

Zwei Klarstellungen:
1. Eine GPU auf dem I/O Die ist wenig sinnvoll. Dann schleppt man die größte GPU mit auch auf SKUs die gar keine haben oder man braucht mehrere I/O Dies die sich nur in der GPU unterscheiden. Außerdem ist der I/O Die bei Rome 14nm weil 7nm für I/O nichts bringt, aber für GPUs bringt es sehr viel. GPUs auf 14nm verschwendet Strom, mehrere I/O Dies mit 100mm² I/O und <50mm² GPU auf 7nm statt 14nm sind der Höhepunkt der Geldverschwendung.


Wie ich schon oben geschrieben habe sehe ich das ganz anders. Eine minimal GPU im IO-Teil fände ich sehr sinnvoll (also 1-2CU). Ansich ist es genau das was AMD für OEM Geschäfte im gehobenen Bereich fehlt. Für Office reicht es schon und für Highend Laptops kann man dann auch 8-16 Kern CPUs anbieten mit Optimus ähnlichem Support. Das Ding soll Desktop hinbekommen(das ja auch schon 3D-beschleunigt ist) und für den Rest gibt es entweder einen GPU chiplet oder gleich eine dedizierte GPU.

[w0mbat]

Rome is exactly what we said it was in July, a monster with nine die, eight 8C CCXs on 7nm, and one IOX built on 14nm.
https://semiaccurate.com/2018/11/09/amds-rome-is-indeed-a-monster/

Charlie meint zu wissen, dass es 8C CCX sind.

[Locuza]

Charlie weiß es laut Tweeter-Feed nicht:

2ccx per die. Each Ccx is 4C
Are you sure about that? I asked directly and was told AMD would not answer it until the full technical disclosure. I am assuming it is one CCX per... umm... CCX.
I am willing to bet they simply just upped the core count per cluster from 4 to 8 and called it good. I didn't get a chance to ask why Zeppelin was 2x4 but I am assuming the added time to work on it allowed a 1x8 setup.
https://twitter.com/dylan522p/status/1060348124689059841

[reaperrr]

https://semiaccurate.com/2018/11/09/amds-rome-is-indeed-a-monster/

Charlie meint zu wissen, dass es 8C CCX sind.
Oder bringt Begrifflichkeiten durcheinander, kommt bei ihm gelegentlich vor (das ist jetzt übrigens nicht als Bashing gemeint, er hat mMn öfter Recht und v.a. öfter als erster Infos gebracht die sich später als richtig herausgestellt haben, als ihm in Forendiskussionen oft zugestanden wird).

[Langlay]

Also ich glaube nicht daran, das wir CCX mit mehr als 4 Kernen sehen werden. Ich glaube ein CCX mit 4 Kernen ist eine der grundsätzlichen Designentscheidungen die wir auch in den kommenden Generationen immer wieder sehen werden.

[CompuJoe]

Ich glaube ein Chiplet = ein CCX, also 8 Kerne. Würde allein schon von der Fläche her Sinn machen, vergleicht die Größe eines Zeppelin mit den Chiplet minus IO in 7nm.
Wenn ein Die 2 CCX hätte währe die Form wohl wieder eher rechteckig. Die haben die CCX auf 8 aufgebohrt.
Das hat mich auch auf die Idee gebracht das wir auf AM4 evtl. doch sowas wie einen monolithischen Die sehen könnten, 2 x 8 Core CCX und dazwischen der IO-bereich.

[gravitationsfeld]

wieso hat man C-ray als Benchmark genommen? der passt praktisch in den L1
Da muss die Szene die gerendert wird aber schon unglaublich primitiv sein. Sind das nur paar Kugeln?

[YfOrU]

Zwei Klarstellungen:
Eine GPU auf dem I/O Die ist wenig sinnvoll. Dann schleppt man die größte GPU mit auch auf SKUs die gar keine haben oder man braucht mehrere I/O Dies die sich nur in der GPU unterscheiden. Außerdem ist der I/O Die bei Rome 14nm weil 7nm für I/O nichts bringt, aber für GPUs bringt es sehr viel. GPUs auf 14nm verschwendet Strom, mehrere I/O Dies mit 100mm² I/O und <50mm² GPU auf 7nm statt 14nm sind der Höhepunkt der Geldverschwendung.

Schau dir Intels Portfolio an. Die Chips welche sowohl für Mobile als auch Desktop und Entry Server/Workstation verwendet werden haben praktisch alle die gleiche kleine IGP mit 24 EUs. Die fetteren IGPs (48 EUs mit eDRAM bzw. Vega M on Package) gibt es dagegen nur als BGA für Mobile/SFF etc.

Wenn das nicht wirtschaftlich wäre und nicht den Anforderungen des Marktes entspräche würde man es bei den exorbitant hohen Stückzahlen welche Intel absetzt kaum so umsetzen

Natürlich wäre 7nm (I/O) mit integrierter IGP grundsätzlich von Vorteil aber mit Blick auf die Kosten und die notwendige Performance reicht sicherlich auch 14nm. Das hat früher (IGP im Chipset/NB mit einem älteren Prozess) auch funktioniert. Ein Chip mit kleiner IGP wäre meiner Ansicht nach absolut ausreichend.

Im Format von Raven Ridge wäre natürlich viel zu viel. Proportional betrachtet hat es AMD hier aber eh schon etwas übertrieben. Ich denk auch nicht das AMD das beim Nachfolger (APU) wieder macht sondern zur Skalierung optional eine potentere dGPU (wie bei KBL-G) mit aufs Package setzt. Die fetten IGPs sind nicht nur teuer (Die Size) sondern auch im Kontext des Powermanagements problematisch. Eigentlich ist filigranes Powergating notwendig und das kostet zusätzlich. Eine proportional (14 - 7nm) moderatere IGP und bei Bedarf eine abschaltbare GPU (mit dediziertem Speicher) on Package ist da grundsätzlich ein ganz guter Mittelweg.

[AlterSack]

Ich glaube ein Chiplet = ein CCX, also 8 Kerne. Würde allein schon von der Fläche her Sinn machen, vergleicht die Größe eines Zeppelin mit den Chiplet minus IO in 7nm.
Wenn ein Die 2 CCX hätte währe die Form wohl wieder eher rechteckig. Die haben die CCX auf 8 aufgebohrt.
Das hat mich auch auf die Idee gebracht das wir auf AM4 evtl. doch sowas wie einen monolithischen Die sehen könnten, 2 x 8 Core CCX und dazwischen der IO-bereich.

An 2x8Core-CCX glaub ich nicht. ...zumindest nicht wenn es bei AM4 bleibt.
Macht für mich keinen Sinn an einem DDR4-Zweikanal-SI.
Wenn Chiplet, dann 2X4Core-CCX+SI oder 3x4Core-CCX+ 3Kanal-SI auf AM5.
Wobei sinnvoll für Mainstream-Desktop, auch finanziell, wären für mich
2x4 Kerne wie gehabt und ohne MCM.

[Skysnake]

Wäre bei Epyc 1 im Prinzip auch gegangen (AMD hat die Möglichkeit, chipsatzlose Boards zu bauen bei der Vorstellung von Epyc meiner Erinnerung nach sogar beworben). Nur wenn man alle 128 Lanes für GPUs benutzt, wie bindet man z.B. lokalen Storage und die Kommunikation nach außen, also z.B. Ethernet an? Über USB? Deswegen bieten die Systeme heute maximal 7 volle x16 Slots (112 Lanes), weil man eben ein paar Lanes für Ethernet, SATA, U2 oder Ahnliches abzweigen muß, auch ohne Chipsatz. Das wird sich wohl kaum ändern.

Das ändert sich wohl auch bei Rome. Man ist dem aber ausgewichen

[spotz]

MCM mit GPU ist an sich kein Problem (siehe KBL-G), das einzige Problem das man lösen muss ist der Speicher. Hat die GPU eigenen Speicher braucht man nur PCIe, wenn nicht braucht man Kohärenz, aber mit IF sollte das gehen. Ein IFOP Link ist recht klein, das auf eine GPU zu packen ist nicht gerade teuer. Die Bandbreite reicht per Definition aus, 2x DDR4 hat Takt x 2 (DDR) x 2 (2 Channels) x 8B = Takt x 32B Bandbreite, IF läuft mit dem selben Takt und hat auch Takt x 32B Bandbreite.
Das Ganze ist natürlich wenig sinnvoll wenn man nur eine winzige 25mm² GPU integrieren will, aber wenn AMD wie bei Raven Ridge 100mm² investieren will, dann lohnt es sich schon darüber nachzudenken stattdessen auf den Polaris 11/12 Nachfolger ein IFOP draufzusetzen und bei APUs den GDDR Controller sinnlos mitzuschleppen bzw. bei GPUs IFOP, anstatt einen komplett neuen Die aufzulegen.
Ließe sich das mit dem IFOP Link auch machen wenn der I/O Cip statt DDR4 beispielsweise HBM Speicher unterstützt? Ich könnte mir vorstellen das die höhere Bandbreite von HBM bei größeren GPUs sinnvoll ist.

[iuno]

Ich denke falls man eine APU mit HBM sieht wuerde der Speicher direkt an die GPU angebunden, wie bisher auch. Dafuer braucht man eh einen SI-Interposer (oder EMIB, was AMD nicht hat). Von dort dann per IF oder PCIe zum I/O Chip weiter. Wenn die ganze Bandbreite des HBM ueber IF geschickt werden muesste haette man sich ja durch den HBM eh wieder nichts gespart?

Ist eigentlich schon absehbar dass/ob man HBM mal noch direkt auf einen Chip (I/O die, GPU, APU, was auch immer) oben drauf bekommt? Oder sind die Nachteile zu gross, dafuer dass man sich den interposer spart?

[Setsul]

@Brillus/YfOrU:
Intel GPUs sind jetzt nicht gerade das Paradebeispiel der Wirtschaftlichkeit bei dem Flächenverbrauch.

Natürlich sollte AMD versuchen den Teil des Markts wo Intel auf GT2 sitzt abzudecken, aber ich denke nicht, dass 1-2 CUs auf dem I/O Die dafür der richtige Weg sind. 2 CUs kämen vielleicht gerade so auf ähnliche Leistung, 1 CU definitiv nicht und was hat man dann als Verkaufsargument? Wir haben IGP mit noch schlechterer Leistung als Intel? Also 3 CUs dürften es schon sein, das ist dann etwas schneller als GT2 und kostet immernoch nicht so viel.
Das nächste Problem ist dass AMD anders skaliert. Intel kann GT2, GT3 und GT4 mit 1, 2 und 3 Slices machen und GT1 und GT1.5 mit einer gestützten Slice. AMD würde eigentlich gerne 2 oder 4 Shader Engines mit 2-4 CU/ROP Blöcken zu je 2-4 CUs (am besten 3 oder 4) und 4 ROPs (fix) haben. Eine Shader Engine mit einem ROP Block und 3-4 CUs ist schon ungünstig genug weil Display Engine und Hardware decoding/encoding usw. einfach Fixkosten sind GCP und SE so weit runter nicht mehr gut skalieren, aber das auf 1-2 CUs zu kürzen ist komplett sinnlos. Der ROP Block wird nicht für eine winzige iGPU umdesignt und der ganze andere Overhead bleibt auch. Das ganze Ding hat ~50mm² oder so und nur die CUs zu entfernen bringt dann 5mm², kostet aber die Hälfte der Leistung. Das ist einfach sinnlos.
Lieber gleich 2 Blöcke und 6-8 CUs, den 15mm² trauert keiner nach und dafür deckt es den gesamten Leistungsbereich von etwas über GT2 (über Salvage mit 3-4 CUs) bis GT4 (8 CUs und guter Takt) ab.

Eben genau weil Intel diese exorbitant hohen Stückzahlen und die Ressourcen hat, können sie es sich leisten für alles einzelne Dies zu machen. 2+2, 2+3, 4+2 und 4+3/4, für jede Generation. Wenn AMD 1-4 CUs auf den I/O setzt und den Rest mit dGPU auf Package macht, dann müssten sie den Bereich von GT3-GT4, was ungefähr 6-10 CUs entspricht, mit dGPUs + Speicher abdecken, was fürchterlich teuer ist, oder noch einen Die auflegen. Das ist aber genau der Bereich den RR abdeckt. Wieso sollte AMD sich verrenken um 8C + schleche iGPU zu liefern, wenn sie auch 8C + gute iGPU liefern könnten, was Intel nicht hat? 8C + GT2 Performance ist auch ziemlich sinnlos für Laptops, bei den Preise die Intel für 6C/8C mobile will leistet man sich dann einfach eine dGPU, aber 8C + GT4+ ist interessant. Ich würde also erwarten dass AMD entweder eine 6C/8C APU baut mit 10+ CUs oder IF auf den nächsten kleinen GPU Die für 50-100$ OEM Markt mit 10-16 CUs (P12 Nachfolger) IF packt um das gleiche zu erreichen und dann so wie jetzt auch schon nur im Low End 3-4 CUs anbietet und den Rest des Desktops mit mittelmäßigen Salvage iGPUs (~8 CUs) abdeckt, anstatt Intels Spiel der schlechten iGPUs mitzuspielen, und die guten und kompletten iGPUs landen bei Mobile oder im Falle des separaten Chips eben in GPUs.

Dann noch ein letztes Problem: 7nm ist Verschwendung für den I/O Die, besonders wenn die GPU klein sein soll und nur einen Bruchteil ausmacht.
Aber bei 14nm stellt sich die Frage welche Architektur? Entweder bleibt man auf ewig bei Polaris/Vega oder man darf Navi und Nachfolger immer wieder auf 14nm porten. Das kostet sicherlich mehr als komplexeres Powergating.

Also zusammengefasst kann man sagen, es ist für AMD einfach unangemessen schwer und teuer eine iGPU zu produzieren die genauso schlecht ist wie GT2. GT4 Performance und besser ist nur minimal teurer, also wieso nicht ein deutlich besseres Produkt liefern und den Verschnitt nutzen um mit GT2 zu konkurrieren?

Für die kleinen Mobile Chips und Entry Level Desktop ist eine kleine APU sinnvoll, aber wir reden hier von den 8C Chiplets. Wer das in ein Notebook baut will auch akzeptable GPU Leistung, nicht GT2, aber dGPU + Speicher on Package treibt die Kosten viel zu sehr. Wenn sowieso eine große APU existiert, ob jetzt monolithisch oder MCM, dann ist es sinnvoller für Workstation/Entry Server/HEDT davon Salvage SKUs zu nehmen und die 30-50mm² für mehr CUs als nötig einfach von der Marge absorbieren zu lassen als bei den ganzen vergleichsweise billigen Desktop CPUs 50mm² extra zu haben für eine 3 CU iGPU die 80% der Leute sowieso nicht interessiert.

@spotz/iuno:
Wenn die GPU HBM hat (und entspreched das HBM Interface auf der GPU ist) dann ist das ihr eigener Speicher und man braucht kein IF. Die CPU pfuscht nicht im HBM und die GPU hat kein Interesse am DDR4 mit der vergleichsweise mickrigen Bandbreite. Das ist dann wie bei KBL-G, einfach PCIe von CPU zu GPU, nur eben on Package, das unterstützt jede CPU die PCIe hat.

HBM an den I/O Die anzuschließen ist ziemlich sinnlos weil man die Bandbreite eben nur über kurze Entfernungen und per Interposer erreicht. Die CPU hat wenig Interesse an der Bandbreite weil die Latenz zu schlecht ist und der I/O Die selbst will sowieso nichts. Wenn man die GPU über Interposer mit dem I/O Die verbindet um die Bandbreite zu erreichen und die CPU nichts vom HBM wissen will, dann kann man das HBM Interface auch gleich auf die GPU setzen.

@iuno:
Abgesehen von den TSVs im CPU/GPU die, was sehr ekelhaft ist, wird die Kühlung dann unangenehm. Anstatt einer glatten Oberfläche hat man dann 1 oder 2 HBM Stacks oben drauf kleben. Also man hat neue Probleme und die Probleme die man vorher schon hatte (TSVs) werden jetzt noch viel schlimmer weil sie in einem teureren Chip sind. Kosten sind beim Interposer absolut kein Problem, die Nachteile sind TSVs und Größe. Das wird man beides mit EMIB los, also kein Grund zu stapeln.

[Naitsabes]

[...] Wenn die ganze Bandbreite des HBM ueber IF geschickt werden muesste haette man sich ja durch den HBM eh wieder nichts gespart?
[...]




Ist der Speichercontroller bei Vega intern nicht auch über IF angebunden?

[iuno]

Ist der Speichercontroller bei Vega intern nicht auch über IF angebunden?
Es ist ein Unterschied, ob man on-die ist oder doch wieder uebers package muss. "IF" ist ja nur der Ueberbegriff

@Setsul: danke fuer die Antwort. Leider ist EMIB halt eine Intel-Technik ;)

[Naitsabes]

Das stimmt natürlich.

Reine Spekulation: Man könnte GPU-Chiplet, CPU-Chiplet und IO-Die + einen BHM-Stack auf einen Interposer packen. Ist natürlich aufwendiger als die Serverlösung, aber geringe Latenzen und höhere Bandbreit nötig. Der HBM könnte dann quasi wie der L4 bei Skylake (nicht Broadwell!) wirken. Bringt der CPU zwar nicht viel (wenn überhaupt), aber der GPU.

Jedenfalls wäre das ein Chip, den ich gerne für meinen mITX-Rechner hätte. Kaby G gibt es ja leider nicht gesockelt (wie auch...) und mir würde HBCC fehlen...

[mboeller]

ich glaube nicht, dass es sich für AMD lohnt eine APU/CPU mit einen IOX mit iGPU zu fertigen.

https://en.wikichip.org/wiki/amd/ryzen_5/2400g

-> laut dem Bild auf der Webseite macht das CCX gerade mal 20% der Die-Fläche aus.

Ein IOX mit iGPU wäre also in 14nm min. 170mm² groß (die IF-Links kommen noch dazu). Die paar mm² die man einspart wenn die GPU nur 3CU statt 11CU besitzt ändern auch nicht viel (nur ca. 30mm² Unterschied in der die-area für die 8CU alleine). Display-Engine, Multimedia-Engine etc... bleiben ja alle gleich wenn eine iGPU im IOX sind.

[Setsul]

@iuno:
Ja, aber momentan ist es auch noch kein so großes Problem. TSVs hat man einigermaßen im Griff und die Größe ist noch machbar. Wenn man mal öfter 4000mm² an Chips verbinden will, dann werden sicher auch andere ähnliches oder Interposer mit mehrfacher reticle size anbieten. Bis jetzt lohnt sich der Aufwand nicht.

@Naitsabes:
Die Frage ist natürlich wie viel ein Interposer für die Latenz bringt. Der Unterschied in der Entfernung dürfte unmerklich sein. RC delay sollte bei dünneren Leistungen (1/R ~ d^2) auch nicht besser werden.

[basix]

Für die APU denke ich, dass es ein monolithisches Die wird mit 8C + ca. 12 CU. Das sollte flächenmässig deutlich kleiner ausfallen als RR, sagen wir mal max. 150mm2. Grösser wäre wirtschaftlich unvorteilhaft. Mehr Kerne sind gut für TAM (inkl. Desktop) und die iGPU noch grösser zu machen ist zumindest für Mobile komplett unnötig (Bandbreitenlimit, Power Limit). Mit HBM / DDR5 kann man die iGPU dann wieder ein wenig aufbohren.

[Windi]

Ist der GloFo 14nm Prozess nicht dafür da, um verschwendet zu werden? :freak: ;D

Ich mein bei den ZEN Chips wird doch Platz ohne Ende "verschwendet".
Da steckt USB, Sata und PCIe für die SSD drin, das auch in den Chipsatz gepasst hätte.
Manch einer braucht es, ein anderer nicht.
Und wenn ich mir einen 8 Kerner kaufen will, ist dort auch alles für Epyc mit integriert.
Wenn ich einen 4 Kerner haben will, dann bekomme ich entweder solch einen 8 Kerner, bei dem zusätzlich die Hälfte der Kerne auch noch einmal deaktiviert wurden. Oder einen Raven Ridge, bei dem der komplette Grafikteil deaktiviert wurde, was auch wieder eine riesige Fläche ist.

Jetzt kommt auch noch der Athlon, der massiv kastriert wurde.
Und der kostet gerade einmal 50€. Wenn man dort Steuern, Zölle und Händlermarge abzieht, dann bekommt AMD davon vielleicht 30€.

AMD ist anscheinend dazu bereit bei manchen Modellen fast 80mm² zu opfern, nur um nicht zu viele unterschiedliche Masken zu haben. Und diese Modelle sind eher im niedrigeren Preissegment angesiedelt, wo sich dies voll auf die Marge durchschlägt. Zen2 ist hingegen erst einmal für die teureren Produkte, wo das nicht ganz so drastisch ist.

Ich würde die Display und Multimedia Engine mal zusammen auf 20mm² schätzen. Dazu kommt dann noch ein Vega 3. Dessen größe kann ich jetzt nicht so gut abschätzen, da neben den CUs ja noch weitere Dinge mit dazu gehören. Sagen wir mal, das sind 30mm² (Vega 3 war ja eh schon für Banded Kestrel geplant, das sollte also eigentlich machbar sein) (Und vielleicht kommt Banded Kestrel ja noch)
Das wären zusammen 50mm². Weniger als das, was AMD heute bei manchen Modellen verschwendet.
Dafür hat man dann eine integierte GPU, die sicherlich viele interessieren dürfte.
Im Büro ist es häufig nur wichtig, das Windows, Exel und Friefox flüssig laufen, sei es nun bei einem 4 oder 16 Kerner.
Viele würden sich auch über eine Notfall GPU freuen.

Und wenn doch mehr Grafikleistung gefragt ist, dann packt man halt ein weiteres Chiplet dazu. Die Display und Multimedia Engine kann man wahrscheinlich weiter gebrauchen, den kleinen Vega 3 müßte man wohl deaktivieren.

Die Sache ist halt, das AMD beim GloFo 14nm Prozess nicht unbedingt sparen muss.
Zum einen muss der Chip eine bestimmt Größe erreichen, damit man alle Kontakte nach außen führen kann. Zum anderen muss man eh eine bestimmte Menge Wafer abnehmen. Nur weil die Chips kleiner werden, liefert GloFo nicht weniger Wafer.
Auch hat man dadurch die Möglichkeit APUs anzubieten, ohne das man immer 2 Chiplets braucht.
Das heißt, das jeder Transistor den man in 7nm bei TSCM produziert zusätzlich Geld kostet.
Bei GloFo gibt es sie hingegen fast geschenkt.

[Gipsel]

Das ändert sich wohl auch bei Rome. Man ist dem aber ausgewichen
Was soll sich da ändern? Ist doch der gleiche Sockel. Oder meinst Du, da wären noch ein paar Pins frei, die man mit neuen Boards entsprechend mit ein paar zusätzlichen Lanes (über 128 hinaus) belegen kann? Also Epyc2 kommt im "SP3v2", ist kompatibel mit alten SP3-Boards, kann aber in neuen Boards ein wenig mehr Konnektivität nach außen führen? Klingt jetzt für mich auf Anhieb nicht unmöglich, aber auch nicht umwerfend wahrscheinlich.

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

Das ist dann wie bei KBL-G, einfach PCIe von CPU zu GPU, nur eben on Package, das unterstützt jede CPU die PCIe hat.PCIe on package macht man vielleicht bei Kabylake-G, wo man mit einem intel-Chip kommunizieren muß. Aber das ist eigentlich eine recht ineffiziente Lösung, wenn man beide Komponenten selber produziert. Es wäre deutlich energie- und flächeneffizienter, wenn man z.B. so einen GMI/IFOP-Link benutzt. Sehr viel kleiner und verbraucht deutlich weniger Energie für die Datenübertragung (und schneller ist es im Zweifelsfall auch noch [sogar schneller als PCIe4]).

[Eldoran]

Es wäre deutlich energie- und flächeneffizienter, wenn man z.B. so einen GMI/IFOP-Link benutzt. Sehr viel kleiner und verbraucht deutlich weniger Energie für die Datenübertragung (und schneller ist es im Zweifelsfall auch noch [sogar schneller als PCIe4]).
Das wäre der wichtigste Punkt dabei. GPUs hängen ja ziemlich an der Speicherbandbreite, somit würde der Link quasi die meiste Zeit am Limit laufen, was auch Energie kostet. 5-10W extra kann man sich etwa bei Laptops kaum erlauben.

[Setsul]

@Windi:
Eher die Hälfte, also 15, nicht 30mm² für 3 CUs. Also wieso 50mm² verschwenden und damit gerade so mit Intel schritthalten wenn man für 80mm² fast den gesamten Markt adressieren kann? Es spart eine Maske.

WSA dürfte sich gewaltig verändern, GF kann nicht Bedingungen aushandeln zu denen sie 7nm entwickeln und dann einfach nicht liefern.

@Gipsel:
Bandbreite ist bei einer externen GPU mit eigenem Speicher nicht wirklich ein Problem.
Das Wichtige ist, dass sobald man der GPU eigenen Speicher gibt, egal ob HBM oder GDDR, Kompatibilität vollkommen egal ist. Die GPU hat garantiert ein Speicherinterface, also braucht man nicht einen speziellen I/O Die mit HBM/GDDR. Die GPU braucht kein IFOP, weil PCIe immer funktioniert. Wenn die GPU zufälligerweise IFOP/GMI hat, dann ist das toll (sieht natürlich dann nicht mehr wie eine normale dGPU aus, also bisschen mehr Aufwand für Treiber), aber es lohnt sich auf jeden Fall nicht einen anderen I/O Die oder eine andere GPU (oder beides) zu entwickeln, eben weil AMD beide selbst produziert. Keiner würde für die Sonderanfertigung bezahlen, also nimmt man was schon da ist.

[Skysnake]

Ja genau das Gipsel

[Gipsel]

Das wäre der wichtigste Punkt dabei. GPUs hängen ja ziemlich an der Speicherbandbreite, somit würde der Link quasi die meiste Zeit am Limit laufen, was auch Energie kostet. 5-10W extra kann man sich etwa bei Laptops kaum erlauben.Das bezog sich ja auf ein Setup ähnlich Kabylake-G, bei dem VRAM direkt am GPU-Die hängt.
Ein recht breitbandiger und sogar (wahlweise) kohärenter Link zur GPU kann aber sehr helfen, wenn HBCC und ähnliche Sachen ins Spiel kommen, CPU und GPU also auf einen virtuell einheitlichen Speicher (deren Teile nur unterschiedliche Performancecharakteristik besitzt) zugreifen können.

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

Bandbreite ist bei einer externen GPU mit eigenem Speicher nicht wirklich ein Problem.Siehe oben mit dem gemeinsamen Speicherpool.
Und als Hauptvorteil habe ich den deutlich geringeren Flächenbedarf der GMI/IFOP-PHYs (nur 20% oder so im Vergleich zu PCIe x16) auf dem Die und auch den geringeren Stromverbrauch für die Datenübertragung (2 pJ/Bit vs >10 pJ/bit für die IFOP-Version von Zen1 vs PCIe 3.0) genannt.
Das Wichtige ist, dass sobald man der GPU eigenen Speicher gibt, egal ob HBM oder GDDR, Kompatibilität vollkommen egal ist. Die GPU hat garantiert ein Speicherinterface, also braucht man nicht einen speziellen I/O Die mit HBM/GDDR.Na daß eine größere GPU das Speicherinterface direkt integriert und das dann nicht am IO-Die hängt, versteht sich ja von selbst.
Die GPU braucht kein IFOP, weil PCIe immer funktioniert. Wenn die GPU zufälligerweise IFOP/GMI hat, dann ist das toll (sieht natürlich dann nicht mehr wie eine normale dGPU aus, also bisschen mehr Aufwand für Treiber), aber es lohnt sich auf jeden Fall nicht einen anderen I/O Die oder eine andere GPU (oder beides) zu entwickeln, eben weil AMD beide selbst produziert. Keiner würde für die Sonderanfertigung bezahlen, also nimmt man was schon da ist.
Falls der IO-Die für den Desktop zwei IFOP/GMI Ports hat (der IO-Die von Rome geviertelt hätte zwei), könnte AMD entscheiden, ob man da zwei 8 Core CPU-Chiplets dranhängt (für bis zu 16 Kerne auf AM4) oder 1 CPU-Chiplet + 1 GPU-Chiplet für eine APU. Da wird es interessant zu sehen sein, ob man wirklich das IO-Die, ein CPU-Chiplet und noch ein GPU-Chiplet+HBM für eine relativ High-End-Lösung draufgequetscht bekommt oder nicht. Und ob AMD entscheidet, dafür einen extra GPU-Die aufzulegen (weil der sich dann schlecht in einer diskreten GPU recyclen läßt, außer Navi zerlegt die GPUs auch irgendwie in Chiplets). Keine Ahnung ob der Markt das hergeben würde. Falls es ein Apple-Designwin dafür geben würde, vielleicht. Wäre wohl sowieso erst was für 2020 oder so.

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

Ja genau das Gipsel
Sicher? Hat irgendwer mal die Belegung vom SP3 gesehen? Wieviele Kontakte sind denn da noch frei?

[Oddzz]

Ich glaube ein Chiplet = ein CCX, also 8 Kerne. Würde allein schon von der Fläche her Sinn machen, vergleicht die Größe eines Zeppelin mit den Chiplet minus IO in 7nm.
Wenn ein Die 2 CCX hätte währe die Form wohl wieder eher rechteckig. Die haben die CCX auf 8 aufgebohrt.

Dieses Interview (https://youtu.be/Q2XuZ0UQUfM?t=2545) mit David Bounds von AMD scheint deine Vermutung zu bekräftigen. Hier spricht er davon, daß der 7nm-Teil in Zen2 CCD (Compute Dies) genannt werden und man somit vom CCX Design Abschied nimmt (meine Interpretation). Ist zwar keine Bestätigung deiner Theorie, passt aber zum Puzzle.

[iuno]

Und ob AMD entscheidet, dafür einen extra GPU-Die aufzulegen (weil der sich dann schlecht in einer diskreten GPU recyclen läßt, außer Navi zerlegt die GPUs auch irgendwie in Chiplets).
Wieso? Die GPU braeuchte halt beide Interfaces. Es gab aber auch schon APUs mit DDR und GDDR-kompatiblen Speichercontrollern. Man wird sicher etwas mehr Flaeche verbrauchen, braucht dafuer aber nicht extra einen neuen Chip.
Also je nachdem wie der Ausbau ist IF fuer die APU, die keinen HBM hat + GDDR Interface fuer Verwendung als dGPU bzw., falls HBM dabei ist, IF+PCIe fuer die Anbindung der GPU.

[Skysnake]

Sicher? Hat irgendwer mal die Belegung vom SP3 gesehen? Wieviele Kontakte sind denn da noch frei?

Die von AMD meinten auf der ISC bei meiner Frage nach den extra pcie lanes für Chipsatz plus 128 pcie lanes ich s8lle bis ende des Jahres warten. Mehr haben sie dann aber nicht mehr sagen wollen

Kannst dir jetzt selbst überlegen wie man das deuten kann

[Setsul]

@Gipsel:
Es ging um diese Frage:
Ließe sich das mit dem IFOP Link auch machen wenn der I/O Cip statt DDR4 beispielsweise HBM Speicher unterstützt? Ich könnte mir vorstellen das die höhere Bandbreite von HBM bei größeren GPUs sinnvoll ist.
Und die Antwort ist einfach HBM bringt zwar was für die GPU, aber nicht auf dem I/O Chip.
Die CPU wird HBM nicht nutzen wegen der Latenz und die GPU wird DDR4 nicht mehr nutzen wegen der Bandbreite, außer man will völlig neue Wege gehen beim Memory Management, also kann man das auch trennen. HBM Interface auf der GPU ist wesentlich sinnvoller als IF mit derselben Bandbreite auf GPU und I/O Die und HBM Interface auf dem I/O Die. In dem Fall kann man aber auch auf PCIe ausweichen wenn die GPU kein IFOP hat, weil sie jetzt eigenen Speicher hat, also braucht man nur eine beliebige GPU die ein HBM Interface hat. Das auf den I/O Chip zu setzen bringt nichts.
Jetzt klar was ich meine?

Wenn man jetzt extra eine GPU mit HBM auflegen müsste, dann kann man natürlich IFOP dazuwerfen. Aber mal ehrlich, bei 128 GB/s mit HBM1 konnte man noch darüber reden, aber bei >200 GB/s mit HBM2 muss schon eine große GPU dranhängen damit sich das lohnt. Die legt man nicht doppelt auf, da kommt entweder HBM Interface zusätzlich drauf oder sie hat sowieso HBM als dGPU und man verwendet sie eben auch für die MCM-APU.


I/O Die mit 2x IFOP und wahlweise 2x8C oder 8C+GPU hatte ich ja schon vorgeschlagen. 100 mm² I/O + 2x ~70 mm² 8C Chiplet passt bei geringen Abstand gut auf AM4. Polaris 12 Nachfolger, also irgend so ein kleines 50-100$ 10-16 CU GPU Ding, mit IFOP wird kaum größer sein, geht auch.
Aber eine GPU mit HBM? Siehe oben, ich sehe eigentlich keinen Grund HBM1 wieder auszugraben, da bekommt man doch mit 64 bit GDDR5X/GDDR6 mehr Bandbreite. Bei >200 GB/s ist HBM2 aber entweder overkill oder man braucht eine entsprechende GPU. AMD will ja doch mal bessere Bandbreiteneffizienz erreichen, also mit weniger CUs als bei Polaris 10 braucht man eigentlich nicht rechnen. Selbst auf 7nm geht das dann doch auf 200 mm² zu. Mal ganz abgesehen dass das schon sehr knapp wird auf AM4, sehe da keine TDP dafür.
Nur für eine APU eine GPU mit HBM oder HBM + GDDR und IF aufzulegen die mit der Hälfte der Bandbreite zurecht kommt wäre schon eine sehr teure Spielerei.
Da ist es noch wahrscheinlicher, dass sie einen oder zwei Chips GDDR6 dazupacken und mit HBCC über IFOP den Speichermangel kaschieren.

Für Semi-Custom dürfte es natürlich hochinteressant sein. Wenn eine GPU mit einem HBM2 Stack und IFOP existiert, dann dauert das doch gefühlt 5 Minuten um das nächste Console SoC zusammenzustellen. Wenn gewünscht ist und die TDP es erlaubt könnte man sogar eine große GPU mit 2 Stacks dranhängen, sind immerhin auch bis zu 8 Kerne.

[amdfanuwe]

Mal ganz abgesehen dass das schon sehr knapp wird auf AM4, sehe da keine TDP dafür.
Sehe ich auch so.
Für Desktop AM4 macht das keinen Sinn. Da steckt man sich eine Grafikkarte dazu, wenn man mehr GPU braucht als die APU liefert.
Für Notebook ist man nicht an den Formfaktor gebunden und kann ein größeres MCM auflegen.

Für Desktop AM4 haben wir nächstes Jahr erstmal 12nm RavenRidge2018 und für mehr Kerne 7nm CPU Chiplets + I/O.
Wobei ich immer noch der Meinung bin, dass AMD RavenRidge2018 als I/O nutzt ( vorzugsweise Chips mit defekten CPU Kernen ). Das erhöht den Yield für RR18 und man produziert größere Mengen, wodurch dieser recht günstig wird.

Eine reine monolithische 7nm APU dürfte erst Ende 2019/ Anfang 2020 auf dem Programm stehen, womöglich erst mit EUV.

[Gipsel]

@Gipsel:
Es ging um diese Frage:

Und die Antwort ist einfach HBM bringt zwar was für die GPU, aber nicht auf dem I/O Chip.Genau das habe ich ja auch geschrieben. Darüber müssen wir nicht diskutieren.
Wenn man jetzt extra eine GPU mit HBM auflegen müsste, dann kann man natürlich IFOP dazuwerfen.Vielleicht muß man nicht, will aber, weil es Vorteile bietet und einen anderen Markt erschließt (APU mit kräftiger Grafik)?
Aber mal ehrlich, bei 128 GB/s mit HBM1 konnte man noch darüber reden, aber bei >200 GB/s mit HBM2 muss schon eine große GPU dranhängen damit sich das lohnt. Die legt man nicht doppelt auf, da kommt entweder HBM Interface zusätzlich drauf oder sie hat sowieso HBM als dGPU und man verwendet sie eben auch für die MCM-APU.Wie groß muß die denn sein? 256 GB/s sind so grob ab Polaris-Leistung angebracht. Wie groß wäre das denn in 7nm? Nimmt man die 232mm² von Polaris, rupft da alle externen Interfaces raus (PCIe, GDDR5-Interface, Displayausgänge [und 3 der 6 Displayengines]) dann mißt das vielleicht noch 175mm². Der Teil schrumpft dann zu 7nm auf etwas weniger als die Hälfte, sagen wir mal 85mm². Da packen wir dann wieder 3 Displayausgänge dazu (~2,5mm²), dazu ein 1024bit HBM2-PHY (~11mm² bei Vega) und ein GMI/IFOP-PHY (~1mm² beim Zeppelin-Die) und landen immer noch knapp unter 100mm² bei der Milchmädchenrechnung*. Wird also nicht wirklich viel größer als eine Zen2-8C-Die (groben Schätzungen zufolge ja ~80mm²). HBM2 vs. GDDR5 spart alleine schon bestimmt an die 20W, und wenn man das Teil nicht viel höher taktet als Polaris10 (also sagen wir mal ~1,3Ghz), kann man voll die 50% Effizienzsteigerung von 7nm mitnehmen, womit dann die GPU im Peak vermutlich maximal 70W oder so verbrät (was für eine APU mit 105W TDP völlig okay wäre und auch unter Last noch genügend Saft für die CPU-Kerne übrig läßt).
Da ist natürlich jede Menge Raum für weitere Änderungen über einen beinahe dummen Shrink von Polaris hinaus, was sich dann auf Takt und Stromverbrauch sowie Diesize auswirken kann, insbesondere wenn man z.B. erst Anfang 2020 dafür anpeilt. Aber es zeigt, daß das durchaus gehen würde.
I/O Die mit 2x IFOP und wahlweise 2x8C oder 8C+GPU hatte ich ja schon vorgeschlagen. 100 mm² I/O + 2x ~70 mm² 8C Chiplet passt bei geringen Abstand gut auf AM4. Polaris 12 Nachfolger, also irgend so ein kleines 50-100$ 10-16 CU GPU Ding, mit IFOP wird kaum größer sein, geht auch.Polaris 12 ist in 14nm schon nur 101mm². Reiße da PCIe raus, portiere das auf 7nm und das wird bald zu klein (insbesondere ist es für die Bandbreite eines HBM-Interfaces eine zu kleine GPU). Wenn das nur die low-cost Desktoplösung ohne eigenen Speicher werden soll, dann klemmt man da vielleicht sogar eine 10CU 14nm GPU dran. Mehr als 10 sehr moderat getaktete CUs wären dann sowieso Verschwendung, weil das mit der Bandbreite von DDR4 verhungert.
Aber eine GPU mit HBM?Natürlich HBM2.
Bei >200 GB/s ist HBM2 aber entweder overkill oder man braucht eine entsprechende GPU. AMD will ja doch mal bessere Bandbreiteneffizienz erreichen, also mit weniger CUs als bei Polaris 10 braucht man eigentlich nicht rechnen. Selbst auf 7nm geht das dann doch auf 200 mm² zu.Ich hatte ja nicht umsonst mehrfach Kabylake-G als Vergleich angeführt (wo die GPU fast noch etwas klein ist, unter 7nm kann man da natürlich mehr Einheiten reinpacken). Und ohne PCIe und mit einem HBM2-Stack statt GDDR5 wäre Polaris 10 schon in 14nm unter 200mm².;)
Mal ganz abgesehen dass das schon sehr knapp wird auf AM4, sehe da keine TDP dafür.Knapp wird der Platz. TDP reicht locker, wenn man die GPU auf sagen wir mal 1,3GHz limitiert (halber Stromverbrauch gegenüber 14nm und HBM spart ja beim Speicher auch noch was).
Die Polaris10-Karten liefen ja Stock mit etwas über 150W (inklusive Wandlerverlusten und Lüfter, die hier wegfallen), 110W war @stock das Powerlimit des Chips selber. HBM(2) ist deutlich energieeffizienter als GDDR5, das verbraucht nicht soviel. Den Verbrauch des Chips @1,2-1,3GHz halbiert man mit 7nm. Da gehen also locker 1,3GHz innerhalb von 70W inklusive dem HBM. Dann bleiben noch 35W für die CPU-Kerne und den IO-Chip (sollte immer noch für 3GHz allcore bei der CPU langen) bei voller GPU-Last (Powermanagement muß das Budget natürlich vernünftig verteilen). Das Verhältnis ist tendentiell sogar besser als bei heutigen APUs.
Nur für eine APU eine GPU mit HBM oder HBM + GDDR und IF aufzulegen die mit der Hälfte der Bandbreite zurecht kommt wäre schon eine sehr teure Spielerei.HBM+GDDR kommt wohl recht sicher nicht, das wäre wirklich Verschwendung. Aber warum sollte man die GPU-Chiplets nicht genauso wiederverwenden können wie die Core-Chiplets? Gäbe es einen Markt für einen Epyc mit 4 CPU- und 4 GPU-Chiplets? Verkauft man davon nur einige zehntausend Stück für irgendeine Installation, dann hat man die Entwicklungskosten dafür wohl schon wieder drin (angenommener Preis: $5000). Und ich sprach ja beim Zeitrahmen von 2020. Das dürfte dann wohl schon Navi sein.
Da ist es noch wahrscheinlicher, dass sie einen oder zwei Chips GDDR6 dazupacken und mit HBCC über IFOP den Speichermangel kaschieren.Ein HBM2-Stack wird schon platztechnisch eng, GDDR auf dem Package noch eher (weil man mindestens 2 Chips benötigt, um auch nur annähernd in die Nähe der Bandbreite zu kommen).
Für Semi-Custom dürfte es natürlich hochinteressant sein. Wenn eine GPU mit einem HBM2 Stack und IFOP existiert, dann dauert das doch gefühlt 5 Minuten um das nächste Console SoC zusammenzustellen. Wenn gewünscht ist und die TDP es erlaubt könnte man sogar eine große GPU mit 2 Stacks dranhängen, sind immerhin auch bis zu 8 Kerne.Und der nächste Anwendungsfall. Mit der kohärenten und relativ breitbandigen Verbindung über IFOP/GMI kann man auch weiterhin einen gemeinsamen Speicherbereich mit akzeptabler Performance erhalten.
Nachteil wäre natürlich, daß man dann im Zweifelsfall zwei Speicherinterfaces hätte (DDR4 + HBM2 oder GDDR6), was insbesondere bei den Konsolen auch ein Kosten- und Platzfaktor ist (Letzteres bei HBM2 nicht so sehr und wer weiß, wie die Kalkulation bei den momentanen DRAM-Kosten genau ausfällt, wenn man 24+GB reinpacken will, DDR4 ist ja definitiv billiger). Aber auch bei PS4 und XB1 müssen die Entwickler ja noch festlegen, wie von CPU bzw. GPU auf allozierte Speicherbereiche zugegriffen werden kann (wichtig für die Performanceoptimierung). Das Verschieben zwischen den Pools wird dann zwar zu einem echten Verschieben (statt nur Ummappen), aber das sollte im Normalfall noch gehen, wenn die Bandbreite groß genug ist.

* edit:
Crosscheck mit Vega 10 und 20:
Vega 10:
484mm² - 2*11 mm² (HBM) - 5 mm² (Display-Ausgänge) - 7,5mm² (x16 PCIe3) = 449,5mm²
skaliert mit der Transistorzahl (13,2 vs 12,5 Milliarden) würde man auf ~475mm² für Vega20 ohne IO @14nm kommen.

Vega20:
331 mm² - 4*11mm² (HBM) - 5mm² (Display) = 282mm²
Ohne Dieshot läßt sich etwas schwer abschätzen, wieviel die PCIe4 (16GT/s) und xGMI-Interfaces (25GT/s) einnehmen. Kleiner als die PCIe3 PHYs (maximal 8GT/s) werden die wohl aber auf keinen Fall. Nehmen wir mal 9mm² pro x16-Block an.
282mm² - 3*9mm² (x16 PCIe4 + 2* x16 xGMI) = 255mm².

475mm² vs. 255mm² Ist jetzt nicht ganz Faktor 2, aber für den einfachen Ansatz gar nicht mal so schlecht. Immerhin muß bei Vega20 ja auch das on-Die Fabric (was wohl auch schlecht schrumpft) mindestens verdoppelt werden, um mit den Datenraten vom vierfachen HBM2-Interface klarzukommen. Das Problem hätte man ja bei dem kleineren Chip oben nicht.

[iuno]

Um mal von der anderen Seite her zu kommen: Intel verbaut mit VegaM 24 CUs und HBM. AMD wird es sicherlich nicht toll finden, nicht selbst die schnellste APU stellen zu koennen. Dazu kommt, dass Intel ab 2020 eigene GPUs bringen will, ich gehe mal davon aus, dass da dann zuegig Nachfolge fuer KBL-G kommt.

Der HBM muss ja auch nicht zwingend mit maximaler Frequenz laufen. bei KBL-G sind es auch nur 400 MHz. Mit ~32 CUs waere das doch ordentlich. Und sekundaer koennte das Ding z.B. als RX660 P10 abloesen ohne dass man dafuer einen neuen Chip braucht.

[unl34shed]

sollte es nicht auch mal low-cost HBM geben? Würde sich für so etwas anbieten.

[Gipsel]

sollte es nicht auch mal low-cost HBM geben? Würde sich für so etwas anbieten.
Erhöhte Frequenz auf halber Breite (512bit) über high density µBumps auf organischem Interposer mit etwa 200GB/s pro Stack war glaube ich der Plan. Keine Ahnung, wie der Status da ist.

[Ravenhearth]

Vega20:
331 mm² - 4*11mm² (HBM) - 5mm² (Display) = 282mm²
Ohne Dieshot läßt sich etwas schwer abschätzen, wieviel die PCIe4 (16GT/s) und xGMI-Interfaces (25GT/s) einnehmen. Kleiner als die PCIe3 PHYs (maximal 8GT/s) werden die wohl aber auf keinen Fall.
Geht der als Die-Shot durch (https://images.anandtech.com/doci/13562/DavidWang_NextHorizon_06.jpg)? Auch wenn ein paar Flächen "leer" erscheinen, wo aber auf jeden Fall sein was sein müsste (siehe hier (http://www.pcgameshardware.de/screenshots/original/2018/11/AMD-Radeon-Instinct-MI60-Vega-20-6--pcgh.png)).

[Setsul]

@Gipsel:
Meine Rechnung ist etwas weniger optimistisch bei der Größe.
Also erstens würde ich PCIe drinlassen. Es ist wahrscheinlicher, dass eine GPU aus dem normalen Portfolio verwendet wird.
Ich habe auch mit etwas mehr Fixkosten gerechnet, aber kein genaues Pixelzählen, also kann man sich da streiten.
Dann nehme ich an, das die Größe pro CU (inklusive Overhead) eher so aussieht wie bei Vega, vielleicht sogar etwas mehr, und nicht wie bei Polaris. Das wäre sonst ein Rückschritt.
AMD will wie gesagt wohl noch bessere Bandbreiteneffizienz, also wenn das Ziel erreicht wird wäre es zusätzlich noch etwas mehr CUs.
Insgesamt nehme ich dann an, dass eine GPU, die AMD regulär verkaufen würde mit einem Stack HBM2 (dann wahrscheinlich die vollen 256 GB/s oder sogar die neuen Chips mit 300 GB/s), so um die 100-120W TDP inklusive Speicher hat und auf 200 mm² zugeht.
Eine entsprechend runtergetaktete Salvage Version könnte man bei 105W TDP natürlich gerade noch unterbringen, aber was ist der Markt dafür? Die reguläre dGPU wäre auf dem Desktop deutlicher schneller und nicht viel teurer, eine GPU und CPU mit identischer Leistung wahrscheinlich sogar billiger. Für Mobile ist die TDP zu hoch. Abgesehen eben von KBL-G ähnlichen SKUs die CPU + dGPU ersetzen sollen, aber im Gegensatz zu Intel verliert AMD nichts wenn sie stattdessen eine MXM dGPU verkaufen.

Eine APU die nur für den Desktop brauchbar ist (selbst KBL-G hat 65W SKUs), rechtfertigt meiner Meinung nach keinen eigenen GPU Die. Eine GPU bei der 256 GB/s angebracht sind und AMD wird wahrscheinlich wieder hart am Limit fahren, wird meiner Meinung nach zu groß und stromhungrig.
Eine kleinere Sonderanfertigung wie bei KBL-G wo die Bandbreite von HBM eigentlich unnötig ist, aber jemand bereit ist dafür zu zahlen, wäre sinnvoll, aber nur wenn es dafür einen oder mehrere Kunden (z.B. eben Apple) gibt. Von sich aus wird AMD das wohl kaum machen.

Zum Polaris 12 Nachfolger: Ich gehe von einer Low Cost Desktop GPU aus, eben genau sowas wie die 540-550X. PCIe ist drin. Wahrscheinlich 64 bit GDDR6. Etwas höhere Bandbreiteneffizienz und bis dahin auch etwas höhere Bandbreite von GDDR6 und bis zu 16 CUs scheinen sinnvoll. Viel kleinere Chips werden sich auf 7nm wohl nicht mehr lohnen und selbst das könnte ein 14nm Chip werden. Aber ich denke AMD wird irgendeinen Chip in der Größe im Portfolio haben.
RR hat schon 11 CUs. Entsprechend runtergetaktet und nicht die vollen 16 CUs mit etwas höherer Bandbreiteneffizienz wäre wohl das Maximum was mit 2xDDR4 sinnvoll ist. Besonders auf 7nm geht das selbst bei Mobile locker in die TDP. Also der neue Low Cost Desktop GPU Chip kommt auf 7nm und damit bekommt man einen besseren Low Cost Chip, aber hauptsächlich deckt man damit die High-End APUs ab ohne einen großen monolithischen 8C APU die auflegen zu müssen. Das Ding rennt GT4e davon, ganz ohne HBM, und sollte auch entsprechende Preise ermöglichen.

GDDR6 auf dem Package könnte sinnvoll sein, GDDR5 natürlich eher nicht. Mit einem Chip und 60-70 GB/s und vielleicht dem vollen GPU Chip (16 CUs oder was auch immer) könnte man die Leistung im Vergleich zu 12-14 niedrige getakteten CUs + ~40 GB/s vom DDR4 den man sich mit der CPU teilt schon ziemlich pushen.
Ich sehe da weniger ein Problem mit der Größe als mit der Kapazität. 1 GB wäre schon sehr unangenehm und 2 GB sind auch nicht gerade viel. Und dann noch ein ganz anderes Problem: Ich würde keinen IHS auf die Dies löten wollen wenn daneben ein Plastikchip sitzt. Bei BGA Sockeln aber machbar.
HBCC sollte eigentlich mit dem Speichermangel zurecht kommen, aber die ideale Variante wäre so ähnlich wie bei der GTX 970. Man adressiert DDR4 direkt, legt dorthin aber seltener gebrauchte Daten und schiebt weniger herum. Die 1-2 GB aktivsten Daten liegen auf GDDR6. Wenn dabei eine effektive Bandbreite von ~90 GB/s rauskommt kann man eigentlich gut damit leben.
Wenn die GPU auf 7nm ist könnte man den Takt bei Navi CUs voll ausfahren und die Leistung der kleinen KBL-G Vega hochprügeln. Aber das ist alles Zukunftsmusik.
Von Low Cost HBM hat man ja leider nichts mehr gehört, sonst wäre das alles einfach.


Zusammengefasst: Ich denke dGPUs die AMD sowieso mit HBM2 auflegt werden etwas zu groß sein, GPUs die nicht die volle HBM2 Bandbreite brauchen lohnen sich nicht als Sonderanfertigung, wenn nicht Kunden genau das wollen in entsprechenden Mengen, und alles was nicht unbedingt die Platzersparnis braucht lässt sich mit kleineren APUs und dGPUs (MXM für Mobile) locker abdecken ohne Sonderanfertigungen.

Zu Semi-Custom:
Ich hätte für die nächste Generation auch >=16 GB erwartet. Bei einem Stack und 256 GB/s klingt 8+8 nicht schlecht. Aber wahrscheinlich wird gespart und nur 4 GB HBM verbaut, wäre ja nicht das erste Mal. Wenn jemand 400+ GB/s will, dann ist die Frage ob 16 GB nur für die GPU jemals notwendig wären, aber selbst wenn wären die Kosten wohl zu hoch. Wahrscheinlich 8 GB HBM2 + 8-16 GB DDR4. HBCC ist natürlich verlockend, wenn man den Speicher nicht manuell managen will, muss man nicht, Größe angeben reicht.

@Ravenhearth:
Naja das ist immer etwas stilisiert und folgt einer anderen Logik. Die rechteckige Box mit "Infinity Link" drin wird nie kürzer sein als "Infinity Link" in der Schriftgröße die alle anderen Boxen verwenden, egal wie groß das Ding wirklich ist.

[mboeller]

Gäbe es einen Markt für einen Epyc mit 4 CPU- und 4 GPU-Chiplets?

vielleicht?

https://okayiran.github.io/docs/pdf/Routing-ISCA2018.pdf

hat aber nur 1 CPU Chiplet und 4 GPU Chiplets und 8 DRAM Interfaces (Figure2) und schaut für mich deshalb mehr nach einer Konsolen APU aus.

[iuno]

Geht der als Die-Shot durch (https://images.anandtech.com/doci/13562/DavidWang_NextHorizon_06.jpg)?

Das ist ein Schaubild. Es zeigt den logischen Aufbau aber nicht unbedingt die richtigen Groessenverhaeltnisse. Sowas gabs damals zum Vega 10 Launch auch schon, was dann auch gleich grosskotzig von diversen Seiten als FAKE verkauft wurde, obwohl eigentlich jedem klar war, dass es halt ein Schaubild ist.

Gäbe es einen Markt für einen Epyc mit 4 CPU- und 4 GPU-Chiplets?

Diesbezueglich wurde ja eigentlich schon vor ein paar Jahren von einer HPC APU gesprochen. Es sollte also durchaus irgendeinen Bedarf in die Richtung geben. Wenn man es mit den Chiplets auch GPU-seitig flexibel hinbekommt wird es denke ich kommen.

[Skysnake]

Dafür gibt es nur einen Bedarf wenn sie Fortran supporten. Also am besten ohne OpenCL, HIP oder sonst was.

Würde die iGPU einfach als Vektor units genutzt werden wäre das Ding definitiv mehr als nur einen Blick wert.

[Hidemind]

Opencl ist kein Problem. Man kann die Workloads gut zwischen mehreren GPUs ganz gut aufteilen. Klar wenn man synchronisieren muss, kostet das etwas mehr. Bezüglich GPU chiplets wird es interessant, wie ein IO chiplets aussehen muss. Ich kann mir gut vorstellen dass eine Hpc APU aus 4 chiplets+ bestehen kann.
CPU + GPU + IO + HBM

Der HBM sollte am IO chiplets hängen. Natürlich bräuchte man einen aktiven interposer. Der Rest geht über die infinity fabric. Wieviel Bandbreite liefert ein Infinity Fabric Port? Das wäre ein Indikator wie fett eine GPU chiplet aussehen kann. Eventuell hat eine GPU chiplet zwei Infinity Ports. Ahja, falls aktiver Interposer in 14nm dann kann da der Io Kram auch reinwandern.

Das sind sehr viele Variablen, welche verschiedene Produktkonfigurationen ermöglicht.

[danarcho]

Dafür gibt es nur einen Bedarf wenn sie Fortran supporten. Also am besten ohne OpenCL, HIP oder sonst was.

Würde die iGPU einfach als Vektor units genutzt werden wäre das Ding definitiv mehr als nur einen Blick wert.
Ähm ja.. das Problem ist sicher nicht OpenCL, HIP oder sonst was. Und die Lösung auch nicht Fortran (mit OpenMP?).
Die iGPU als Vektoren einbinden wird in den nächsten Jahren nicht passieren.
Du kannst heute schon extrem performant für die APUs schreiben, wenn du denn möchtest (ja, mit OpenCL, HIP, HC etc.). Das Problem ist aber, dass es meistens entweder auf mehr Hardware laufen muss oder schon als legacy geschrieben wurde und keiner Bock hat zu portieren.
Würde man es wirklich drauf anlegen, könnte ein RR wahrscheinlich jede consumer CPU in fast jedem Benchmark versäbeln.
Solange es keiner nutzt, sehe ich nicht den Sinn an der Stelle die Performance (für HPC) zu erhöhen. Es ist halt billiger eine ganze Rechenfarm hinzustellen als den Code umzuschreiben.

[Setsul]

@Hidemind:
Wieso HBM an den I/O Chip? Was bringt der aktive Interposer?
IFOP hat 32B pro Takt, wenn das weiter am DRAM-Takt hängt sind das 42 GB/s. Bei 2 Gbps HBM2 Stacks braucht man 6 IF Links pro Stack.
Ein aktiver Interposer erhöht auch nicht auf magische Weise die Bandbreite, er kann nur selbst das Routing übernehmen, kostet aber viel mehr. Das ist hier aber nicht das Problem, also verschwendetes Geld. Genauso 14nm für den Interposer.

Es ist viel sinnvoller einfach jedem Chiplet einen eigenen HBM Stack zu geben (den kann man dann auch niedrigere takten) anstatt alles mit Gewalt durch den I/O Die zu routen. Selbst wenn die Zugriffe komplett zufällig wären spart man sich schonmal 1/4 der Bandbreite. Wenn die Zugriffe nicht zufällig sind kann man die Bandbreite zwischen den Chiplets auf realistische Werte reduzieren.

[Complicated]

@Hidemind:
IFOP hat 32B pro Takt, wenn das weiter am DRAM-Takt hängt sind das 42 GB/s.

Es hängt immer noch mit dem RAM Takt zusammen.
Die 32B pro Takt gelten für Zen1 und PCIe 3.0. Denn durch die muxed lanes ist das vorgegeben und man orientiert sich an PCIe.
PCIe 4.0 verdoppelt den Durchsatz pro Takt. Daher wäre der neue IFOP Durchsatz durchaus mit 84 GB/s möglich. AMD hat dazu noch keine Details raus gegeben.

[Leonidas]

Wurden eigentlich schon die +29% IPC thematisiert, die AMD in den Fußnoten zwischen Zen 1 und Zen 2 ermittelt haben will?!
https://www.3dcenter.org/news/zen-2-soll-laut-amd-einen-ipc-zuwachs-von-29-gegenueber-zen-1-bringen

https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=64747&d=1542020949

[mboeller]

ja schon:

https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11845947&postcount=1465

[Leonidas]

Wie man sieht, braucht es manchmal, ehe sich das durchs Internet frisst. Momentan rollt das ganze aber schon los, das ist heute Abend auf allen IT-Seiten.

[HOT]

Einfach mal abwarten :). Vorabinfos wird man bei der CES ja schon bekommen und das ist ja nicht mehr lange hin.
Es sieht jedenfalls alles sehr positiv aus im Ersteindruck, was ja schon mal optimistisch stimmen kann. Den Hype würd ich natürlich trotz dem am Boden lassen. Das ist aber glaub ich nicht zu verhindern :D.

[Setsul]

@Complicated:
Leider falsch.
Wenn wir von einer hypothetischen Verbindung um HBM anzubinden reden, muss IF nicht am RAM Takt hängen. Der Sinn des Ganzen ist ja, dass es keine Clock domain crossings gibt, was die Latenz erhöhen würde. HBM läuft aber nicht mit DDR4 Takt also lässt sich das nicht vermeiden und die Latenz ist den GPU Chiplets auch ziemlich egal. Erst recht wenn man HBM an den I/O Die anschließt anstatt direkt, dann macht das bisschen mehr keinen Unterschied.

PCIe 3.0 hat damit überhaupt nichts zu tun. GMI/IFOP läuft über eigene PHYs mit 32b und vierfachem RAM Takt. Takt * 4 * 32b * 2 Richtungen = Takt * 32B bidirektional. Das sind gemächliche 5,3 Gbps bei 1333 MHz RAM und ich bezweifle dass AMD das einfach verdoppelt, dann funktioniert das ganze mit single ended und dem Stromverbrauch nicht mehr so gut.

Was über die multi-protocol PHYs läuft ist SATA, Ethernet, PCIe und xGMI/IFIS. Die PHYs sind deswegen aber schon 12G und nutzen bei 1333 MHz 10,6 davon (16b mit achtfachem Takt, aber wegen encoding nur 8/9 der Bandbreite). PCIe 4.0 braucht 16G PHYs, das wird also bei Weitem keine Verdoppelung der Bandbreite.

[Der_Korken]

@+29% IPC:
Es wurde schon angemerkt, dass sich darin auch zu großen Teilen die verdoppelte AVX-Leistung wiederspiegeln könnte. Insofern sind solche Angaben mit Vorsicht zu genießen. Ich persönlich glaube nicht, dass wir in "normalem Code" derartige IPC-Sprünge nochmal zu sehen bekommen. Selbst die Hälfte davon wäre schon viel.

[Kriegsgeier]

Man müsste einfach folgendes klären:

measured ... for DKERN + RSA

Was DKERN und RSA (Kryptoprotokoll?) genau bedeuten!

Denn, wenn ZEN2 es in Hardware hat und ZEN1 es noch nicht hatte und emulieren musste, dann ist wohl klar woher diese IPC kommt ;)

[Leonidas]

@ Kriegsgeier: Denke ich nicht, die Differenz zwischen emuliert und nativ ist gewöhnlich in Richtung mehrerer Größenordnungen.

@ Der_Korken: Genau das könnte es sein. Was aber nicht bedeutet, das dies nicht teilweise auch in echten Benches ankommt. AVX und FPU sind auch dort gefragt.

[iuno]

Da muss man nichts emulieren, denn Zen kann bekanntlich schon AVX2, hat aber halt nur 128 Bit Breite, braucht also zwei Zyklen fuer 256, zen2 nur noch einen.

RSA ist einfach das am weitesten verbreitete public-key Verfahren, dort hat man grosse Schluessel von mehreren kB. Wahnsinnig viel ent-/verschluesselt man damit aber idR. nicht, sondern tauscht einen symmetrischen Sitzungsschluessel aus.

dkern benutzt man wohl in R fuer statistische Zwecke. Es sind halt AVX Benchmarks.

[Rancor]

@+29% IPC:
Es wurde schon angemerkt, dass sich darin auch zu großen Teilen die verdoppelte AVX-Leistung wiederspiegeln könnte. Insofern sind solche Angaben mit Vorsicht zu genießen. Ich persönlich glaube nicht, dass wir in "normalem Code" derartige IPC-Sprünge nochmal zu sehen bekommen. Selbst die Hälfte davon wäre schon viel.

Denke ich auch nicht. Vllt sind es +5%-10% IPC in "normalen" Anwendungen drin.
Wichtiger wäre der Takt. 4,5GHZ Stock sollte mindestens drin sein.

[Setsul]

Es muss gar nicht an AVX liegen.
Das sind Microbenchmarks, wenn wegen etwas anderer Verteilung der Execution Units auf einmal eine Schleife die 90% der Zeit frisst mit 5 statt 4 IPC läuft dann gibts knapp 25% mehr IPC ohne dass sich groß etwas geändert hat.

Generell ändert sich IPC je nach Programm sehr unterschiedlich. Skylake hat zwischen 5 und 70% mehr IPC als Sandy Bridge.
https://images.anandtech.com/doci/9483/01%20-%20Gains%20over%20Sandy.png

Also 30% mehr IPC in einem Programm, selbst wenn es kein Microbenchmark ist, sagt erstmal wenig für den Rest.

[iuno]

Dafür gibt es nur einen Bedarf wenn sie Fortran supporten. Also am besten ohne OpenCL, HIP oder sonst was.

Würde die iGPU einfach als Vektor units genutzt werden wäre das Ding definitiv mehr als nur einen Blick wert.

Es ist uebrigens seit einiger Zeit ein GCN backend fuer GCC in Arbeit:

This patch series contains the non-OpenACC/OpenMP portions of a port to
AMD GCN3 and GCN5 GPU processors. It's sufficient to build
single-threaded programs, with vectorization in the usual way. C and
Fortran are supported
https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00264.html

Ich habe mich damit nicht weiter befasst, soll aber fuer GCC9 angepeilt sein. Ansonsten gibt es noch das: https://www.amd.com/en/press-releases/2018-11-02-mentor-graphics-hpc-application-development-environment-now-available-for

Ich weiss auch nicht, ob die das von sich aus oder im Auftrag von AMD gemacht haben. AMD scheint ja auf HSA/ROC zu setzen, was aber ja eine moegliche Kooperation nicht ausschliesst. Vielleicht gibt es tatsaechlich bestimmte Kunden die speziell das haben wollen und dafuer baut man dann halt so einen, von Gipsel angesprochenen, Epyc mit ein paar GPU und CPU Chiplets, nur fuer eine/wenige groessere Installationen.

Edit: hier nochmal nachgeliefert, wonach ich auf bei dem entsprechenden Post zuvor nicht mehr gesucht habe:
Seitdem Analyst Day 2015 steht die HPC-APU auf der Roadmap:

http://www.nextplatform.com/wp-content/uploads/2015/05/amd-fad-datacenter-roadmap.jpg

[HPVD]

IC: With the FP units now capable of doing 256-bit on their own, is there a frequency drop when 256-bit code is run, similar to when Intel runs AVX2?

MP: No, we don’t anticipate any frequency decrease. We leveraged 7nm. One of the things that 7nm enables us is scale in terms of cores and FP execution. It is a true doubling because we didn’t only double the pipeline with, but we also doubled the load-store and the data pipe into it.

interessant.

https://www.anandtech.com/show/13578/naples-rome-milan-zen-4-an-interview-with-amd-cto-mark-papermaster

[Pirx]

Es ist uebrigens seit einiger Zeit ein GCN backend fuer GCC in Arbeit:


https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00264.html

Ich habe mich damit nicht weiter befasst, soll aber fuer GCC9 angepeilt sein. ...
passend dazu https://www.phoronix.com/scan.php?page=news_item&px=Radeon-GCN-GCC-November

[w0mbat]

Auch aus dem Anandtech Interview: https://www.anandtech.com/show/13578/naples-rome-milan-zen-4-an-interview-with-amd-cto-mark-papermaster

IC: Can you confirm where the parts of Rome are manufactured?

MP: Chiplets on TSMC 7nm, the IO die is on GlobalFoundries 14nm.
IC: The IO die as showed in the presentation looked very symmetrical, almost modular in itself. Does that mean it can be cut into smaller versions?

MP: No details at this time.
C: Do the chiplets communicate with each other directly, or is all communication through the IO die?

MP: What we have is an IF link from each CPU chiplet to the IO die.
IC: One of the key aspects of IF is that it has started becoming a big part of the power consumption on EPYC. What is AMD doing to manage that power?

MP: Fabrics going forward have to be developed with the same energy efficiency optimizations in mind as with our core engines, such as our CPUs and GPUs. When we started with IF in our CPUs, we started with tremendous energy efficiency for our high performance objectives. We are making generationally excellent performance per watt improvements in our core engines, and we have IF on the same track. Energy efficiency is required in any of the markets that we serve. Therefore we are driving every IP that we develop in the company to improve energy efficiency each and every generation.

[Der_Korken]

IC: Now the Zen 2 core has two 256-bit FP pipes, can users perform AVX512-esque calculations?

MP: At the full launch we’ll share with you exact configurations and what customers want to deploy around that.

Ich dachte Zen hat vier FP-Pipes? Oder sind zwei davon 256bit breit und die anderen beiden nur 128bit?

[Smee]

Denke ich auch nicht. Vllt sind es +5%-10% IPC in "normalen" Anwendungen drin.
Wichtiger wäre der Takt. 4,5GHZ Stock sollte mindestens drin sein.
64748
Der Hypetrain gerät außer Kontrolle und lässt solche geringen Erwartungen nicht zu:freak:

[HOT]

Nenene, der Hypetrain darf nur bei 8 kernigen Coffeelakes und völlig überzogene Erwartungen an einen 10nm Turings mit 60% mehr Leistung ungebremst rollen. Bei AMD muss er im Bahnhof bleiben.

[Locuza]

Ich dachte Zen hat vier FP-Pipes? Oder sind zwei davon 256bit breit und die anderen beiden nur 128bit?
Zen 1 und Zen 2 haben vier FP-Ports, wo bei beiden zwei ADD- und zwei MUL-Pipes hängen.
Alle Pipelines sind 128-Bit (Zen1) oder 256-Bit (Zen2) breit.

Möchte man eine FMA-Operation durchführen (ADD+MUL), dann liegt der Durchsatz bei zwei 128-Bit (Zen1) oder zwei 256-Bit (Zen2) Operationen.
https://cdn.wccftech.com/wp-content/uploads/2016/08/AMD-Zen_Microarchitecture.png

[Leonidas]

Wie legt man dies gewöhnlich aus? Ich dächte früher hätte man gesagt, das sind 4 Einheiten, selbst wenn sie jeweils nur eine bestimmte Operation beherrschen.

[Isen]

MP: What we have is an IF link from each CPU chiplet to the IO die.

Freu... das gibt pfeffer beim OC. :-D

[Kriegsgeier]

dIC: Can you confirm where the parts of Rome are manufacture?

MP: Chiplets on TSMC 7nm, the IO die is on GlobalFoundries 14nm.


Also nicht mal 12nm für den IO-Chip? Hat wohl physikalische Gründe: z.B: parasitäre Kapazitäten sind bei 14nm wesentlich geringer als bei einem 7nm Prozess?

IO-Chip hat ja wesentlich andere Aufgaben zu erledigen, als eine CPU. Sind vielleicht die Latenzen in 14nm sogar geringer als sie in 7nm wären?!

[Skysnake]

Nein ziemlich sicher nicht.

Die PDKs von älteren Prozessen sind aber ausgereifter für den Analogkram.

Was ein Vorteil wäre ist SOI. Da könnte man schon einen echten Vorteil für die SerDes sehen indem man das back Gate eben mit Spannung beaufschlagt damit die Variation kleiner wird. Damit kann man das HighSpeed Zeug dann effizienter designen.

Aber muss man halt auch erstmal machen....

[basix]

12nm ist ja fast das selbe. Evtl. spart man kaum an I/O Fläche und Stromverbrauch aber hat den teureren Prozess. Kosten / Nutzen Rechnung. Alternativ hat 14nm mehr Kapazität beim Fertigungsvolumen.

[Piefkee]

dIC: Can you confirm where the parts of Rome are manufacture?

MP: Chiplets on TSMC 7nm, the IO die is on GlobalFoundries 14nm.


Also nicht mal 12nm für den IO-Chip? Hat wohl physikalische Gründe: z.B: parasitäre Kapazitäten sind bei 14nm wesentlich geringer als bei einem 7nm Prozess?

IO-Chip hat ja wesentlich andere Aufgaben zu erledigen, als eine CPU. Sind vielleicht die Latenzen in 14nm sogar geringer als sie in 7nm wären?!

12nm bitten gegenüber 14nm keinen optischen shrink, auch wenn das von GloFo mal so kommuniziert würde. 12nm = 14nm Sturkbriete mäßig

[Mangel76]

12nm bitten gegenüber 14nm keinen optischen shrink, auch wenn das von GloFo mal so kommuniziert würde. 12nm = 14nm Sturkbriete mäßig

Es hieß doch immer, dass ein Shrink möglich wäre, AMD aber nur höhere Leistung nutzt um sich das neue Design bzw. neue Masken zu sparen???

[HOT]

12LP ist sehr wohl kleiner als 14LPP, AMD nutzte die Shrink-Option allerdings nicht, da man einfach dieselben Masken einsetzt wie vorher (also Zepplin B2 und Ellesmere).
12LP bringt für I/O im Speziellen aber keinerlei Vorteile, da die Packdichte für das I/O-Zeug sicherlich eh kaum schrumpft - deswegen macht man das ja auch nicht in 7nm - und man möchte sich sicherlich die Option offenhalten die I/O-Chips bei extremen Bedarf auch bei Samsung fertigen zu können, das ist ja derselbe Prozess. Perf/W wird für den nicht-leistung-Chip keine Rolle spielen ob 14LPP oder 12LP, das wird dabei gleich sein.

[Godmode]

Und das was TSMC als 7nm verkauft, ist ja eigentlich der 10nm Prozess, oder täusche ich mich da? Somit werden die neuen GPUs von AMD und Nvidia sicher nicht so stark, wie viele das erwarten.

[dildo4u]

Und das was TSMC als 7nm verkauft, ist ja eigentlich der 10nm Prozess, oder täusche ich mich da? Somit werden die neuen GPUs von AMD und Nvidia sicher nicht so stark, wie viele das erwarten.

Es gibt keine Regeln wie man diese Nodes bezeichnen muss. Intel's 10nm sollte ursprünglich auf dem selben Level sein wie TSMC 7nm,aber niemand weiß welche Kompromisse Intel jetzt machen muss damit sie endlich vernünftige Yields produzieren können.

[Unicous]

@Godmode

Was ist denn jetzt schon wieder "der 10nm" Prozess"?:confused:

Von Intel? Hört doch bitte auf die Prozesse immer nach ihren Namen zu vergleichen. Die Charakteristiken sind doch total unterschiedlich. Dass Intel auf dem Blatt die besseren Specs aufweist tut doch in der Realität nichts zur Sache. Keiner der Prozesse entspricht dem was man klassisch unter 10nm oder 7nm erwarten würde.

Wenn sich die Gerüchte bestätigen, dass Intel '10nm' Prozess angepasst hat(sofern sie ihn nicht ganz einstellen wie von einigen behauptet wird), dann ist der TSMC Prozess eh der "bessere" '10nm' Prozess.

Wichtig ist was am Ende für Chips aus der Fab kommen und wie sie sich verhalten. Und das was Intel im Moment anbietet kann man unter "Das war wohl nichts" einheften.

[Godmode]

Ich hab das von hier:
https://en.wikichip.org/wiki/16_nm_lithography_process
https://en.wikichip.org/wiki/10_nm_lithography_process
https://en.wikichip.org/wiki/7_nm_lithography_process

Mir ist schon klar das 10nm nur ein Name ist und jeder Hersteller was anderes darunter versteht.

[Setsul]

Möchte man eine FMA-Operation durchführen (ADD+MUL), dann liegt der Durchsatz bei zwei 128-Bit oder zwei 256-Bit Operationen.
Tippfehler? Sollte eine 256-bit Operation sein.

Wobei FMA die ADD-Ports nur teilweise blockiert (ist ja nur für einen Operand und nicht für die gesamte Dauer des MULs), deshalb kann man lustige Sachen machen wie im Durchschnitt 4x ADD + 4x FMA (ja, FMA) alle 3 Takte (alles 128b).

[Piefkee]

12LP ist sehr wohl kleiner als 14LPP, AMD nutzte die Shrink-Option allerdings nicht, da man einfach dieselben Masken einsetzt wie vorher (also Zepplin B2 und Ellesmere).
12LP bringt für I/O im Speziellen aber keinerlei Vorteile, da die Packdichte für das I/O-Zeug sicherlich eh kaum schrumpft - deswegen macht man das ja auch nicht in 7nm - und man möchte sich sicherlich die Option offenhalten die I/O-Chips bei extremen Bedarf auch bei Samsung fertigen zu können, das ist ja derselbe Prozess. Perf/W wird für den nicht-leistung-Chip keine Rolle spielen ob 14LPP oder 12LP, das wird dabei gleich sein.

https://fuse.wikichip.org/news/1497/vlsi-2018-globalfoundries-12nm-leading-performance-12lp/

Fin Pitch, Poly Pitch und Metal sind zu 14nm identisch.
Einzig der wechsel von 9T zu 7,5T ermöglicht eine reduzierung der Cell Hight von 576nm zu 480nm --> 32,94MTr/mm^2 zu 36,71MTr/mm^2

Also Transitorgröße hat sich nichts geändert nur die Höhe der Cell. Ist für einen I/O Chip also unwichtig.

[Gipsel]

Fin Pitch, Poly Pitch und Metal sind zu 14nm identisch.
Einzig der wechsel von 9T zu 7,5T ermöglicht eine reduzierung der Cell Hight von 576nm zu 480nm --> 32,94MTr/mm^2 zu 36,71MTr/mm^2

Also Transitorgröße hat sich nichts geändert nur die Höhe der Cell. Ist für einen I/O Chip also unwichtig.Und welche Zellengröße man wählt, folgt Erwägungen bezüglich Power/Performance/Fläche. Die größeren Zellen sind ja potentiell schneller, verbrauchen aber mehr (sowohl Fläche als auch Strom).
Die Sache bei GFs 12nm ist ja, daß sie die Fins etwas optimiert haben, so daß man wohl im Schnitt mit den 7,5T-Zellen auf in etwa die gleiche Performance wie mit den 9T Zellen kommen kann. Das ist dann aber eine reine Optimierung der Dichte und vielleicht noch des Stromverbrauchs, schneller wird es dadurch nicht. AMD hat für die Ryzen 2000er Serie also entschieden, bei 9T-Zellen zu bleiben. Einzig die besseren Fins (höhere, etwas größerer Querschnitt, besser definiert) sorgen dann für eine etwas höhere Performance, die Fläche bleibt dann natürlich identisch.

[BoMbY]

Könnte das nicht auch was mit FX-14 (https://www.globalfoundries.com/sites/default/files/product-briefs/pb-cdc-11-web.pdf) zu tun haben, was auf 14LPP aufsetzt?

[BoMbY]

Alle Wege führen nach Rom:


High-Performance Computing Center Stuttgart and Hewlett Packard Enterprise Collaborate to Build World’s Fastest Supercomputer for Industrial Production (https://www.hlrs.de/fileadmin/sys/public/press/releases/PM_HLRS_Hawk-English.pdf)

Hawk, based on HPE’s next-generation high-performance computing (HPC) platform running a next generation AMD EPYC™ processor code named Rome, will have a theoretical peak performance of 24 petaFLOPs, and consist of a 5,000-node cluster.


Dürfte schwer sein auf die mögliche Anzahl Kerne zurück zu rechnen?

[iuno]

Bei 16 DP FLOP (4 256b pipes) pro cycle waeren die 5000 nodes wohl mit je zwei sockets a 64 Kerne und ~2,3 GHz bestueckt. Aber warum ist das wichtig? War es nicht zu erwarten, dass es wieder dual socket systeme gibt?

Uebrigens ist jetzt ein erstes Epyc System (bzw. eins mit Chips aus dem chinesischen joint venture) in der Top500. Laeuft

[BoMbY]

Es hat ja niemand gesagt das es wichtig ist. Eine Einordnung in die Liste (https://www.top500.org/lists/2018/11/) wäre prinzipiell interessant (vor allem Performance/Watt), aber dazu gibt es halt leider noch zu wenig Informationen.

[BoMbY]

Erstes Rome-Motherboard mit PCIe 4.0 gesichtet: https://www.anandtech.com/show/13596/first-amd-epyc-rome-motherboard-spotted

[Skysnake]

Hat jemand die Bilder gesichert?

[w0mbat]

Leider nicht, sah aber groß aus.

[Skysnake]

Wenn ich richtig gesehen habe waren insgesamt 10 SAS links auf dem Board zusammen mit 16 DDR4 Slots. Dazu noch nen 16x und nen 8x mezzanine. So with ich gesehen habe waren noch 2x m2 und 2 Sata Ports vorhanden.

Wirkte für mich nach ziemlich viel

[BoMbY]

Wofür hat man denn einen Browser-Cache:

https://i.imgur.com/6Jho5ckl.jpg (https://i.imgur.com/6Jho5ck.jpg)

https://i.imgur.com/lTGZJkjl.jpg (https://i.imgur.com/lTGZJkj.jpg)

Edit: Der andere Winkel:

https://i.imgur.com/7ZFCEdXl.jpg (https://i.imgur.com/7ZFCEdX.jpg)

[BoMbY]

640.000 Rome-Cores mit 2.35 GHz btw:

https://pbs.twimg.com/media/Dr6kg7yWoAA35XN.jpg:large

https://twitter.com/VideoCardz/status/1062468031056674816

Edit: @iuno: Gut gerechnet.

[Gipsel]

Und nur 1GB Ram pro Core, also 64GB pro 64kerniger CPU (128GB pro Node). Na wenn das mal nicht ein wenig knapp ist.

[BoMbY]

Ja, aber RAM ist gerade teuer. Könnte ein Grund sein.

Der Tianhe-2A mit 4.981.760 Intel Xeon E5-2692v2 12C 2.2GHz Kernen kommt auf 100.678,7 TFlpos Peak. Stimmt die Milchmädchenrechnung, dass Rome damit nah an die doppelte IPC kommt? Edit: ca. + 75%?

[Ravenhearth]

Update: AMD has made a statement to Notebookcheck clarifying the nature of the IPC improvement cited in the footnotes of its document, reiterating that this IPC uplift was calculated in a specific task that specifically used integer and floating point operations. It is not an aggregate for all applications. (https://www.notebookcheck.net/Updated-AMD-claims-Zen-2-has-29-higher-IPC-than-Zen-1-in-certain-workloads.359556.0.html)
As we demonstrated at our Next Horizon event last week, our next-generation AMD EPYC server processor based on the new “Zen 2” core delivers significant performance improvements as a result of both architectural advances and 7nm process technology. Some news media interpreted a “Zen 2” comment in the press release footnotes to be a specific IPC uplift claim. The data in the footnote represented the performance improvement in a microbenchmark for a specific financial services workload which benefits from both integer and floating point performance improvements and is not intended to quantify the IPC increase a user should expect to see across a wide range of applications. We will provide additional details on “Zen 2” IPC improvements, and more importantly how the combination of our next-generation architecture and advanced 7nm process technology deliver more performance per socket, when the products launch.

[Gipsel]

Der Tianhe-2A mit 4.981.760 Intel Xeon E5-2692v2 12C 2.2GHz Kernen kommt auf 100.678,7 TFlpos Peak. Stimmt die Milchmädchenrechnung, dass Rome damit nah an die doppelte IPC kommt? Edit: ca. + 75%?Ist halt noch IvyBridge mit nur AVX-Support (kein FMA) ;). Allerdings weiß ich nicht, wie die auf die angegebene Peak-Performance kommen. Schafft ein IvyBridge-Kern 9,2 Flops/Takt? Und bei intel gibt es gar keinen E5-2692v2. Haben die den extra für die Kiste so genannt? Boostet der dort auf ~2,5GHz? Hmm.

[mczak]

Ist halt noch IvyBridge mit 128Bit AVX-Einheiten ;). Allerdings weiß ich nicht, wie die auf die angegebene Peak-Performance kommen. Schafft ein IvyBridge-Kern 9,2 Flops/Takt? Hmm.
Auch Ivy-Bridge hat 256bit AVX Einheiten, die hatte auch Sandy Bridge schon.
Allerdings kein FMA, und (sustained) "nur" 0.5 256bit Store + 1 256bit Load pro Takt (ist mehr als die Hälfte von 128bit loads/stores (da gehen sustained 2x128bit load oder 1x128bit load + 1 128bit store), weil die Datenpfade 2x128bit für load und 1x128bit for store sind aber der Chip bloss 2 AGUs hat).

[Gipsel]

Auch Ivy-Bridge hat 256bit AVX Einheiten, die hatte auch Sandy Bridge schon.
Allerdings kein FMA, und (sustained) "nur" 0.5 256bit Store + 1 256bit Load pro Takt (ist mehr als die Hälfte von 128bit loads/stores (da gehen sustained 2x128bit load oder 1x128bit load + 1 128bit store), weil die Datenpfade 2x128bit für load und 1x128bit for store sind aber der Chip bloss 2 AGUs hat).Habe ich dann auch noch mitbekommen. Ist wohl schon zu lange her. :rolleyes:

[Nightspider]

Könnte man in Zukunft nicht DRAM auf den I/O-Chiplet stacken?

Das Ding ist riesig, da würde eine menge DRAM draufpassen und die Abwärme vom I/O Teil dürfte kein Problem für den DRAM sein.

Dann können die Zen Chiplets ungebremst takten und hätten viel mehr Bandbreite, bei kürzeren Latenzen. Sowas könnte ich mir zumindest bei Konsolen vorstellen, wo man eine fixe Menge an Hauptspeicher benötigt.

[HOT]

Auch Ivy-Bridge hat 256bit AVX Einheiten, die hatte auch Sandy Bridge schon.
Allerdings kein FMA, und (sustained) "nur" 0.5 256bit Store + 1 256bit Load pro Takt (ist mehr als die Hälfte von 128bit loads/stores (da gehen sustained 2x128bit load oder 1x128bit load + 1 128bit store), weil die Datenpfade 2x128bit für load und 1x128bit for store sind aber der Chip bloss 2 AGUs hat).
Lt Wikihausen stimmt das so nicht. Sandy und Ivy haben nur 128Bit Rechenwerke, die bei Bedarf auf Kosten anderer erweitert werden können für 256Bit.

[Piefkee]

https://www.reddit.com/r/Amd/comments/9wtywo/zen2_rome_clocks_leaked_64c_235ghz/

Gegenüber dem Epyc 1 32 mit 2,2GHz Base ist das schon ordentlich wenn man bedenkt das Epyc 2 doppelte Kernanzahl bietet :)

[basix]

Wenn es denn der Basis-Takt ist. Ich vermute ja schon, aber der EPYC 7601 hat einen All-Core Boost von 2.7 GHz

[Birdman]

Die 2.35Ghz sind sicher Base-Clock, Boost wird vermutlich zwischen 2.7 und 3.0Ghz liegen.
Damit liegt der Basis Takt etwas höher als ich für den 64C Rome spekuliert hatte (2.1Ghz), was dann wirklich nicht schlecht wäre. (vor allem wenn sie die gleiche TDP beibehalten - wovon ich mal ausgehe)

[Der_Korken]

Selbst für den Boost wären 2,35Ghz OK. Das wären trotzdem noch 74% mehr Rohleistung bei wahrscheinlich gleichem Verbrauch. Mit IPC-Steigerungen wären es fast Faktor 2.

[HOT]

Wegen der 2,35 würd ich Boost wahrscheinlicher finden. Basis ist sicher 2,0 oder 2,2.

[Setsul]

Nicht übermütig werden, wir reden hier von doppelt sovielen Kernen mit doppelt sovielen FLOPs pro Kern und höherer IPC. Das kostet alles ein bisschen.
Also selbst 2,35 GHz Boost statt 2,7 bei mehr als doppelt sovielen Transistoren ist völlig in Ordnung. 7nm kann auch keine Wunder vollbringen.

Wobei man sagen muss, dass HPC sich auch für Effizienz interessiert. Das muss nicht die am höchsten getaktete 64C SKU sein.

[mboeller]

Wobei man sagen muss, dass HPC sich auch für Effizienz interessiert. Das muss nicht die am höchsten getaktete 64C SKU sein.

Ein MW mehr oder weniger, was spielt das schon für eine Rolle. :)

[BoMbY]

64c mit 2,35 GHz Takt bei 180W TDP könnte ungefähr hinkommen bei 7nm nach den bisherigen Informationen (50% Power bei der gleichen Frequenz).

Bei Epyc 7601 ist 2.2 GHz Grundtakt und ein All-Core-Boost von max. 2.7 GHz bei 180W TDP angegeben. Da könnten 2.35 GHz genau der Sweet-Spot sein.

Da bei dem Hawk 10.000 Stück abgenommen werden, könnte es auch gut sein, dass es ein Custom-Modell ist, jedenfalls was das Binning und die Einstellungen angeht.

[Ravenhearth]

Wenn der Computer 38 Millionen Euro kosten soll, und 10.000 CPUs verbaut sind, kommt man auf nur 3800€ pro Prozessor... und das ist ohne den ganzen "Rest". Allein der RAM kostet Millionen. Das heißt, pro CPU können das höchstens 2000€ sein, wenn überhaupt. Das ist aber schon sehr billig, nicht?

[Sunrise]

Wenn der Computer 38 Millionen Euro kosten soll, und 10.000 CPUs verbaut sind, kommt man auf nur 3800€ pro Prozessor... und das ist ohne den ganzen "Rest". Allein der RAM kostet Millionen. Das heißt, pro CPU können das höchstens 2000€ sein, wenn überhaupt. Das ist aber schon sehr billig, nicht?
Ging mir auch gerade durch den Kopf. Ob die Zahlen (Gesamtkosten) stimmen? Das wäre ja schon fast ein Superschnäppchen pro CPU. Da gabs wohl nochmal fette 50% Rabatt on top, dann kommts eher hin.

[BoMbY]

Pro Chiplet dürften es kaum mehr als $75 Produktkosten sein, inkl. Abschreibungen etc. Da macht AMD bei einem VK von $2.000 an HP problemlos noch $1.250 Gewinn.

[Locuza]

AMD's 7nm Rome processors are ushering in a new wave of multi-chip architectures for data center processors, but AMD has remained coy about exactly when the 64-core 128-thread processors will come to market, instead saying vaguely that they will arrive in 2019. According to a motherboard vendor that displayed a new motherboard designed to support the Rome processors and PCIe 4.0, the first wave of fully-compatible Rome motherboards will arrive in Q3 2019, likely signalling the beginning of shipments for the Rome chips.
https://www.tomshardware.com/news/amd-rome-motherboard-epyc-cpu,38071.html

Das hätte ich einen Tick früher erwartet, sollte sich das bewahrheiten.

[Sunrise]

https://www.tomshardware.com/news/amd-rome-motherboard-epyc-cpu,38071.html

Das hätte ich einen Tick früher erwartet, sollte sich das bewahrheiten.
Hm, war nicht die ganze Zeit eher das Frühjahr im Gespräch? Das galt also lediglich für die CPU?

[Ravenhearth]

"Im Gespräch", das waren halt nur die Erwartungen der Leute. AMD hat dazu nie was gesagt.

[Gipsel]

Wobei man sagen muss, dass HPC sich auch für Effizienz interessiert. Das muss nicht die am höchsten getaktete 64C SKU sein.Genau. Meist wird nicht das Top-Modell eingesetzt bzw. z.T sogar extra niedriger getaktete Versionen speziell für solche Installationen benutzt.
Und man sollte auch nicht vergessen, daß AMD die finalen Taktraten vermutlich noch nicht festgelegt hat. Das wird der Takt von irgendwelchen Samples sein, die es wahrscheinlich aussehen lassen, daß man diesen Takt erreichen wird.

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

Ein MW mehr oder weniger, was spielt das schon für eine Rolle. :)Eine ziemlich große (ein paar Millionen an jährlichen Betriebskosten, mal abgesehen von den nötigen Investitionen um den erhöhten Energie- und Klimatisierungsaufwand bereitszustellen).

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

https://www.tomshardware.com/news/amd-rome-motherboard-epyc-cpu,38071.html

Das hätte ich einen Tick früher erwartet, sollte sich das bewahrheiten.Na wenn die Boards erst in Q3/19 PCIe4 unterstützen (und gerüchteweise vielleicht sogar ein paar extra Lanes für Chipsatz/SATA/Ethernet oder so), mag das ja so sein. Trotzdem funktioniert Rome mit PCIe3 auch schon in Q2/19 in alten Boards.

[Locuza]

Ich hätte jetzt nicht erwartet, dass das Bring-Up für PCIe4.0 solange dauern würde, wenn der Rest der Platinen und Spezifikationen weitgehend identisch ausfällt.

[BoMbY]

PCIe 4.0 verdoppelt die Frequenz von PCIe 3.0. Es sind bei PCIe 4.0 8 GHz statt bisher 4 GHz. Da kann es zu einer Menge an Störeinflüssen kommen. Und PCIe 5.0 soll nochmal eine Verdoppelung der Frequenz bringen.

[mboeller]

Hm, war nicht die ganze Zeit eher das Frühjahr im Gespräch? Das galt also lediglich für die CPU?

Denke ich auch. Da Rome ohne Probleme (?Bios?) auf die bisherigen SP3-Boards passen soll macht es nicht so viel aus, wenn die neuen Boards erst 3 Monate später in Q3 kommen.

edit: hat Gipsel aber ein wenig ausführlicher auch schon erklärt :)

[Unicous]

Ich hätte jetzt nicht erwartet, dass das Bring-Up für PCIe4.0 solange dauern würde, wenn der Rest der Platinen und Spezifikationen weitgehend identisch ausfällt.

Es gibt noch gar kein Ökosystem für PCIe 4.0.

Ich schätze mal im Laufe der nächsten Monate werden immer mehr Produkte gelaunched die 4.0 unterstützen. Bis auf IP-Blöcke der üblichen Verdächtigen ist eher wenig los.


edit:

Wenn man vom Teufel spricht:

Xilinx Extends Data Center Leadership with New Alveo U280 HBM2 Accelerator Card; Dell EMC First to Qualify Alveo U200 (https://www.eejournal.com/industry_news/xilinx-extends-data-center-leadership-with-new-alveo-u280-hbm2-accelerator-card-dell-emc-first-to-qualify-alveo-u200/)



The Alveo U280 will start sampling in Q1 2019.

[iuno]

Wegen der 2,35 würd ich Boost wahrscheinlicher finden. Basis ist sicher 2,0 oder 2,2.
Der Vorgaenger mit Intel ist mit theoretischen Peak Werten des base clocks angegeben. Allerdings weiss ich nicht, ob das bei dem Modell dem AVX Takt entspricht. Boost hat der sonst auch einiges mehr, 3,3 statt 2,5 GHz.
Vielleicht wissen die es auch einfach selbst noch nicht und 2,35 ist das was AMD als Minimum zugesagt hat.

[Sunrise]

Der Vorgaenger mit Intel ist mit theoretischen Peak Werten des base clocks angegeben. Allerdings weiss ich nicht, ob das bei dem Modell dem AVX Takt entspricht. Boost hat der sonst auch einiges mehr, 3,3 statt 2,5 GHz.
Vielleicht wissen die es auch einfach selbst noch nicht und 2,35 ist das was AMD als Minimum zugesagt hat. Zumal sie extra betonen, dass sie Rome genommen hat, weil er die Leistung dauerhaft liefert, also kann es gar kein boost clock sein.
Das wäre natürlich brachial, d.h. das wäre wohl genau im sweet spot dauerhaft verfügbar (quasi sustained), selbst bei AVX-Last.

[iuno]

Die letzte Aussage muss ich allerdings zuruecknehmen, ich finde das Zitat nicht mehr :D

[mczak]

Lt Wikihausen stimmt das so nicht. Sandy und Ivy haben nur 128Bit Rechenwerke, die bei Bedarf auf Kosten anderer erweitert werden können für 256Bit.
Naja die Betrachtung ist etwas kompliziert (weil eben die SIMD-Int-Einheiten weiterhin nur 128bit sind, deswegen gibt es ja 256bit breite AVX-Int-Befehle erst mit AVX2).
Die Register sind scheinbar auch aufgeteilt in 2 128bit Hälften.
Wie genau das intern aussieht weiss ich auch nicht, aber ja die 256bit FP Befehle scheinen Resourcen zu nutzen der SIMD-Int Einheiten (die können eh nicht parallel verwendet werden weil sie am selben Execution Port hängen), aber Tatsache ist dass am Ende 256bit AVX-Befehle denselben Durchsatz haben wie 128bit AVX (oder SSE), das ist ein Fakt (wie gesagt mit Ausnahme von Load/Store, und zudem bei Sandy Bridge noch mit Ausnahme der Dividiereinheit). Deswegen finde ich ist es auf alle Fälle korrekt wenn man das (im Gegensatz zu Zen 1) als "echte" 256bit Einheiten betrachtet, auch wenn das nicht alle Details berücksichtigt. Eine gute Erklärung dazu gibt's z.B. hier: https://www.realworldtech.com/sandy-bridge/6/

[YfOrU]

Pro Chiplet dürften es kaum mehr als $75 Produktkosten sein, inkl. Abschreibungen etc. Da macht AMD bei einem VK von $2.000 an HP problemlos noch $1.250 Gewinn.

Die haben ungefähr die Größe eines Apple A12 SoCs. Die reinen Fertigungskosten würde ich eher im Bereich von 15 bis $20 pro 7nm Chiplet ansetzen.

Deutlich drüber ist proportional zu viel wenn man bedenkt für welche Beträge heute ein um 100mm² großer 14nm Chip als fertiges Produkt zu haben ist. Schlecht laufen kann der Prozess auch nicht denn Apple bezieht hohe Volumen und hat mit dem A12X gleich noch ein etwas größeres Design gebracht. Den 14nm I/O Part würde ich bei $40 einordnen. Komplett mit Package auf jeden Fall deutlich unter $200. Damit Richtung 50% teurer als die erste Generation. Aber hat halt auch doppelte so viele Kerne. Mit vier Chiplets sollte es halbwegs vergleichbar sein.

[Skysnake]

Und nur 1GB Ram pro Core, also 64GB pro 64kerniger CPU (128GB pro Node). Na wenn das mal nicht ein wenig knapp ist.

Ja ist mir auch aufgefallen. Das ist schon etwas bitter. Die 128GB mit nur 24 Cores bei HazelHen waren nämlich schon recht angenehm. Wurde aber jetzt wohl nicht von so vielen Leutenauch wirklich ausgereizt.

Dennoch schon schade bzw bei rund 4 mal so viel Performance und bot allem 5 mal mehr Cores schon dünn

[BoMbY]

Die haben ungefähr die Größe eines Apple A12 SoCs. Die reinen Fertigungskosten würde ich eher im Bereich von 15 bis $20 pro 7nm Chiplet ansetzen.

Ja, $10-$20 je nachdem wie gut die Yields sind. Dann noch Binning und Packaging-Anteil. Dazu noch intern verrechnete Produktosten inkl. Umlage von Entwicklungskosten und Rücklagen für zukünftige Entwicklungen, Marketingkostenumlage, etc.

[BlacKi]

neuer fred zu picasso?
https://videocardz.com/79070/amd-ryzen-7-3700u-spotted-features-picasso-gpu

[SKYNET]

mal wer dran gedacht, das durch Zen2 PCIe 4.0 für alle A/B/X bretter der ersten generation ebenfalls aktiv werden? zumindest für den hauptslot, der ja direkt an der CPU hängt ohne bridge chip... so geil, AMD user bekommen nur durch ein CPU upgrade ein PCIe 4.0 slot gratis oben drauf(sofern die layer vom MB gut genug sind, und das sollte eigentlich jedes nicht ganz billige board erfüllen).

[BoMbY]

Nochmal: PCIe 4.0 verdoppelt die Übertragungsfrequenz. Es gibt keine Garantie dass das auf alten Boards stabil funktioniert. Eventuell ist das auch ein Feature welches über BIOS/AGESA auf x370/x470 einfach komplett ausgeschaltet wird.

[amdfanuwe]

mal wer dran gedacht, das durch Zen2 PCIe 4.0 für alle A/B/X bretter der ersten generation ebenfalls aktiv werden?
Wie kommst du denn darauf? ZEN2 hat mit PCIe doch nicht viel zu tun, wird doch durch den I/O Chip realisiert und da kommt für AM4 garantiert ein anderer.
Wer sagt denn, dass AMD für AM4 auch PCIe 4.0 im I/O implementiert.
Macht doch im Grunde keinen Sinn. Noch keine GPUs vorhanden die PCIe 3.0 ausschöpfen, schon gar keine mit PCIe 4.0 zudem viel Ärger mit inkompatiblen Boards.
Ich denke mal, PCIe 4.0 bleibt erst mal den Server und Workstation vorbehalten. Für den Low-End Einsteigersockel AM4 bleibt es bei PCIe 3.0.
Vielleicht mal mit AM5.

[BoMbY]

PCIe 4.0 GPUs kommen nächstes Jahr. AMD wäre dumm das nicht vorzusehen, und ebenso wäre es dumm nicht auch einen passenden x570-Chipsatz dafür raus zu bringen.

[Brillus]

Gehe auch davon aus zen2 kann pcie4 aber nur auf neuen Boards, dann mit Chipsatz der auch per pcie4 angebunden ist.

[SKYNET]

Wie kommst du denn darauf? ZEN2 hat mit PCIe doch nicht viel zu tun, wird doch durch den I/O Chip realisiert und da kommt für AM4 garantiert ein anderer.
Wer sagt denn, dass AMD für AM4 auch PCIe 4.0 im I/O implementiert.
Macht doch im Grunde keinen Sinn. Noch keine GPUs vorhanden die PCIe 3.0 ausschöpfen, schon gar keine mit PCIe 4.0 zudem viel Ärger mit inkompatiblen Boards.
Ich denke mal, PCIe 4.0 bleibt erst mal den Server und Workstation vorbehalten. Für den Low-End Einsteigersockel AM4 bleibt es bei PCIe 3.0.
Vielleicht mal mit AM5.

geht nicht ums "es hat noch keine grakas mit PCIe 4.0" sondern in dem business um "wir hatten es zuerst"...

der 1. PCIe slot ist grundsätzlich nativ an die CPU gebunden, da ist nix mit bridgechip, das ist ledeglich für die weiteren slots und NVMe... die würden weiterhin mit PCIe 3.0x laufen.

[amdfanuwe]

der 1. PCIe slot ist grundsätzlich nativ an die CPU gebunden, da ist nix mit bridgechip,
Du hast Rome verpasst? Die 7nm CPU Chiplets haben kein PCIe.

[basix]

Das kann man als "nativ" verstehen bei Rome ;)

[iuno]

ebenso wäre es dumm nicht auch einen passenden x570-Chipsatz dafür raus zu bringen.
Woher die Gewissheit,dass es ueberhaupt noch einen extra 500er Chipsatz auf AM4 gibt?
Gibt's irgendwo ein Pinout von AM4? Ggf. kommt man mit den Pins hin und spart sich das einfach.

[Brillus]

Woher die Gewissheit,dass es ueberhaupt noch einen extra 500er Chipsatz auf AM4 gibt?
Gibt's irgendwo ein Pinout von AM4? Ggf. kommt man mit den Pins hin und spart sich das einfach.
Eher erwartung weil der aktuelle mit PCIe3 angebunden ist. Unter der Annahme PCIe4 auf Desktop zu bringen nur logisch. Auserdem haben die MoBo Hersteller gerne neue Features das es sich besser verkauft.

[Setsul]

Oder anders: Wieso für Zen+ neue Chipsätze aber für Zen2 nicht?
Intel bringt aus gutem Grund jedes Jahr selbst bei gleicher Architektur neue Chipsets. Die MoBo Hersteller wollen es so. MoBos unterliegen wie alles in der PC-Industrie einem graduellen Preisverfall. Natürlich ist es für die Erfahreneren offensichtlich, dass das das gleiche MoBo wie letztes Jahr ist, nur mit einer um eins höheren Ziffer am Anfang und 2 USB Ports mehr, aber im Gegensatz zu den ein Jahr alten MoBos kann man dafür erstmal wieder die UVP verlangen.

[reaperrr]

Woher die Gewissheit,dass es ueberhaupt noch einen extra 500er Chipsatz auf AM4 gibt?
Gibt's irgendwo ein Pinout von AM4? Ggf. kommt man mit den Pins hin und spart sich das einfach.
In manchen Bereichen waren doch schon die 300er zum Launch nicht State of the Art, und die 400er sind nichts weiter als umgelabelte und leicht umkonfigurierte 300er.

Nach zwei Jahren wäre alles andere als echte, neue 500er Chipsätze für Zen2 eine ziemliche Enttäuschung, und vor allem auch reichlich seltsam.

Das bedeutet ja auch nicht, dass deshalb irgendwas am Sockel geändert werden muss oder die alten Boards nicht mit den neuen CPUs laufen, bloß die neuesten Features wie PCIe 4.0 und zusätzliche USB/SATA-Ports usw. brauchen dann halt die neuen CPUs + 500er Chipsatz.

PCIe3.0 ging bei Intel damals auch nur in der Kombi Z77 + Ivy, obwohl der Sockel derselbe war.

[Lehdro]

PCIe3.0 ging bei Intel damals auch nur in der Kombi Z77 + Ivy, obwohl der Sockel derselbe war.
So ein Quatsch. Z68 + Ivy Bridge = PCIe 3.0, selber getestet.

[iuno]

In manchen Bereichen waren doch schon die 300er zum Launch nicht State of the Art, und die 400er sind nichts weiter als umgelabelte und leicht umkonfigurierte 300er.

Nach zwei Jahren wäre alles andere als echte, neue 500er Chipsätze für Zen2 eine ziemliche Enttäuschung, und vor allem auch reichlich seltsam.
Ich rede auch nicht davon, dass man alte Chipsaetze wiederverwendet, sondern sie einfach weg laesst.


Oder anders: Wieso für Zen+ neue Chipsätze aber für Zen2 nicht?
Weil es womoeglich voellig unnoetig ist.

Dazu muesste man aber wie gesagt wissen, ob die Pins bei AM4 ausreichend sind. Vielleicht hat AMD das schon so vorgesehen und sich in erster AM4 ersten Generation nur noch mit promontory beholfen. Vielleicht aber auch nicht.

[Setsul]

Dann wäre es für Zen+ auch schon unnötig.
Es gibt für Zen2 "neue" Chipsätze, das garantiere ich dir. Die Frage ist ob sie wirklich neu sind.

B550/X570 wird es geben, ob mit oder ohne PCIe 4.0 ist die Frage.

[KORE]

Schon allein deswegen das man keine 450/470 Leiche aus einem Regal bekommt das noch ein altes BIOS drauf hat ... es gilt eben Menschen die 100% Sicherheit brauchen ... und 550/570 vermitteln 100% kompatibel mit ryzen3000 ...

[gbm31]

So ein Quatsch. Z68 + Ivy Bridge = PCIe 3.0, selber getestet.

SLI-Brett nein, non-SLI-Brett ja, weil dann Lanes frei dazu.

Hatte ich selbst bis August im EInsatz.

[Complicated]

Thema ist doch, dass Zen einfach ein SoC ist der neue I/O im Package integriert. Wozu sollte man neue Chipsätze brauchen?
Ob die Mainboards immer ready sind wie jetzt für PCIe 4.0 steht auf einem anderen Blatt. Doch ein neuer Chipsatz muss es nicht sein wenn ausreichend lanes onChip sind.

[BoMbY]

Nur sind bei AM4 bereits die Lanes on Chip > Lanes on Package/Socket. Und es reicht hinten und vorne nicht aus für etwas anspruchsvollere Systeme. Mit einem neuen Chipsatz und PCIe 4.0 Anbindung könnte man wenigstens einmal sekundär PCIe 3.0 x8 mehr anbieten, oder zwei mal NVMe mit PCIe 3.0 x4 Anbindung, oder, oder ...

Edit: Ich würde mir ja wünschen die würden den x570 mit PCIe 4.0 x8 Anbinden (die aktuellen x4 Lanes für NVMe und x4 für Chipsatz kombiniert), und dann direkt einen ordentlichen PCIe-Switch da zu integrieren auf 2x x8 oder so, dann wären die MB-Hersteller komplett flexibel und könnten ganz unterschiedliche Dinge damit machen.

[iuno]

Thema ist doch, dass Zen einfach ein SoC ist der neue I/O im Package integriert. Wozu sollte man neue Chipsätze brauchen?
Dagegen spricht halt, dass ein Zeppelin die auf AM4 nur 24 PCIe lanes raus fuehrt, auf Epyc aber 32. Aber das kann ja verschiedene Gruende haben.

[amdfanuwe]

Und es reicht hinten und vorne nicht aus für etwas anspruchsvollere Systeme.
Dafür gibt es andere Platformen.
AM4 ist Einsteiger Platform, 1 x GPU + SSD + HDD, fertig. Reicht für 99,9% der Anwender.
Du hörst dich an wie eine Polo oder Fiesta Fahrer der sich über zu wenig Laderaum und PS beschwert.

[Lehdro]

SLI-Brett nein, non-SLI-Brett ja, weil dann Lanes frei dazu.
Und wieder Quatsch, hatte hier ein SLI Brett mit PCIe 3.0 Support:
https://www.asrock.com/mb/Intel/Z68%20Extreme3%20Gen3/index.asp

Lief hier lange mit SB und IB abwechselnd, jeweils mit PCIe 2.0 und 3.0. Woher kommt das dumme Gerücht mit den Lanes? Das hat damit 0 zu tun, die Lanes takten mit IB einfach höher, da physisch auf dem Board schon dafür vorbereitet. Das einzige was 2.0 bleibt sind die beiden x1 Slots.

Hatte ich selbst bis August im EInsatz.
Board?

[BoMbY]

Dafür gibt es andere Platformen.
AM4 ist Einsteiger Platform, 1 x GPU + SSD + HDD, fertig. Reicht für 99,9% der Anwender.
Du hörst dich an wie eine Polo oder Fiesta Fahrer der sich über zu wenig Laderaum und PS beschwert.

:rolleyes: Ja, mit 8c/16t CPUs, oder wenn man nach den Wünschen vieler hier geht sogar mit 16c/32t CPUs.

Kann mir wirklich mal jemand erklären warum andauern irgendwelche Leute extrem gegen PCIe 4.0 argumentieren? Ist das der Neid weil Intel es nicht anbieten kann?

[Eldoran]

Kann mir wirklich mal jemand erklären warum andauern irgendwelche Leute extrem gegen PCIe 4.0 argumentieren? Ist das der Neid weil Intel es nicht anbieten kann?
Ich habe nichts gegen PCIe 4.0, aber wie so häufig ist das mehr als nur ein +1 auf die Versionsnummer. In diesem Falle eben wieder einmal eine Verdopplung der Frequenz was deutlich höhere Anforderungen bei allen beteiligten Komponenten bedeutet um die diversen störenden Einflüssen beherrechen zu können. Auch wenn logischerweise "nur" die Strecke CPU_Sockel zu Steckplatz betroffen ist, heisst das noch lange nicht, dass die Verbindung den Ansprüchen genügt. Beispielsweise gibt es einen Unterschied bei der praktisch einsetzbaren Taktfrequenz beim RAM, obwohl da ja auch nur Leitungen zwischen CPU und RAM liegen. Das war unter anderem eines der Gebiete bei dem die Qualität bei späteren Ryzen Boards verbessert wurde. Oder die Cat6 und bessere Netzwerkkabel setzt man auch nur zum Spass ein - bei entsprechenden Datenrate (und somit frequenz) sowie Leitungslänge ist sonst keine stabile Übertragung möglich.
Oder anderes Beispiel - von PCIe 3.0 auf 4.0 bedeutet etwa auch, dass keine passiven Riser-Karten benutzt werden können - die Dämpfung wäre zu hoch.

[Complicated]

Die Riser-Karten laufen dann eben weiter im PCIe3-Modus. Sie können einfach weiter benutzt werden, da alles Abwärtskompatibel bleibt.

[amdfanuwe]

Kann mir wirklich mal jemand erklären warum andauern irgendwelche Leute extrem gegen PCIe 4.0 argumentieren? Ist das der Neid weil Intel es nicht anbieten kann?
Ich sehe einfach nicht den Sinn und die Notwendigkeit bei AM4.
Threadripper könnte nächstes Jahr höchst interessant werden. Eine Menge Kerne mit hohem Takt und genügend PCIe und Speicherbandbreite. So richtig was für Männer.

[Deinorius]

PCIe 4.0 für AM4? Kann mir jemand erklären, was das genau bringen soll? Die Grafikkarte verhungert wohl kaum an Bandbreite. Hilft das überhaupt, mehr M.2 SSDs anzubinden? Mehr gibt es ja nicht, wo man wirklich viele Lanes im Mainstream Markt braucht.

Ich habe auch nix dagegen, aber ich glaube eher, dass PCIe 4.0 erst mit dem nächsten Mainstream Sockel AM5 (oder wie auch immer) kommen wird. Primärer Grund: Niedrigere Kosten, kaum Notwendigkeit, ganz einfach.

[Brillus]

PCIe 4.0 für AM4? Kann mir jemand erklären, was das genau bringen soll? Die Grafikkarte verhungert wohl kaum an Bandbreite. Hilft das überhaupt, mehr M.2 SSDs anzubinden? Mehr gibt es ja nicht, wo man wirklich viele Lanes im Mainstream Markt braucht.

Ich habe auch nix dagegen, aber ich glaube eher, dass PCIe 4.0 erst mit dem nächsten Mainstream Sockel AM5 (oder wie auch immer) kommen wird. Primärer Grund: Niedrigere Kosten, kaum Notwendigkeit, ganz einfach.
Naja die meisten dieser Art von Features sind bei Einführung nicht weil man es braucht sondern weill sie einen schönen Aufkleber auf der Verpackung abgeben.

Un ein echter neuer Chipsatz von AMD wird auch mal wieder Zeit rein aus OEM Anforderung schon.

[Deinorius]

Ich habe auch nix dagegen. Wenn es kommt, kommt es. Aber es sollte auch keiner überrascht sein, wenn dem nicht so ist.
Da Threadripper eher Salvage von Epyc ist, kann ich mir vorstellen, dass der große I/O-Die als Salvage Variante für Threadripper verwendet werden könnte. Heißt, wer PCIe 4.0 will, sollte auf Threadripper setzen, sofern es nicht für AM4 kommt.

[Daredevil]

PCIe 4.0 für AM4? Kann mir jemand erklären, was das genau bringen soll?
Ja klar, ganz einfach sogar.
Wenn PCIe 4.0 doppelt so schnell ist wie PCIe 3.0, brauche ich nur noch halb so viele Lanes und habe die gleiche Geschwindigkeit.

Zwei mal PCIe 4.0 8x wären so schnell wie zwei mal PCIe 3.0 16x und demnach könnte man bei der aktuellen GPU Leistungsstufe z.B. überhaupt gescheit SLI/Crossfire nutzen.
NVMe SSDs muss man nicht mehr mit 4x anbinden, sondern könnte sie mit 1x anbinden. Wobei das "nur" 1,969MB7s sind , aber einem einem 4x kann man zwei dran bekommen halt.

Ich glaube nicht, dass PCIe 4.0 ein Pflichtprogramm sein muss, aber wenn das möglich ist, wäre es schon eine sehr feine Sache.

[iuno]

Hilft das überhaupt, mehr M.2 SSDs anzubinden? Mehr gibt es ja nicht, wo man wirklich viele Lanes im Mainstream Markt braucht.
Falls es NVMe mit PCIe4x2 geben wird (keine Ahnung, wuerde aber Sinn ergeben) schon. Allgemein braucht man ja nur noch halb so viele Lanes. Einer Graka wuerde also statt PCIe3x16 auch PCIe4x8 reichen, wenn man so scharf drauf ist, die alte Bandbreite zu behalten. Falls es noch einen extra Chipsatz gibt kann der auch mit gleich vielen Lanes doppelt so schnell angebunden werden und den Sinn wird wohl keiner bestreiten.

Wird die Diskussion hier eigentlich einfach zum Spass gefuehrt oder gibt es auch einen Grund dafuer, warum man auf PCIe 3 beharren sollte? Kostet das ueberhaupt massgeblich weniger? Die IP ist ja schon da und mehr Leitungen braucht man auch nicht. Ich denke mal auf das bisschen 14nm space ist kommt es nicht an.

[Daredevil]

Verstehe ich auch nicht. :D
Aktuelle 8700k oder 2700x Systeme sind z.B. einfach schlecht, wenn man mit MultiGPU arbeiten will.
Da muss man im Neukauf zu einem x299 oder Threadripper greifen, das ist total unnötig für Gaming.

Der Unterschied bei MultiGPU und den PCIe Versionen mit zwei Vega 64 sind folgende: Klick (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11828497#post11828497)

PCIe 1.0 65fps
+69%
PCIe 2.0 110fps ( Entspricht PCIe 3.0 8x, also Zen/Zen+ )
+13%
PCIe 3.0 124fps

Ich sehe da noch kein Ende, zumal Grafikkarten ja auch schneller werden. :)
Es ist doch eigentlich lächerlich, dass ich mit einer x79 Plattform von 2011 mehr GPU Leistung fahren kann, als mit einem Ryzen und AM4 bzw. Coffee Lake und Z370.

[BoMbY]

Ja, ich weiß auch nicht warum wir von den Bäumen runter kommen sollen, uns geht es doch super hier oben?

[Lehdro]

Wenn PCIe 4.0 technisch möglich ist (und das scheint es), dann kommt es definitiv für AM4 & TR. Die Mainboardhersteller lechzen nach jedem Feature was man gewinnbringend vermarkten kann. PCIe 4.0 ist definitiv ein selling feature. Nebenbei gesagt: PCIe 3.0 x4, also der "normale" NVMe Anschluss stößt doch schon fast wieder an das Bandbreitenlimit. Für M.2/M.3 könnte PCIe 4.0 mehr als nur interessant sein, da Verdoppelung der Bandbreite bei gleicher Laneanzahl, oder halt halbe Laneanzahl bei selber Bandbreite. Wenn man sich AM4 so anschaut, könnte man dann mit PCIe 4.0 zum Chipsatz einen zweiten M.2 mit voller Bandbreite ohne Nebenwirkungen und Abstriche anbinden.

[Savay]

Es ist doch eigentlich lächerlich, dass ich mit einer x79 Plattform von 2011 mehr GPU Leistung fahren kann, als mit einem Ryzen und AM4 bzw. Coffee Lake und Z370.

Davon abgesehen das ich PCIe 4.0 für die Mainstream Plattformen mittelfristig allein schon für die Zunkunfssicherheit für sinnvoll halte:

Ähmm...aber dafür sind die HEDT Plattformen doch eigentlich da... da fehlt nur oft die "ultimative" Gaming CPU sondern es sind meistens eher Workstation CPUs und umfunktionierte Server Dies. :wink:
Die Plattformen sind nicht das Problem...eher das CPU angebot dafür! Es fehlen halt oft eher eine extrem hochtaktende CPUs mit weniger Kernen dafür.

Ich weiß auch nicht wo das Problem ist, das die Mainstreamplattformen eher rein auf Single GPU ausgelegt sind. (wie sie nunmal 99% der User nutzen...) SLI und CF ist nunmal kein Mainstream Feature mehr und wird es auch nicht mehr werden. :wink:
Die Sockel und Boards würden ja auch für den Großteil der Anwender deutlich aufgebläht teurer und komplexer ohne das sie was davon hätten!

Und ganz im Ernst:
Bei AM4 kann man sich aber IMHO eh absolut nicht beschweren...da hast du immerhin neben der GPU noch die NVMe SSD direkt an der CPU dank der 20 Lanes die über bleiben!

Davon abgesehen läuft nen kleiner TR mittlerweile ja schonmal nicht oder nur äußerst selten schlechter als ein 2700X in Spielen. ;)
Warum da als an mGPU interessierter Enthusiast nicht gleich zur großen Plattform greifen? So nen 12 Kerner macht sich da bestimmt ganz passabel.
Mit Zen2 wird sich das sicher nicht ändern...eher im Gegenteil wenn sich der Chiplet Aufbau auch für AM4 bewahrheiten sollte.

Nebenbei gesagt: PCIe 3.0 x4, also der "normale" NVMe Anschluss stößt doch schon fast wieder an das Bandbreitenlimit.

Aber auch wirklich nur fast...und bei AM4 im ggs. zur Intel Mainstreamplattform wenigstens nicht noch zusätzlich verkrüppelt. :wink:
Der 2. NVMe Anschluss wird da ja auch nur wegen dem statischen Routing als PCIe 2.0 über den Chipsatz limitiert...theoretisch sollte der auch sustained mit der vollen PCIe 3.0 Bandbreite laufen können.

Davon abgesehen ist die Bandbreite von NVMe ja für Heimanwender auf absehbare Zeit mehr als nur ausreichend...der merkt am ehesten in einigen Grenzfällen mal eher das mehr IOPS und die noch weiter gesunkenen latenzen. (aber auch nur noch extrem selten verglichen mit ner SATA SSD)

[gbm31]

Und wieder Quatsch, hatte hier ein SLI Brett mit PCIe 3.0 Support:
https://www.asrock.com/mb/Intel/Z68%20Extreme3%20Gen3/index.asp

Lief hier lange mit SB und IB abwechselnd, jeweils mit PCIe 2.0 und 3.0. Woher kommt das dumme Gerücht mit den Lanes? Das hat damit 0 zu tun, die Lanes takten mit IB einfach höher, da physisch auf dem Board schon dafür vorbereitet. Das einzige was 2.0 bleibt sind die beiden x1 Slots.

Board?

Gen3 konnten explizit pcie 3.0

https://www.overclock.net/forum/6-intel-motherboards/1242211-faq-does-my-p67-z68-motherboard-s-support-pci-express-3-0-a.html#/topics/1242211


ASRock z68 Pro3-m mit i7-3770k und GTX 1070Ti

[Daredevil]

SLI/Crossfire hat halt nichts mit Workstation zu tun, das ist eben das Ding.
Ich muss mir keinen 12 Kerner für 400€, ein Mainboard für 300€ und RAM für 200€ holen, damit ich Tomb Raider in 4k60fps spielen kann, wenn mein 200€ Bundle von früher genau die gleiche Performance schießt.

AM4 und Z370 Boards werden fleißig mit SLI und Crossfire beworben, Nvidia hat mit NVLink eine neue Ebene von SLI betreten, DX12 Support und MultiGPU wird immer besser. Es ist vielleicht minimal existent und horrend teuer/ineffizient, aber es ist nicht tot. :D


Skalierbarkeit ist ja etwas, wo sich jeder Hersteller eine goldene Nase verdienen würde. Ich glaube nicht, dass wir MultiGPU in Zukunft nicht mehr sehen werden. Gerade das pro Feature von Nvidia, dass der Speicherraum zusammen geführt werden kann, ist doch schon eine feine Sache.

Wenn es "HighEnd" Boards für 280€ gibt für AM4, dann sollen die halt auch HighEnd sein. :(

[Savay]

Ich muss mir keinen 12 Kerner für 400€, ein Mainboard für 300€ und RAM für 200€ holen, damit ich Tomb Raider in 4k60fps spielen kann, wenn mein 200€ Bundle von früher genau die gleiche Performance schießt.

Vergleichst du jetzt echt Neupreise mit ner alten aus der Bucht geschossenen HEDT/Workstation Plattform?! :freak:


Wenn es "HighEnd" Boards für 280€ gibt für AM4, dann sollen die halt auch HighEnd sein. :(

Das Problem ist halt nur, dass die Auslegung darauf es auch für alle anderen teurer macht die es absolut nicht brauchen...sorry...aber das ist ein schlechter tausch auf kosten der Anwender die nicht solche exotischen Anforderungen haben und das sind nunmal 99,99999% der Kunden!
Hier muss man die Kirche auch mal im Dorf lassen.

Es sind ja nicht nur ein "paar" Highend Boards die sich deshalb ändern müssten sondern die komplette Plattform und dessen auslegung müsste angepasst werden.
Ich hätte ehrlich gesagt echt kein Bock den scheiß mit bezahlen zu müssen obwohl ich ihn absolut nicht brauche!
Und das es beworben wird ist ja ok...es funktioniert ja auch...ganz ok eigentlich...nur halt nicht zu absolut 100% optimal...aber wer das braucht muss halt eher zu exotischeren Lösungen greifen...und der muss dann auch die Kröte mit den Mehrkosten schlucken.

Selbst wenn BTW alle Lanes des Zen Dies angebunden wären (die frage ist ja auch ob das Pinout das hergibt!), würde das noch nicht für zwei 16x Slots, eine NVMe (4x) und den Chipsatz (4x) reichen. :freak:
Nicht das man sich bei AMD überhaupt beschweren könnte das sie verglichen mit Intel zu geizig mit den Lanes gewesen wären. :tongue:

Das bei einer hypotetischen Chiplet Lösung für den Desktop das IO Chiplet auf einmal mit 40 Lanes daherkommt halte ich für vollkommen ausgeschlossen...das kostet ja auch wertvollen Diespace der für die meisten Anwendungsfälle komplett vergeudet wäre! (wenn es alles zusammen dann überhaupt noch unter den HS und auf den Träger passt!)

[gravitationsfeld]

Wenn PCIe 4.0 technisch möglich ist (und das scheint es)
So klar ist das fuer mich nicht. Die Pin-Sockel sind eigentlich schlechter was Signal-Qualitaet angeht.

Kommt Ryzen 3 sicher noch fuer AM4? Ich war schon erstaunt, dass sie fuer Ryzen keinen neuen genommen haben.

[Linmoum]

Meinst du mit Ryzen 3 jetzt die 3xxx-Serie oder Zen3? Ersteres kommt sicher für AM4, letzteres ist durchaus wahrscheinlich, da AM4 laut wiederholt offizieller Aussagen bis 2020 supported wird. Würde mich wundern, wenn sie Zen3 auf 2021 verschieben.

[Savay]

Da kommt IMO dann sicher nen AM4+ irgendwann hinterher mit PCIe 4.0 und später dann AM5 mit DDR5 usw.

Mit ähnlichen Spielchen wie mit AM3/AM3+ und AM2/AM2+ am Ende.
Ne AM4+ CPU läuft dann u.U. mit Fallback auf AM4 aber nicht umgekehrt oder sowas...eingeschränkt ist vielleicht sogar noch AM4+ kompatibel zu AM5 CPUs...oder irgendwas in der Art.

[Lehdro]

Ich war schon erstaunt, dass sie fuer Ryzen keinen neuen genommen haben.
Was? AM4 war explizit auf Ryzen ausgerichtet, der bissl APU Kram vorher war Bonus. Muss ja nicht jeder den Intel Weg gehen und alle zwei "Generationen" den Kunden veräppeln.

[iuno]

Witzig wird es spaetestens dann, wenn man wegen DDR5 neue Sockel bringt und dort dann neue packages kommen mit neuem i/o aber alten CPU chiplets ;)

[Brillus]

Meinst du mit Ryzen 3 jetzt die 3xxx-Serie oder Zen3? Ersteres kommt sicher für AM4, letzteres ist durchaus wahrscheinlich, da AM4 laut wiederholt offizieller Aussagen bis 2020 supported wird. Würde mich wundern, wenn sie Zen3 auf 2021 verschieben.

Wenn die mit dem IO-Chip druchziehen, kann es Zen3 auch gut mit AM4 und AM5 geben, je nachdem wie sich das IF-Interface ändert oder auch nicht könnte man für AM4 einfach das IO-Chiplet weiterverwenden und dann bräuchte man für AM5 einfach nur ein neues.

Ich habe auch sowas in Erinnerung das es zu Northbrighe Zeiten schon mal sowas gabe, ein CHip für 2 unterschiedliche Sockel.

[AlterSack]

Wenn die mit dem IO-Chip druchziehen, kann es Zen3 auch gut mit AM4 und AM5 geben, je nachdem wie sich das IF-Interface ändert oder auch nicht könnte man für AM4 einfach das IO-Chiplet weiterverwenden und dann bräuchte man für AM5 einfach nur ein neues.

Ich habe auch sowas in Erinnerung das es zu Northbrighe Zeiten schon mal sowas gabe, ein CHip für 2 unterschiedliche Sockel.


Ich hab noch einen Slot-A Thunderbird.:wink:

[gravitationsfeld]

Was? AM4 war explizit auf Ryzen ausgerichtet, der bissl APU Kram vorher war Bonus. Muss ja nicht jeder den Intel Weg gehen und alle zwei "Generationen" den Kunden veräppeln.
Mit neu meinte ich LGA statt PGA. Aber schon richtig, ich hatte irgendwie im Kopf, dass AM4 immer noch gleich viele Pins hat wie AM2/3/939/940.

[Ravenhearth]

Zusammenfassung von Wikichip: AMD Discloses Initial Zen 2 Details (https://fuse.wikichip.org/news/1815/amd-discloses-initial-zen-2-details/)

[basix]

Gute Zusammenfassung. Was neues steht aber nicht drin.

[Eldoran]

Charlies twitter (https://mobile.twitter.com/CDemerjian/status/1064674656781824000?p=v) habe ich ein interessantes Detail gefunden - die haben von dem Cray Rechner (Shasta) die Spezifikation des Kühlsystems zurückgerechnet, die auf max 250W/CPU spezifiziert ist. Laut Charlie sollen es 240W werden, es dürfte also eine massvolle Steigerung des Verbrauchs geben. An sich ist ja etwas Mehrverbrauch zu erwarten - mehr/schnellere IF Links, schnelleres RAM, PCIe 4.0 sollte schon allein für mehr Verbrauch sorgen.

[Eldoran]

Neue Belege zu dem potentiellen IF/CCIX support von EPYC:
https://www.servethehome.com/xilinx-alveo-u280-launched-possibly-with-amd-epyc-ccix-support/
Xilinx Alveo U280:
PCI Express: Gen4x8 with CCIX

[Deinorius]

@Eldoran
Ich dachte, Epyc hat eine TDP von 250 W.

[HOT]

Jo soweit ich weiss ändert sich da überhaupt nix. Epyc2 schafft fast exakt doppelte Performance/W lt. AMDs Benchmark.

[Gipsel]

@Eldoran
Ich dachte, Epyc hat eine TDP von 250 W.
Nein. Maximal 180W je nach Modell. (https://www.amd.com/system/files/2017-06/AMD-EPYC-Data-Sheet.pdf)

Und die Schlußfolgerungen, die Epyc2 anhand des Kühlsystems auf 240/250W taxieren, stehen auf sehr wackligen Beinen (es werden sicher keine 2 CPUs an einer Kupferplatte gesandwitched [paßt mechanisch mit dem RAM nicht], maximal wird da der Slingshot-NIC gekühlt [bzw. alternativ eine GPU?]). Sicher sind 250W möglich, aber da würde ich eher ranziehen, daß der TR2990WX bereits jetzt 250W TDP hat.

[Deinorius]

Ach ja, der hat 250 W...

[Relic]

Nein. Maximal 180W je nach Modell. (https://www.amd.com/system/files/2017-06/AMD-EPYC-Data-Sheet.pdf)

Und die Schlußfolgerungen, die Epyc2 anhand des Kühlsystems auf 240/250W taxieren, stehen auf sehr wackligen Beinen

4% Sicherheit im Kühlsystem bei einem Millionen teurem Supercomputer wäre mir persönlich etwas knapp ^^

[BoMbY]

Hmm. Das wurde angeblich im Februar 2015 in Japan gezeigt (https://twitter.com/KOMACHI_ENSAKA/status/1064930452421586944):

https://pbs.twimg.com/media/Dsdkjr0UwAAJvTE.jpg:orig

https://pbs.twimg.com/media/DsdklI-VYAAAatn.jpg:orig

Multi TFlops 64-bit HPC APU ...

[reaperrr]

Hmm. Das wurde angeblich im Februar 2015 in Japan gezeigt (https://twitter.com/KOMACHI_ENSAKA/status/1064930452421586944):

Multi TFlops 64-bit HPC APU ...
Ursprünglich waren mal HPC-APUs geplant, bei denen z.B. Vega10 mit einem Zeppelin-Die über IF verbunden wird.

M.E. wird da aber nichts mehr draus, weil Kühlung, Verbrauch und Assembly zu viele Kompromisse erfordern würden und so eine APU eben nichts Halbes und nichts Ganzes wäre, weil man weder die CPU-Leistung einer dedizierten CPU noch die GPU-Leistung einer dedizierten GPU erreichen würde.
Und wenn man sich die Supercomputer so anschaut, geht es sowohl bei CPUs als auch GPUs hauptsächlich um Leistung.
Gleiches Problem wie bei (richtigen) Spiele-PCs also.

[iuno]

@BoMbY: was soll uns der Tweet Neues sagen? Das ist uralt und wurde auch damals schon hier besprochen. Es stand damals auch offiziell auf der Roadmap, dass man eine HPC APU plant.

[BoMbY]

Es stand damals auch offiziell auf der Roadmap, dass man eine HPC APU plant.

Welche offizielle Roadmap soll das gewesen sein?