Was kommt (nach den ersten Deneb (K10.5+)) fuer den Desktop bis zum Launch der BD(APUs)?
- Ersteller TNT
- Erstellt am
Kann er dazu irgendwelche Quellen nennen?
Das widerspräche sämtlichen bisherigen Roadmaps, JFs Aussagen und auch sonstigem Konsens.
Ich meine, wenn bisher 2011 im Raum stand und da war meistens nicht Anfang 2011 angenommen, dann wäre Ende 2010 schon ein gewaltiger Schritt...
Also entweder sie bringen nen "kastrierten" BD dieses Jahr um den PErformanceabstand zu intel zu verkürzen und das "echte" dauert dann noch, oder sie haben ne Validierung in Rekordzeit hingekriegt...
Aber jetzt die Plattform mit aufwändigen Konstruktionen alla MC zu launchen und in nichtmal 9 Monaten die BD-Ablösung auf der selben Plattform zu bringen, wäre doch irgendwie irre oder?
Die können doch nie und nimmer in der Zeit genug MC verkaufen um die Entwicklungskosten reinzuholen... da macht man sich ja selbst Konkurrenz...!?
Grüßchen
ich
Das widerspräche sämtlichen bisherigen Roadmaps, JFs Aussagen und auch sonstigem Konsens.
Ich meine, wenn bisher 2011 im Raum stand und da war meistens nicht Anfang 2011 angenommen, dann wäre Ende 2010 schon ein gewaltiger Schritt...
Also entweder sie bringen nen "kastrierten" BD dieses Jahr um den PErformanceabstand zu intel zu verkürzen und das "echte" dauert dann noch, oder sie haben ne Validierung in Rekordzeit hingekriegt...
Aber jetzt die Plattform mit aufwändigen Konstruktionen alla MC zu launchen und in nichtmal 9 Monaten die BD-Ablösung auf der selben Plattform zu bringen, wäre doch irgendwie irre oder?
Die können doch nie und nimmer in der Zeit genug MC verkaufen um die Entwicklungskosten reinzuholen... da macht man sich ja selbst Konkurrenz...!?
Grüßchen
ich
Macht aber Sinn. Bisher waren die Abstände zwischen den ServerCPUs immer weniger als ein 3/4 Jahr. Shanghai - Istanbul - Magny-Cours/Lisbon (noch Q1 2010) also wäre es Ende 2010 durchaus wieder Zeit.
Für Desktop kommt jetzt Thuban über ein Jahr nach Deneb, wenn es aber kein natives 4-Kern-Design geben sollte, würd ich an AMDs Stelle den so schnell wie möglich durch BD ersetzen. Thuban sehe ich mehr so als Zwschenlösung, um was für den 200€-Markt zu haben.
Ich tippe darauf, dass Valencia dann wohl wirklich dieses Jahr noch kommt (evtl November?) und Zambezi dann im Januar.
Das Lisbon-Die ist wohl eher als "Ersatzdesign" zu sehen, also etwas, das die bisherige Planung ersetzt, um die Zeit möglichst kostengünstig und mit guten Verkäufen zu überbrücken. Die Planungen für die Jahre 2009 und 2010 sind ja seitens AMDs komplett über den Haufen geworfen worden. Barcelona ist die letzte CPU, wie wirklich im Plan lag und dann aufgrund von Designfehlern 1/2 Jahr zu spät kam. Zudem war der 65nm-Prozess offenbar völlig ungeeignet für solche Designs - da kamen 2 Dinge zusammen, die besonders ungünstig waren. Normalerweise hätte es noch eine 65nm Rev.C vom K10 geben müssen (November 2007), außerdem hätte es noch einen nativen 65nm 2-Kerner geben müssen (Januar 2008 ) - das machte aber aufgrund sowieso ungeeigneten Fertigungsprozesses und der massiven Verspätung der Rev.B keinen Sinn mehr. Stattdessen setzte man bei 45nm alles auf eine Karte und verschob die Rev.C einfach auf 45nm - alle nachfolgenden Planungen wurden dadurch sinnlos. SockelF wurde um ein Jahr verlängert, BD auf 32nm verschoben und G3MX komplett gecancelt. Hydra - die eigentliche 45nm-Generation - wurde von 8 auf 6-Kerne und ohne G3MX-Support gekürzt. Gleichzeitig wurde Maranello aus der Taufe gehoben und eine 2. 45nm-Generation geplant, um die neue Plattform auch nutzen zu können. Diese Plattform (Maranello) ist dann auch für den dann in 32nm verfügbaren, geänderten BD gedacht, muss aber eben kurzfristig noch mit K10 betrieben werden, solange BD noch in Entwicklung ist. Da dachte man sich offenbar bei AMD, warum nicht die Rev.E auch in den Desktop-Markt bringen, um da auch besser dazustehen?
Für Desktop kommt jetzt Thuban über ein Jahr nach Deneb, wenn es aber kein natives 4-Kern-Design geben sollte, würd ich an AMDs Stelle den so schnell wie möglich durch BD ersetzen. Thuban sehe ich mehr so als Zwschenlösung, um was für den 200€-Markt zu haben.
Ich tippe darauf, dass Valencia dann wohl wirklich dieses Jahr noch kommt (evtl November?) und Zambezi dann im Januar.
Das Lisbon-Die ist wohl eher als "Ersatzdesign" zu sehen, also etwas, das die bisherige Planung ersetzt, um die Zeit möglichst kostengünstig und mit guten Verkäufen zu überbrücken. Die Planungen für die Jahre 2009 und 2010 sind ja seitens AMDs komplett über den Haufen geworfen worden. Barcelona ist die letzte CPU, wie wirklich im Plan lag und dann aufgrund von Designfehlern 1/2 Jahr zu spät kam. Zudem war der 65nm-Prozess offenbar völlig ungeeignet für solche Designs - da kamen 2 Dinge zusammen, die besonders ungünstig waren. Normalerweise hätte es noch eine 65nm Rev.C vom K10 geben müssen (November 2007), außerdem hätte es noch einen nativen 65nm 2-Kerner geben müssen (Januar 2008 ) - das machte aber aufgrund sowieso ungeeigneten Fertigungsprozesses und der massiven Verspätung der Rev.B keinen Sinn mehr. Stattdessen setzte man bei 45nm alles auf eine Karte und verschob die Rev.C einfach auf 45nm - alle nachfolgenden Planungen wurden dadurch sinnlos. SockelF wurde um ein Jahr verlängert, BD auf 32nm verschoben und G3MX komplett gecancelt. Hydra - die eigentliche 45nm-Generation - wurde von 8 auf 6-Kerne und ohne G3MX-Support gekürzt. Gleichzeitig wurde Maranello aus der Taufe gehoben und eine 2. 45nm-Generation geplant, um die neue Plattform auch nutzen zu können. Diese Plattform (Maranello) ist dann auch für den dann in 32nm verfügbaren, geänderten BD gedacht, muss aber eben kurzfristig noch mit K10 betrieben werden, solange BD noch in Entwicklung ist. Da dachte man sich offenbar bei AMD, warum nicht die Rev.E auch in den Desktop-Markt bringen, um da auch besser dazustehen?
Zuletzt bearbeitet:
mocad_tom
Admiral Special
- Mitglied seit
- 17.06.2004
- Beiträge
- 1.234
- Renomée
- 52
Ganz ehrlich,
mMn gab es in 45nm schon eine fertige Version wo zumindest die beiden Int-Cores komplett durchvalidiert werden konnten. Die FPU wurde für die 32nm-Version nochmal geändert, die Int-Einheiten stehen seit längerem und konnten durch mehrere Revisionen hindurch auf bessere Taktbarkeit optimiert werden.
Die Sockel-Validierung passiert komplett mit Magny-Cours.
Das gesamte Cache-Subsystem/Memory-Controller wird von Shanghai/Istanbul mitgenommen und weiter und weiter verbessert.
Mich würde jedenfalls nicht wundern, wenn wir den ersten Valencia-Die-Shot vorgelegt bekommen und die Uncore-Bereiche decken sich stark mit Shanghai.
Nochmals -> es gab eine 45nm Bulldozer-Version mit relativ weit fortgeschrittenen Int-Einheiten. Dieser Bulldozer wurde evtl. sogar den Investoren in Abu Dhabi bei den Vertragsverhandlungen vorgelegt.
Grüße,
Tom
mMn gab es in 45nm schon eine fertige Version wo zumindest die beiden Int-Cores komplett durchvalidiert werden konnten. Die FPU wurde für die 32nm-Version nochmal geändert, die Int-Einheiten stehen seit längerem und konnten durch mehrere Revisionen hindurch auf bessere Taktbarkeit optimiert werden.
Die Sockel-Validierung passiert komplett mit Magny-Cours.
Das gesamte Cache-Subsystem/Memory-Controller wird von Shanghai/Istanbul mitgenommen und weiter und weiter verbessert.
Mich würde jedenfalls nicht wundern, wenn wir den ersten Valencia-Die-Shot vorgelegt bekommen und die Uncore-Bereiche decken sich stark mit Shanghai.
Nochmals -> es gab eine 45nm Bulldozer-Version mit relativ weit fortgeschrittenen Int-Einheiten. Dieser Bulldozer wurde evtl. sogar den Investoren in Abu Dhabi bei den Vertragsverhandlungen vorgelegt.
Grüße,
Tom
Jo, dann frage ich aber, was die die ganzen Jahre gemacht haben? Genau, ein solches Design entwickelt, dass dann in den BD mündet. Bei den anderne Dice waren eben aufgrund der nicht vorhanden einschneidenden Befehlssatzänderungen solcher Entwicklungsaufwand nicht nötig. Dass jetzt nochmal ein 45nm-K10 dazwischengeschoben wird, ändert doch nix an der BD-Entwicklung. Ich bin auch davon überzeugt, dass es ein 32nm-BD-Tapeout schon letztes Jahr gab.
Ich sage ja nciht es wäre unmöglich...
Aber irgnedwie fällt mir schwer zu glauben dass die in gut einem jahr "mal eben" die FPU auf AVX aufgebohrt kriegen mit FMA und aller gloria und das debugged und validiert bekommen und uns das ding einfach so vor die Füße werfen... Transistoren wollen ja auch erstmal auf 32nm hindesignt werden (da hilft die 45nm-Architektur nix) und womöglich gibts noch wegen HKMG irgendwelche Eigenheitn zu beachten...
Selbst wenn die INT-Cores schon eine weile fertig sind, gitbs genug zu tun! AVX wurde doch letztes Jahr erst von Intel freigegeben. (Und damals war noch nicht mal das neue Patentaustauschabkommen unter Dach und Fach)
Natürlich haben die die letzten Jahre daran herumentwickelt, aber wieso steht es für 2011 auf der Roadmap wenn man mal eben so locker 2010 einhalten kann? trotz vorgezogenem Istanbul etc.
Haben die grade ne geniale Phase oder arbeiten da Kobolde im Keller!?
Aber irgnedwie fällt mir schwer zu glauben dass die in gut einem jahr "mal eben" die FPU auf AVX aufgebohrt kriegen mit FMA und aller gloria und das debugged und validiert bekommen und uns das ding einfach so vor die Füße werfen... Transistoren wollen ja auch erstmal auf 32nm hindesignt werden (da hilft die 45nm-Architektur nix) und womöglich gibts noch wegen HKMG irgendwelche Eigenheitn zu beachten...
Selbst wenn die INT-Cores schon eine weile fertig sind, gitbs genug zu tun! AVX wurde doch letztes Jahr erst von Intel freigegeben. (Und damals war noch nicht mal das neue Patentaustauschabkommen unter Dach und Fach)
Natürlich haben die die letzten Jahre daran herumentwickelt, aber wieso steht es für 2011 auf der Roadmap wenn man mal eben so locker 2010 einhalten kann? trotz vorgezogenem Istanbul etc.
Haben die grade ne geniale Phase oder arbeiten da Kobolde im Keller!?
rkinet
Grand Admiral Special
Die Erfahrung der Vergangenheit (wie Quad-Core) zeigen dass AMD ein fertiges Bulldozer-Design längst publiziert hätte.
Nächstes wichtige Datum aber die off. Vorstellung von Magny Cours und Socket G34. Hier ist zu erwarten dass AMD entweder Kompatibilität zum Bulldozer mit verkündet oder Bulldozer ist eben noch nicht soweit.
Wobei http://www.computerbase.de/news/har.../november/amd-server-roadmap_viele_cpu-kerne/ nahe legt dass Bulldozer noch 2010 Thema wird ... als Sample oder fertiges Produkt ?
Ich tippe mal März 2010 45nm für letzte K10.5 Produkte und Frühjahr 2011 für erste kompatible Bulldozer als native 6-fach Core DIEs. Welche dann vielleicht Herbst noch um native 8-fach Core ergänzt werden. Mehr wie 6-fach Core bekommt AMD im Desktop nicht unter was eigenes DIE nahe legt.
Ende April sollen die Desktop-K10 (Thuban, Zosma) kommen, im März die Server-K10 (Lisbon/Magny-Cours).
Was macht es denn bitte so unmöglich, dass ein 32nm-BD zum Ende des Jahres hinkommt? Die arbeiten ganz sicher schon seit Ende 2009 mit 32nm-BD(Rev.A)-Dice! Ein Jahr reicht zur Fertigstellung des Designs mit Sicherheit aus, wenns keine größeren Probleme gibt und da scheint sich bisher nix ergeben zu haben (*holzklopf*
). Man braucht ja keine neuen Plattformen und nix, der aufwändige Uncore-Kram ist ja schon beim K10 angefallen und sollte recht unproblematisch sein (siehe Llano) - zumal Valencia nicht mehr als 4 Kerne haben wird, es geht ja hier "nur" um die Kerne als solche. Sicherlich ist das auch aufwändig, aber dafür sollte ein Jahr ganz sicher reichen. Es ist eben mehr ein Risiko, als zusätzlicher Aufwand. Wenn man gleichzeitig Design und Fertigungsprozess wechselt, kann das entweder ne Menge Kosten und Arbeit sparen oder eben mächtig in die Hose gehen. Bisher zeichnet sich eher ersteres ab.
Ich glaube übrigens nicht, dass man schon mit 45nm BDs rumgespielt hat. Da bezweifel ich sogar, dass es ein entsprechendes Tapeout gab. die Pläne sind zu frühzeitig eingestampft worden. Ein Tapeout des 45nm BD wäre frühestens Frühsommer 2008 möglich gewesen, ich glaube nicht, dass zu dem Zeitpunkt noch Planungen für den BD in 45nm exisitiert haben. Die wird man schon Ende 2007 oder gar noch früher endgültig begraben haben. Seit dem wird man aber am 32nm BD arbeiten - 1 1/2 bis 2 Jahre Vorabeit bis zum Tapeout sind sehr plausibel, das Tapeout erfolgte dann sobald der 32nm-Prozess es zulies, also Ende 2009. Wenn die Rev.A schon läuft und man mit dem testen gut voran kommt ist doch alles klar, dann erscheint der BD schon in der Rev.B.
Was macht es denn bitte so unmöglich, dass ein 32nm-BD zum Ende des Jahres hinkommt? Die arbeiten ganz sicher schon seit Ende 2009 mit 32nm-BD(Rev.A)-Dice! Ein Jahr reicht zur Fertigstellung des Designs mit Sicherheit aus, wenns keine größeren Probleme gibt und da scheint sich bisher nix ergeben zu haben (*holzklopf*
). Man braucht ja keine neuen Plattformen und nix, der aufwändige Uncore-Kram ist ja schon beim K10 angefallen und sollte recht unproblematisch sein (siehe Llano) - zumal Valencia nicht mehr als 4 Kerne haben wird, es geht ja hier "nur" um die Kerne als solche. Sicherlich ist das auch aufwändig, aber dafür sollte ein Jahr ganz sicher reichen. Es ist eben mehr ein Risiko, als zusätzlicher Aufwand. Wenn man gleichzeitig Design und Fertigungsprozess wechselt, kann das entweder ne Menge Kosten und Arbeit sparen oder eben mächtig in die Hose gehen. Bisher zeichnet sich eher ersteres ab.Ich glaube übrigens nicht, dass man schon mit 45nm BDs rumgespielt hat. Da bezweifel ich sogar, dass es ein entsprechendes Tapeout gab. die Pläne sind zu frühzeitig eingestampft worden. Ein Tapeout des 45nm BD wäre frühestens Frühsommer 2008 möglich gewesen, ich glaube nicht, dass zu dem Zeitpunkt noch Planungen für den BD in 45nm exisitiert haben. Die wird man schon Ende 2007 oder gar noch früher endgültig begraben haben. Seit dem wird man aber am 32nm BD arbeiten - 1 1/2 bis 2 Jahre Vorabeit bis zum Tapeout sind sehr plausibel, das Tapeout erfolgte dann sobald der 32nm-Prozess es zulies, also Ende 2009. Wenn die Rev.A schon läuft und man mit dem testen gut voran kommt ist doch alles klar, dann erscheint der BD schon in der Rev.B.
Zuletzt bearbeitet:
Na dein Wort in Gottes Gehörgängen...
Ich will mir garnicht ausmalen wie viel bei einem komplexen Design wie BD schiefgehen kann, TLB-Bug hatten wir ja schon, nun haben wir 1 Decoder der 2 INT-Cores und eie dicke FPU füttern muss, der Eine Reihe neuer Befehlssätze beherrschen muss, plus "Known Good code" o.ä. wenn das wirklich alles an Bord ist.
Das Routing wann welche Instruktion wohin geht, Sprungvorhersage mit dem/den Trace-cache(s), auch noch virtualisiert, verschiedene Szenarien mit der shared FPU, welche Load und Store-Einheiten der Int-Kerne "ausborgen" muss... das Ganze Drama gewürzt mit unseren Spekulationen über Hochtakt-Design oder gar verschiedene Taktdomänen die Synchronisiert werden müssen...
Und das sich am Uncore garnichts geändert hat wage ich auch zu bezweifeln... neue Speicherstandards (welche auch Validiert werden müssen) und ggf. schnellerer Cache...?
Die Crossbar ist womöglich schon auf die GPU-Integration alla Llano vorbeiretet etc...
Wenn ich mir das so ansehe ist Übereifer da wirklich fehl am Platze... wir wollen doch keinen zweiten Barcelona...
Ich will mir garnicht ausmalen wie viel bei einem komplexen Design wie BD schiefgehen kann, TLB-Bug hatten wir ja schon, nun haben wir 1 Decoder der 2 INT-Cores und eie dicke FPU füttern muss, der Eine Reihe neuer Befehlssätze beherrschen muss, plus "Known Good code" o.ä. wenn das wirklich alles an Bord ist.
Das Routing wann welche Instruktion wohin geht, Sprungvorhersage mit dem/den Trace-cache(s), auch noch virtualisiert, verschiedene Szenarien mit der shared FPU, welche Load und Store-Einheiten der Int-Kerne "ausborgen" muss... das Ganze Drama gewürzt mit unseren Spekulationen über Hochtakt-Design oder gar verschiedene Taktdomänen die Synchronisiert werden müssen...
Und das sich am Uncore garnichts geändert hat wage ich auch zu bezweifeln... neue Speicherstandards (welche auch Validiert werden müssen) und ggf. schnellerer Cache...?
Die Crossbar ist womöglich schon auf die GPU-Integration alla Llano vorbeiretet etc...
Wenn ich mir das so ansehe ist Übereifer da wirklich fehl am Platze... wir wollen doch keinen zweiten Barcelona...
@Ge0rgy
denkst du AMD ist dumm und macht wieder ein 2. Barcelona oder wie Intel P4, die wissen ganz genau das BD schnell und für die Zukunft das richtige ist
AMD möchte mit BD vertrauen gewinnen, der Serveranteil von AMD liegt bei 10% und Interlagos wird das ändern müssen, hoffen wir das AMD im Serverbereich bis 2013 auf 30% Anteil kommt.
Edit: wenn Bulldozer für Server ende 2010 kommt, muss ein TapeOut bereits erfolgt sein
Bei Intel hat Sandy Bridge schon ein Tape Out lange hinter sich.
denkst du AMD ist dumm und macht wieder ein 2. Barcelona oder wie Intel P4, die wissen ganz genau das BD schnell und für die Zukunft das richtige ist
AMD möchte mit BD vertrauen gewinnen, der Serveranteil von AMD liegt bei 10% und Interlagos wird das ändern müssen, hoffen wir das AMD im Serverbereich bis 2013 auf 30% Anteil kommt.
Edit: wenn Bulldozer für Server ende 2010 kommt, muss ein TapeOut bereits erfolgt sein
Bei Intel hat Sandy Bridge schon ein Tape Out lange hinter sich.
Zuletzt bearbeitet:
rkinet
Grand Admiral Special
Genau !
AMD benötigt zunächst seine Schaltung in echtem SOI-32nm Silicium.
Nachdem AMD den Shanghai beim Tape Out und ersten Ergebnissen publizierte ist does für das erste und funktionsfähige Bulldozer-Silicium so auch zu erwarten.
Wobei dies dies spätestens per G34 Launch kommen sollte auch mit Blick auf frühere frühzeitige Ankündigungen zu Kompatibilitäten.
Nachdem schon die 8/12-fach Cores nur mäßig takten sind aber rel. langsame Bulldozer als Opteron im Frühjahr 2011 kein Marktproblem.
Eher der Desktop der ja viel höher Taktende erwartet. Daher hier eher Herbst 2011 für erste So. AM3 Bulldozer. 8)
Natürlich wissen sie das.... und genau deswegen halte ich einen "verfrühten" BD-Start für äußerst unwahrscheinlich.
Im Vergleich zum stark K8 verwandten K10, ist der Architekturwechsel zu BD vergleichsweise groß.
Wenn also schon damals so viel danebengehen konnte und auch schiefgegangen ist, werden sie dieses mal ihre Hausaufgaben besonders gründlich machen und lieber alles 2 mal checken.
Ich an deren Stelle würde sogar die ALUs das einmaleins bis zur 64Bit-INT-Grenze durchrechnen lassen und dann wieder zurück dividieren nur um sicher zu gehen dass man keinen Pentium-Bug herumschleppt.
Wobei so ein Fehler noch vergleichsweise einfach zu finden ist, richtig lustig wirds mit dem Zusammenspiel von verschiedenem, virtualisiertem und nicht-Virtualisiertem Code, der Speicherverwaltung, etc (siehe TLB-BUG)
Da Können schwer zu reproduzierende Fehler entstehen die sich nur in bestimmten Konstellationen ergeben usw.
Die Errata-Liste der akt. K10 ist schon lang genug... BD muss da nicht unbedingt weitere Rekorde aufstellen...
Stellt euch das ganze mal nicht zu trivial vor... Wenn ich alleine bedenke wie viele verschiedene Opcodes ein aktueller Prozessor kennt, und der hat noch kein AVX, zu jedem Opcode gibt es viele Kombinationsmöglichkeiten mit anderen Codes, jede Menge Flags die korrekt gesetzt werden müssen, Exceptions wie division durch null usw.
Es reicht bei weitem nicht mal eben Windows auf nem BD-Sample zu booten und wenn es ne stunde Word und IE überstanden hat ist der Prozessor Produktionsreif...
Schön wärs...
Im Vergleich zum stark K8 verwandten K10, ist der Architekturwechsel zu BD vergleichsweise groß.
Wenn also schon damals so viel danebengehen konnte und auch schiefgegangen ist, werden sie dieses mal ihre Hausaufgaben besonders gründlich machen und lieber alles 2 mal checken.
Ich an deren Stelle würde sogar die ALUs das einmaleins bis zur 64Bit-INT-Grenze durchrechnen lassen und dann wieder zurück dividieren nur um sicher zu gehen dass man keinen Pentium-Bug herumschleppt.
Wobei so ein Fehler noch vergleichsweise einfach zu finden ist, richtig lustig wirds mit dem Zusammenspiel von verschiedenem, virtualisiertem und nicht-Virtualisiertem Code, der Speicherverwaltung, etc (siehe TLB-BUG)
Da Können schwer zu reproduzierende Fehler entstehen die sich nur in bestimmten Konstellationen ergeben usw.
Die Errata-Liste der akt. K10 ist schon lang genug... BD muss da nicht unbedingt weitere Rekorde aufstellen...
Stellt euch das ganze mal nicht zu trivial vor... Wenn ich alleine bedenke wie viele verschiedene Opcodes ein aktueller Prozessor kennt, und der hat noch kein AVX, zu jedem Opcode gibt es viele Kombinationsmöglichkeiten mit anderen Codes, jede Menge Flags die korrekt gesetzt werden müssen, Exceptions wie division durch null usw.
Es reicht bei weitem nicht mal eben Windows auf nem BD-Sample zu booten und wenn es ne stunde Word und IE überstanden hat ist der Prozessor Produktionsreif...
Schön wärs...
mocad_tom
Admiral Special
- Mitglied seit
- 17.06.2004
- Beiträge
- 1.234
- Renomée
- 52
Ganz ehrlich (mal wieder)
Bulldozer war ein Design Team, dass nie, auch nur im geringsten von Kürzungen betroffen war, sie waren die einzigen, die nie durch Arbeitsplatzabbau wirklich bedroht wurden. Und die BD-Konzeption existiert schon lange. Als Sam Naffziger zu AMD kam wurden ihm die bisher gesammelten Konzepte vorgelegt und er brachte seine mit ein. Von dem Tag weg wurde mit Hochdruck an BD gearbeitet.
Könnt ihr euch noch an diese komischen Reverse-Hyperthreading-Gerüchte erinnern - ich glaube da hat ein Praktikant innerhalb der Firma nur irgendwelche Informationshappen in den falschen Kontext gesetzt. Bis heut wird ja noch nachgefragt, ob ein Int-Core Ressourcen des anderen Int-Cores nutzen kann (was einem Reverse-Hyperthreading schon sehr nahe kommt).
http://www.realworldtech.com/page.cfm?NewsID=359&date=03-28-2006#359
K9 wurde gerade zu Grabe getragen (3. November 2005):
http://www.theinquirer.net/inquirer/news/1004537/amd-k10-delayed-dead
Reverse Hyperthreading ( 10. Juli 2006):
http://www.theinquirer.net/inquirer/news/1009078/reverse-hyperthreading-exist
Grüße,
Elefantenhirn-Tom
Bulldozer war ein Design Team, dass nie, auch nur im geringsten von Kürzungen betroffen war, sie waren die einzigen, die nie durch Arbeitsplatzabbau wirklich bedroht wurden. Und die BD-Konzeption existiert schon lange. Als Sam Naffziger zu AMD kam wurden ihm die bisher gesammelten Konzepte vorgelegt und er brachte seine mit ein. Von dem Tag weg wurde mit Hochdruck an BD gearbeitet.
Könnt ihr euch noch an diese komischen Reverse-Hyperthreading-Gerüchte erinnern - ich glaube da hat ein Praktikant innerhalb der Firma nur irgendwelche Informationshappen in den falschen Kontext gesetzt. Bis heut wird ja noch nachgefragt, ob ein Int-Core Ressourcen des anderen Int-Cores nutzen kann (was einem Reverse-Hyperthreading schon sehr nahe kommt).
http://www.realworldtech.com/page.cfm?NewsID=359&date=03-28-2006#359
Wir sprechen hier vom 28. März 2006.
K9 wurde gerade zu Grabe getragen (3. November 2005):
http://www.theinquirer.net/inquirer/news/1004537/amd-k10-delayed-dead
Reverse Hyperthreading ( 10. Juli 2006):
http://www.theinquirer.net/inquirer/news/1009078/reverse-hyperthreading-exist
Grüße,
Elefantenhirn-Tom
BavarianRealist
Grand Admiral Special
- Mitglied seit
- 06.02.2010
- Beiträge
- 3.358
- Renomée
- 80
@Performance von BD:
Der 32nm-SOI-HKMG-Prozess soll rund 40% mehr Performance als der 45nm-SOI-Prozess bei gleicher Energieaufnahme liefern. Da aufgrund des kleineren Dies etwas weniger Energie emittiert werden kann, bleiben vielleicht +30%. Dazu kommen noch ein paar kleine Tweaks am K10.5-Core für 32nm. Schon alleine dadurch dürfte AMD schon mit dem alten K10.5-Core in 32nm ordenltich zu Intel aufholen, wenn deren Sandy-Bridge nur +20% gegenüber derer heutiger CPU liefern soll. Zudem dürfte auch schon das "überholte" jetzt mit Magny-Cours kommende 45nm-K10.5-Core mit Turbo-Modus noch etwas mehr können, als die bisherigen K10.5. Auf diese Weise läßt sich wohl grob extrapolieren, wo BD landen sollte (nicht muss!).
Und last but not least sollte BD wohl gleichzeitig ein ordentliches Stück mehr können, als das geplante 32nm-K10.5-Core. Von daher sollte alles ein ganzes Stückchen besser aussehen.
Der 32nm-SOI-HKMG-Prozess soll rund 40% mehr Performance als der 45nm-SOI-Prozess bei gleicher Energieaufnahme liefern. Da aufgrund des kleineren Dies etwas weniger Energie emittiert werden kann, bleiben vielleicht +30%. Dazu kommen noch ein paar kleine Tweaks am K10.5-Core für 32nm. Schon alleine dadurch dürfte AMD schon mit dem alten K10.5-Core in 32nm ordenltich zu Intel aufholen, wenn deren Sandy-Bridge nur +20% gegenüber derer heutiger CPU liefern soll. Zudem dürfte auch schon das "überholte" jetzt mit Magny-Cours kommende 45nm-K10.5-Core mit Turbo-Modus noch etwas mehr können, als die bisherigen K10.5. Auf diese Weise läßt sich wohl grob extrapolieren, wo BD landen sollte (nicht muss!).
Und last but not least sollte BD wohl gleichzeitig ein ordentliches Stück mehr können, als das geplante 32nm-K10.5-Core. Von daher sollte alles ein ganzes Stückchen besser aussehen.
Markus Everson
Grand Admiral Special
hot schrieb:
Für welches Design war der 65nm Prozess ungeeignet?
gruffi
Grand Admiral Special
Ja, die Aussagen sind ja schon etwas älter. Diese hatte er später revidiert. Ich habe das so aufgefasst, als hätte er sich da vertan. Allerdings bezog ich mich eigentlich darauf, mit welcher Granularität AMD Termine publiziert.
Ich denke nicht, dass Magny-Cours als solches so viel Entwicklungskosten verschlungen hat. Lisbon, welcher als Grundlage für Magny-Cours dient, ist ja mehr oder weniger ein getweakter Istanbul. Der eigentliche Aufwand bei der Plattform ist MCM und der neue Unterbau (G34). Und dies wird auch für Bulldozer weiter genutzt.
Der bisherige Zeitplan sieht jedenfalls wie folgt aus:
Q3 2008: Shanghai
Q2 2009: Istanbul
Q1 2010: Magny-Cours
Q4 2010: ?
Wie hot schon sagte, Ende 2010 für etwas Neues würde also durchaus ins bisherige Schema passen. Mit Desktop Modellen sollte man aber wirklich frühestens 2011 rechnen.
Richtig. Das hatte ich ja auch schon angerissen. Man sollte trotzdem bedenken, Bulldozer läuft bereits ~5 Jahre parallel zu allen anderen Entwicklungen. Also genügend Zeit zum Testen und Validieren hatte man bereits. Ich denke auch nicht, dass hier Budgetkürzungen vorgenommen wurden. Und auch wenn AVX recht umfangreich ist, auch hier hat AMD mit SSE5 schon viel Vorarbeit hinter sich. Klar ist Bulldozer nicht trivial. Trotzdem muss nach so langer Zeit auch irgendwann mal etwas fertig sein. Ansonsten frage ich mich, was man die ganzen Jahre getan hat.
Dann hast du anscheinend noch nie Errata Listen von Intel Prozessoren gesehen.
Für ein Quad Design wie Barcelona.
Markus Everson
Grand Admiral Special
gruffi schrieb:
Inwiefern war er dafür weniger geeignet als für ein DualDesign?
In meinen Augen hat AMD den Prozess einfach viel zu lange nicht ausreichend in den Griff bekommen. Punkt, Ende der Geschichte. Auch die 65nm DC waren keine Energiesparwunder.
gruffi
Grand Admiral Special
Der Prozess war auf gute Yields und den K8 Dual-Core getrimmt. So wurde zB die Cache Latenz gelockert. Auch hohe Taktraten waren damit nicht drin. Ein High-Performance Prozess, wie er für Barcelona und hoch taktende Dual-Cores notwendig gewesen wäre, war es jedenfalls nicht. Und die Mittel, wie sie GloFo hat, und die Auswahl, die sie damit bieten können, hatte AMD seinerzeit auch nicht.
Dresdenboy
Redaktion
☆☆☆☆☆☆
@Ge0rgy:
Die meisten AVX-Befehle wären schon auf für SSE5 entwickelten FPUs umsetzbar gewesen. AVX erweitert bisherige SSEn-Befehle auf 256 Bit, bringt 3-Operanden-Adressierung, FMA, breitere Register, zeroing idioms und ein paar Befehle, die sich auf die volle Breite auswirken. Nun sollte bedacht werden, dass die FPU keine SSEn-Befehle verarbeitet, sondern einen dafür optimierten Koprozessor darstellt.
Dieser FP-Koprozessor konnte schon immer die 3-Operanden-Adressierung. (1. Problem gelöst)
Die logischen Register wurden auch bisher auf die internen abgebildet, wie schon bei K7 u. K8 die SSE-Register auf die 120 90-bit-breiten Register verteilt wurden. Man braucht also nicht einmal 256 bit breite Register. (2. Problem gelöst)
Die Verbreiterung der alten SSE-Befehle kann meist mit separater Bearbeitung durch 128 Bit breite FP-Einheiten erfolgen (es sind ja Vektordaten, die meist unabhängig voneinander parallel verarbeitet werden können) und erfordert nur bei einer kleineren Menge Befehlen Anpassungen (z.B. Datenpfade zwischen den Hälften), um diese dann durch Microcode oder mit etwas angepassten Einheiten auch ohne Microcode ausführen zu können. (3. Problem gelöst)
FMA war auch für SSE5 vorgesehen, sogar mit mehr Möglichkeiten. Kann man also auch wiederverwenden. (4. Problem gelöst)
War noch 'was die FPU betreffend? Ja, Zeroing Idioms. Da die logischen Register sowieso gemappt werden, könnte das hier über ein Mapping auf ein Konstant-0-Register für die Registerhälfte erfolgen. (5. Problem gelöst)
Die größeren Anpassungen betreffen also nur den Decoder. Da BD keine 256-bit-Einheiten hat, hätten sowieso für die volle Breite immer 2 µOps und getrennte Registerhälften benutzt werden müssen. Es tut also nicht mal weh.
So, das war mal ein kleiner Abriss dazu. Es sind alles nur Lösungsideen, zeigen aber, was möglich ist.
Natürlich muss für die Transistoren das Design low level angepasst werden. Aber das geschieht großteils über "Macroblöcke". Diese werden teils automatisch, teils von Hand zusammengestellt und verknüpft. Das Layout eines solchen Blocks (z.B. Adder oder Flip-Flop) kann schon festgelegt sein, während die Transistoren u. das Rezept für die Produktion noch leicht angepasst werden können. Siehe auch Eric Quinnell's Dissertation zur Bridged FMA-Einheit.
Es gab übrigens auch mal 180 nm-K8-Muster. Zu kaufen bekam die keiner. Aber Wafer damit konnte ich genug bei AMD sehen. Aber das hat vielleicht mit der Verzögerung zu tun, so dass die Hammer-Architektur - lang genug vorher in Entwicklung - erst einmal mit 180 nm entwickelt werden musste.
Und wegen Design-Zeiten:
Es sagt ja keiner, dass an Istanbul und Shanghai genausoviel Leute arbeiten, wie an BD. Es sind ja auch verschiedene Teams, die wie beim Pipelining im Prozessor dann für versch. Phasen des Designs zuständig sind. Wenn für die Entwicklung des Istanbul weniger Leute eingesetzt wurden, als für Shanghai, dann ist die Frage, warum bei weniger Änderungen das Design nicht gleich nach Shanghai kam, zwecklos. Da lässt sich nichts von außen ableiten. Haben z.B. 50 Leute am Istanbul entwickelt (z.B. Probe Filter finalisiert) und 100 Leute validiert (die gleichen, die Shanghai validiert haben) - innerhalb von < 1 Jahr - kann ich nicht ableiten, dass 400 Leute in der Entwicklung und 250 Leute in der Validierung 3 Jahre benötigen müssten. Dafür wurde ja das Mannjahr erfunden. Nur wir haben keine Daten.
@rkinet:
BTW, die Kompatibilität von BD und G34 ist schon bekanntgegeben. Das wird immer über die umfassenden Kästchen in den Präsentationen dargestellt, innerhalb derer sich die CPU-Generationen abwechseln.
@hot:
Gute Überlegungen!
Die meisten AVX-Befehle wären schon auf für SSE5 entwickelten FPUs umsetzbar gewesen. AVX erweitert bisherige SSEn-Befehle auf 256 Bit, bringt 3-Operanden-Adressierung, FMA, breitere Register, zeroing idioms und ein paar Befehle, die sich auf die volle Breite auswirken. Nun sollte bedacht werden, dass die FPU keine SSEn-Befehle verarbeitet, sondern einen dafür optimierten Koprozessor darstellt.
Dieser FP-Koprozessor konnte schon immer die 3-Operanden-Adressierung. (1. Problem gelöst)
Die logischen Register wurden auch bisher auf die internen abgebildet, wie schon bei K7 u. K8 die SSE-Register auf die 120 90-bit-breiten Register verteilt wurden. Man braucht also nicht einmal 256 bit breite Register. (2. Problem gelöst)
Die Verbreiterung der alten SSE-Befehle kann meist mit separater Bearbeitung durch 128 Bit breite FP-Einheiten erfolgen (es sind ja Vektordaten, die meist unabhängig voneinander parallel verarbeitet werden können) und erfordert nur bei einer kleineren Menge Befehlen Anpassungen (z.B. Datenpfade zwischen den Hälften), um diese dann durch Microcode oder mit etwas angepassten Einheiten auch ohne Microcode ausführen zu können. (3. Problem gelöst)
FMA war auch für SSE5 vorgesehen, sogar mit mehr Möglichkeiten. Kann man also auch wiederverwenden. (4. Problem gelöst)
War noch 'was die FPU betreffend? Ja, Zeroing Idioms. Da die logischen Register sowieso gemappt werden, könnte das hier über ein Mapping auf ein Konstant-0-Register für die Registerhälfte erfolgen. (5. Problem gelöst)
Die größeren Anpassungen betreffen also nur den Decoder. Da BD keine 256-bit-Einheiten hat, hätten sowieso für die volle Breite immer 2 µOps und getrennte Registerhälften benutzt werden müssen. Es tut also nicht mal weh.
So, das war mal ein kleiner Abriss dazu. Es sind alles nur Lösungsideen, zeigen aber, was möglich ist.
Natürlich muss für die Transistoren das Design low level angepasst werden. Aber das geschieht großteils über "Macroblöcke". Diese werden teils automatisch, teils von Hand zusammengestellt und verknüpft. Das Layout eines solchen Blocks (z.B. Adder oder Flip-Flop) kann schon festgelegt sein, während die Transistoren u. das Rezept für die Produktion noch leicht angepasst werden können. Siehe auch Eric Quinnell's Dissertation zur Bridged FMA-Einheit.
Es gab übrigens auch mal 180 nm-K8-Muster. Zu kaufen bekam die keiner. Aber Wafer damit konnte ich genug bei AMD sehen. Aber das hat vielleicht mit der Verzögerung zu tun, so dass die Hammer-Architektur - lang genug vorher in Entwicklung - erst einmal mit 180 nm entwickelt werden musste.
Und wegen Design-Zeiten:
Es sagt ja keiner, dass an Istanbul und Shanghai genausoviel Leute arbeiten, wie an BD. Es sind ja auch verschiedene Teams, die wie beim Pipelining im Prozessor dann für versch. Phasen des Designs zuständig sind. Wenn für die Entwicklung des Istanbul weniger Leute eingesetzt wurden, als für Shanghai, dann ist die Frage, warum bei weniger Änderungen das Design nicht gleich nach Shanghai kam, zwecklos. Da lässt sich nichts von außen ableiten. Haben z.B. 50 Leute am Istanbul entwickelt (z.B. Probe Filter finalisiert) und 100 Leute validiert (die gleichen, die Shanghai validiert haben) - innerhalb von < 1 Jahr - kann ich nicht ableiten, dass 400 Leute in der Entwicklung und 250 Leute in der Validierung 3 Jahre benötigen müssten. Dafür wurde ja das Mannjahr erfunden. Nur wir haben keine Daten.
@rkinet:
Erfahrungswerte haben m. W. keine Beweiskraft vor deutschen Gerichten. Und warum sollte AMD mit den ersten Samples gleich zu Intel rennen, um denen zu helfen, das SB-Design darauf abzustimmen? Hier geht es nicht um einen evolutionären Designschritt, womit keiner groß überrascht werden könnte und entsprechende Publicity nicht so wettbewerbsbeeinflussend ist.
BTW, die Kompatibilität von BD und G34 ist schon bekanntgegeben. Das wird immer über die umfassenden Kästchen in den Präsentationen dargestellt, innerhalb derer sich die CPU-Generationen abwechseln.
@hot:
Gute Überlegungen!
Markus Everson
Grand Admiral Special
gruffi schrieb:
Werden Cache Latenzen durch den Herstellungsprozess bestimmt? Du vermischst m.E. munter Probleme des Barcelona an sich mit den Problemen des Prozesses. 65nm war mies - das aber für jedes Prozessordesign. Erst mieser Prozess und Bugs im Design zusammen waren katastrophal.
Zuletzt bearbeitet:
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
xbit hat ne Meldung zur low-power C32 Plattform:
http://www.xbitlabs.com/news/cpu/display/20100224035621_AMD_Readies_Low_Power_Server_Platform.html
1,5 GHz 6Kerner ... witzig..
Modellübersicht gabs bei S/A:
ciao
Alex
http://www.xbitlabs.com/news/cpu/display/20100224035621_AMD_Readies_Low_Power_Server_Platform.html
1,5 GHz 6Kerner ... witzig..
Modellübersicht gabs bei S/A:
http://www.semiaccurate.com/2010/02/24/us-magny-cours-pricing-revealed-early
ciao
Alex
Zuletzt bearbeitet:
@Tom und Dresdenboy
Wist ihr wie viele "Bulldozers" unterwegs schon auf der Strecke liegenblieben?
Wissen wir genau, dass das was momentan als Bobccat und BD in entwicklung ist, genau die beiden Designs sind über die 2006 gesprochen wurde?
AMD war doch selbst überrascht vom Erfolg des Conroe und seiner Nachfolger... K9 als "super-Core" wurde auch gekippt... udn der Ursprüngliche K10 - Entwurf, als Barcelona naoch unter K8L lief.
Es wurden so viele Designs unterwegs beerdigt, so viele Leute kamen und gingen in der Zwischenzeit, aus SSE5 wurde AVX, mit welchem Intel mehrmals die Speilregeln änderte usw.
Schon K8/K10 sind in Sacehn OoO-Effizienz ziemlich sub-optimal wie wir wissen, alleine dort bestnad erstmal verbesserungsbedarf bevor man ähnliches für BDs Int-Cores verwenden könnte.
Lass die FPU eine vergleichsweise einfache Geschichte sein, der Rest ist es dennoch nicht!
Theoretisch könnte BD anfangs mal mit eager execution, speculative multithreading etc.geplant gewesen sein, mit unified L1-cache etc. und man hat unterwegs bemerkt dass das zu komplex wird und wir kriegen nun die "Brute Force" - version.
Keiner von uns kann nachvollziehen was AMD-Intern in all den Jahren genau vorging und wie viel im akt. BD noch von der Ursprungsidee übrig ist.
Ich sage nur die Roadmap hat BD nicht aus Spaß auf 2011 datiert...
Wist ihr wie viele "Bulldozers" unterwegs schon auf der Strecke liegenblieben?
Wissen wir genau, dass das was momentan als Bobccat und BD in entwicklung ist, genau die beiden Designs sind über die 2006 gesprochen wurde?
AMD war doch selbst überrascht vom Erfolg des Conroe und seiner Nachfolger... K9 als "super-Core" wurde auch gekippt... udn der Ursprüngliche K10 - Entwurf, als Barcelona naoch unter K8L lief.
Es wurden so viele Designs unterwegs beerdigt, so viele Leute kamen und gingen in der Zwischenzeit, aus SSE5 wurde AVX, mit welchem Intel mehrmals die Speilregeln änderte usw.
Schon K8/K10 sind in Sacehn OoO-Effizienz ziemlich sub-optimal wie wir wissen, alleine dort bestnad erstmal verbesserungsbedarf bevor man ähnliches für BDs Int-Cores verwenden könnte.
Lass die FPU eine vergleichsweise einfache Geschichte sein, der Rest ist es dennoch nicht!
Theoretisch könnte BD anfangs mal mit eager execution, speculative multithreading etc.geplant gewesen sein, mit unified L1-cache etc. und man hat unterwegs bemerkt dass das zu komplex wird und wir kriegen nun die "Brute Force" - version.
Keiner von uns kann nachvollziehen was AMD-Intern in all den Jahren genau vorging und wie viel im akt. BD noch von der Ursprungsidee übrig ist.
Ich sage nur die Roadmap hat BD nicht aus Spaß auf 2011 datiert...
Crashtest
Redaktion
☆☆☆☆☆☆
AMD hat BD auf 2011 datiert damit man die Analysten und Aktionäre bei einer Q4/2010-Aktion erfreuen kann
Immerhin gibts in spätestens 4 Wochen endlich MC (mir ist klar, dass AMD MC seit Januar verteilt ...)
Immerhin gibts in spätestens 4 Wochen endlich MC (mir ist klar, dass AMD MC seit Januar verteilt ...)
Ähnliche Themen
