AMD Kabini APU / Jaguar CPU + Graphics Core Next GPU, 2-4 Kerne, 28nm TSMC, 2013

[Locuza]

Nun, aber was hat das beim HSA-Level für eine Bedeutung, ob der FCH jetzt im die ist oder nicht?

Bezüglich der Aussage von Roy.
Yes, es liest sich praktisch eindeutig nach Kabini, aber man will ja nie aufgeben sich da mehr zusammen zu phantasieren, als es im Endeffekt sein könnte.
das ganze würde dann auch bedeuten, dass Kaveri Ende 2013 technisch weiter ist, als die PS4.

 

[Markus Everson]

2 Compute Units und kein "nativer 8-Kerner".

Worin besteht die Differenzierung?

 

[amdfanuwe]

das ganze würde dann auch bedeuten, dass Kaveri Ende 2013 technisch weiter ist, als die PS4.

Vom Technischen her anscheinend schon. Jedoch werden wir da wohl noch keine 8 Kerne und entsprechende GPU Leistung sehen. Könnte mir vorstellen, dass die PS4 APU bis zu 200W zieht. Im PC werden wir wohl erst mit 20nm vergleichbare APUs sehen.

 

[Locuza]

Worin besteht die Differenzierung?

Das war zugegeben dünnes Eis und hat so etwas von Bulldozer mit "echter Octo-Core oder Quadcore?".
Um es mal bildlich zu verdeutlichen, was mir bei einem "nativen 8-Kerner" vor sich schwebte.
Anhang anzeigen 27159

Somit hätten alle Kerne mit gleicher Latenz Zugriff auf den 4mb großen L2-Cache und nicht wie es bisher ist 17 vs. ~ 100 Takte.
Das würde aber natürlich auch bedeuten, dass man das Front-End hätte anders gestalten müssen und die restliche Verdrahtung ebenfalls anders ausgefallen wäre.
Das hätte sehr kompliziert ausfallen können.

Vom Technischen her anscheinend schon. Jedoch werden wir da wohl noch keine 8 Kerne und entsprechende GPU Leistung sehen. Könnte mir vorstellen, dass die PS4 APU bis zu 200W zieht. Im PC werden wir wohl erst mit 20nm vergleichbare APUs sehen.

Das ist leider klar.
Da müsste man ja bis Ende 2015 darauf warten.
Problematisch ist auch, wie man eine hohe Bandbreite erreichen will?
DDR4 selbst im Quad-Modus würde nur ~100 GB/s bringen können.
AMD müsste da sich irgendetwas interessantes einfallen lassen müssen, um eine deutlich dickere GPU wie bei der PS4 auch beim PC-Anwender füttern zu können.

 

[Stryki]

Das sind genauso echte Octo-Core wie der C2Q ein Quad war, sollte es als MCM realisiert sein.
AMD hat das bei den 16 Core Teilen doch auch gemacht ( Codename gerade nicht präsent).
Die Frage ist letztlich wie die Verbindung zwischen beiden Modulen realisiert ist? HT hat der Jaguar nicht vermutlich was mit PCIe.

 

[ndrs]

Hier stand Mist. PCIe könnte passen.

 

[ONH]

Die Frage ist letztlich wie die Verbindung zwischen beiden Modulen realisiert ist? HT hat der Jaguar nicht vermutlich was mit PCIe.

Woher kommst du auf die Idee das die 2 CU auf verschiedenen Chips liegen? Beide zusammen mit den GPU CU auf einem Chip und analog zu Bobcate bei Zacate mit der NB verbinden, den die CU sind ja nur die 4 Kerne und L2.

Verbaut wird wohl was weniger Kosten verspricht und da denke ich das AMD genug verlangen wird das es sich für Sony lohnt das OS an die HW anzupassen.

 

[amdfanuwe]

Scheint so, als hätten wir 3 Fälle zur Spekulation:
1.) 2X CU 4Core als getrennte Einheiten verbunden über NB. Programmiert sich wie zwei seperate PCs mit einer schnellen Verbindung, Programmierer haben sich um koköränz und Syncronisation zu kümmern.
2.) 2X CU 4Core kohärent Verbunden. Programmiert sich wie ein Multiprozessorsystem. Programmierer müssen sich aus Performancegründen um Threadverteilung kümmern. Datenlokalität auf einem CU ist zu bevorzugen.
3.) 1X CU 8Core. Alle Cores gleichberechtigt. Programierer haben nichts zu tun mit Threadverteilung und kohärenz der Daten. Wäre der erste "echte" 8 Kerner von AMD.

Zu 2 und 3 sollte es keine Probleme mit dem OS geben.
Mit HSA strebt AMD 3 an.
Bin mal gespannt, wann man näheres erfährt.

 

[Complicated]

