Opteron APU in 20nm, was ist möglich?

[Gipsel]

Weil das im VI-Thread aufkam, hier mal ein neuer Thread dazu.

http://abload.de/img/volcanic-islands26iur9.jpghttp://abload.de/img/1j5sqq.jpg
Also für mich sieht das eher nach einer Skizze eines hybriden Opterons aus. Es gibt acht 72bit (64Bit+ECC) Speicherinterfaces für DDR3, wenn ich das richtig entziffere. Außerdem sind dort nur 16 CUs zu erkennen, also "nur" 1024 SPs. Und die paarweise Anordnung der Kerne erinnert doch irgendwie an Bulldozer. Außerdem, steht in der Mitte zwischen zwei Kernen in dem blauen Feld nicht "FPU"? Das ist also meiner Meinung ein high-level-Blockdiagramm eines 16 Kern-Bulldozer-Derivats mit 16 CUs (1024 SPs) und 8kanaligem DDR3-Speicherinterface (Bandbreite 136GB/s bei DDR3-2133).
Im SA-Forum gibts das Bild in hoher Auflösung (aber in einem anderen Stil) übrigens schon seit September 2012. Also Fake?

http://abload.de/img/8006662970_d953f3c45bllzom.jpg (http://abload.de/image.php?img=8006662970_d953f3c45bllzom.jpg)
http://www.semiaccurate.com/forums/showpost.php?p=168728&postcount=7

Könnte eine Opteron APU sein?
Sag' ich doch ;). Im Übrigen hat der Poster des Bildes bei SA unter das Bild geschrieben: "(Nevermind what's on the image, it's irrelevant to the topic of PI and VI)". Der hat das nur als Teaser benutzt und als Idee, was man unter 20nm so ungefähr auf ein Die quetschen könnte. Ob es echt ist oder nicht, läßt sich damit nicht entscheiden. Aber daß es nicht zu VI oder PI gehört, sollte klar sein.

PS:
Bei Chiphell haben die übrigens nur die Farben invertiert und das Bild aufgeblasen. :freak:

[marc-05]

Opteron mit fetten GPU :confused: dann eher PS4 Chip die 1024 Shader aka 7850 würden passen.

[Gipsel]

Opteron mit fetten GPU :confused: dann eher PS4 Chip die 1024 Shader aka 7850 würden passen.
Mit 16 (Steamroller?)-Kernen bei vermutlich höherem Takt ist das Ding bei seriellen Workloads (wenn die CUs nicht genutzt werden, kann das Teil recht hoch boosten) vermutlich deutlich schneller als der PS4-Chip mit 8 Jaguar-Kernen (und übrigens 18CUs, nicht 16).

[marc-05]

PCM ist GPU Teil 16 CUs ~ 170mm²

SPMs CPU Teil mit 8 Einheiten/Kernen/Threads

Mit z.B 16 Steamroller Threads wird "das Ding" ein Monstrum von Chip

[S940]

Sieht nett aus, aber 8 Kanäle DDR3??
Wenn dann doch DDR4, was will man mit DDR3 in ~2 Jahren. Außerdem: Wieviel Pins wären dafür nötig? Das würde doch "etwas" kompliziert werden ...

Maximal sehe ich die Hälfte realistisch. Quad-Channel ist doch auch schon was Feines. 4 Module reichen, die 1024 SPUs kann man vielleicht lassen, 512 wären zu wenig.

Edit:
Würde man was gewinnen, wenn man den Sockel streichen würde, und den Chip direkt verlöten würde?
Für ne Seamicro-Karte wäre das Teil ja sicherlich nicht schlecht. Da man dort Karten tauschen kann, wär ein Sockel eventuell überflüssig.

[Nakai]

Egal was das für ein Chip sein könnte, sowas werden wir erst Mitte/Ende 2014 sehen. Wäre schön, wenn das Ding eine bessere DP:SP-Ratio(1:4) hätte.


0,8 * 1024*2 (~1600) + 16 * 8 * 4,0 (~500) ~ 2,1 TFLOPs (SP)

400 + 250 = 0,650 TFLOPs (DP)

Wäre das eine Konkurrenz zu Maxwell und Xeon Phi?

€: Reinher von den FLOPS kommt man weder gegen Maxwell oder Xeon Phi an. Die zusätzlichen CPU-Kerne könnten aber doch ein guter Vorteil sein.

[Gipsel]

PCM ist GPU Teil 16 CUs ~ 170mm²

SPMs CPU Teil mit 8 Einheiten/Kernen/Threads

Mit z.B 16 Steamroller Threads wird "das Ding" ein Monstrum von ChipDu vergißt, daß das Teil für 20nm im Raum steht. Schon ein Pitcairn mit 20CUs und 256Bit-Interface nimmt nur 212mm² ein, die CUs selber sind davon ~100mm². Selbst mit dem ganzen Drumherum, was da noch benötigt wird, der komplette PCM-Teil sollte in 20nm wohl in 100mm² passen, selbst mit 1:2 DP Rate (die hier für einen Opteron-Einsatz vermutlich angesagt wäre).
Und es sind übrigens 16 CPU-Kerne im SPM-Teil, nicht nur 8. Es sind 8 Dual-Core-Module.
Sieht nett aus, aber 8 Kanäle DDR3??
Wenn dann doch DDR4, was will man mit DDR3 in ~2 Jahren. Außerdem: Wieviel Pins wären dafür nötig? Das würde doch "etwas" kompliziert werden ...

