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

[Complicated]

Ok das mit den schreiben/flushen des Caches leuchtet mir ein um eben kohärenz zu gewährleisten - was aber da nicht dazu passt ist die Bezeichnung hit/miss. Da sich das ja lediglich auf Leseoperationen bezieht, und es um die penalty geht bei unterschiedlichen hit/miss Szenarien. Hier sehe ich kein Szenario wo ein Remote L1 Cache abgefragt werden sollte, ausser eben wenn es bei Multi CPU Systemen einfach schneller ist als der Umweg über den RAM. Innerhalb einer Multicore CPU kommt sowas aber nicht vor. Das würde, dann eben auf 2 CPUs hinweisen oder MCM, Was wiederum auch eine seperate GPU bedeuten könnte - siehe "Liverpool". Dann aber doch keine Jaguar CUs!? Jaguar ist ja ohne onBoard GPU bisher nicht geplant gewesen....

 

[Opteron]

Der L1 muss auch nicht abgefragt werden, eben weil der L2 inkusive L1 Daten sind. Aber eventuell könnte im L2 stehen, dass die L1 Daten modifiziert wurden, der L1 ist ja write back, also muss man da ggf.auch nachschauen.

Innerhalb einer Multicore CPU kommt sowas aber nicht vor.

Meinst DU eventuell ne Multicore CPU mit einem gemeinsamen L2 Cache? Ist bei dem XBox-Chip nach dem Schema halt nicht der Fall. 2 Cachesegmente auf dem gleichen Chip ... dass das dann schneller geht auf den Nachbarcache zuzugreifen, als die Daten vom RAM zu holen ist klar. CPU-Takt >> RAM-Takt.

 

[Locuza]

@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.

Irgendwo habe ich gelesen das man den Speicher auch als L3-Cache missbrauchen könnte, also habe ich hier nachgefragt.
Aber als ich zwei Sekunden darüber nachgedacht habe, dann findet sich ja eh das ganze Zeug im Speicher oder wird von dort geholt, also würden sich ja gar keine Vorteile ergeben, wenn ich den Cache-Inhalt ständig im Arbeitsspeicher spiegeln würde.

 

[gruffi]

Könnte man in dem Fall nicht schon praktisch den Hauptspeicher als lahmen L3-Cache missbrauchen?

Wenn du keinen L3 hast, musst du das zwangsläufig. Ich würde es anders formulieren. Remote Zugriff ist letztendlich wie der Zugriff auf den Hauptspeicher. Nur halt etwas schneller bzw etwas weniger langsam. Richtig schnell ist ein Kern nur, wenn er auf den lokalen L1/L2 zugreifen kann.

Interessant hierbei ist, dass Jaguars L2 Latenz geringer als bei Bulldozer ist. Trotz gleicher Grösse und trotz mehr angebundener Kerne. Ist das nun dem Design geschuldet? Üppiges L2 Interface, Write-Back, etc. Oder ist das der 28nm Fertigung geschuldet?

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

Müssen sie nicht mal, wenn alles auf einem Die ist. Wovon ich im Moment ausgehe. Aber selbst wenn nicht, wüsste ich nicht, was gegen PCIe sprechen würde. Ist ja ebenfalls bidirektional.

Ok das mit den schreiben/flushen des Caches leuchtet mir ein um eben kohärenz zu gewährleisten - was aber da nicht dazu passt ist die Bezeichnung hit/miss. Da sich das ja lediglich auf Leseoperationen bezieht, und es um die penalty geht bei unterschiedlichen hit/miss Szenarien.

Hit/miss bezieht sich darauf, ob sich Daten an entsprechender Adresse im Cache befinden. Ob dann gelesen oder geschrieben wird, steht auf einem anderen Blatt.

Man sollte vielleicht nochmal hervorheben, wie Opteron schon sagte, der L2 in Jaguar ist jetzt inklusive. Das erfordert natürlich einige Anpassungen. Der L2 bei Bobcat zuvor war nicht inklusive.

 

[Locuza]

Interessant hierbei ist, dass Jaguars L2 Latenz geringer als bei Bulldozer ist. Trotz gleicher Grösse und trotz mehr angebundener Kerne. Ist das nun dem Design geschuldet? Üppiges L2 Interface, Write-Back, etc. Oder ist das der 28nm Fertigung geschuldet?

