Bulldozer 2.0 / BDver2: Sepang, Terramar, Komodo, Trinity, Vishera

Was genau sind für dich "echte Neuerungen"? Laut der Übersicht vor einiger Zeit unterschieden sich 10h und 20h doch so gut wie überhaupt nicht. Im Gegensatz zu 00h.
Na die 4 zusätzlichen AGLU-Befehle. Zugegeben nicht viel, aber mMn schon ein größerer Eingriff. Wenns schon eingebaut wäre, würden sies ja spätestens mit 10h freischalten.
OOODER: Es gab soviele Bugs, dass sie keine Zeit für den Kleinkram hatten.

Mittlerweile würd ich das auch nicht mehr ausschließen wollen *chat*
 
Nun ja, ich sehe da eigentlich nur "MOV reg, reg" als Neuerung, die was bringen kann. Auch wenn ich mir noch nicht erklären kann, warum man die zusätzlichen AGLU Instruktionen nicht schon mit 10h bringt. Vielleicht ist der SOG hier aber auch noch fehlerhaft. 20h wird dort ja auch noch mit bis zu 5 CUs beschrieben.
 
Ohne mich jetzt durchs SOG zu wühlen...
Die AGLUs lernen mit 20h also das MOV von Register zu Register? - d.h. wenn keine Adresse gebraucht wird, kann ein Mov auch auf der AGLU laufen. - soweit so gut.
War nicht auch mal irgendwas im Gerede das mit 20h "Streaming Stores" verbessert und auf K10-Niveau gehieft werden sollen?
 
Ohne mich jetzt durchs SOG zu wühlen...
Die AGLUs lernen mit 20h also das MOV von Register zu Register? - d.h. wenn keine Adresse gebraucht wird, kann ein Mov auch auf der AGLU laufen. - soweit so gut.
Kann es sein, dass Du Anfang Februar nicht online warst? :)
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1328302051
War nicht auch mal irgendwas im Gerede das mit 20h "Streaming Stores" verbessert und auf K10-Niveau gehieft werden sollen?
Das galt für die "zweite Generation" ich nehm mal an, dass damit schon Piledriver gemeint war. Werden wir ja bald sehen :)
 
Crashtest hat recht. Family 21 Model 2 Stepping 0 ist C0 (schrieb ich auch auf Twitter so) - vom FX. Da Trinity u. neuere CPUs ein neues Modell darstellen (Modell 16 hatten wir ja schon), werden sie das Stepping (Model minus 16 für Buchstaben + Steppingzahl) neu zählen.
Hab jetzt meine Meinung geändert.
Grund:
a) Ein Orochi mit Piledriver-Kernen wäre eben *keine* neue Modellgruppe. 20h war Komodo mit integriertem PCIe und 3-4 RAM-Kanälen, aber das Ding ist eben gestrichen. Fazit: "Model 2" tuts allemal.

b) Nach der DIV-Geschichte frag ich mich sowieso inwieweit sich Bulldozerkern und Piledriver überhaupt unterscheiden. Sieht immer mehr danach aus, als ob Piledriver nur ein vollständig entbuggter BD ist -> Modell 0h - Fh

c) Zeit: Nach dems jetzt schon bald Mai wird, wird das Zeitfenster für nen C0-Bulldozer und darauffolgendem Vishera immer knapper. Maximal würde das nun ein halbes Jahr werden. Sowas gabs noch nie. Wenn man dagegen Rev.Cx = Vishera setzt passt alles. Man bekam gerade EE-Samples, alles im Zeitplan für nen Launch in H2. Letztes Jahr um die Zeit hatten sie auch schon (fast) B0.
 
B) ergibt für mich wenig Sinn. Nur mal zwei Punkte aus dem SOG:
Increased L1 DTLB size to 64 (models 10h–1fh and 20h–2fh)
2.12 Load-Store Unit
...
For models 10h-2Fh the depth
of the load queue is increased to 44 entries.
Und dazu kommt ja auch noch die Geschichte mit den AGLUs. Das hört sich nicht nur nach Fehlerbereinigung an.
 
Stimmt da hast Du recht.
Aber große Eingriffe sind das auch nicht, das läuft dann auch nur unter "Kleinvieh".
Die AGLUs wärem wohl ne größere Baustelle, aber die gabs ja nur für 20h, nicht für 10h. Ich denk das sparen sie sich bis zur 2013er Vishera-Version.