Maximal sehe ich die Hälfte realistisch. Quad-Channel ist doch auch schon was Feines. 4 Module reichen, die 1024 SPUs kann man vielleicht lassen, 512 wären zu wenig.Du willst das Teil ja auch angemessen füttern. Bandbreite ist dafür schon wichtig, wenn man sich mal ansieht, daß ein Pitcairn auf heutigen GPUs ja auch mal so um die 150GB/s zur Verfügung hat. Auf übermäßig viel weniger will man sich vermutlich nicht unbedingt einlassen, wenn man es vermeiden kann. Wie genau diese Bandbreite erreicht wird, dürfte erstmal egal sein (und eventuell hat das zum Zeitpunkt der Erstellung der Grafik auch noch gar nicht festgestanden), aber 100+GB/s wären schon wünschenswert. Das würde natürlich mit aufgelötetem Speicher einfacher bzw. mit schmalerem Interface zu realisieren sein, was aber die Flexibilität bei der Menge des Speicherausbaus einschränkt. Das ist ja auch ein Schwachpunkt von DDR4, daß man nur ein einziges Modul pro Kanal benutzen kann. Um die für Server üblichen Speicherausbauten (4 bis 8GB+ pro Kern) hinzubekommen, benötigt man schon ein paar mehr Kanäle, schlicht um mehr Module benutzen zu können. So einen 16Kerner mit noch 16 CUs würde man vermutlich (natürlich je nach genauem Einsatzzweck) möglichst mit 128GB RAM betreiben, wenn nicht gleich mit 256GB RAM. Bei nur 4 Speicherkanälen, bräuchte man dafür schon DIMMs mit einer Kapazität von 32GB oder gar 64GB. In den Regionen wird das schweineteuer (der Preis steigt irgendwann deutlich stärker als linear mit der Kapazität; doppelte Kapazität, 4facher Preis oder sowas), falls es sie überhaupt gibt (momentan gibt es maximal 16GB DDR4 DIMMs, 32 GB sind für die nähere Zukunft geplant, 64GB geht wohl nur mit Stacking von Chips auf dem DIMM => extrateuer). 16GB DIMMs für 8 Kanäle dürften da deutlich eher erschwinglich sein als 32 GB DIMMs oder gar noch größere.

[S940]

Gipsel schon klar, aber irgendwie hab ich Angst um den Sockel (und die ganzen Pins). PCIe muss ja auch noch nach außen geführt werden. Aber gut - immerhin sparte man sich die Hypertransportanschlüsse.

Zu DDR4:
Die 16GB sind schon mit unbuffered Modulen geplant, gibts bei DDR4 keine reg. Module? Da sollte mehr eigentlich kein Problem sein. Es gibt heute schon registered 32GB DDR3 quad-rank Module:
http://geizhals.de/crucial-dimm-32gb-pc3l-8500r-reg-ecc-cl7-ddr3l-1066-ct409672bq1067q-a673183.html

Glaube kaum, dass DDR4 da schlechter werden würde. Aber gut - teuer sind sie, das stimmt ^^

[Skysnake]

Sieht nett aus, aber 8 Kanäle DDR3??
Wenn dann doch DDR4, was will man mit DDR3 in ~2 Jahren. Außerdem: Wieviel Pins wären dafür nötig? Das würde doch "etwas" kompliziert werden ...

72Bit*2 differenzielle Leitungen*8 -> >=1152 Pins nur für den Speicher

DDR3 ist halt JETZT verfügbar, und nicht irgendwann. Wenn das Ding noch dieses Jahr raus kommen würde, dann wäre es schon ziemlich fett :cool:

AMD hat ja für dieses Jahr auch APU-Opterons angekündigt, wobei man da ja eher von kleineren Geschützen ausgegangen ist :ugly:


Maximal sehe ich die Hälfte realistisch. Quad-Channel ist doch auch schon was Feines. 4 Module reichen, die 1024 SPUs kann man vielleicht lassen, 512 wären zu wenig.

Quad-Channel ist VIEL VIEL VIEL VIEL zu wenig. Nen normaler Opteron mit 8 Modulen hat ja schon Quadchannel und ist damit tendenziell eher unterversorgt. Wenn da jetzt 8 Module+iGPU drauf sind, dann ist Octa-Channel das absolute Minimum. Besser wäre noch ein fetter eDRAM, und/oder GDDR5. Wobei eben DDR3 sich für die CPU besser eignet. Die optimale Lösung wäre eDRAM+HMC


Edit:
Würde man was gewinnen, wenn man den Sockel streichen würde, und den Chip direkt verlöten würde?

An "Pins" rein gar nichts. Du kannst aber VIEL leichter höhere Taktraten erreichen. Das ist dann natürlich auch für den Verbrauch ein Vorteil.

Für ne Seamicro-Karte wäre das Teil ja sicherlich nicht schlecht. Da man dort Karten tauschen kann, wär ein Sockel eventuell überflüssig.
Ja, da wäre das durchaus ohne Problem machbar. Server mit fest verlötetem Speicher wird man in Zukunft eh immer mehr sehen. DIMMs sind für wassergekühlte Server scheise.

