Bulldozer 2.0 / BDver2: Sepang, Terramar, Komodo, Trinity, Vishera
Crashtest
Redaktion
☆☆☆☆☆☆
Etwas Bestätigung vom AMD ganz offen - keine Ahnung obs hier irgendwo nicht schon stand:
AMD Family 15h Model 10 bis 15h ist Trinity mit definitiv mit den Ablegern Comal und Virgo
Quelle : http://developer.amd.com/tools/CodeAnalyst/codeanalystwindows/Pages/default.aspx
Und etwas aus dem CodeAnalyst von AMD - bin\events\TN-events.xml
Womit auch definitiv klar ist wie die Maske / "Stepping" sich nennt : TN-xx zB TN-B0
AMD Family 15h Model 10 bis 15h ist Trinity mit definitiv mit den Ablegern Comal und Virgo
Quelle : http://developer.amd.com/tools/CodeAnalyst/codeanalystwindows/Pages/default.aspx
Und etwas aus dem CodeAnalyst von AMD - bin\events\TN-events.xml
Womit auch definitiv klar ist wie die Maske / "Stepping" sich nennt : TN-xx zB TN-B0
Dass BDs Flex-FPU brutto weniger Leistung hat als die 6 FPUs in Thuban ist logisch.
Allerdings stellt sich die Frage wie oft sich das Problem in der Praxis zeigt.
Der Jux am Moduldesign mit Shared FPU war ja eben der, dass die FPU ein transistorenfresser erster Güte ist, der aber nur in 30% des Codes überhaupt angesprochen wird.
Wenn ich so an den Programmierer-Alltag denke... Schleifenzähler, indizes, andere Zählvariablen, Booleans oder Bitfelder als Statusflags, Sprünge in Datenstrukturen auf und ab... das ist aber alles ALU/AGU - Futter. FP-Code begegnet mir eigentlich nur wenn es darum geht Geldbeträge auszurechnen, prozentwerte, Mehrwertsteuer usw.
Also davon ausgehend wären in meinem Alltag der ALU-Anteil > 90%.
Sogar H264 (also encoding) scheint doch nicht so furchtbar FPU-Lastig zu sein sodass die Schiebebefehle alla SSE5 (XOP) mehr bringen als die 256Bit-AVX sachen.
IMHO ist die FlexFPU bei BD sehr gelungen, allerdings hatten wir in Dresdenboys Patenten ja designes mit Bridged-FPU die noch interessanter gewesen wären, und die Vollen Durchsatz auch bei non-FMA geliefert hätten.
Also defacto gibt es dort optimierungspotenzial, aber nicht genug um den vollen Aufwand für eine Verdopplung zu gehen (Ausser man will LRBni unterstützen...) und IMHO ist das auch zuviel für so ein Mild-Update alla Piledriver.
Ich erwarte von Piledriver Verbesserungen im Cache-Management (weniger Trashing im L1), Die Decoderauslastung sollte verbessert werden bzw. der Durchsatz erhöht (fastpath, oder wie auch immer..) und es könnte noch einiges Tuning in den LOAD/STORE-Pipelines geben. Opteron hatte dazu doch mal was gepostet.
Effektiv nichts anderes als "Die Ecken abschleifen" damit es besser flutscht.
Dann noch etwas tuning am Transistorlayout und ggf. ULK um höhere Takte/weniger Spannung hinzukriegen und wir haben einen sehr brauchbaren Chip.
Steamroller kann dann noch ne Kohle drauflegen... Eager Execution, Tracecache, und der "do what i want" - Befehl
Allerdings stellt sich die Frage wie oft sich das Problem in der Praxis zeigt.
Der Jux am Moduldesign mit Shared FPU war ja eben der, dass die FPU ein transistorenfresser erster Güte ist, der aber nur in 30% des Codes überhaupt angesprochen wird.
Wenn ich so an den Programmierer-Alltag denke... Schleifenzähler, indizes, andere Zählvariablen, Booleans oder Bitfelder als Statusflags, Sprünge in Datenstrukturen auf und ab... das ist aber alles ALU/AGU - Futter. FP-Code begegnet mir eigentlich nur wenn es darum geht Geldbeträge auszurechnen, prozentwerte, Mehrwertsteuer usw.
Also davon ausgehend wären in meinem Alltag der ALU-Anteil > 90%.
Sogar H264 (also encoding) scheint doch nicht so furchtbar FPU-Lastig zu sein sodass die Schiebebefehle alla SSE5 (XOP) mehr bringen als die 256Bit-AVX sachen.
IMHO ist die FlexFPU bei BD sehr gelungen, allerdings hatten wir in Dresdenboys Patenten ja designes mit Bridged-FPU die noch interessanter gewesen wären, und die Vollen Durchsatz auch bei non-FMA geliefert hätten.
Also defacto gibt es dort optimierungspotenzial, aber nicht genug um den vollen Aufwand für eine Verdopplung zu gehen (Ausser man will LRBni unterstützen...) und IMHO ist das auch zuviel für so ein Mild-Update alla Piledriver.
Ich erwarte von Piledriver Verbesserungen im Cache-Management (weniger Trashing im L1), Die Decoderauslastung sollte verbessert werden bzw. der Durchsatz erhöht (fastpath, oder wie auch immer..) und es könnte noch einiges Tuning in den LOAD/STORE-Pipelines geben. Opteron hatte dazu doch mal was gepostet.
Effektiv nichts anderes als "Die Ecken abschleifen" damit es besser flutscht.
Dann noch etwas tuning am Transistorlayout und ggf. ULK um höhere Takte/weniger Spannung hinzukriegen und wir haben einen sehr brauchbaren Chip.
Steamroller kann dann noch ne Kohle drauflegen... Eager Execution, Tracecache, und der "do what i want" - Befehl
Was ist denn eigentlich eine Bridged-FPU, wenn man fragen darf?^^
Hab davon bisher noch nichts gehört und konnte auch nichts zu dem Namen finden...
Gerade durch Optimierungen der Caches sollte allerdings denke ich auch noch einiges drin sein. Die Eager Execution erinnert mich sehr an eine mögliche speculative execution für bedingte Sprünge und sollte eigentlich mit dem CMT Design recht gut realisierbar sein, aber dadurch sinkt auch wieder die Energieeffizienz, weswegen solch eine Methode doch recht fraglich erscheint.
Für die Dekoder wäre evtl. eine dynamische Aufteilung dessen Ressourcen an die Threads noch wünschenswert, anstatt immer abwechselnd für jeden Thread zu dekodieren...
Dazu noch mal eine Frage aus Eigeninteresse, wäre es nicht evtl. sinnvoller den normalen x87 FPU Code von den SIMDs zu trennen und lieber die ALU's dementsprechend zu erweitern? Dann könnte man die SIMD-Einheiten auch besser mit Vektorrechnungen auslasten anstatt sie mit skalarem Code zu füttern. Das würde dann auch später eine Fusion mit einer GPU erleichtern, die ja auch massiv auf SIMD ausgelegt ist und seit NI sogar einen kleinen skalaren Berechnungspfad spendiert bekommt.
Was dagegen sprechen könnte wäre die Größe einer FPU-Einheit, aber ich schätze mal dass sich das bei einer rein skalaren Einheit noch in Grenzen hält, oder?
Hab davon bisher noch nichts gehört und konnte auch nichts zu dem Namen finden...
Gerade durch Optimierungen der Caches sollte allerdings denke ich auch noch einiges drin sein. Die Eager Execution erinnert mich sehr an eine mögliche speculative execution für bedingte Sprünge und sollte eigentlich mit dem CMT Design recht gut realisierbar sein, aber dadurch sinkt auch wieder die Energieeffizienz, weswegen solch eine Methode doch recht fraglich erscheint.
Für die Dekoder wäre evtl. eine dynamische Aufteilung dessen Ressourcen an die Threads noch wünschenswert, anstatt immer abwechselnd für jeden Thread zu dekodieren...
Dazu noch mal eine Frage aus Eigeninteresse, wäre es nicht evtl. sinnvoller den normalen x87 FPU Code von den SIMDs zu trennen und lieber die ALU's dementsprechend zu erweitern? Dann könnte man die SIMD-Einheiten auch besser mit Vektorrechnungen auslasten anstatt sie mit skalarem Code zu füttern. Das würde dann auch später eine Fusion mit einer GPU erleichtern, die ja auch massiv auf SIMD ausgelegt ist und seit NI sogar einen kleinen skalaren Berechnungspfad spendiert bekommt.
Was dagegen sprechen könnte wäre die Größe einer FPU-Einheit, aber ich schätze mal dass sich das bei einer rein skalaren Einheit noch in Grenzen hält, oder?
WindHund
Grand Admiral Special
@ tex_
Eine Bridge-FPU sind 2x 128Bit FPUs, die zu 1x 265Bit zusammengefasst werden.
Bisher nutzten aber nur sehr wenig Anwendungen 265Bit Befehle, von daher ist hier ein recompilieren nötig.
Hier gibt es ein Blogeintrag von JF über die Flex FPU: http://blogs.amd.com/work/2010/10/25/the-new-flex-fp/
Eine Bridge-FPU sind 2x 128Bit FPUs, die zu 1x 265Bit zusammengefasst werden.
Bisher nutzten aber nur sehr wenig Anwendungen 265Bit Befehle, von daher ist hier ein recompilieren nötig.
Hier gibt es ein Blogeintrag von JF über die Flex FPU: http://blogs.amd.com/work/2010/10/25/the-new-flex-fp/
die bridge-FPU aus den patenten würde aber IMHO bei nicht-256Bit-Code eine bessere Auslastung erreichen können als die Flex-FPU die momentan verbaut ist.
Das mit der eager execution ist im prinzip speculative multithreading... und Andy Glew sagte mal, dass eben jene zu ermöglichen eigentlich der Hauptgrund dafür wäre CMT zu benutzen bzw. sein Entwurf darauf hin abzielte. Die energieeffizienz steht auf einem anderen blatt, kann unter umständen bei chaotischem code aber sogar ganz gut sein...man hat das ergebnis ja effektiv schon vorliegen und rechnet auch nicht zweimal, zumindest wenn die sprungvorhersage passt.
Notfalls könnte man das Abschaltbar gestalten, dass der Benutzer entscheiden kann per BIOS-Option ob ihm das den zusätzlichen Stromverbrauch wert ist...
Ob sich das mit den ALUs lohnt weiss ich nicht... immerhin hat man dann FP-Recheneinheiten in den ALUs und nochmal im SIMD-FP-teil... das widerspricht eigentlich dem paradigma des REssourcensharings...
Das mit der eager execution ist im prinzip speculative multithreading... und Andy Glew sagte mal, dass eben jene zu ermöglichen eigentlich der Hauptgrund dafür wäre CMT zu benutzen bzw. sein Entwurf darauf hin abzielte. Die energieeffizienz steht auf einem anderen blatt, kann unter umständen bei chaotischem code aber sogar ganz gut sein...man hat das ergebnis ja effektiv schon vorliegen und rechnet auch nicht zweimal, zumindest wenn die sprungvorhersage passt.
Notfalls könnte man das Abschaltbar gestalten, dass der Benutzer entscheiden kann per BIOS-Option ob ihm das den zusätzlichen Stromverbrauch wert ist...
Ob sich das mit den ALUs lohnt weiss ich nicht... immerhin hat man dann FP-Recheneinheiten in den ALUs und nochmal im SIMD-FP-teil... das widerspricht eigentlich dem paradigma des REssourcensharings...
http://www.cpu-world.com/news_2012/2012011101_Features_of_AMD_Piledriver_processors.html
Vishera = Komodo @ AM3? Also keinesfalls ein Orochi 2.0? Das wär plausibel, wenn man bedenkt, dass Terramar und Sepang offenbar noch aktuell sind. Und technisch wäre es ebenfalls möglich, da man einen der RAM-Controller einfach deaktiviert und nur einen der HT-Links nutzt.
Dass man sich von FM2 zu AM3 umentschieden hat, mag ganz einfach daran liegen, dass Kaveri offenbar wieder eine neue Plattform benötigt.
Vishera = Komodo @ AM3? Also keinesfalls ein Orochi 2.0? Das wär plausibel, wenn man bedenkt, dass Terramar und Sepang offenbar noch aktuell sind. Und technisch wäre es ebenfalls möglich, da man einen der RAM-Controller einfach deaktiviert und nur einen der HT-Links nutzt.
Dass man sich von FM2 zu AM3 umentschieden hat, mag ganz einfach daran liegen, dass Kaveri offenbar wieder eine neue Plattform benötigt.
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Hab mir das Ganze nun man genau angeschaut.
So wies ausschaut bleibt der alte Zusammenhang bestehen, die 20h Teile sollten schon Steamroller sein. Grund:
Bei den Instruktionen gibts nur bei den 20h Modellen ne aufgepumpte AGLU. Die kann jetzt noch mehr Instruktionen außer LEA+INC/DEC ausführen, vornehmlich solche, die nur auf Register zugreifen, macht ja dann auch Sinn, da man dafür logischerweise keine Adressen berechnen braucht, die AGLU also ansonsten arbeitslos wäre.
Die FPU wird dagegen schon mit dem 10h Modell aktualisiert. Recht viel tut sich allerdings da auch nicht, hauptsächlich werden die 256b AVX Befehle auf "Normalspeed" der 128b Versionen gebracht. Zusätzlich werden noch ein paar µCode Instr. schneller, aber nicht die Welt. Ein paar werden auch einen Takt langsamer. Aja und nachtürlich die neuen Befehle, FMA3/F16C etc. pp.
Außerdem werden Bypasses auf Store umsonst, bisher kosten die einen Takt.
Und die Befehle sind noch erwähnenswert, die sinken von 2 auf 0 Takte:
Allgemeines: Das PDF wird immer chaotischer, die D-TLB Infos werden jetzt noch mehr gestreut, z.B. beim I-TLB, obwohl der D-TLB Eintrag genau eine Zeile tiefer kommt, da muss einer Tomaten auf den Augen gehabt haben.
Bauchschmerzen hab ich nachwievor bei dem Quad-Channel Info. Einerseits kann ichs mir nicht vorstellen, andrerseits gabs vorher ja schon die Triple-Channel bestätigung bei früheren Modell. Nachdem Intel jetzt auch 4 hat, könnte AMD sich das nun auch leisten wollen. Außerdem gibts ja seit Kurzem nen 28nm-SHP Prozess bei GF, der steht für 2012 auf der Liste. Möglicherweise kommt der jetzt gleich zum Einsatz. Auf der hp-Roadmap steht das erst für 2013 mit Dublin/Macau im Plan, aber die ist vom April 2011, Rory kam erst im August. Außerdem hat sich BD1 ja gut verspätet und Komodo stand mit "Piledriver" Kernen auf der Liste.
Weiterer Punkt: AMD hat bekanntlich die 28nm low-end Produktion bei GF gestrichen, eventuell haben sie die Bestellung auf 28nm SHP geändert bzw. gebraucht.
Und Vishera? Der müßte auch Weg vom Fenster sein, angeblich sollens ja auch wieder Piledriver-Kerne werden, aber im Opt.PDF steht ja ausdrücklich, dass die 10h Modelle keinen L3 und nur 2 Module haben. Aber gut - die Qualität des Teils wird immer schlimmer, beim nächsten Update kann sich das schon wieder ändern.
Aber: Allein, ohne Server-Chips macht ein Vishera-Projekt eigentlich auch herzlich wenig Sinn. Ein Intel Weg, bei dem man die "Enthusiasten" als Beta-Tester einspannt, wie gerade beim 2011-Start wäre eigentlich ganz praktisch. Also vielleicht Ende 2012 ne C2012-Beta Quad-Channel Plattform fürs Volk. Bis dahin könnte auch brauchbares 28nm SHP Silizium vom Band gefallen sein
Naja, kommt Zeit kommt Analysten-Messe ^^
Crashtest
Redaktion
☆☆☆☆☆☆
Also noch mal zum mitschreiben :
AMD Family 15h Model 10h-1Fh ist TRINITY und der braucht keine 4 Module weil ja auch ne GPU eingebaut werden muss, daher auch kein L3 und nur 2 Module.
Bis zu 4 "Kerne" mit GPU reicht für die meisten Desktop und Mobilgeräte
AMD Family 15h Model 20h-2Fh wird der Orochi-Nachfolger für Server, Workstation und FX
Daher auch mehr Module, L3-Cache und HT
AMD macht ein wenig auch Intel TickTockTucken
erst ein Update des Llanos auf Trinity und kurz danach das Update des Bulldozers auf Model 20h-2Fh ...
AMD Family 15h Model 10h-1Fh ist TRINITY und der braucht keine 4 Module weil ja auch ne GPU eingebaut werden muss, daher auch kein L3 und nur 2 Module.
Bis zu 4 "Kerne" mit GPU reicht für die meisten Desktop und Mobilgeräte
AMD Family 15h Model 20h-2Fh wird der Orochi-Nachfolger für Server, Workstation und FX
Daher auch mehr Module, L3-Cache und HT
AMD macht ein wenig auch Intel TickTockTucken
erst ein Update des Llanos auf Trinity und kurz danach das Update des Bulldozers auf Model 20h-2Fh ...
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Jo, das passt. Nur wundert es mich halt, dass die Kerne unterschiedlich sind. Keine Frage, das PDF ist qualitätsmäßig auf niederem Niveau, aber dass man die pure Info vertauscht, also bessere AGLUs "ab M 20h" schreibt, anstatt "ab M 10h", glaub ich eher weniger. Mit 20h hab ich aber noch nicht gerechnet, weswegen ich spekuliere, dass die 20h Teile schon vom Typ Steamroller sind.
Wenn dem so ist, kommt die Frage auf, was es für den high-end Desktop gibt. Der Mainstream ist natürlich mit 4 Threads bestens aufgestellt, aber ein Orochi Nachfolger sollte schon 8 in die Waagschale werfen können.
So wies jetzt ausschaut wird das eher Ende 2012 was mit nem Upgrade für Orochi, damit paßte aber auch Orochi Rev. B3 gut ins Bild, das wäre quasi dann das Haupt-Die für 2012.
Und beim Tickgetocke ist eben die Frage nach 28nm SHP, ob das schon bereit steht. Aus zeitlicher sicht wäre mir eigentlich 32nm lieber aber Komodo & Co. sind ja gestrichen.
Wenn dem so ist, kommt die Frage auf, was es für den high-end Desktop gibt. Der Mainstream ist natürlich mit 4 Threads bestens aufgestellt, aber ein Orochi Nachfolger sollte schon 8 in die Waagschale werfen können.
So wies jetzt ausschaut wird das eher Ende 2012 was mit nem Upgrade für Orochi, damit paßte aber auch Orochi Rev. B3 gut ins Bild, das wäre quasi dann das Haupt-Die für 2012.
Und beim Tickgetocke ist eben die Frage nach 28nm SHP, ob das schon bereit steht. Aus zeitlicher sicht wäre mir eigentlich 32nm lieber aber Komodo & Co. sind ja gestrichen.
Onkel_Dithmeyer
Redaktion
☆☆☆☆☆☆
28nm soll doch in New-York anfahren oder? Da stand mal was von Produktionsbeginn in der zweiten Jahreshälfte im Raum. (Anlaufen der Massenproduktion) Wird dieses Jahr also eher eng.
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Das weiß keiner so genau, Dekaisi schrieb im Prozess-Thread, dass sie die für NY vorgesehenen Maschinen nach DD umleiteten, obwohl die schon in NY waren ... bei GF gehts halt auch rund ...
Außerdem sollte in DD ja jetzt 28nm low-end Bobcats vom Band fallen. Zwar nicht SHP, sondern LP, aber soo kompliziert sollte der Umstieg jetzt nicht sein. Preisfrage ist, ob AMD die Chips gestrichen hat, weil sies einfach wollten, oder weil GF aufgrund fehlendem Equipments mit 28nm nicht in die Pötte kam. Aber zumindest ARM (Prototypen)-Designs gibts ja in 28nm.
Am wohlsten wäre mir, wenns überall Piledriver Kerne wären, und die Modelnummern nur die unterschiedlichen Produkte kennzeichnet, aber nach der AGLU-Info müssen das was neue Kerne sein.
Edit:
NY fährt auch gerade mit 32nm an:
http://globalfoundries.com/newsroom/2012/20120109.aspx
Nachdem da auch was von eDRAM steht, aber wohl eher ein IBM Design, kein AMD. 100%ig ists nicht auszuschließen, aber der 32nm Shrink Power7+ des 45nm-Power7 fehlt eh noch.
foenfrisur
Grand Admiral Special
- Mitglied seit
- 19.02.2002
- Beiträge
- 4.791
- Renomée
- 77
wenn amd von +10% mehr x86-performance beim bulettendoser 2 spricht, ist das dann wieder "best case" oder durchschnitt ?
oder ist die folie ALT?
unten steht "media-workload", bedeutet?
gibt hier bestimmt jmd, der mehr infos hat oder?
http://www.pcgameshardware.de/aid,8...Features-von-Piledriver-und-Trinity/CPU/News/
also der rundumschlag wirds wohl immernoch nicht so ganz.
mfg
oder ist die folie ALT?
unten steht "media-workload", bedeutet?
gibt hier bestimmt jmd, der mehr infos hat oder?
http://www.pcgameshardware.de/aid,8...Features-von-Piledriver-und-Trinity/CPU/News/
also der rundumschlag wirds wohl immernoch nicht so ganz.
mfg
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Den abgrundtiefen Mist haben wir schon hier besprochen:
http://www.planet3dnow.de/vbulletin/showthread.php?p=4551748#post4551748
Noch zum PDF:
Was mir gerade noch einfällt ... das Quad-DDR3-Interface könnte auch dafür herhalten eine Plattform einzusparen. Die ganze Validierung & Co. kostet ja auch gut Geld und Personal, der Ertrag dürfte aber arg mager sein, soviel C32 Systeme gibts ja nicht. Angedacht wars ja eh nur für die Cloud. Spart sicherlich einiges, wenn man das jetzt streicht. Dafür halt nur einen einzigen Quad-Sockel und fertig. Nachteil: Die-Größe wird deutlich umfangreicher, aber wird sich schon noch im Rahmen halten.
Crashtest
Redaktion
☆☆☆☆☆☆
Quad-DDR3 ist m.M.n. für den Sockel C32-Nachfolger undoder einige G34 gedacht:
- der C-Nachfolger soll(t)e 3-Kanal DDR3 haben (also ein Kanal deaktiviert)
- es gibt bedarf für kleine G34-CPUs sodass man bei einem bis 5 Moduler mit Quad-DDR3 auch Single-DIE-G34 bauen könnte.
Der G34-Nachfolge soll(t)e auch nur Quad-DDR3 haben ?!?
Es ist derzeit viel Chaos bei AMD:
- AMD Family 15h Model 10h-1Fh in Anmarsch -> Pilenzieher
- AMD Family 15h Model 20h-2Fh in Anmarsch -> Pilenzieher
- AMD Family 15h Model 30h-3Fh in der Nähe/Planung -> Steamrolle
- AMD Family 15h Model 40h-3Fh in der Nähe/Planung -> Steamrolle
Kommisch diese Extended-Model-Sprünge der Family 15h kennen wir doch bereits - Family 15 hatte dies auch ....
Ggf. erfolgen Familiensprüng um 20h dh
Family 15h Model 00-0Fh - kein APU
Family 15h Model 10-1Fh - APU
Family 15h Model 20-2Fh - kein APU
uswusf - hat auch was
Aber da gibts noch Rumor bzgl. AMD Family 16h Model 00-0Fh und auch AMD Family 17h Model 00-0Fh (halt MEGA-Chaos); von den AMD Family 14h Model 10-1Fh und Model 20-2Fh wollen wir mal lieber nicht reden ...
Mal sehen was die NDA-Quellen so machen ....
- der C-Nachfolger soll(t)e 3-Kanal DDR3 haben (also ein Kanal deaktiviert)
- es gibt bedarf für kleine G34-CPUs sodass man bei einem bis 5 Moduler mit Quad-DDR3 auch Single-DIE-G34 bauen könnte.
Der G34-Nachfolge soll(t)e auch nur Quad-DDR3 haben ?!?
Es ist derzeit viel Chaos bei AMD:
- AMD Family 15h Model 10h-1Fh in Anmarsch -> Pilenzieher
- AMD Family 15h Model 20h-2Fh in Anmarsch -> Pilenzieher
- AMD Family 15h Model 30h-3Fh in der Nähe/Planung -> Steamrolle
- AMD Family 15h Model 40h-3Fh in der Nähe/Planung -> Steamrolle
Kommisch diese Extended-Model-Sprünge der Family 15h kennen wir doch bereits - Family 15 hatte dies auch ....
Ggf. erfolgen Familiensprüng um 20h dh
Family 15h Model 00-0Fh - kein APU
Family 15h Model 10-1Fh - APU
Family 15h Model 20-2Fh - kein APU
uswusf - hat auch was
Aber da gibts noch Rumor bzgl. AMD Family 16h Model 00-0Fh und auch AMD Family 17h Model 00-0Fh (halt MEGA-Chaos); von den AMD Family 14h Model 10-1Fh und Model 20-2Fh wollen wir mal lieber nicht reden ...
Mal sehen was die NDA-Quellen so machen ....
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Ja, aber Komodo ist ja auch weg vom Fenster, und seit der letzten Analystenkonferenz verlor AMD erst nen CEO, und nach nem halben Jahr kam ein Neuer.
Jo, sowas schwebt mir vor ^^
Jo, reicht doch. Bei den dual-Dies muss man halt deaktivieren, aber die sind teuer genug, dass sich das da rentiert. Vorteil für die single-Dies ist, dass man auch noch dick viel RAM reinbringt. Fände es gar nicht sooo schlecht, wenn man C32 begräbt, kostet nur und wenn man eh schon nen Nachfolger mit 3 Kanälen plant, kann man gleich noch einen dazubasteln und eine Plattform einsparen.
Das dacht ich bisher (vor dem neuen OSG) auch, aber jetzt steht da 20h mit ner überarbeiteten AGLU drin, die die 10hs noch nicht haben -> ergo es kann kein Piledriver sein.
Hmm, ja möglich, irgendwas muss man sich ja einfallen lassen.
Ja, hör mir nur auf, mir reicht das aktuelle Chaos schon *g*
Jo, das oder halt die Konferenz nächsten Monat, da sollte dann mal klar Tisch gemacht werden.
P.S: Was mir gerade noch einfällt: Wäre auch gut zu wissen, was die Jungs im Writecombiningabsatz mit den Fam. 15h "version 1" und "version 2" meinten. Version 1 muss wohl der aktuelle sein, aber ist Version 2 jetzt 10h oder 20h, oder beides?
Danke für die erhellende Info. Das würde ja auch bedeuten, dass die neue CPU höchstwahrscheinlich weder auf AM3 noch auf FM2 läuft. Wenn man auch im Desktop-Markt PCIe3 (wahrscheinlich mehr als 32 Lanes) bringen möchte, macht QuadChannel ja auch wieder Sinn von der Bandbreite her - man muss ja nicht nur die CPU versorgen. Die Neue wär dann ja dann eher sowas wie SBE.Hab mir das Ganze nun man genau angeschaut.
So wies ausschaut bleibt der alte Zusammenhang bestehen, die 20h Teile sollten schon Steamroller sein. Grund:
Bei den Instruktionen gibts nur bei den 20h Modellen ne aufgepumpte AGLU. Die kann jetzt noch mehr Instruktionen außer LEA+INC/DEC ausführen, vornehmlich solche, die nur auf Register zugreifen, macht ja dann auch Sinn, da man dafür logischerweise keine Adressen berechnen braucht, die AGLU also ansonsten arbeitslos wäre.
Die FPU wird dagegen schon mit dem 10h Modell aktualisiert. Recht viel tut sich allerdings da auch nicht, hauptsächlich werden die 256b AVX Befehle auf "Normalspeed" der 128b Versionen gebracht. Zusätzlich werden noch ein paar µCode Instr. schneller, aber nicht die Welt. Ein paar werden auch einen Takt langsamer. Aja und nachtürlich die neuen Befehle, FMA3/F16C etc. pp.
Außerdem werden Bypasses auf Store umsonst, bisher kosten die einen Takt.
Und die Befehle sind noch erwähnenswert, die sinken von 2 auf 0 Takte:
Allgemeines: Das PDF wird immer chaotischer, die D-TLB Infos werden jetzt noch mehr gestreut, z.B. beim I-TLB, obwohl der D-TLB Eintrag genau eine Zeile tiefer kommt, da muss einer Tomaten auf den Augen gehabt haben.
Bauchschmerzen hab ich nachwievor bei dem Quad-Channel Info. Einerseits kann ichs mir nicht vorstellen, andrerseits gabs vorher ja schon die Triple-Channel bestätigung bei früheren Modell. Nachdem Intel jetzt auch 4 hat, könnte AMD sich das nun auch leisten wollen. Außerdem gibts ja seit Kurzem nen 28nm-SHP Prozess bei GF, der steht für 2012 auf der Liste. Möglicherweise kommt der jetzt gleich zum Einsatz. Auf der hp-Roadmap steht das erst für 2013 mit Dublin/Macau im Plan, aber die ist vom April 2011, Rory kam erst im August. Außerdem hat sich BD1 ja gut verspätet und Komodo stand mit "Piledriver" Kernen auf der Liste.
Weiterer Punkt: AMD hat bekanntlich die 28nm low-end Produktion bei GF gestrichen, eventuell haben sie die Bestellung auf 28nm SHP geändert bzw. gebraucht.
Und Vishera? Der müßte auch Weg vom Fenster sein, angeblich sollens ja auch wieder Piledriver-Kerne werden, aber im Opt.PDF steht ja ausdrücklich, dass die 10h Modelle keinen L3 und nur 2 Module haben. Aber gut - die Qualität des Teils wird immer schlimmer, beim nächsten Update kann sich das schon wieder ändern.
Aber: Allein, ohne Server-Chips macht ein Vishera-Projekt eigentlich auch herzlich wenig Sinn. Ein Intel Weg, bei dem man die "Enthusiasten" als Beta-Tester einspannt, wie gerade beim 2011-Start wäre eigentlich ganz praktisch. Also vielleicht Ende 2012 ne C2012-Beta Quad-Channel Plattform fürs Volk. Bis dahin könnte auch brauchbares 28nm SHP Silizium vom Band gefallen sein
Naja, kommt Zeit kommt Analysten-Messe ^^
Die Rev.B3 bzw. Rev.C-Info macht dann auch wieder mehr Sinn, ursprünglich waren ja keinerlei Fixes in den Fixlisten. Das könnte sich im Zuge des Strategiewechsels ja auch wieder geändert haben, dass jetzt also doch mehr Fixes laufen werden. Ein komplett neues Die mit PD-Kernen für AM3+ wäre eigentlich auch echt Schwachsinn, weil wie schon erwähnt es keine Serverdice gäbe und der Prozessor wahrscheinlich auch nur recht kurz auf dem Markt wäre. Hinzu kommt, dass PD kaum Vorteile bieten dürfte, die ein so tiefgreifendes Orochi-Upgrade rechtfertigen würden, erst recht ohne Server. Mit Steamroller allerdings lässt sich Q3 absolut nicht halten, da wäre Ende Q4 der früheste Termin mMn. Und die kämen auch nicht auf NY, die kämen aus Dresden. NY läuft ja erstmal mit 32nm überhaupt an, dann lässt sich Dresden auch problemlos früher umrüsten als geplant, ohne dass man sich in der Produktion zu viel einschränken müsste. Wahrscheinlich waren die neue 28nm-Bulk-Produkte in NY geplant, nun sind aber die 32nm-Produkte dank IBM nach NY gewandert, so wird Dresden frei für die Umstellung nach 28nm-SOI. Dann laufen auch im Zuge der Umstellung erstmal die neuen 28nm-Dickschiffe vom Band, später kommt Kaveri hinzu, wenn man schon größere Mengen produzieren kann und auch NY dann zur 28nm Umstellung entlastet werden kann. Trinity dürfte in der doch erheblich größeren NY-Fab auch deutlich besser aufgehoben sein, da man damit evtl. Lieferproblemen besser begegnen kann. Hey, das könnte sogar der Grund sein, warum jetzt plötzlich von Sommer die Rede ist bei Trinity, obwohl es ja erst hieß man schafft sogar noch im März...
Es ist auch sicher sinnvoll erstmal einen schon fertig entwickelten Prozess in der neuen Fab zu nutzen, als gleich mit einem nagelneuen Fertigungsprozess einzusteigen. Das wird man bei Wichita recht schnell gemerkt haben, dass es nicht sinnvoll ist, alles gleichzeit zu machen
.3 Kanäle macht AMD mit an Sicherheit grenzender Wahrscheinlichkeit nicht. Intel zeigt ja ganz gut, wie man das effizient hinbekommt mit vieren. Bis AMD damit kommt, wird das auch im Desktop-Bereich günstig zu produzieren sein seitens der Mobo-Hersteller. AMD wird sich das zu Nutze machen. Man wird es eher wie Intel machen und die 2P-Plattform in den Desktop-Markt bringen. Das geht garnicht anders, weil sich eine separate Plattform nur für High-End-Desktop beim besten Willen nicht lohnt. Dann werden wir wohl auch endlich mal LGA im Desktop sehen bei AMD
.Das ist echt ne seltsame Aufteilung. PD ist ja 1xh, also warum sollte 2xh auch PD sein? Mach mMn keine erkennbaren Sinn. 0xh = BD, 1xh = PD, 2xh = SR und 3xh = Exc ist erheblich sinnvoller mMn... Man darf ja auch nicht vergessen, wenn der 20nm Excavator in 2013 ansteht, muss er jetzt schon in Planung/Design sein.
Zuletzt bearbeitet:
Markus Everson
Grand Admiral Special
Hat der neue Oberboß nicht gerade erst verkünden lassen das er sich auf ein Prestigerennen nicht einlassen und stattdessen auf Gewinn konzentrieren will? Damit fällt ein High-End-Desktop-SBE-Surrogat-Derrivat-Extract fast automatisch raus.
Für PCIe3 x1 bis x8 brauchst Du keine höhere Bandbreite zum Ram. Um eine Karte an PCIe3x16 zu sättigen die bereits an PCIe2x16 gesättigt war brauchst Du ebenfalls keine höhere Bandbreite.
Aber von 28nm SOI träumen?
Möglich das das so kommt. Möglich aber auch das Dresden in Ungnade gefallen ist und auf der Abschussliste steht. 32nm SOI versemmelt, 28nm Bulk versemmelt...
Drei Kanäle sehe ich noch nicht. Zu wenig Nutzen für zuviel Aufwand.
Opteron Boards mit Desktop Features? Bin dafür.
Hey, der Satz, den er da abgelassen hat, hatte genau 0 Aussagekraft und war auch nur für die Aktionäre bestimmt. Das hat nicht unbedingt was mit der Realtität zu tun, denn, was ist denn AMDs Kerngeschäft? Richtig, x86er und wer Produziert noch x86er? Richtig Intel. Also ist die Ganze Aussage von Read eigentlich automatisch Bullshit gewesen.
Ist richtig, aber die c't erwähnte zum Sockel 2011 von Intel auch, dass man die ganzen PCIe-Lanes, die da verfügbar sind, sobald die voll genutzt werden, DualChannel theoretisch nicht mehr reichen würde. Ist nur ein theoretischer Wert, klar. Für Desktop macht mehr als 2 Kanäle ohne Grafik keinen erkennbaren Sinn.
Wieso träumen? MMn träumt derjenige, der Bulk favourisiert. AMD wird bei SOI bleiben, das halte ich für 99% sicher. Alle bisherigen CPUs sind SOI und ausgerechnet bei dem neuen Dickschiff soll man jetzt plötzlich Bulk verwenden? Warum?
So ein Quatsch... eine ganze Entwicklungsabteilung fällt nicht in Ungnade, erst recht, wenn doch garnicht sicher ist, dass sie überhaupt was mit 28nm Bulk zu tun hatte - der Prozess wird nämlich eher als 40nm-Bulk-Nachfolger aus Singapur kommen. Man darf nicht vergessen, dass in NY wahrscheinlich überhaupt keine Eigenentwicklung stattfindet. NY war von Anfang an als Massenproduktionsanlage geplant, nicht als Entwicklungsanlage. Es reichen auch zwei Entwicklungsteams in Dresden und Singapur, man wird das wohl eher in Dresden zusammenführen irgendwann, um Kosten zu sparen und Synergien zu nutzen.
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Ich eben auch
Wenn man spekuliert, dass AMD die ganzen Opterons und high-end Desktops auf eine einzige Plattform stellt, passt das schon. Da spart man dann schon zum vorherigen Status, das hat dann nichts mit Prestige zu tun. Wie besagt, die HE-Desktop Leute kann man dann als Beta-Tester mißbrauchen, das sollte sich dann schon rechnen. Preismäßig wird AMD sicherlich etwas weniger für den Chipsatz verlangen, als Intel für den X79, dann gäbs Boardpreise zw. 100-150 Euro, wäre auch ok.
Für den Mainstream gibts eh schon die FMx Plattform, das ist der eigentlich AM3(+) Nachfolger für den Massenmarkt. Dann halt noch GC/2012 dazu, fertig
Markus Everson
Grand Admiral Special
Ich würde sagen das Du mich mißverstanden hast - wenn ich nicht schon gefühlte 10^18 mal betont hätte das SOI an sich sondern 28nm SOI es ist was imo nur Wunschdenken ist.
Aber warten wir mal ab, nach der Messe ist vor der Messe und die nächste Schlipsparade (Bilanzen und Ausblicke) steht ja auch bald wieder an.
.
EDIT :
.
Wollen wir mal hoffen das Du mit Deiner Einschätzung richtig liegst und ich auf dem Holzweg bin. Wäre mir durchaus recht.
.
EDIT :
.
Welcher Chipsatz wäre das? Ich dachte HTr Anbindung zum Chipsatz bedeutet das der hier wie dort funktioniert.
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Gute Frage, vielleicht wird man sich das auch aussuchen können, so ein Serverchip muss ja auch noch Hypertransport dabei haben. An dem könnte man dann noch nen "ollen" HTr Chipsatz bis runter zum nforce3 dranhängen.
Aber zumindest ein "paar" PCIe Lanes muss das Teil auch mitbringen, somit könnte man sich auch gleich mit ner Southbridge zufrieden, bzw. halt dem Llano-Chipsatz oder dessen Nachfolger. Das würde ich favorisieren, die CPUs bekommen ja ziemlich sicher PCIe3.0 eingebaut, was wollte man da noch mit nem alten 990FX Chipsatz mit PCIe 2.0. Ein Update des Chipsatzes auf PCIe 3.0 macht wohl auch wenig Sinn.
Aber warten wirs mal ab, wie Du schon sagst "Schlipsparade" steht an *g*. Ich finds zwar einigermaßen logisch, aber ob das wirklich so kommt, wissen wir nicht. Die Wahrscheinlichkeit, dass das PDF "fehlerhaft" ist, ist nicht gerade klein
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Edit:
Noch ein Hinweis: bei MSI gibts seit Dez. AGESA 1.2.0.0:
http://msi-forum.de/index.php?page=Thread&threadID=99597&pageNo=5&6e941cfe
Noch ein Hinweis: bei MSI gibts seit Dez. AGESA 1.2.0.0:
http://msi-forum.de/index.php?page=Thread&threadID=99597&pageNo=5&6e941cfe
G
Gast30082015
Guest
Der Vollständigkeit halber:
HT4U hat ein bissl in den bekannten Dokumenten gewühlt und aufbereitet:
http://ht4u.net/news/25073_amd_dokumente_verraten_details_zu_trinity-_und_vishera-prozessoren/
Die Leute bei 3dcenter haben sich ne News von x-bit labs geschnappt:
http://www.3dcenter.org/news/amd-pi...-version-fuer-trinity-vollausbau-fuer-vishera
Das Trinity Piledriver Vers.1 und Vishera Pliedriver Vers.2 bekommt, war hier im Board ja schon mehr oder minder bekannt/klar.
HT4U hat ein bissl in den bekannten Dokumenten gewühlt und aufbereitet:
http://ht4u.net/news/25073_amd_dokumente_verraten_details_zu_trinity-_und_vishera-prozessoren/
Die Leute bei 3dcenter haben sich ne News von x-bit labs geschnappt:
http://www.3dcenter.org/news/amd-pi...-version-fuer-trinity-vollausbau-fuer-vishera
Das Trinity Piledriver Vers.1 und Vishera Pliedriver Vers.2 bekommt, war hier im Board ja schon mehr oder minder bekannt/klar.
