Kaveri - der Trinity Nachfolger

FredD schrieb:

Der Rest meiner vorherigen Antwort bezieht sich rein auf die FPU (nicht dass hier was missverstanden wird).

Sollten diese Befunde zutreffen, hätte sich seit der Steamroller-Vorschau letzten Jahres so einiges noch geändert.

Zum Vergrößern anklicken....

Ja, wundern würde es mich nicht. Steamroller_v1 wurde ja gestrichen, also sehen wir jetzt Steamroller-v2.
Preis-Frage ist jetzt nur, was das da im Bild ist... Steamroller_v1_v2 oder gar _v3 (Excavator?)
Wir hatten ja letztens erst das FP@256bit Thema:
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1368122313

Das passte schon zu den doppelten FPU-Resourcen in dem Die-Bild, nur erwartete ich das nicht so schnell, eben auch aus dem Grund, da es noch nicht off. angekündigt war.

gruffi schrieb:

Ich habe die ALUs/AGUs mal deutlicher hervorgehoben.

Zum Vergrößern anklicken....

Ja genau danke, das meinte ich auch mit dem Edit. Frage mich jetzt, ob das latenz-mäßig nichts ausmacht, wenn die hintereinander gestaffelt sind. Außerdem: Im alten Design ist da ja auch irgendwas ... eventuell doch nur ne optische Täuschung? Ein Restrisiko besteht noch ...

Ganz verwegene Zukunftsvision, wie wäre es mit mehr als 2 Threads pro Modul?

Zum Vergrößern anklicken....

Wäre kein Problem, die 2 Registerbausteine sind sowieso schon nur Kopien (jeweils der volle Registersatz), da könnte man also oben und unten zusammen 2 Threads parallel laufen lassen. Aber dann bräuchte man keine extra AGU/ALUs.

Oder meinst Du ne Art CMT (nicht SMT) für INT ... hmhmm ja das wär verwegen
Das wäre quasi CMT eine Ebene tiefer. Lustige Idee...

Opteron schrieb:

Oder meinst Du ne Art CMT (nicht SMT) für INT

Zum Vergrößern anklicken....

Ich hatte an sowas wie bei der FPU gedacht. Also der Scheduler wird vom Frontend abwechselnd befüllt, die ALUs/AGUs selbst arbeiten dann SMT-like.

Wäre echt 'ne lustige Idee. Im Moment wird Decoder/Dispatcher zwischen 2 Threads mittels Round-Robin Verfahren geteilt. So viel ist bisher durchgesickert, Steamroller wird für beide Threads dedizierte Decoder/Dispatcher mitbringen. Warum diese jeweils nicht wieder für 2 Threads mittels Round-Robin Verfahren teilen? Insgesamt dann also 4 Threads. Jaguar macht's ja vor, Dual-Thread Compute Unit war gestern, heute ist Quad-Thread Compute Unit. Dank doppelter Einheiten sollte die Performance recht schön im Vergleich zum aktuellen Design skalieren. Nur mit dem Unterschied, für singlethreaded Workloads stünden dann mehr Einheiten zur Verfügung. Wäre also gut für mehr IPC. Aber wie gesagt, recht verwegene Vision. Würde mir aber gefallen.

gruffi schrieb:

Ich hatte an sowas wie bei der FPU gedacht. Also der Scheduler wird vom Frontend abwechselnd befüllt, die ALUs/AGUs selbst arbeiten dann SMT-like.

Zum Vergrößern anklicken....

Ja, da verstehen wir uns dann schon, aber SMT zeichnet sich ja dadurch aus, dass man keine Logikschaltungen kopiert. Wenn es jetzt aber je 2 AGU/ALUs mehr gäbe, wär es dann mehr in Richtung CMT, da dann die Logikschaltungen auch mitkopiert werden würden - ähnlich wie jetzt der ganze INT-Cluster, nur eine Stufe tiefer.

Der Registersatz ist wie besagt schon doppelt vorhanden, deshalb schrieb ich schonmal vor Langem, dass man da auch gut SMT drauf laufen lassen könnte. Erstens ist die single-thread IPC der aktuellen BDs sowieso sch...lecht (unter 1,0), es ist also genügend Platz für nen 2. Thread vorhanden, zweitens gibts schon die doppelten Resourcen in Form der 2 Registersätze.

Sollte eigentlich funktionieren. "Problem" wäre dann nur die FPU, die müsste dann ja gleich 4 Threads verkraften. Allerdings ist die ist ja auch doppelt so groß ... wieso also nicht ...