Du vergißt, daß das Teil für 20nm im Raum steht. Schon ein Pitcairn mit 20CUs und 256Bit-Interface nimmt nur 212mm² ein, die CUs selber sind davon ~100mm². Selbst mit dem ganzen Drumherum, was da noch benötigt wird, der komplette PCM-Teil sollte in 20nm wohl in 100mm² passen, selbst mit 1:2 DP Rate (die hier für einen Opteron-Einsatz vermutlich angesagt wäre).
Und es sind übrigens 16 CPU-Kerne im SPM-Teil, nicht nur 8. Es sind 8 Dual-Core-Module.

Ja, 1:2 DP:SP würde ich da auch erwarten.

Was noch auffallen ist, ist, das man gleich 4ACEs hat ;)


Das würde natürlich mit aufgelötetem Speicher einfacher bzw. mit schmalerem Interface zu realisieren sein, was aber die Flexibilität bei der Menge des Speicherausbaus einschränkt. Das ist ja auch ein Schwachpunkt von DDR4, daß man nur ein einziges Modul pro Kanal benutzen kann.

Dafür wird man leichter/billiger auch 32+ GB Module bekommen. Ich mein mich an 128/256 GB Module zu erinnern in den Planungen.

Um die für Server üblichen Speicherausbauten (4 bis 8GB+ pro Kern) hinzubekommen, benötigt man schon ein paar mehr Kanäle, schlicht um mehr Module benutzen zu können.

4/8 GB Pro Kern ist aber SEHR SEHR tief angesetzt. Das willst du eigentlich als Minimum haben. Für Bigdata und HPC usw will man so viel Speicher wie nur irgendwie möglich. Sprich ~34-64 GB/Kern. Mehr ist heutzutage einfach nicht machbar.

Gerade wenn man aber an Checkpointing usw denkt, dann ist das schon sehr wichtig.

Vor allem reduziert sich die nutzbare Speichermenge ja auch wieder, wenn man die Daten im RAM nochmals spiegelt, um die Ausfallsicherheit zu erhöhen.

Was euch bisher auch noch nicht aufgefallen ist, ist der kleine Kasten in dem
"RAS Features& Error xy" steht. Die Opterons bekommen also RAS Features, und treten damit eventuell in Konkurrenz zu Westmere/IB-EX. Meines Wissens nach haben die aktuellen Opterons noch gar keine RAS-Features.

PCI-E 3 ist wohl auch dabei, wenn ich das richti gelesen habe.

Ansonsten noch ARM A5 für die Secure Sachen, was ja auch schon von AMD angekündigt wurde.

Erstaunlich ist aber auch noch der Hardware-Load-Balancer. Was steckt dahinter? Kann eventuell x86 Code, der eine hohe Parallelität hat automatisch auf die CUs umgeleitet werden? Das ist ja auch der Hintergedanke von HSA. Wäre ziemlich fett.

Wenn ich das Diagramm richtig deute, dann hat man auch einen gesharten L3.

Fragt sich dann nur, was das letzte Kästchen noch ist. Ein L4/eDRAM?
Ok, das ist der SystemControllerChip/MCM. Das macht wohl auch sinn, wenn die iGPU direkt auf die Platten zugreifen können soll/muss für swapabel pages.

[Botcruscher]

Selbst mit HUMA irgendwie sehr für Randgruppen. Welchen Vorteil bringt eine APU gegen mehr CPU-Leistung+ Grafikkarte?

[Skysnake]

Das du komplett neue Problemgruppen angehen kannst, die bisher für GPU-Beschleunigung unbrauchbar sind, weil man den Overhead durch den Datantransfer auch mit unendlicher Rechenleistung nicht kompensieren kann.

Und ja, davon gibt es mehr als genug Probleme.

[Gipsel]

Dank S940 gibt es jetzt im Startpost eine hochaufgelöste Variante des "Originals" des Diagramms, in dem man alles problemlos lesen kann. Aber das sagt natürlich nicht aus, daß das nicht trotzdem einfach was Selbstgezeichnetes von dem oben verlinkten SA-Foren-Member ist.

[S940]

Wenn ich das Diagramm richtig deute, dann hat man auch einen gesharten L3.
Jo den hab ich in der Großversion jetzt auch gesehen. Machts dann doch etwas unglaubwürdig, oder nicht?
Für 8 Module müsste man wohl 16MB L3 einplanen, das wär von der Fläche her dann doch langsam etwas viel, v.a. zusammen mit der GPU.

Gut - eventuell bekommt jedes Modul nur 1 MB L2, damit würden dann 8 MB L3 reichen, würde aber doch trotzdem noch ziemlich groß sein, oder nicht?

Glaubwürdig wirds mMn nur wg. der relativ bescheidenen 1024 SPUs ;-)

Danke für die anderen Anworten.

Dank S940 gibt es jetzt im Startpost eine hochaufgelöste Variante des "Originals" des Diagramms, in dem man alles problemlos lesen kann. Aber das sagt natürlich nicht aus, daß das nicht trotzdem einfach was Selbstgezeichnetes von dem oben verlinkten SA-Foren-Member ist.Immerhin ist jetzt auch noch ne Legende dabei ... einerseits könnte die WCCFtech auch dazugedichtet haben, andererseits ist die Bedeutung der "disabled Units" wohl nicht so einfach aus den Fingern zu saugen.