Ich glaube das ist mehr den Optimierungen geschuldet.
Wenn man sich anschaut wo AMD bei Jaguar überall die Latenzen verbessert hat, dann gehe ich schon davon aus, dass AMD auch bei dem Cache versucht hat besser zu werden, vor allem da er ja mit den halben Taktraten fährt ist das sicher nicht all zu schlecht wenn die Latenzen dann "wenigstens" gut sind.
Steamroller und Jaguar scheinen ja gewisse Ansätze und Grundtechnologien zu teilen.
Wie z.B. die micro-op queue und einen L2-Cache mit Bänken:
http://www.anandtech.com/show/6201/amd-details-its-3rd-gen-steamroller-architecture/2

Dort steht allerdings auch, dass es nicht auf AMDs Prioritätenliste stand die Latenzen zu verbessern.

 

[Opteron]

ALso 17 Takte für nen Cache mit halben Takt sind ziemlich gut. Das würde ja quasi bedeuten, dass der Cache mit vollem Takt nur ~8 Takte Latenz hätte...

Aber so ganz muss man das nicht glauben, ht4u hatte damals beim Bocat 24 Takte gemessen:
http://ht4u.net/reviews/2011/amd_bulldozer_fx_prozessoren/index13.php

Und offiziell hat der auch 17 Takte L2-Latenz..

Ansonsten ja, Ähnlichkeiten gibts, aber das ist nichts Besonderes, die Intel Chips haben das auch (schon ziemlich lange ).

 

[gruffi]

Aber so ganz muss man das nicht glauben, ht4u hatte damals beim Bocat 24 Takte gemessen:
http://ht4u.net/reviews/2011/amd_bulldozer_fx_prozessoren/index13.php

Solche Messungen sind allerdings auch nicht hundertprozentig präzise. Nicht nur die Abweichung von der spezifizierten Latenz, auch von Durchlauf zu Durchlauf können Unterschiede entstehen. Beim Llano erhalte ich zB je nach Durchlauf Ergebnisse zwischen 19-21 Takten für den L2.

 

[Opteron]

Solche Messungen sind allerdings auch nicht hundertprozentig präzise. Nicht nur die Abweichung von der spezifizierten Latenz, auch von Durchlauf zu Durchlauf können Unterschiede entstehen. Beim Llano erhalte ich zB je nach Durchlauf Ergebnisse zwischen 19-21 Takten für den L2.

Jo, aber wie Du schon selbst schreibst, 1-2 Takte Unterschied sind immer mal drin, aber 7 Tage sind signifikant anders.

 

[Complicated]

aber 7 Tage sind signifikant anders.

Ja und stell dir mal vor es wäre eine ganze Woche,..

*SCNR*

 

[Twodee]

Ja und stell dir mal vor es wäre eine ganze Woche,..

*SCNR*

Das wäre dann aber völlig aus dem Takt

 

[gruffi]

Jo, aber wie Du schon selbst schreibst, 1-2 Takte Unterschied sind immer mal drin, aber 7 Tage sind signifikant anders.

Nochmal, absolute Abweichungen und Abweichungen von Durchlauf zu Durchlauf sind zwei verschiedene Dinge, die sich aufsummieren können. Das muss nicht bei 1-2 Takten bleiben. Letztendlich hat man mit Software nur begrenzt die Möglichkeit, die exakte Latenz zu messen.

 

[Opteron]

Lol Tage ... toller Vertipper ^^

@gruffi: Was willst Du da aufsummieren? 10 Takte Unterschied wenn Dus 5x laufen lässt und jeweils 2 Takte Unterschied sind?

Statistisch gesehen bleibts bei 1-2, wenn von 100 Durchläufen mal einer 5 Takte anzeigt dann wars irgendein uninteressanter Störeffekt.

 

[gruffi]

Das sagt dir aber trotzdem nichts darüber, wenn der messende Algorithmus grundsätzliche Abweichungen erzeugt. Man hat softwareseitig nur begrenzte Möglichkeiten, die exakte Latenz zu messen. Und auch nicht jede Architektur ist gleich, so dass ein Algorithmus optimal für alle Architekturen ist. Für x86 wird normalerweise rdtsc genutzt, um Takte zu messen. Nur gibt es hier eine Reihe von Fallstricken. rdtsc is zB nicht thread-safe. OoO Architekturen können ebenso Instruktionen nach belieben umordnen, so dass man dann auf Serialisierungsinstruktionen wie cpuid zurückgreift, was wiederum Takte kostet. Ebenso ist man auf Sprünge angewiesen, was weitere Takte bedeutet. Deshalb versucht man, Schleifen möglichst aufzurollen. Was wiederum mehr Code bedeutet und kontraproduktiv für einen Loop-Buffer ist. Usw. Es ist ein "klein wenig" komplexer, als du dir das vielleicht vorstellst. Unterm Strich misst du nicht nur die Takte für den Cache, sondern auch zusätzliche Takte für die Arbeit der gesamten Pipeline.