Aber es passen ein paar Sachen nicht.
1. Wenn die IPC jetzt sowieso schon nur um 1 liegt, dann bleibt eine Register-Gruppe sowieso schon frei. Die andere Gruppe wäre unbelegt, man müßte deshalb also keine ALU/AGU doppeln. Edit: Gelöst, müsste man doch tuen, wg. den Leitungslatenzen siehe unteres Posting.

2. Platzprobleme: Was war im DIE bisher anstelle der doppelten AGU/ALU? Einzige Erklärung wäre die high-def-Libs, die Platz schafften und auch noch den doppelten L1-Cache ermöglichen. Zusammengenommen irgendwie arg viel ... Wieviel haben sie da letztens Versprochen, das waren 30% Ersparnis, oder? Müsste man mal grob ausrechen, wieviel % das jetzt wären. Einfach mal beim neuen Design 16kB Cache und die doppelten AGU/ALUs weg und schauen wieviel das dann im Verhältnis zum aktuellen BD wäre.

3. Front-End / Back-End Limits?
Bei 4 Threads auf 2 Clustern/1 FPU müsste man einiges an Instruktionen pro Takt ranschaffen und im Notfall dann auch die Daten dazu laden. Wenn die FPU 4x128bit FMA pro Takt abkönnen soll, dann muss die mit einem vollen KBit (4x2x256) an Daten pro Takt gefüttert werden. Viel Holz .. aber immerhin hat man ja 2 L1D-Caches. Da müsste dann halt jeder 512kBit können. Im Moment ists nur die Hälfte, aber wenn sowieso alles verdoppelt wird .. wieso nicht.

4. Wenn sie das machen, heißt das eigentlich auch, dass sie sich quasi vom IPC-Rennen verabschieden. Anstatt die Register besser durch 1 Thread auszulasten, gingen sie eine Art SMT-Weg.

5. Dass die Register bereits jetzt schon doppelt vorhanden sind, hatte irgendwelche Latenz-/Zugriffsgründe ... wenn jetzt doch ein Registersatz für 2AGU/2ALUs herhalten muss, wäre das sicherlich wieder ein Nachteil - aber gut, eventuell einer, der sich unter Durchsatzgesichtspunkten lohnt. Wäre halt trotz der AGU/ALU-Dopplung SMT-Denkweise.

6. *EINE* Sprungvorhersage für 4 Threads??

Aja noch ne Frage: Braucht ein Instruktioncache denn keine Tags? Im B3D Forum schreib einer, dass die pinke Fläche zw. den beiden L1I-Hälften vielleicht die µROMs wären ... aber das sind doch die Tags, oder nicht?

Alles in allem: Ich bin mal vorsichtig optimistisch, wir sind hier schließlich auf dem Grünplaneten ^^

... nur die µCode ROMs würde ich schon noch gerne finden wollen ^^

Edit: Hab mir mal noch die FPU angeschaut ...


Wüsste nicht, was die Kästchen in der neuen FPU außer den Retirementplätzen sonst sein sollen. Das Gute ist auch, dass die bereits auch in dem HD-FPU-Beispiel vorkamen, dadurch weiss man, dass die sich nicht verbessern lassen, die bleiben so,wie sie sind. Fragt sich jetzt nur, was das bedeutet: Entweder doppelte Kapazität oder doppelt soviel Threads ^^

Edit:
Seh gerade, dass auf B3D auch schon eienr die gleiche Idee mit den AGu/ALUs hatte:

A single integer core looks to have twice the integer ALUs, twice the AGUs, but the multiplier and divider sections don't look replicated. The physical register file doesn't appear to be doubled. If it is bigger, it's not significant enough to split it into new sections or appear to be more than incremental growth.
The portions of the pipeline related to gathering operands and immediates for each instruction are doubled.
Interestingly, it looks like the rename tables and retire structures are doubled in size.
The table that might have to do with waking up/picking instructions could be bigger, but it isn't doubled.
The odd thing from a single-threaded perspective is that the scheduler logic outside of the tables is either much denser or not much larger. It's also not really necessary to have double the retirement tracking or rename tables for a core whose decoder is still 4-wide--if the core is single-threaded.
Perhaps it isn't.
If the integer pipeline is partitioned into halves, it might make the bypassing network less of a nightmare than expanding it from 2 ALUs and 2 AGUs to 4x4 single-cycle.

Zum Vergrößern anklicken....

Und die FPU hat er auch gefunden:

The FP unit appears to have rotated a bunch of components 90 degrees, and doubled the capacity of the register file. The two halves of each bank of registers aren't physically identical. This may be a legacy/full vector set distinction.
For what it's worth, what watchimpress stated is the retire control is duplicated. There were already two banks, one per thread with the original dual-threaded FPU. This could mean it's now able to support four.

Zum Vergrößern anklicken....

Lol .. vor dem Posten sollte man den Urthread vielleicht nochmal lesen ^^

Mir sind in dem Die Shot zu viele Elemente glatt gespiegelt oder mehrfach identsich vorhanden. Auch der oberste Bereich oberhalb der Resonant Clocking Strukturen enthält viele Elemente identisch zum Piledriver-Die. Selbst ein großer "random logic" Block mit vielen weiteren Blöcken innerhalb des Decoders, die nun zweimal in den verdoppelten Decoderblöcken auftauchen, sind identisch zu Piledriver.

Mann braucht sich nur diesen Vergleich ansehen http://www.planet3dnow.de/vbulletin/showpost.php?p=4780601&postcount=750 und wird feststellen das es sich um einen Fake handelt, zuviele gleiche Bereiche.

Ja so ganz trau ich dem Braten nachwievor nicht, da ich den µCode-Rom immer noch vermisse, deshalb erstmal keine News. Aber "gleiche Bereiche" lass ich jetzt mal nicht gelten, ist ja nicht so, dass AMD eine bahnbrechend andere Arch. rausbringen würde.

Der Decoder wird bekanntermaßen auch verdoppelt ... also wieso nicht?

Würde es für AMD (oder einzelne Mitarbeiter) einen Vorteil bringen, ganz bewusst eine falsche Fährte zu legen?

EDIT:
Eine Folie zu künsteln ist Kinderkram, aber einen derartigen Die-Shot erstellt man nicht mal eben im Handumdrehen mit einer Bildbearbeitungssoftware nach Wahl...

Edit:
Aja, nochmal wegen den 2 AGU/ALUs mehr: Könnten die sich eventuell nicht auch einfach um AVX2 kümmern? Gibt dann ja 256bit INT-Befehle ... bei den ALUs eventuell dann sinnvoll, aber bei den AGUs? Die Adressen werden ja nicht größer

@FredD:
Nö sicherlich nicht, wenn dann hatte da ein Bulgare einfach Langeweile. Ich hatte ja letztes Jahr auch den 8core K10 als Aprilscherz "gemalt" ... so schwierig ist das gar nicht.

Gleiche Bereiche wie bei PD bei HD-Bibliothek kann eigentlich nicht sein, das müsste doch allumfassend sein.
Die ALUs so dick zu machen ist auch wenig sinnvoll. 128Bit ALUs kann keiner wirklich gebrauchen und 4 ALUs zu füttern ist ja noch schwerer als die 3 beim K7/8/10... Da müsste dann ja wirklich SMT pro Cluster im Spiel sein -> arg unwahrscheinlich

Opteron schrieb:

Ja, da verstehen wir uns dann schon, aber SMT zeichnet sich ja dadurch aus, dass man keine Logikschaltungen kopiert.

Zum Vergrößern anklicken....

Schon klar. Trotzdem macht SMT bzw horizontales Multithreading ja nur Sinn, wenn genügend Einheiten zum Auslasten vorhanden sind. Und 2x ALU/AGU wäre wohl etwas spärlich für zwei Threads. Die FPU wurde gleich von Beginn an so üppig dimensioniert, dass sie ein Thread gar nicht auslasten kann. Vielleicht ist man ja erst später auf die Idee gekommen, das bei den Integer Clustern genauso zu machen?

4. Mehr Einheiten für einen Thread (nicht pro Thread) bedeutet doch erst mal bessere Voraussetzungen für mehr singlethreaded IPC. Die Verbreiterung des Designs für SMT ist produktiv für singlethreaded IPC, allerdings nicht für IPC pro Thread. Sieht man ja bei Intel wunderbar. Der angebliche Steamroller Die wäre der Königsweg, mehr singletheaded IPC (quasi durchweg 4-fach) und trotzdem gute multithreaded Skalierung dank CMT.

Opteron schrieb:

Aja, nochmal wegen den 2 AGU/ALUs mehr: Könnten die sich eventuell nicht auch einfach um AVX2 kümmern?

Zum Vergrößern anklicken....

Kann ich mir nicht vorstellen. ALU/AGU ist eigentlich für Legacy Instruktionen zuständig. Sämtliche Integer SIMD Instruktionen sollten über die Integer-Einheiten in der FPU gehen.

Duplex schrieb:

Mann braucht sich nur diesen Vergleich ansehen http://www.planet3dnow.de/vbulletin/showpost.php?p=4780601&postcount=750 und wird feststellen das es sich um einen Fake handelt, zuviele gleiche Bereiche.

Zum Vergrößern anklicken....

Klar sollte man erst mal vorsichtig sein. Aber was erwartest du? Dass jedes Pixel anders ausschaut? Wenn man mal genau hinschaut, die Pixelstruktur ist bei duplizierten Einheiten eben nicht immer gleich. Was erst mal gegen einen Fake oder eben für einen sehr gut gemachten Fake sprechen würde. Man erfindet das Rad ja nicht neu, sondern nimmt das bisherige Design als Grundlage. Vergleiche doch mal Bulldozer und Piledriver. Da wirst du auch viele gleich ausschauende Bereiche finden. MMn spricht momentan weder etwas für Fake, noch gegen Fake. Man wird wohl einfach auf mehr offizielle Infos warten müssen, um Klarheit zu bekommen.

Bulldozer & Piledriver brauche ich garnicht vergleichen, die Architektur ist gleich.

Und glaubst du, dass sich von Piledriver auf Steamroller alles ändert?

Wer schreibt das sich alles ändern wird?
Sind die DIE Shots von der P6 Architektur Core2 & Nehalem gleich oder Nehalem & Sandy Bridge? Nein obwohl das alles weiterentwicklungen sind.
DIE Shots müssen nicht immer ähnlich aussehen.
Bulldozer war das erste Modul Konzept, würde mich nicht wundern wenn vieles überarbeitet/optimiert wurde, die 315mm² @32nm waren auch recht groß.

Nehalem ist eine völlig andere Entwicklung als Sandy, genau wie Haswell anders ist als Sandy/Ivy. Das sind unterschiedliche Designs von unterschiedlichen Teams. Es gibt wie gesagt etliche Querverbindungen und Austausche, dennoch bleiben die Designs eigenständig. Sowas gibts bei AMD nicht. Hinzu kommt auch, dass Intel die fertigen Dies optimiert bis zum Erbrechen. Da bleibt kein mm² ungenutzt, auch das unterscheided AMD und Intel heftig. Bei AMD bleiben aufgrund der starken Modularität oft Lücken. Auf dem BD sieht man das ja ziemlich krass. Bei AMD werden diese Lücken durch die HD-Bibliothek wegoptimiert (siehe Jaguar). Da AMD nicht den Bruchteil eines Intel-Teams für Optimierung aufwenden kann, muss das was Intel per Hand macht eben automatisiert passieren. Wie man es dreht oder wendet, das sind alles Äpfel/Birnen-Vergleiche.
Intel hatte für Sandy einen fertigen Prozess über 2 Jahre zur Verfügung zur Optimierung (Intel vermeldete die Finalisierung von 32nm Ende 2008 ). Bei BD war der Prozess noch im Entwicklungsstadium als BD darauf entwickelt wurde. Da bleib keine Zeit zur Optimierung. Bei 28nm-SHP ist es jetzt offenbar anders und geht dank automatisierung offenbar auch erheblich schneller. Man sehe sich die Custom-APUs als Beispiel an. Die sind optimiert und fertigungsbereit für beide Foundries. Momentan wird offenbar bei GloFo gefertigt.

Beim SR wird schon einiges wiederzuerkennen sein, nur eben vieles kleiner (also den Halfnode egalisiert betrachtet). Die Grundbausteine bleiben aber sicherlich gleich. Ein Integer-Cluster wird bei SR jetzt nicht plötzlich völlig anders aussehen als bei PD, sondern nur ein bisschen. Man wird ihn aber wiedererkennen. Wenn man Ivy und Haswell vergleicht wird das nicht passieren, die kommen einfach nicht aus der gleichen Entwicklung. Wahrscheinlich erkennt man zwischen Nehalem und Haswell mehr wieder als zwischen Sandy/Ivy und Haswell.

Hans de Vries hat mal seine Sichtweise zum Die Shot auf SA gepostet.

gruffi schrieb:

Hans de Vries hat mal seine Sichtweise zum Die Shot auf SA gepostet.

Zum Vergrößern anklicken....

Seine Sichtweise wirft dann nochmal ein anderes Licht auf die Sache. Zusammengefasst und übertragen in meine eigenen sprachlichen Begriffe würde sich das Design vom bisherigen CMT-Ansatz stark abwenden, hin zu einem breiteren massiv parallelen Design mit noch flexiblerer Nutzung der "Einheitencluster". Das wäre dann schon der nächste Schritt in Richtung heterogenes computing, den ich mir persönlich bestenfalls von Excavator erwartet hätte.