[Gipsel]

Jo den hab ich in der Großversion jetzt auch gesehen. Machts dann doch etwas unglaubwürdig, oder nicht?
Für 8 Module müsste man wohl 16MB L3 einplanen, das wär von der Fläche her dann doch langsam etwas viel, v.a. zusammen mit der GPU.

Gut - eventuell bekommt jedes Modul nur 1 MB L2, damit würden dann 8 MB L3 reichen, würde aber doch trotzdem noch ziemlich groß sein, oder nicht?Wieso? In 20nm wären 16MB L2 kleiner als die 8MB der momentanen FXen und Opterons in 32nm. Also ich sehe da kein größeres Problem.

[Skysnake]

Ah, das war die Northbridge, die ich fälschlicherweise für den L3 hielt ;D

Also da spricht absolut NICHTS dagegen, da die iGPU eben nicht direkt am L3 hängt, sondern "nur" über die Northbridge darauf zugreift. Ob das jetzt so super ist, muss sich zeigen.

Die CPU kann halt so den L3 für sich alleine nutzen, "sieht" aber Zugriffe und Änderungen der iGPU doch recht schnell. Man kann die ganzen Kohärenzsachen da recht einfach weiternutzen, die es bisher auch schon gibt.

Die CPU kann vor allem halt relativ ungestört arbeiten. Dafür dauert der Datenaustausch zwischen CPU und iGPU doch etwas länger, weil man keinen echt geteilten Speicher hat.

Was jetzt schwerer wiegt muss sich erst noch im realen Einsatz zeigen.

[Nakai]

Ja, 1:2 DP:SP würde ich da auch erwarten.




Du vergißt, daß das Teil für 20nm im Raum steht. Schon ein Pitcairn mit 20CUs und 256Bit-Interface nimmt nur 212mm² ein, die CUs selber sind davon ~100mm². Selbst mit dem ganzen Drumherum, was da noch benötigt wird, der komplette PCM-Teil sollte in 20nm wohl in 100mm² passen, selbst mit 1:2 DP Rate (die hier für einen Opteron-Einsatz vermutlich angesagt wäre).
Und es sind übrigens 16 CPU-Kerne im SPM-Teil, nicht nur 8. Es sind 8 Dual-Core-Module.

Schön dann:
2*400 + 250 = 1,05 TFLOPs (DP)

Schön, dann auf 1 TFLOP hochskaliert.

Ist das Diagramm überhaupt einen Thread wert? Sicherlich, sowas ist unter 20nm möglich. Die Frage die viel wichtiger ist, ist jedoch: Kommt sowas in der Art auch auf den Markt?

Imo ist das nur Wunschdenken eines Users. Natürlich sind da viele kleine Details drin, die darauf schließen, dass es kein Hirngespinnst eines Users ist, sondern tatsächlich kommen könnte. Außerdem stürzen sich sehr viele auf dieses Diagramm, was darauf schließen könnte, dass dem nicht so ist.

[Skysnake]

Kommen wird so was in der Art definitiv früher oder später. Obs genau so aussieht, kann aber durchaus bezweifelt werden.

[Godmode]

Kann man den absehen, wann GF 20nm für AMD fertigen kann?

[Skysnake]

Keine Ahnung, wäre aber theoretisch auch bei TSMC möglich, da APU.

[S940]

Wieso? In 20nm wären 16MB L2 kleiner als die 8MB der momentanen FXen und Opterons in 32nm. Also ich sehe da kein größeres Problem.
Auch wieder wahr ... wir sollten mal die "Hauptsachen" auflisten.
GPU-Teil von Dir oben:
100mm²
1 Steamrollercore mit 2 MB Cache: 30,9 mm² /1,41 = 22 mm2
Mal 8 = 176mm² also runde 180mm²
(32nm Wert von Piledriver durch den Fullnodescalingfaktor, die half-node von 22 auf 20nm rechnen wir mal grob mit gatefirst <> gate last auf)
L3 Segmentschätzung: Ungefähr die Hälfte eines BD-Moduls, sagen wir mal 10 mm2 für 2 MB.
Mal 8 = 80 mm²

Damit wären wie jetzt bei 360 mm² mit CPU+L3+GPU. Fehlt noch der ganze UNB Krams. Ist bei Orochi ziemlich viel und luftig gebaut, aber wenn man da günstige ~50mm² ansetzt ist man auch schon über 400mm²

Möglich, dass die Modulschätzung schlecht ist, aber ein Steamrollermodul wird mit der verdoppelten Sprungvorhersage und dem 96kB L1I$ wohl eher größer als kleiner, da hilft auch nicht die Flächenersparnis bei der synth. FPU.

Keine Ahnung, wäre aber theoretisch auch bei TSMC möglich, da APU."Große" APUs kamen bisher immer von GF. Halt die, die Probleme machen :freak:

Problem das man bei so nem Riesendie hat, wären natürlich schlechte Yields. Selbst wenn GF meldet, dass sie Ende 2013 20nm herstellen würden, würde ein ~400mm² DIE ziemlich miserable Ausbeuten haben.

Schätze also, dass das eher was für 2015 wäre, wenn der 20mn Prozess eingefahren ist.

[mczak]