Programmierer werden in keinem Fall etwas mit der mit Threadverteilung und kohärenz der Daten zu tun haben. Dafür ist die HSA API doch da, unabhängig der unterliegenden Hardware. Ich denke das war auch der ausschlagegebende Punkt für den Zuschlag AMDs im Konsolengeschäft.

Anstatt eine Handvoll Ninja-Programmierer teuer bezahlen zu müssen, können Horden von 08/15 x86 Programmierer, Massen von Spielen in kürzester Zeit für einen Appel und ein Ei raus hauen. Ob die Qualität stimmen wird, wird sich zeigen. Doch derzeit hat man das Gefühl dass die Leute eher die Zahl der vorhanden Software zählen anstatt zu schauen ob sie was taugt - siehe App-Biotop Mentalität.

 

[ONH]

Muss meine Aussage konkreter schreiben alle CU (GCN oder x86) gleichberechtigt an einem CI wie bei Zacate die BC Core an der NB angebunden sind. Bleibt gegenüber von 1x8 nur der geteilte L2 übrig und der sollte sich doch analog wie heute zwischen den CPU Kernen handhaben lassen.

 

[gruffi]

Das sind genauso echte Octo-Core wie der C2Q ein Quad war, sollte es als MCM realisiert sein.

Nicht ganz. Bereits bei Magny Cours / Interlagos hat AMD den shared Cache direkter verbunden (HT-Bridge). Beim C2Q ging es ja noch über den FSB zum Mainboard.

Ist aber echt interessant, ob Jaguar vielleicht vergleichsweise einfach in ein Design mit 8 Kernen und 4 MiB L2 gepresst werden kann. Das würde in der Tat für einen sehr modularen Aufbau sprechen. Aber selbst 2 4-Kern CUs mit jeweils 2 MiB L2 sollten kein Problem für die Performance sein. An MCM glaube ich nicht. Wird wohl alles auf einem Die untergebracht sein.

 

[Opteron]

VGleaks beschreibt hier die angebliche Durange Einheit:
http://www.vgleaks.com/durango-cpu-overview/

Sind 2x4 Kerne, kohärenter Zugriff auf den jeweils anderen Modul-Cache ist möglich, aber ziemlich langsam.

 

[Complicated]

Ehrlich gesagt glaube ich davon recht wenig. Was soll denn remote L1 heissen?
Welchen Sinn ergibt das denn:

Remote L2 hit, remote L1 miss 100 Required line is in the other module’s L2
Remote L2 hit, remote L1 hit 120 Required line is in the other module’s L2 & in remote ore’s L1

Wenn der benötigte Code im L2 gefunden wurde, wozu dann den L1 durchsuchen?
Und wenn der Code dort gefunden wird gibt es 20 cycle penalty? Wofür?
Der L1 Cache ist ja exklusiv für den jeweiligen Core.
Durango ist zudem Xbox und nicht PS4.

 

[Opteron]

Und wenn der Code dort gefunden wird gibt es 20 cycle penalty? Wofür?
Der L1 Cache ist ja exklusiv für den jeweiligen Core.
Durango ist zudem Xbox und nicht PS4.

Na der L1 ist doch auch im L2 gespiegelt. Zuerst wird der remote L2 beschnüffelt, wenn es dort nen Hit gibt, dann wird nachgeschaut ob die Daten auch noch in nem L1 stehen, da man die dort dann auch "sicher" muss. 20 Takte Penalty sind zwar ne Menge, aber vorstellen kann ich mir das bei dem ganzen Koheränzgedöns schon, das ist kompliziert und für die Spielkonsole haben sie sicher nur ne Quick n Dirty Lösung genommen.

 

[Complicated]

Das macht doch nur Sinn für den Core dem der L1 Cache gehört. Was nutzt dem Remote Core der Zugriff auf den Remote L1 eines anderen Cores nur um dann festzustellen dass er in manchen Fällen 20 cycles penalty hat und Keinerlei nutzen aus dem remote L1? Besser er schaut erst gar nicht dort nach und behandelt alle remote L2 anfragen wie einen remote L1 miss. Ist 20% schneller falls es im L1 vorhanden ist.

 

[ndrs]

Es kann aber sein, dass im L1 die aktuellere Version der Daten steckt und diese noch nicht in den L2 zurückgeschrieben wurde. Dann muss natürlich diese genommen werden.

 

[Complicated]

Dann wäre es ja ein L2 miss. Also nicht die benötigten Daten im L2 Cache gefunden.
Zudem wäre mir keine CPU bekannt die einen shared L1 Cache hat für read Zugriffe. Ich kenne nur Core exklusiven L1 Cache- Das wäre ja eine Weltneuheit, oder irre ich mich?

Ich habe zumindest mal nicht einen Hinweis bei Google auf die Existenz solcher L1 Cache Modelle gefunden. Wieso auch. Sollten die Daten im L1 cache von Core0 liegen und der Zugriff 3 cycles brauchen, wie sollte dann Core1 in 120 cycles mit diesen Daten noch was anfangen können? Was für ein scheduler würde denn so arbeiten?