Beispiel, die tatsächliche Latenz beträgt 20 Takte. Dein Algorithmus erzeugt aber eine Abweichung von 2-4 Takten, je nach Durchlauf. Deshalb spuckt er immer nur 22-24 Takte aus. Die tatsächliche Latenz bekommst du nie zu sehen. Das meinte ich mit aufsummieren. Wie gesagt, das muss nicht so sein, kann aber passieren, abhängig von Architektur und Algorithmus. Eigentlich hast du nur im Labor die Möglichkeit, exakte und zuverlässige Werte zu ermitteln. Auf Anwenderebene ist es maximal eine Annäherung.

 

[Markus Everson]

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.

Welcher Kern hat bisher 17 vs. ~ 100 Takte beim Zugriff auf den 4 MB großen L2 Cache?

Ich komm da echt nicht mehr mit. Bei Kabini soll doch ein gemeinsamer L2 für 4 Kerne zuständig sein, das passt also nicht. Von der PS4 APU finde ich nirgends derart detaillierte Angaben. Andere APUs oder CPUs sollten hier eigentlich nicht Thema, da deren Verhalten nicht übertragbar, sein. So what?

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.

Du kennst das Frontend der PS4-APU? Erzähl!!

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.

Die Frage ist ob das wirklich notwendig ist, die GPU wirklich so dick sein muss. Die Masse der Kunden dürfte heuer bei Neuanschaffungen beim Display im Mittel noch immer unter FullHD 1080 kaufen. 720p läßt sich sehr gut auf 1080p skalieren. Schafft Jaguar 720p mit hohem Detailgrad in Spielen dann wäre damit schon sehr viel Gewonnen.

@All: Ich bin hier ja immer noch mit meiner 4670 unterwegs die allmählich laut wird. Wo liegt die in der Prognose leistungsmäßig im Vergleich zur integrierten GPU des Kabini?

 

[Dresdenboy]

@All: Ich bin hier ja immer noch mit meiner 4670 unterwegs die allmählich laut wird. Wo liegt die in der Prognose leistungsmäßig im Vergleich zur integrierten GPU des Kabini?

Von Kabini habe ich noch nichts gefunden. Temash liefert 981 Punkte bei 3DMark Vantage (Performance). Der Z-60 erreichte da 455 Punkte. Die schnellsten Zacates erreichen knapp über 1000 Punkte. Skaliert die 15W-Kabini-Grafik ähnlich, wären das ca. 2000 Punkte. Eine möglicherweise höhere Flexibilität im Energiemanagement könnte da noch etwas drauflegen. Und das 25W-Modell könnte sogar 3000 Punkte schaffen.

Im Vergleich dazu hat deine 4670 etwa 3800 Punkte in dem Benchmark.

 

[amdfanuwe]

Wie seht ihr die Wahrscheinlichkeit, dass Kabini mit defekten CPU Cores als billig GPU für Crossfire zum Einsatz kommt?
Oder noch weiter gesponnen: Ein 2ter Kabini als Aufrüstkarte im Multiprozessing Einsatz.
8 Core Crossfire in nem Billiglaptop hört sich nicht schlecht an.

Obwohl, HSA bietet doch cohärenten Speicher. Wäre das mit Kaveri denkbar, dass durch einfaches zustecken weiterer Kaveri Karten ein Multi APU System realisiert werden kann?

 

[~DeD~]

Obwohl, HSA bietet doch cohärenten Speicher. Wäre das mit Kaveri denkbar, dass durch einfaches zustecken weiterer Kaveri Karten ein Multi APU System realisiert werden kann?

feuchte träume

endlich intros und videos in stunden udn nicht in tagen rendern

 

[Opteron]

Wie seht ihr die Wahrscheinlichkeit, dass Kabini mit defekten CPU Cores als billig GPU für Crossfire zum Einsatz kommt?

Das geht gegen Null, Kabini bekommt doch nur 2 CUs/128 Shader. Das ist nicht der Rede wert. CF rentiert sich da nicht.

Obwohl, HSA bietet doch cohärenten Speicher. Wäre das mit Kaveri denkbar, dass durch einfaches zustecken weiterer Kaveri Karten ein Multi APU System realisiert werden kann?

Wenn Du die mit nem Kohärenten Bus verbindest ja ... Du brauchst also entweder Hypertransport oder QPI.