Das ist doch sicher Fake. Was sollen z.B. die 4 Geometry/Raster Engines? Für Compute Tasks braucht man die gar nicht, und selbst für Grafik sind die bei 16 CUs Overkill (demgegenüber sind 4 ACEs für einen Compute-Part nicht gerade viel wenn man bedenkt dass die PS4 das massiv aufgebohrt hat). Ausserdem, 16 RBEs ist zwar sehr wohl denkbar für einen solchen Chip, aber doch nicht organisiert als single-RBEs.
Ausserdem müsste ein solcher Chip wohl mindestens 150W TDP haben damit man da überhaupt einigermassen sinnvolle Taktraten erreichen kann (und damit meine ich nicht maximale Taktraten sowohl beim CPU wie beim GPU-Teil das würde eher 300W benötigen...). Gut so weit entfernt von den jetzigen HE Versionen wäre das auch nicht (140W).

[Skysnake]

Mehr als 4 ACEs machen keinen Sinn. Bei GCN bilden ja 4 CUs die kleinste vollständige Logikeinheit, da man sich ja den Instructioncache.http://www.hardwareluxx.de/images/stories/newsbilder/astegmueller/2011/expreview_amd_hd_7000_gcn-01.jpg

Und mit 4 ACEs bist du halt bei genau 16 CUs. Mehr macht also wirklich kaum Sinn. Die ACEs kann man ja noch immer aufbohren.

Du musst ja bedenken, das TahitiXT mit 32 CUs ja gerade mal 2 ACEs hat...

[Gipsel]

1 Steamrollercore mit 2 MB Cache: 30,9 mm² /1,41 = 22 mm2
Mal 8 = 176mm² also runde 180mm²
(32nm Wert von Piledriver durch den Fullnodescalingfaktor, die half-node von 22 auf 20nm rechnen wir mal grob mit gatefirst <> gate last auf)Der Fullnode-Scaling-Faktor ist immer 2. Man betrachtet ja Flächen, da mußt Du Deine 1,41 quadrieren. ;)
Was sollen z.B. die 4 Geometry/Raster Engines? Für Compute Tasks braucht man die gar nicht, und selbst für Grafik sind die bei 16 CUs Overkill (demgegenüber sind 4 ACEs für einen Compute-Part nicht gerade viel wenn man bedenkt dass die PS4 das massiv aufgebohrt hat).Das mit dem Frontend ist mir auch aufgefallen. Insbesondere bilden die ACEs weder Blöcke mit den Geometrie-Engines und Rasterizern, noch hängen sie unter dem Command-Processor (die sind parallel angeordnet, eine ACE ist selber ein abgespeckter Command-Processor).
Und so wirklich dem GCN-Schema entspricht die Zeichnung ja auch nicht. Bei GCN hat nicht jede CU eigene skalare und I-Caches.
Ausserdem müsste ein solcher Chip wohl mindestens 150W TDP haben damit man da überhaupt einigermassen sinnvolle Taktraten erreichen kann (und damit meine ich nicht maximale Taktraten sowohl beim CPU wie beim GPU-Teil das würde eher 300W benötigen...). Gut so weit entfernt von den jetzigen HE Versionen wäre das auch nicht (140W).Das kann ich jetzt nicht nachvollziehen. AMD verkauft in 32nm produzierte 16-Kerner (dual Die), die je nach Version auch deutlich unter 100W konsumieren. Und ein Pitcairn mit 20CUs bekommt man in 28nm auch mit noch halbwegs ansprechenden Takten in ~100W gequetscht (und das ist für die ganze Karte, da sind Speicher und Spannungswandler dabei). In 20nm dürften da 140W (oder auch weniger) locker machbar sein (und wenn der GPU-Teil wenig genutzt wird, boosten die CPU-Kerne kräftig oder auch andersrum).

Aber ich stimme mit Dir überein, daß die Zeichnung vermutlich ausgedacht ist. Wahrscheinlich sogar von dem 268.... (keine Ahnung, wie die Nummer genau lautet) im SA-Forum.
Mehr als 4 ACEs machen keinen Sinn. Bei GCN bilden ja 4 CUs die kleinste vollständige Logikeinheit, da man sich ja den Instructioncache.
[..]
Und mit 4 ACEs bist du halt bei genau 16 CUs. Mehr macht also wirklich kaum Sinn. Die Zahl der ACEs ist erstmal völlig unabhängig von der Zahl der CUs. Die PS4 hat z.B. 8 ACEs (die jeweils 8 Command-Queues verwalten können, also in der Summe 64 Queues), aber nur 18CUs. ;)

[S940]

Der Fullnode-Scaling-Faktor ist immer 2. Man betrachtet ja Flächen, da mußt Du Deine 1,41 quadrieren. ;)
Mist irgendwie lebe ich mit dem Umrechnungsfaktoren immer noch auf Kriegsfuß ^^

Also dann mit 2:
30,9 / 2= 15,5
Mal 8 = 124 mm² schon mal besser.

L3-Cache:
8 x 7mm² = 56 mm²

Zusammen: 180 mm² (viel besser ^^).
Plus GPU: 100 mm²
-----------
280 mm²

Wenn man jetzt selbst 100mm² für UNB und Co ansetzt bleibt man mit 380mm² noch schön unter 400 mm²

Wäre dann eigentlich wirklich machbar. Bisschen größer als Orochi vielleicht.
Krass .. das ganze Zeugs und nicht viel größer :freak:

[mczak]

Das kann ich jetzt nicht nachvollziehen. AMD verkauft in 32nm produzierte 16-Kerner (dual Die), die je nach Version auch deutlich unter 100W konsumieren. Und ein Pitcairn mit 20CUs bekommt man in 28nm auch mit noch halbwegs ansprechenden Takten in ~100W gequetscht (und das ist für die ganze Karte, da sind Speicher und Spannungswandler dabei). In 20nm dürften da 140W (oder auch weniger) locker machbar sein (und wenn der GPU-Teil wenig genutzt wird, boosten die CPU-Kerne kräftig oder auch andersrum).

Naja es gibt zwar (wenige) 16-Kerner die unter 100W sind (85W), aber sinnvoll ist das nicht mehr wirklich wenn du dir die erreichten Taktraten ansiehst (von "HE" sieht man da bei den 85W Versionen jedenfalls nichts mehr steigt doch die TDP ziemlich linear zur Frequenz). Für vernünftige Taktraten brauchst du die 115W Versionen. Und ich bin davon ausgegangen dass 20nm gegenüber 32nm SOI verbrauchsmässig nicht so wahnsinnig viel bringt, und man den GPU-Teil auch noch etwas benutzen möchte ohne dass der CPU-Takt gleich in den supertiefen Bereich absackt. Aber klar solange man bloss hauptsächlich den CPU- oder GPU-Teil nutzt reichen auch weiterhin 115W locker, ansonsten müsste man halt wohl mit grösseren Takteinschränkungen leben.

[Skysnake]

Und wo ist das Problem? Man hat da ja keine Latenzkritischen Tasks, sondern welche, die einfach mit möglichst wenig Ressourcen überhaupt erledigt werden sollen.

@Gipsel:
Ja, aber die CUs sehen da ja auch etwas anders aus. Bei der PS4 kann ich mir auch gut vorstellen, dass die Ansteuerung der CUs eben nicht gleich ist, sondern manche eine eigene ACE haben, und andere sich einen teilen müssen

[Gipsel]

@Gipsel:
Ja, aber die CUs sehen da ja auch etwas anders aus. Bei der PS4 kann ich mir auch gut vorstellen, dass die Ansteuerung der CUs eben nicht gleich ist, sondern manche eine eigene ACE haben, und andere sich einen teilen müssenPrinzipiell können die Wavefronts eines Kernels von jeder ACE an alle CUs verteilt werden. Eine ACE ist (normalerweise) nie nur für einen Teil der CUs zuständig, sondern verteilt die Aufgaben in seiner/seinen Queues auf alle CUs.

[Skysnake]

Würde es aber deutlich einfacher machen, was ich sagen will, man könnte die Verdrahtung und Logik der ACEs eben sehr entschlacken, und dafür mehr in Branches und SP:DP investieren.

Wäre ja auch durchaus gut, wenn man 4 ACEs mit jeweils 4 CUs hat. Da könnte man ein schönes Mapping machen, das sich eben jeweils 2 Module 1 ACE teilen. Also fixes mapping.

Wenn man dann pro ACE 8 Queues hätte ;) dann könnte man jede ACE mit jeweils 4 CUs von einem Modul parallel ansprechen lassen. Also praktisch die gleiche logische Aufteilung wie die FPUs bei AVX Code darstellen.

4CUs sind halt die kleinste geschlossene logische Einheit unter dem gesamten Chip mit L2 für GCN.

Das klingt schon sehr nett und vor allem einfach, weil man die gleichen Strukturen auf der CPU und auf der GPU hätte. Die GPU würde dann mehr oder weniger nur wie extrem fette "Register" für die CPU aussehen. Halt 2048 Bit register :biggrin:

Das könnte man schon so ähnlich machen wie bei MIC, nur eben nochmals vier mal so fett.

Zumindest ICH fände das schon sehr geil, und würde da die fehlende Flexibilität auch nicht wirklich vermissen. Wenn ich weniger als 2048 Bit breite Operationen hätte, also z.B. eben nur 512 würde ich wohl eh mit AVX besser wegkommen.

Man könnte halt wirklich die unterschiedlichen Rechenwerke wieder mehr auf ihre Spezialbereiche trimmen. Gerade bei der GPU eben einiges an Aufwand, den man für den besseren Umgang mit feinerer Granularität macht wieder weglassen.

[Gipsel]

Und was passiert bei einem fixen Mapping von ACEs zu CUs, wenn Du einen Kernel hast (der ja nur in einer Queue auf einem ACE drinsteht), der aber die komplette GPU, also alle CUs nutzen soll?
Nee nee, das ist schon in Ordnung so und auch flexibler, daß alle ACEs alle CUs befeuern können. Die Verteilung künstlich auf ein Subset einzuschränken, wenn der Entwickler das will (device fission, was die ACEs ja angeblich unterstützen), wird davon ja nicht berührt.

[Liszca]

Sieht nett aus, aber 8 Kanäle DDR3??

Ich verstehe da eher Speicherbänke, was eigentlich fast nichts über die Anzahl der Kanäle sagt.

[S940]

Ich verstehe da eher Speicherbänke,
Begründung?
72-Bit ist die nornmale Breite eines ECC-DDR3-Kanals, wüsste nicht, wieso man das irgendwie anders interpretieren sollte.

[Skysnake]