Auch steht im Link an Anfang dass L1 Cache read exklusiv ist für den jeweiligen Core - also was nun? Das widerspricht sich ja.

 

[gruffi]

@Complicated

Fürs Lesen hast du recht. Da macht es keinen Sinn. Anders schaut das beim Schreiben aus. Wenn die Daten in Remote L1 und Remote L2 vorhanden sind, müssen diese abgeglichen werden. Read only ist übrigens nur der L1I, nicht der L1D.

 

[Complicated]

Naja das macht doch aber nicht der Remote Core. Warum sollte der nicht in den eigenen L1 und L2 schreiben? Und wie sollte ein Remote L1 beschrieben werden wenn der exklusiv dem anderen Core gehört?

Ist dir irgendein Chip bekannt der das macht?
In dem Link steht übrigens sowohl für L1I und L1D "dedicated to 1 core"

 

[Opteron]

@Complicated: Schaut Dir mal das Moesi Protokoll nochmal an ..
Nur Miss und Hit zu betrachten ist zu simpel, da gibts noch owned, modified, shared ... etc.

 

[Complicated]

Hab ich mir ja schon angeschaut, doch das setzt ja voraus dass ein Cache auch von mehreren Cores geteilt wird
Bei L1 ist mir das bisher nicht untergekommen.

Das einzige wie das Sinn ergeben könnte, wäre wenn das nicht nur ein MCM Chip Package wäre, sondern tatsächlich eine Konfiguration mit 2 seperaten CPUs.

Außerdem kann die Kommunikation zwischen zwei oder mehreren CPUs bzgl. Latenz und Übertragungsrate signifikant besser sein als zwischen CPU und Hauptspeicher. Bei Multicore-CPUs mit jeweils eigenen Caches pro Core ist dies meist der Fall.

Dann gebe es diesen Remote L1 Cache, weil eine Remote CPU vorhanden ist und der Arbeitspeicher umgangen wird.

Edit:
Achso Quelle:
http://de.wikipedia.org/wiki/MOESI

 

[gruffi]

@Complicated

Wie die konkreten Implementierungsdetails ausschauen, kann dir nur AMD verraten. In der Theorie ist es aber in der Tat so, dass bei einem WB-Cache zusätzlicher Aufwand notwendig ist, wenn die geschriebene Daten in Remote L1 und Remote L2 vorhanden sind. Der Remote Kern kann den Abgleich ja nicht einfach übernehmen. Der bekommt davon gar nichts mit. Das muss schon über das CCI gesteuert werden. Ein Kern selbst gleicht L1 und L2 nur ab, wenn dies die eigene Pipeline veranlasst. Und mal davon abgesehen, 120 Takte sind ja immer noch weniger als die 144-160 Takte, die für den Zugriff auf den Hauptspeicher notwendig sind.

 

[Locuza]

Könnte man in dem Fall nicht schon praktisch den Hauptspeicher als lahmen L3-Cache missbrauchen?
(Bezogen auf die PS4 mit GDDR5 und 176GB/s)

 

[Complicated]

@gruffi
Nur hat das ja AMD bisher bei Opterons in 2-4P Systemen über HT realisiert. Kann das PCIe leisten?

 

[Opteron]

Das einzige wie das Sinn ergeben könnte, wäre wenn das nicht nur ein MCM Chip Package wäre, sondern tatsächlich eine Konfiguration mit 2 seperaten CPUs.

Macht doch keinen Unterschied, das ist nur das Verbindungsmedium, mit der Speicherkohärenz ansich hats doch nichts zu tun. Egal ob man auf der Landstraße oder Autobahn nach Rom fährt, das Ziel ändert sich nicht.
Oder meinst Du mit seperat 2 getrennte Speicherbereiche?

In dem Studentenpaper hier sind ab Seite 15 ein paar Infos zu Multi-levelcache Kohärenz:
http://www.di.unipi.it/~vannesch/SPA 2010-11/Silvia.pdf

Considering requests from other nodes, some, but not all, of these requests relevant to the L2 cache are also relevant to the L1 cache and must be prop-agated to it. For example, if a block is invalidated in the L2 cache, the invalidation must also be propagated to the L1 cache if the data is present in it. Inform the L1 cache of all actions that were relevant to the L2 cache is the easiest solution but in many cases it is useless. A more attractive solution is for the L2 cache to keep extra state (inclusion bit) with cache blocks; which record whether the block is also present in the L1 cache. It can then suitably lter interventions to the L1 cache at the cost of a little extra hardware and complexity.

@Locuza:
Was meinst Du da genau? Wenn der Speicher so schnell ist, brauchst Du keinen L3. Aber lass Dich da mal nicht von der Bandbreite täuschen, das wichtige bei Cachezugriffen ist die Zugriffszeit, die Datenblöcke selbst sind ja relativ klein.