Und dann hast DU das Problem, dass die Bandbreite selbiger Interconnects im Vergleich zu Dual-Channel DDR3 oder gar 4 ziemlich besch...eiden ist. Für HPC-Sachen nicht so wichtig, aber zum Spielen taugts nicht.

 

[Complicated]

Das geht gegen Null, Kabini bekommt doch nur 2 CUs/128 Shader. Das ist nicht der Rede wert. CF rentiert sich da nicht.

Wenn Du die mit nem Kohärenten Bus verbindest ja ... Du brauchst also entweder Hypertransport oder QPI.

Und dann hast DU das Problem, dass die Bandbreite selbiger Interconnects im Vergleich zu Dual-Channel DDR3 oder gar 4 ziemlich besch...eiden ist. Für HPC-Sachen nicht so wichtig, aber zum Spielen taugts nicht.

Ich denke das bezog sich nur auf den GPU Part ohne CPUs. Das gibt es ja als MXM Module und HSA GPUs sollen das ja auch über PCIe können.

 

[amdfanuwe]

War nicht mal die Rede davon, dass kommender Opteron CPUs kein HT Interface mehr haben sondern PCIe und im Multiprozessorsystem ein abgespektes HT ähnliches Protokoll über PCIe gefahren wird?
Ob sich das zum Spielen eignet
Für ein Multimonitorsystem oder 3d, in dem jeder APU Part sein eigenes Bild berechnet könnte es was bringen.
In einem anderem Thread hier wurde auf NVIDIAs Maxwell aufmerksam gemacht, der ARM Kerne enthalten soll.
Sollte sich das durchsetzen, dass zukünftig APUs anstelle von GPUs eingesetzt werden, steht AMD schonmal gut da. Mit ARM64 hat man bei AMD dann noch die freie Auswahl. Eventuell kommt auch noch ein SeaMicro Freedom™ fabric Interface auf den Chip.

 

[Locuza]

Welcher Kern hat bisher 17 vs. ~ 100 Takte beim Zugriff auf den 4 MB großen L2 Cache?

Ich komm da echt nicht mehr mit. Bei Kabini soll doch ein gemeinsamer L2 für 4 Kerne zuständig sein, das passt also nicht. Von der PS4 APU finde ich nirgends derart detaillierte Angaben. Andere APUs oder CPUs sollten hier eigentlich nicht Thema, da deren Verhalten nicht übertragbar, sein. So what?

Du kennst das Frontend der PS4-APU? Erzähl!!


Die Frage ist ob das wirklich notwendig ist, die GPU wirklich so dick sein muss. Die Masse der Kunden dürfte heuer bei Neuanschaffungen beim Display im Mittel noch immer unter FullHD 1080 kaufen. 720p läßt sich sehr gut auf 1080p skalieren. Schafft Jaguar 720p mit hohem Detailgrad in Spielen dann wäre damit schon sehr viel Gewonnen.

@All: Ich bin hier ja immer noch mit meiner 4670 unterwegs die allmählich laut wird. Wo liegt die in der Prognose leistungsmäßig im Vergleich zur integrierten GPU des Kabini?

Dann noch einmal in einer kleinen Übersicht:

Vgleaks meint die CPU von der Xbox Next ist so aufgebaut (Und ich erwarte bei der PS4 CPU das gleiche):
2x Jaguar Compute Units zusammengeschaltet.
Jede Jaguar Compute Unit besteht aus 4 Kernen und 2 MB L2$.
Es wird angegeben das, wenn ein Modul seinen 2MB L2 Cache überprüft, dass dies 17 Takte dauert.
Wird aber jetzt von diesem Modul der 2MB große L2$ des anderes Moduls überprüft, dann beträgt die Latenz 100 Takte, weil die Kerne keinen direkten Zugriff auf die L2-Bänke durch das L2-Interface haben wie bei ihrem Modul , sondern über die Northbridge überprüfen müssen.

http://www.vgleaks.com/durango-cpu-overview/

Ich habe ja auch schnell das Schaubild verändert, um zu zeigen was ich mir unter einem "nativen" 8-Kerner vorgestellt hätte:
http://www.planet3dnow.de/vbulletin/attachment.php?attachmentid=27159&d=1362204172

Das hätte ja dann aber auch bedeutet, dass man das L2-Interface hätte verändern müssen und auch zusätzliche Verdrahtung von den Kernen auf die 8 Bänke vom 4MB großen L2-Cache legen.
Also sorry, dass mit Front-End war falsch, ich meinte es hätte zusätzlichen Aufwand bedeutet 8 Kerne ohne "Barrieren" zu realisieren, über ein einziges Interface kommunizieren zu lassen, mit einer gleichgroßen Latenz zu den L2-Bänken, anstatt einfach 2 Module zusammen zu kleben und diese über die Northbridge kommunizieren zu lassen.