Und was passiert bei einem fixen Mapping von ACEs zu CUs, wenn Du einen Kernel hast (der ja nur in einer Queue auf einem ACE drinsteht), der aber die komplette GPU, also alle CUs nutzen soll?
Nee nee, das ist schon in Ordnung so und auch flexibler, daß alle ACEs alle CUs befeuern können. Die Verteilung künstlich auf ein Subset einzuschränken, wenn der Entwickler das will (device fission, was die ACEs ja angeblich unterstützen), wird davon ja nicht berührt.
Dann kann man noch immer durch den Commandprozessor usw die Sachen in mehrere ACEs reinschieben ;)

Am Ende kommts eh darauf an, was in der realen Implementierung halt leichter/geschickter zu machen ist.

[2phil4u]

Welche Leistung haette denn das Teil ohne GPU-Teil und wie gut ist der GPU-Teil im Vergleich zu aktuellen Grafikkarten.
Sicher waere das Ding zwar eher für GPU-Computing gedacht, aber irgendwie sagen mir die ganzen Werte wenig.

Wobei das Ding natürlich pure Spekulation ist.
Solange AMD nicht irgendwas wirklich leistungsstarkes praesentiert, glaube ich gar nix.

Da kann man gleich den Roadmaps von Globalfoundries vertrauen, die ja 2015 in 10 nm produzieren ;)

[Liszca]

Begründung?
72-Bit ist die nornmale Breite eines ECC-DDR3-Kanals[...].

Und eines käuflichen ECC Moduls, auf dem auch mehrere Bänke verbaut werden können. Für den Serversysteme können ja durchaus vier Kanäle zu je zwei Bänken herauskommen. Für Consumer dann eher doch nur 2 Kanäle mit je vier bänken, einfach für mehr Arbeitsspeicher was schon standard ist.

[S940]

Und eines käuflichen ECC Moduls, auf dem auch mehrere bänke verbaut werden können.
Natürlich, aber das hat genau 0 mit der Interfacebreite zu tun :confused:

[S940]

Noch zum Stromverbrauch, ich denke das hier gibt nen guten Richtwert vor, ist ja ein ähnliches Teil:

http://www.abload.de/img/hpc2018xguzr.png

Rechts oben im Eck ^^

Quelle:
http://www.lanl.gov/orgs/hpc/salishan/salishan2011/3moore.pdf

RIF C. Moore.

[Liszca]

Natürlich, aber das hat genau 0 mit der Interfacebreite zu tun :confused:

Danke habs irgendwie wohl nicht geschafft auf diesen Punkt zu kommen.

[Skysnake]

Noch zum Stromverbrauch, ich denke das hier gibt nen guten Richtwert vor, ist ja ein ähnliches Teil:

http://www.abload.de/img/hpc2018xguzr.png

Rechts oben im Eck ^^

Quelle:
http://www.lanl.gov/orgs/hpc/salishan/salishan2011/3moore.pdf

RIF C. Moore.

UI!!!

DAS sieht aber sehr sehr sehr vielversprechend aus :biggrin:

Deutet auf ein MCM hin. Man kann also für CPU und GPU jeweils den optimalen Prozess nutzen. Intel setzt da ja auf einen Prozess für beides. AMD könnte so auch viel leichter zwischen reinen CPU und APU Designs, eventuell sogar reinen GPU-Designs, wechseln.

Man packt halt nur unterschiedliche Kombinationen an DIEs auf ein Package, und bzgl MCM packages hat AMD wirklich sehr sehr viel Erfahrung.

Das sollten Sie eigentlich sehr gut im Griff haben! Vorallem mit HT haben Sie da auch eine wirklich gute Anbindung zwischen den DIEs, aber das muss man einfach abwarten, was Sie da genau dann machen.

Was hier aber bisher noch keinem! aufgefallen ist, ist der Punkt mit dem NIC!

4x 40-100 Gbs Interconnects onChip! wohl. Das ist der Hammer!

Dazu 32-64 GB stacked RAM!, der jetzt aber nur an der iGPU hängt, wobei man über den gesharten L3 mit der CPU auch darauf zugreifen können sollte, wohl nur mit einem kleinen latency penalty. Eventuell deutet der gesharte L3 auch darauf hin, dass das kein MCM ist. hm... Muss ich nochmal drüber nachdenken.

Auf jedenfall sieht das Designkonzept mal richtig richtig fett aus. Auch das man "Checkpoint Storage" direkt mit integriert, und das relativ nahe, zeigt, das man mit dem Design auch in große HPC-Cluster usw will, wo Checkpointing unersetzlich ist, da immer mal ein Node aussteigt.

Also das sieht schon wirklich sehr sehr geil aus. :up:

[Knuddelbearli]

Dazu 32-64 GB stacked RAM!
?
;-)

[S940]

@Skysnake:
Na das war ne Pilotstudie für 2018. Da haben sie sicherlich schon mit 10nm oder so geplant, glaube kaum, dass da ein MCM nötig wäre.

Fett schauts aus, ohne Frage, aber wie besagt nur ne fast 2 Jahre alte Studie und der Präsentator ist leider verstorben. Papermaster wird das Ding sicherlich etwas verändern ;-)

Die NICs werden vielleicht durch den Seamicro-Link ersetzt. Wobei man die Dinger bei ~250W Abwärme dann aber etwas luftiger als in nem aktuellen Seamicro-Setup positionieren sollte ^^