Problem ist immer noch, dass der SOG auf dem Kommodo (=20h)-Stand ist, und wir da irgendwie Vishera reinzwängen müssen, solange AMD kein Update rausrückt.
Ich spekulier eben drauf, dass nach dem nächsten Update da steht:
Increased L1 DTLB size to 64 (models 02h–3fh) (02h = OR-Cx, 30h sollte wohl Kaveri werden).
 
AMD könnte den jetzigen BD-µArchitektur-Update-Zyklus von 1 Jahr nicht halten, wenn sie erst ein Design fertig entwickeln und dann schauen würden, was es kann. Alle Architektur-Features, die im BD1 nicht enthalten sind und in BD2+ kommen, wurden so geplant bzw. eingetaktet.

Doch genau, das tun sie..schauen was eine Architektur kann... und dann eventuell das schon in die naechste Generation wieder zu verbessern - zu erwarten. Nur dass sie gewiss nicht warten bis sie tatsaechlich eine neue CPU gegossen haben...sondern das passiert gewiss schon sehr viel frueher...in der Entwicklung ;-).
Ich glaube gewiss nicht, dass erst dass erst ein fertiger Chip vom Band fallen muss, um
schon erste Lehren aus dem Design ziehen zu koennen und Dinge am Design weiterzuentwickeln...

Richtig neue Anpassungen an äußere Gegebenheiten, die größere Architekturänderungen nach sich ziehen(z.B. AVX2), könnten es kaum zum Steamroller schaffen, eher aber zum Excavator.

Solche Dinge dauern doch in der Entwicklung...Jahre... oder!?
 
Doch genau, das tun sie..schauen was eine Architektur kann... und dann eventuell das schon in die naechste Generation wieder zu verbessern - zu erwarten. Nur dass sie gewiss nicht warten bis sie tatsaechlich eine neue CPU gegossen haben...sondern das passiert gewiss schon sehr viel frueher...in der Entwicklung ;-).
Ich glaube gewiss nicht, dass erst dass erst ein fertiger Chip vom Band fallen muss, um
schon erste Lehren aus dem Design ziehen zu koennen und Dinge am Design weiterzuentwickeln...
Wie würdest du Chuck Moores "HW: The Ultimate Simulator" interpretieren?

Eine Architektur in der Simulation (und mit verschiedener Tiefe) zu bewerten, ist eine Sache. Da kann man schon viele Bugs finden und beseitigen sowie etwas optimieren. Aber umso weiter man in den Folgejahren an die Umsetzung in Silizium heranrückt, umso mehr Feinheiten kommen in das Design rein. Aber erst mit echten A0-Mustern können umfangreichere Codebasen und Testcases darauf laufen. Und wenn man sich mal einige Bedingungen zur Provokation von Bugs entsprechend der Errata-Liste anschaut (z.B. TLB-Bug), kann man sich schon vorstellen, warum man diese nicht eher gefunden hat.

Gerade feine Racing Conditions, Timingprobleme usw. in Multiprozessorumgebungen können auf sich warten lassen, bis sie gefunden werden. Warum ist wohl Design for Testability so wichtig?

Solche Dinge dauern doch in der Entwicklung...Jahre... oder!?
Ja, aber die einen davon erfordern komplett neue Einheiten (FMA, AES..), teils mit komplettem Umbau anderer Einheiten (Register File, Scheduler, Decoder etc. dank mehr Operanden), und andere erfordern eine Anpassung existierender Einheiten und deren Modus der Nutzung. AVX2 ist die Anwedung der AVX1-Codierung und 256b-Register auf Integer-SIMD. Dafür könnten auf einem BDv1 aufbauend sowohl die existierenden 128b Integer-SIMD-Einheiten (wie jetzt 128b FP für AVX auch) angepasst werden, als auch die schon existierende AVX-Decoderlogik und das Handling der 256b-Werte erweitert werden. Vermutlich könnte es aber eher schon richtige 256b (halb abschaltbar) oder mehr 128b-Einheiten und ein besseres 256b-Registerhandling geben. Effizienteres Decoding gehört dann auch dazu. Was mit den 128b-Load/Store-Pfaden passiert, ist auch fraglich. Das wäre sonst das nächste Bottleneck.

Und wenn man auf vieles aufbauen kann, ist der Aufwand geringer. Jahre dauert es sowieso immer. Aber wenn man strategisch denkt (und das sollte eine Firma in dem Halbleiter-Business genauso tun wie woanders auch), versucht man die Schritte des anderen vorauszudenken. Wer nur reaktiv handelt, kann per se nie Erster sein.
 
Gerade feine Racing Conditions, Timingprobleme usw. in Multiprozessorumgebungen können auf sich warten lassen, bis sie gefunden werden.