FredD schrieb:

Seine Sichtweise wirft dann nochmal ein anderes Licht auf die Sache. Zusammengefasst und übertragen in meine eigenen sprachlichen Begriffe würde sich das Design vom bisherigen CMT-Ansatz stark abwenden, hin zu einem breiteren massiv parallelen Design mit noch flexiblerer Nutzung der "Einheitencluster". Das wäre dann schon der nächste Schritt in Richtung heterogenes computing, den ich mir persönlich bestenfalls von Excavator erwartet hätte.

Zum Vergrößern anklicken....

Hmm, nö finde ich jetzt nicht ... nachdem die ALU-AGU-Resourcen ja auch verdoppelt werden, ist das nachwievor eher die CMT-Idee, die da heißt: Jedem Thread seine eigenen Resourcen.

SMT für die FPU ist nachwievor ok, wobei 4fach natürlich schon ne Hausnummer wäre

K7-K10 3Fach
Bulldozer 2Fach

Und bald 4 Fach Superskalär? Vielleicht wird da wirklich was großes vorbereitet, man hat auch gesagt das man in 2 Jahren wieder Konkurrenzfähig sein will...

Duplex schrieb:

Und bald 4 Fach Superskalär? Vielleicht wird da wirklich was großes vorbereitet, man hat auch gesagt das man in 2 Jahren wieder Konkurrenzfähig sein will...

Zum Vergrößern anklicken....

Naja 4fach oder eher 2x2.
4fach glaub ich eher weniger, da es weiterhin nur 2 Registersätze gibt. Aber mal schauen ...

Edit:
Sieht nach 2x2 aus, falls die Bendingungen zu den Wire-Delays noch gelten sollten:

The execution unit supports single-cycle operand bypass from an instruction to a dependent instruction. Two ALU ops and two AGU ops can be executed in a cycle. AGU ops include increment/decrement (INC), address generate, and x86-64 LEA instructions. The ALUs and the INC units participate in single-cycle operand bypass. Four result buses, one from each of the units, feed four writes ports into the PRF. Each execution unit can receive data from any of the four write ports or from a PRF read. Each execution unit has two sources, requiring eight read ports in the PRF. To remove wire delay (and congestion) from the critical bypass path, the PRF is duplicated. The register file is divided into halves; the critical half, further from the output driver, has fewer pull-downs on the local bitline, reducing slew rates on critical words with minimal area impact (Fig.4.6.6). Duplicating the INC removes the vertical wire delay from the worst-case bypass path, which is from any INC to the far ALU.

Zum Vergrößern anklicken....

Nachdem jetzt selbst Hans de Vries nicht von nem Fake ausgeht, schreib ich mal ne News dazu.

Im Anandtech hat jemand eine Desktop Roadmap ausgegraben die auf einer Investor Veranstaltung gezeigt wurde:

http://i.imgur.com/2DdQH4D.png

Also nur 2 Module für Kaveri.

2013 ist ja bald rum

Triskaine schrieb:

http://i.imgur.com/2DdQH4D.png

Also nur 2 Module für Kaveri.

Zum Vergrößern anklicken....

Im Quantenreich der AMD-Spekulationen sind erstmal alle Zustände mit ihrer gewissen (und oft auch unterschiedlichen) Wahrscheinlichkeit möglich. Die Zustände, in denen sich das beobachtete System befindet, nennt man dann Zustandsgemisch. Für das menschliche Gemüt ist es häufig jedoch höchst unbefriedigend, wenn zwei oder mehr sich auch noch widersprechende Zustände zugleich wahr und falsch sein können.
Die Spekulation mit den 3 Modulen ist nicht von mir, würde aber aus "taktischer" Sicht ganz gut ins Bild passen. Bei den (bestätigten und nicht-bestätigten) offiziellen Roadmaps hat sich an den 2 Modulen / 4 Kernen bislang nichts geändert. In einigen Monaten herrscht hoffentlich mehr Sicherheit im Zustandsgemisch

Das wäre dann aber ziemlich früh für Kaveri. Schaut nach Mitte Q3 aus. Kann natürlich aber auch sein, dass man so viel Platz gebraucht hat, damit der ganze Text reinpasst.

Zur Computex Anfang Juni sollten erste Samples oder genauere Daten zu Kaveri auftauchen. Andernfalls wäre ich mich nicht sicher, ob Kaveri noch in 2013 in einem Produkt auftauchen wird.