[HOT]

Wenn das Teil echt ist, ist es ein Excavator-Opteron und benötigt sicherlich 20nm FinFETs.

[Skysnake]

Ich bin durch Zufall über die Suche auf diesen Topic gestoßen.

Kommt euch die Folie zu der möglichen APU nicht verdammt bekannt vor? Also Zeppelin usw?

Mal schauen, was in 2017 noch dazu kommt. Schon krass irgendwie, wie weit zurück derartige Planungen gehen bei AMD.

[Botcruscher]

Abgesehen vom HBM gab es auch null Fortschritt.

[iuno]

Du meinst aus dem SPM "Cluster" wurde der "4C-Zen-Cluster"?
Ersetze Modul mit 2 SPU Cores und FPU durch Zen Kern und fertig ist der Zeppelin?
:ulol:

[Skysnake]

Nein, sondern das man 8 CPU Cores mit einer 10 TFlop GPU paart, dazu noch ein Quad-Channel DDR Interface und 32-64 GB Stacked RAM (HBM) auf ein Package packt, zusammen mit nem 4 40-100 GBit Interfaces.

Und das eben schon 2013 im Kopf für 2018. Das würde ziemlich gut passen, auch wenn es eher für 2017 wünschenswert wäre.

Ob da jetzt BD verwendet wird, spielt dabei mal keine Rolle, sondern wie gut man an sich eigentlich mit den Zahlen hinkommt und auch dem konzept als solchem.

BESONDERES! Augenmerk sollte man auch mal Checkpoint Storage legen.

2013 waren Diskless nodes genau wie heute auch verdammt IN im HPC-Bereich. Das ändert sich erst jetzt wieder, wo man so richtig hart IO als hartes Problem für Exascale sieht.

Das ist insgesamt schon verdammt gut projiziert für die Zukunft. Wenn die 2017 so ein Design (Nur eben mit Zen statt BD) bringen würde, dann wäre das wohl verdammt interessant.

Pack noch HSA rein, was vom Aufbau her absolut möglich wäre, und das Ding steht architektonisch sehr nice da.

Wenn man überhaupt was ändern wollen würde, würde man wohl statt normalen DIMMS NV-DIMMS haben wollen, die nen echten Hot-Storage bieten können, statt dem Checkpointstorage extern. Aber das ist Ansichtssache.

[iuno]

Ah jetzt.
Ich dachte erst, du sprichst auf das Ding im Startpost an.
Und das eben schon 2013 im Kopf für 2018. Das würde ziemlich gut passen, auch wenn es eher für 2017 wünschenswert wäre.
Das Bild ist ja sogar noch aelter, wohl von der Konferenz 2011. Originalquelle gibt es leider nicht mehr, die Seite listet nur noch Materialien bis 2009. Finde auch nur Material, das sich darauf bezieht. Stammt das urspr. ueberhaupt von AMD? Edit: Chuck Moore, AMD Corporate Fellow and CTO of Technology Group, also ja ;D

BESONDERES! Augenmerk sollte man auch mal Checkpoint Storage legen.
Was meint man damit?

[Skysnake]

Insbesondere die Amis fahren bei Ihren System Checkpoints.

Also du machst alle 20 Min oder Stunde einen Checkpoint der Application, um bei einem Soft-/Hardware-Fehler die Applikation wieder neu starten zu können.

Man muss ja nicht immer Zwischenergebnisse raus schreiben, bzw manchmal dauert es halt einfach auch länger.

Das ist eine Abwägung zwischen Ausfallwahrscheinlichkeit und Kosten für das Checkpointing.

Die Alternative ist halt, einfach keine Checkpoints zu fahren, und dann falls etwas schief geht, alles neu zu berechnen. Kommt halt wie gesagt ganz darauf an, wie lange es braucht, bis man einen "fertige" Zwischenergebnisse rausschreiben kann, die quasi auch einen Neustart erlauben.

[Rabiata]

Nein, sondern das man 8 CPU Cores mit einer 10 TFlop GPU paart, dazu noch ein Quad-Channel DDR Interface und 32-64 GB Stacked RAM (HBM) auf ein Package packt, zusammen mit nem 4 40-100 GBit Interfaces.

Und das eben schon 2013 im Kopf für 2018. Das würde ziemlich gut passen, auch wenn es eher für 2017 wünschenswert wäre.
2018 für das Gesamtpaket sollte schon passen, 2017 erscheint optimistisch.

Die 10 TFlop GPU kommt vermutlich als Vega ("klein") wobei wir auf etwas mehr als 10 TFlop hoffen :wink:. 32 GB Stacked RAM wäre mit 4 HBM2 Stacks machbar.

Aber damit ist noch keine CPU drauf, und angesichts von AMDs endlichen Entwicklungskapazitäten vermute ich, daß erst mal die diskreten CPUs und GPUs kommen und die "dicke" APU etwas später.

[StefanV]

Hm, einfach 'ne Maske basteln, bei der ein VEGA Chip an der richtigen Stelle neben dem entsprechenden Zen Die ist?

Vorteil: wenn eines der beiden Dies unbrauchbar ist, hat man immerhin noch einen funktionierenden Chip...

Oder man klatscht das alles schlicht auf einen Interposer bzw ein Package...