Es ist aber nunmal leider so, das BD im Desktop nicht bei einzelnen Anwendungen versagt sondern das er nur in absoluten Ausnahmefällen überhaupt mal "auf Touren kommt". Das hätte die Analyse bereits vor A0 zeigen müssen. (zornig mit dem Fuß aufstampf :-)
 
Es ist aber nunmal leider so, das BD im Desktop nicht bei einzelnen Anwendungen versagt sondern das er nur in absoluten Ausnahmefällen überhaupt mal "auf Touren kommt". Das hätte die Analyse bereits vor A0 zeigen müssen. (zornig mit dem Fuß aufstampf :-)
Das hat sie sicherlich. Dann hat jemand JF gesagt, dass das bei B0 ganz sicher repariert wird, und die IPC steigen wird, d.h. eine höhere IPC, also eine bessere IPC als vorher, quasi IPC++ (mehr fällt mir jetzt nicht mehr ein).

Bloß blöderweise war Vieles dann mit B0 immer noch nicht funktionsfähig und Essig wars mit der IPC... (wenn mir mal JF glauben wollen ... Ich glaub ihm mal. Den Shitstorm nach seiner offensichtlichen Lüge kann man als Marketingmann nicht gewollt haben ^^).
 
Es ist aber nunmal leider so, das BD im Desktop nicht bei einzelnen Anwendungen versagt sondern das er nur in absoluten Ausnahmefällen überhaupt mal "auf Touren kommt". Das hätte die Analyse bereits vor A0 zeigen müssen. (zornig mit dem Fuß aufstampf :-)
Gut, ich vergaß: Das reale Verhalten von über einer Milliarde 32nm-Transistoren aus der GF-Fertigung im Verbund erlebt man erst, wenn man über eine Milliarde 32nm-Transistoren aus der GF-Fertigung auf einem Chip testen kann. ;)

Leistungsfähigkeit hängt von IPC und Takt ab, der Taktspielraum dann vom Verbrauch und der gesetzten TDP. Es spielt alles zusammen, so wie immer.

Kommen die Transistoren nicht so schön aus der Fertigung, wie geplant, geht der Verbrauch hoch, die TDP mag keinen Platz schaffen, also geht die Performanz zwangsweise runter - auf ganzer Linie, wie du andeutest.
 
Mir stellt sich hier die Frage ob eine Technologie wie Resonant Clock Mesh auch schon seit Jahren feststeht oder erst Ende 2010 beschlossen wurde, als man sich ausmalen konnte wie sich Bulldozer "verhalten" könnte.

Ist das eher eine Technologie für den Fertigungsprozess oder für die Architektur. Ich ging eigentlich von letzterem aus.
 
Falscher Link?


Neue Folien zu Piledriver gibt's hier.

 
Genau falscher link , wobei ich nicht weiss woher der gekommen ist, ist korrigiert. Aber verlinken wolte ich die Seite mit der Grafik die du gepostet hast.
 
Vielleicht ist es etwas weit hergeholt aber wie hoch ist die Chance das die neuen Features der Piledriver bereits im Bulldozer Kern enthalten aber aufgrund von Fehlern nicht aktiv sind? Das würde vielleicht auch ein Grund für das recht große Die sein.
Vieles ist bereits in Hardware vorhanden, wird aber nicht genutzt.
 
@sompe
Fiffty Fiffty würde ich mal vermuten, hab schon ein paar Register probiert, aber wirklich mehr Leistung ist nicht bei rumgekommen, da bringt übertakten schon mehr.
Allerdings ist das meiner Meinung nach nur für Benchmarks interessant, im Alltag bringt das kaum was.
Hinzu kommt noch das die meisten Benchmarks mit HT Code arbeiten und somit die 8 Int-Kerne nicht 100% auslasten können.
(Erkennt man auch daran, dass die Programme nur 4 Kerne und 8 Threads anzeigen)

Bleibt nur zu hoffen das AMD bald einen Compiler für Windows bereitstellt und die Entwickler das Modul Konzept bei der Programmierung berücksichtigen.
Aber solange die Entwickler von Intel bezalht werden, wird sich daran wohl nicht viel ändern.

Einzig mit Linux könnte man noch einiges reißen, ich bin zwar dran aber Hexen kann auch ich nicht.

MfG
 