Wenn am PC-Markt die APUs ebenfalls das alte Schema ersetzen sollen, dann brauchen wir ja dickere GPUs und mehr Bandbreite.
Ich kann bisher ja keine APU als Gaming-Maschine einsetzen, trotzt der großen Vorteile.
Es wäre aber mein Wunsch eine fette APU zu haben.

Bezüglich Kabini.
Es werden ja 128 GCN Cores angenommen, wobei spekuliert wird, ob nicht noch mehr hineinpassen in das die-size was angegeben wurde. (192/256 Cores)
Jedenfalls bei 600-800Mhz wären das 153-204 GFLOPs vs. 480 GFLOPs von deiner 4670.
Rechnet man noch 30-50% Effizienz-Bonus von GCN drauf sind das dann grob bis zu 300 GFLOPs.
Aber bei den Filtereinheiten müsste man deutlich einstecken, dass wären gerade mal 8 TMUs bei 128 Cores. Deine alte hat ja 32.
Alles nur sehr grob, aber effektiv landet man wohl bei weniger als der Hälfte der 3D-Leistung einer alten 4670.

 

[Dresdenboy]

Bezüglich Kabini.
Es werden ja 128 GCN Cores angenommen, wobei spekuliert wird, ob nicht noch mehr hineinpassen in das die-size was angegeben wurde. (192/256 Cores)
Jedenfalls bei 600-800Mhz wären das 153-204 GFLOPs vs. 480 GFLOPs von deiner 4670.
Rechnet man noch 30-50% Effizienz-Bonus von GCN drauf sind das dann grob bis zu 300 GFLOPs.
Aber bei den Filtereinheiten müsste man deutlich einstecken, dass wären gerade mal 8 TMUs bei 128 Cores. Deine alte hat ja 32.
Alles nur sehr grob, aber effektiv landet man wohl bei weniger als der Hälfte der 3D-Leistung einer alten 4670.

Zwei Wege, zwei Ergebnisse. Gesamtfazit: Kabini könnte grob die Hälfte der 4670-Leistung erreichen, solange komplexere Shaderprogramme genutzt werden. Ginge der Fokus eher in Richtung 3dfx style dual texturing, werden sowohl TMU/ROP- als auch der damit zusammenhängende Speicher-Flaschenhals zuschlagen.

 

[Markus Everson]

Vgleaks meint die CPU von der Xbox Next ist so aufgebaut (Und ich erwarte bei der PS4 CPU das gleiche)

Ich empfehle einen Blick in die offizielle Verlautbarung von Sony:
"Main Processor: Single Chip Prozessor"

Nun kann man natürlich Sony unterstellen das sie hier lügen (wer aktiv versucht seinen Kunden rootkits unterzuschieben ist über diesen Verdacht wohl kaum erhaben). Aber wenn man so anfängt dann muss man ALLES was bisher über die PS4 verlautbart wurde in Frage stellen - also auch den Prozessor selbst und das RAM.

 

[amdfanuwe]

"Main Processor: Single Chip Prozessor"

Versteh deinen Komentar nicht. Hat doch niemand gesagt, dass die 2 CU nicht auf einen Die sitzen.

 

[Complicated]

Temash lässt sich im Hybrid-CF mit einer GPU im Turbodock betreiben, welche auf VLIW Architektur basiert. Heisst das dann kein GCN, oder ist GCN auch mit VLIW kompatibel?
http://www.heise.de/newsticker/meld...mmt-Anfang-April-mit-896-Shadern-1816636.html

AMD selbst zeigte während einer Sitzung unter anderem den Temash-Kombiprozessor. In einem Wistron-Tablet steckend gab er das Hack-n-Slay Torchlight 2 flüssig bei mittlerer Detailstufe wieder. AMD wollte auf Anfrage partout nicht bestätigen, dass in Temash tatsächlich eine GCN-GPU steckt, obwohl dies aus der Januar-Roadmap hervorgeht. Auch die Tatsache, dass sich die Temash-GPU mit einer im Turbo-Dock steckenden Einsteiger-GPU (VLIW) koppeln lässt, ist ein möglicher Hinweis darauf, dass sie doch noch auf VLIW4-Technik fußen könnte.

Seltsam dass dieses DX9 Spiel demonstriert wird.