Das mag stimmen, aber Compiler können ggf. auch auf die Eigenheiten von BDs Fetch und Decode-stufe Rücksicht nehmen.
Ich hab da was im Hinterkopf was im Spekulatiusforum vor dem BD-Launch herumgeisterte und als "Accellerated Mode" oder so ähnlich seitens AMD betitelt wurde. - Das Klingt für mich danach als ob eben dieser Modus bei gut präpariertem Code zum Tragen kommen kann und das Dekodieren beschleunigen. - Und genau hier haperts ja auch bei BD noch recht ordentlich.
Trinity sieht hier schon eine Version besser aus. - Aber was mich nachdenklich stimmt ist, dass Intel schon seit mehreren CPU-Generationen mit Loop-Cache / Trace - Cache arbeitet, und gerade SAndy IMHO auch ordentlich von seinem µOp-Buffer profitiert. - Während AMD sowas anscheinend nicht gebacken kriegt und munter ein und die selbe Instruktion 100 mal durch den Decoder jagt (dessen Bandbreite sowieso knapp ist) wenn ich eine Schleife mit 100 Durchläufen schreib.
Also entweder ist sowas extrem kompliziert und schwer beherrschbar und Intel kann das Momentan auch nur stemmen durch die Vorarbeit zu Netburst-Zeiten, oder irgendwas ist faul in AMDs Ingineurscorps.
Ich meine, welcher CPU-Inginieur setzt freiwillig mehr Transistoren unter Feuer als nötig wären um eine Aufgabe zu erledigen? - und gerade bei geteilten Ressourcen kann es doch nur sinnvoll sein sich die Arbeit zu ersparen...!?
Hoffentlich sehen wir was änhliches in Steamroller oder so... wäre langsam an der Zeit...
 
Hoffentlich sehen wir was änhliches in Steamroller oder so... wäre langsam an der Zeit...
Jo habs mir auch nochmal überlegt, 2xµOp Cache würde wohl reichen um das Ganze deutlich zu entspannen und nähme auch nicht viel Platz weg. War bisher ja der 2x Decoder Fan, aber was ich da vergaß war das Interface zur Xbar, das würde man damit (höchstwahrscheinlich) auch verdoppeln (außer man beließe es bei einem gemeinsamen L1I-Cache, aber ob das dann was brächte?) -> Dickes Problem, bis 8 Kernen gehts vielleicht noch, aber dann wär ein Ring wie bei Intel nicht verkehrt.

Bin echt gespannt, was AMD beim Streamroller treiben.

Zum Compiler: Hab gerade im Heise-Forum gelesen, dass jemand meinte dass sein spezieller Code sehr gut mit Clang+LLVM laufen würde, fast auf Intel-Niveau, deutlich vor GCC. Mal schauen, ob das langfristig was wird ...
 
Mein Reden ;)
Eigentlich war ich bisher der Meinung dass das ganze BD-Konzept regelrecht prädestiniert für µOp Cache ist. Evtl. sogar ein einzelner für beide Kerne... genauso wie es nur 1 L1I-Cache gibt... ich weiss nicht wie hoch die wahrscheinlichkeit ist, dass es die selbe instruktion in 2 threads gibt... aber wenn der fall eintritt, würde ein gemeinsamer µop cache sogar dem zweiten Thread das dekodieren ersparen...
Zwei einzelne sind natürlich auch gut...
hauptsache in der Richtugn geht mal was
 
Wie oft kommen solche Schleifen denn im Alltag bei der Wald und Wiesen Software vor?
 
http://opencompute.org/wp/wp-content/uploads/2012/05/Open_Compute_Project_AMD_Motherboard_v2.0.pdf

http://opencompute.org/wp/wp-conten...ompute_Project_AMD_Motherboard_Roadrunner.pdf
* Two sockets per board
* Support for AMD processor codenamed “Magny-Cours”, “Interlagos”, and “Abu Dhabi” processors
* Abu Dhabi (“Orochi”-Rev C) support is mandatory
* Supports Infrastructure Group A, B, C: 85W, 115W, and 140W TDPs
* Magny-Cours: 8/12 cores codenamed “Greyhound” for Hydra die (MCM)
* Interlagos: 12/16 cores codenamed “Bulldozer” for Orochi die (SCM)
* Abu Dhabi: 4/8/12/16 cores codenamed “Piledriver” (MCM)
* Coherent Links: Triple x16 HyperTransport3 link supporting speeds up to 6.4 GT/s with support for HT1 operation @ 2.0 GT/s

damit dürfte doch alles gesagt sein oder ?
 
Zuletzt bearbeitet:
Ich finde die Einträge in dem PDF nicht *noahnung*

Wenn es stimmt hat Piledriver wieder "nur" 8 Kerne pro Die. Waren für BD nicht schon mal 10 gemunkelt worden?
 
Zurück
Oben Unten