AMDs "Excavator" - 4. Modul Generation Spekulation

[Duplex]

Wahrscheinlich kommt der nur im APU Markt zum Einsatz, große DIEs wird AMD damit vermutlich nicht mehr planen.
AMD ist gegen die großen Intel CPUs sowieso nicht mehr konkurrenzfähig, Intel fertigt in 22nm 15 Kerne mit 30 Threads
Bis Excavator fertig ist gibt es schon längst Skylake in 14nm, dann wird die Lage für AMD im oberen Segment noch schwieriger.
AMD wird sich nur mit Konsolen Chips & APUs halten können, gegen den Rest haben Sie keine Chance mehr, erst recht nicht in 28nm.

 

[tomturbo]

Du solltest schon gelernt haben dass 22nm oder 28nm nur Worthülsen sind.
Beide Fertigungen können gleich große Strukturen erzeugen.
Von daher muss es nicht sein dass die 22nm Intel Fertigung besser ist als die 28nm GF Fertigung.

Und hör jetzt wieder auf mit dem Dauerbashing in jedem Thread zu AMD, Danke.

 

[Emploi]

Wer einmal den Sport zum Hobby gemacht hat, wird sicher nicht so schnell aufhören damit. Von daher, einfach ein Kanditat für Schindlers Liste.

 

[Opteron]

Da Intel in 2014 mit DDR4 auf der Serverplattform anfangen will und es so verfügbar wird, kann AMD damit auch eine neue (APU-)Serverplattform launchen und da gleich XV als CPU-Kerne einsetzen.

Hmm wann 2014? Anfang 2014 kommt doch die neue Serverplattform mit Berlin aka Kaveri-Server. Da bleibt nicht viel Platz für weitere Spielchen, die Planung ist in dem Fall schon bekannt und fest. Ob dann im 2. Halbjahr schon ein Update für DDR4 kommt, glaub ich eher auch nicht, denn dann hätte man sich den FM2+ auch gleich ganz sparen können.

Also das seh ich aber anders. Wenn Excavator wirklich so ein Wurf ist, muss es jetzt mit dem neuen Prozess Samples geben, damit man den auch 2015 fertig hat. Das wird bei der Komplexität sicher bis Rev.C dauern bis das Massenproduktionstauglich ist. Und man wird zu 99,999% dafür auch den 28SHP verwenden. Das Canceln der großen Komodo und SR-Prozessoren hat eben auch einiges an Entwicklungsfähigkeit für Excavator freigemacht. Man darf nicht vergessen, dass man Exc. erst in einem neuen Fertigungsprozess auflegen wollte (20nm SHP alias 16nm AMD/IBM SOI-Fertigung?). Das Vorziehen von Excavator im "alten" Prozess ist der logische Schritt. Für Excavator wäre es 2014 einfach zu knapp gewesen, dashelb gibts noch mal den Warschau-Kern. Als Überbrückung reicht das noch mal.

Hmmm klingt besser, aber bei der Argumentation zur "Überbrückung" ist die Frage Überbrückung zu was und das könnte dann schon auch der simple 20nm LPM-Prozess von GF sein, Laufen tut der Prozess ja schon, d.h. der geleakten Die-Shot könnte 20nm sein und Warsawa braucht man, da das Ding eben noch debuggt werden muss (aktuell max. A0 Silizium) und GF auch den Prozess rampen muss.
Eventuell gabs die Warsaw-Entscheidung nach dem A0 Silizium. Vermutlich war das total mieß, sodass klar war, dass man mehr Zeit zum Entwicklen braucht, ergo hat mans verschoben und Warsaw aus der Taufe gehoben.

Wäre dann ein ziemlich glaubhaftes Szenario mMn, aber natürlich trotzdem nur Spekulation.

 

[ONE_FOR_ALL]

Und hör jetzt wieder auf mit dem Dauerbashing in jedem Thread zu AMD, Danke.

Wieso den mir fehlen noch die Prozent Angaben bezogen auf Steamroller (Leistung unbekannt)gegen Excavator(Wahrscheinlich ist er für den Wap Antrieb der Enterprise verantwortlich).

 

[ELKINATOR]

der blödsinn das AMD nie wieder mithalten werden kann nervt langsam.

 

[hot]

[...]

Hmmm klingt besser, aber bei der Argumentation zur "Überbrückung" ist die Frage Überbrückung zu was und das könnte dann schon auch der simple 20nm LPM-Prozess von GF sein, Laufen tut der Prozess ja schon, d.h. der geleakten Die-Shot könnte 20nm sein und Warsawa braucht man, da das Ding eben noch debuggt werden muss (aktuell max. A0 Silizium) und GF auch den Prozess rampen muss.
Eventuell gabs die Warsaw-Entscheidung nach dem A0 Silizium. Vermutlich war das total mieß, sodass klar war, dass man mehr Zeit zum Entwicklen braucht, ergo hat mans verschoben und Warsaw aus der Taufe gehoben.

Wäre dann ein ziemlich glaubhaftes Szenario mMn, aber natürlich trotzdem nur Spekulation.

Das Ding kommt nicht in 20nm. Warum sollte man das antun, wenn man einen "ordentlichen" Fertigungsprozess hat? 20SLP ist von der Leistungsfähigkeit doch ein Witz ggü. 28SHP und kostet vermutlich dasselbe in der Produktion (SOI vs. 20nm-Aufschlag). Außerdem hat man den selbst teuer entwickelt, den wird man ausquetschen wie eine Zitrone. Nene, man nutzte 2 Jahre 32SHP und man wird 2 Jahre 28SHP nutzen (Warschau ist hier als "Unfall" zu sehen, weil man keine Lust hatte Orochi zu shrinken). Der nächste Prozessor nach dem Bagger kommt in 14XM oder 14 FDSOI (alias 16nm ETSOI?) frühestens 2016.
Erschwerend hinzu kommt, ist, dass wenn Excavator wirklich so ein heftiger Architektursprung wird man eh besser den alten Fertigungsprozess nutzt. Jetzt einen Sprung zu versuchen wäre Selbstmord, vor allem, bei so einer Gurke wie 20SLP.

Ich hab noch einen . Wenn man die Theorie zugrunde legt, dass 28SHP der ursprüngliche 22nm-Prozess von AMD/IBM ist, wer sagt denn dass 20SLP in Wirklichkeit nicht das Low-End-Pendand dazu ist? Ist 20SLP überhaupt kleiner als 28SHP oder heißt der marketingtechnisch nur einfach so?

 

[OBrian]

Marketingtechnisch umbenannt wurde so weit ich weiß nur der XM14, der flächenmäßig so viel wie der 20-nm-Prozeß benötigt, aber bessere Transistoren verwendet und daher einen deutlichen Sprung ggü. dem normalen 20-nm-Prozeß darstellt.

Warum muß man übrigens den 20-nm-Prozeß jetzt schon als "Gurke" bezeichnen? Außer Behauptungen in Foren von Leuten, die überhaupt keine Ahnung haben KÖNNEN (da keine GF-Mitarbeiter in leitender Position!), ist dazu doch nichts bekannt, und selbst GF wird das noch nicht wissen, ob der Prozeß gut oder nicht so gut wird. Auch sein Vorgänger 28 nm ist noch überhaupt nicht einzuschätzen, weil Kaveri das erste Produkt damit wird. Selbst zu 32 nm kann man sich eigentlich kein ernsthaftes Urteil erlauben, weil man nicht sagen kann, ob es AMD wegen des Prozesses oder wegen der Architektur so "gut" geht. Wahrscheinlich spielt beides eine Rolle.

 

[bbott]

Wirklich vergleichen lassen sich die Fertigungsprozesse schon seit längerem nicht mehr, laut ct (18/13 - Vom Sand zum Chip). Da verschiedene Materialien hinzu gemischt werden, First/Last-Gate und Low-Power vs. High Performance um nur einige zu nennen. In dem Artikel wir vor allem darauf hingewiesen das jeder seine eigenen Transistoren entwirft und das es da schon riesige Unterscheide gibt.

Jetzt kommt noch hinzu das beim z.B. beim XM14 andere bzw. unterschiedliche Bauelemente bzw. -teile die Strukturbreite angeben.

Quelle (Leider nur für Abonnenten)


In der aktuellen ct wird beschreiben wie aus Silizium die Chips gemacht werden.

 

[hot]

"Gurke" im Sinne von Ungeeignet für einen High-Performance-Chip der 4 GHz machen muss und nicht im Sinne von schlecht.

 

[LoRDxRaVeN]

Eventuell gabs die Warsaw-Entscheidung nach dem A0 Silizium. Vermutlich war das total mieß, sodass klar war, dass man mehr Zeit zum Entwicklen braucht, ergo hat mans verschoben und Warsaw aus der Taufe gehoben.

Warsaw würde nach welchem A0-Silizum aus der Taufe gehoben? (also rein bezogen auf deine Spekulation)

Selbst zu 32 nm kann man sich eigentlich kein ernsthaftes Urteil erlauben, weil man nicht sagen kann, ob es AMD wegen des Prozesses oder wegen der Architektur so "gut" geht.

Man hat zumindest den K10 basierenden Llano zum mehr oder weniger direkten Vergleich. Das lässt zumindest die bekannte Vermutung zu, dass der Prozess sicherlich nicht ideal ist. Das widerspricht sich aber in keinster Weise mit deiner Aussage, dass man kein "ernsthaftes" Urteil abgeben kann. Das sehe ich durchaus ähnlich...

 

[Opteron]

Das Ding kommt nicht in 20nm. Warum sollte man das antun, wenn man einen "ordentlichen" Fertigungsprozess hat? 20SLP ist von der Leistungsfähigkeit doch ein Witz ggü. 28SHP
(...)
Ich hab noch einen . Wenn man die Theorie zugrunde legt, dass 28SHP der ursprüngliche 22nm-Prozess von AMD/IBM ist, wer sagt denn dass 20SLP in Wirklichkeit nicht das Low-End-Pendand dazu ist? Ist 20SLP überhaupt kleiner als 28SHP oder heißt der marketingtechnisch nur einfach so?

Der 20nm Prozess bei GF heißt 20LPM, nicht SLP Und ja, das ist ein deutlicher Shrink ggü. 28nm, 64nm Pitches ist schon ganz "nett". SHP wär besser für Takt, ja, aber will AMD das? Wenn die 1P-Strategie stimmt, und wenn überhaupt noch ne reine CPU kommt, dann werden sie eher nen fetten Prozessor ala Intel-2011 auflegen, da die MCM-Möglichkeit mangels Hypertransport wegfällt. Ergo viele Module auf einem Die. Das geht in 20nm besser als in 28. Natürlich verliert man ohne SOI an Spitzen-Takt, aber selbiger wär bei nem z.B. 6-oder gar 8-Modul-Chip so oder so begrenzt - aufgrund der schieren Kernzahl.

@LoRDxRaVeN:
A0-Silizium von nem spekulativen Excavator-Server-Die. Full-Revision-Spins brauchen ca. ein halbes Jahr, d.h. wenn sie ne Bx oder besser C-Version haben wollen, könnte es jetzt schon allererste Testchips (eben A0) gegeben haben. Wenn die sch...e waren, sprich überhaupt nicht funktionieren, dann braucht man umso länger für die Fehlersuche und wenn man dann den Fehler gefunden hat, darf man wieder ~6 Monate warten. Für 2014 wäre das dann zu spät gewesen.

 

[OBrian]

Beim großen Die stellt sich nur die Frage, was für Absatzchancen bestehen denn damit?

Denkbar ist noch, daß es einen 4-Modul-"Kaveri" gibt, der in den gleichen Sockel paßt und auch sonst keine Unterschiede aufweist außer eben doppelter Kernanzahl. Wäre relativ einfach zu machen (keine Neuentwicklung von Anbindungen, Layout oder sonstwas, nur zwei Module mehr an einer Seite, das ist fast nur Copy&Paste) und in dem Prozeß sicher auch machbar (wenn ein 4-Moduler in 32nm geht, wird es wohl in 28nm auch gehen), aber selbst dafür müßte es einen erklecklichen Markt geben, der genug Stückzahlen abnimmt. Wenn es sowas also nciht gibt, dann liegt das wohl weniger am Prozeß, sondern an der Entscheidung, nur das zu bauen, womit man auch Umsatz machen kann.

Warum aber AMD unbedingt noch "reine" CPUs bauen soll, will mir nicht in den Kopf. Ein paar deaktivierte Exemplare für Pfennigfuchser, ok, aber sicher kein extra Die. AMD will HSA pushen, das geht nicht mit mutwillig verkleinerter Hardwarebasis, und die GPU kostet ja keinen Strom, wenn sie nicht gebraucht wird, d.h. hat auch keinen Einfluß auf die maximale Performance per Turbo. Nur auf die Diegröße, aber die wäre in dem Bereich mit höherem Stückpreis und relativ wenig Stückzahlen auch nicht so schlimm. Gewöhnt Euch mal langsam daran, daß in AMDs zukünftigen Prozessordesigns IMMER eine GPU als unverzichtbarer Bestandteil mit an Bord sein wird.

 

[Opteron]

Beim großen Die stellt sich nur die Frage, was für Absatzchancen bestehen denn damit?

Gute Frage, aber die wird AMD sicherlich schon eruiert haben ... ist die Frage, wie groß die traditionellen Absatzchacen für die Bereich sind, in denen HSA nichts bringt.

Denkbar ist noch, daß es einen 4-Modul-"Kaveri" gibt, der in den gleichen Sockel paßt

Das Problem an der Sache ist der L3-Cache. Den braucht es wohl für die reinen CPU-Tasks. Der braucht dann halt von der Fläche her ähnlich viel wie die GPU. Also heißt es quasi entweder APU mit CPU+GPU, oder CPU mit CPU+massig L3.

Warum aber AMD unbedingt noch "reine" CPUs bauen soll, will mir nicht in den Kopf.

Mir auch nicht, deswegen schrieb ich ja oben dick und fett:

wenn überhaupt noch ne reine CPU kommt

Das Risiko, dass da nix mehr kommt, besteht durchaus.

Solange es aber noch neue Kerne für die BD-Architektur gibt, werd ich die Flinte nicht komplett ins Korn. Da sehe ich noch Restchancen. Den Kern entwickeln sie so oder so, bisschen L3 dran und Module kopieren ist dann kein Hexenwerk. Das Ganze dann billig in Bulk 20nm produziert könmnte sich dann noch rentieren.

Selbst für Desktop wär 20nm bulk wohl nicht soooo schlecht. Vom Takt her hat ja schon 32nm SOI gereicht, wenn man jetzt damit rechnet, dass 20nm Bulk vom Taktspielraum nicht besser wäre, so könnte man nen 5 GHz BD doch hoffentlich mit weniger TDP herstellen. Ist ja immerhin ein dicker Eineinhalb-Node-Sprung. Ok, bei 20nm wird die Skalierung schlechter, aber unterm Strich bleiben mind. Verbesserungen einer Full-Node.

 

[Duplex]

Du solltest schon gelernt haben dass 22nm oder 28nm nur Worthülsen sind.
Beide Fertigungen können gleich große Strukturen erzeugen.
Von daher muss es nicht sein dass die 22nm Intel Fertigung besser ist als die 28nm GF Fertigung.

28nm GF ist nur ein Halfnode Prozess, erwarte da nicht viel! Intel hat in 22nm bereits 2 CPU Generationen präsentiert, der Prozess ist jedenfalls optimiert.
Bis heute sind keine 28nm HP Chips von GF aufgetaucht, der Fortschritt ist nicht sichtbar, Richland wurde vermutlich wegen 28nm Problemen nachgeschoben.
Wenn der 28nm Prozess Super wäre, dann hätte man auch BD/PD für auf diesen Prozess shrinken können, die Effizienz der 32nm BD/PD ist ja nicht gerade gut, wenn man ein Gesamtes System mit der Konkurrenz vergleicht, dann fällt auf das FX8xxx Modelle zwischen 50-100W mehr Energie als Intel CPUs verbrauchen können.

Und hör jetzt wieder auf mit dem Dauerbashing in jedem Thread zu AMD, Danke.

Das ist kein Bashing, warum sollte ich das machen?
Ich möchte gerne das AMD in den Bereichen wo Intel gute Produkte hat auch konkurrenzfähig ist, so wie zu K7, K8 Zeiten, darauf warte ich wirklich seit Jahren!

 

[tomturbo]

Hätte Hätte Fahrradkette,
es ist NICHTS da von GF in 28nm für AMD und Du bewertest diesen Prozess bereits?
Dann auch noch von 32nm FX auf die Zukunft schließen und auch wieder alles wissen.
Alle Achtung das Zeug möcht ich auch!

 

[Opteron]

Bis heute sind keine 28nm HP Chips von GF aufgetaucht,

Mann wie oft muss ich Dich noch auf den Rockchip hinweisen?

[h=1]Rockchip Launches New Tablet SoCs on GLOBALFOUNDRIES' 28nm HKMG Process Technology[/h]

http://globalfoundries.com/newsroom/2013/20130617.aspx

Langsam wirste leider echt ein Kandidat für die Ignorliste, tut mir irgendwie leid aber ich seh bald keinen Alternative mehr

 

[Markus Everson]

Warum aber AMD unbedingt noch "reine" CPUs bauen soll, will mir nicht in den Kopf. Ein paar deaktivierte Exemplare für Pfennigfuchser, ok, aber sicher kein extra Die.

Sobald AMD es schafft einen L3 in ihre APU zu integrieren - ok. Bis dahin bleibt der Performance Nachteil beim Ausführen nicht optimierten Programmcodes. Mir ist bewußt das AMD es so darstellt als ob ein L3 in einer APU sinnlos sei. Ich hoffe aber das das nur eine Schutzbehauptung ist solange man noch nichts vorzuweisen hat.

 

[hot]

Ein L3-Cache oder besser LLC ließe sich doch extern realisieren. Die bräuchte man doch gar nicht auf dem Die.

 

[tex_]

Der L3 ist dafür da, die Latenzen zum RAM zu verkürzen. Mit einem externen LLC hätte man da also nicht viel gewonnen, man würde sogar vermutlich noch den Weg bis zum eigentlichen RAM verlängern.
In Multikernsystemen, soll er auch gewissermaßen den Datenaustausch zwischen den einzelnen Recheneinheiten vereinfachen. Die einzelnen Kerne sind jetzt nicht besonders breit angebunden, aber wenn man dies alles nach draußen führt würde dies wieder eine verdammt hohe nötige Bandbreite erzeugen, da eben nun jede dieser Einheiten einen eigenen Datenbus haben möchte. (Bei 8 Kernen mit je 64bit Anbindung, müsste man also 512Bit nach außen führen und auch einen entsprechend schnellen Speicher haben).

Die hohen Bandbreiten und kurzen Latenzen zusammen sind extern nun mal nicht wirklich umsetzbar. Selbst stacked RAM wird das nicht so erreichen können wie ein interner SRAM Cache. Da würde ich fast eher noch auf T-/Z-RAM hoffen.

 

[Opteron]

(Bei 8 Kernen mit je 64bit Anbindung, müsste man also 512Bit nach außen führen und auch einen entsprechend schnellen Speicher haben).

Die hohen Bandbreiten und kurzen Latenzen zusammen sind extern nun mal nicht wirklich umsetzbar. Selbst stacked RAM wird das nicht so erreichen können wie ein interner SRAM Cache. Da würde ich fast eher noch auf T-/Z-RAM hoffen.

Naja, HMC ist mit 1024bit spezifiziert, das reicht erstmal, auch für Steamroller bei dem ein Modul nun 256bit bekommt (also 128bit pro Core). Frage mich nur, ob man die 2 GB aufwärts für nen Cache nutzen will, oder ob das vielleicht nicht eher was für Mobileanwendungen ist, die das dann als RAM nehmen. Für Server mit nem halben Terabyte RAM (für DDR4 sind 128GB-Module angekündigt, mit Quadchannel ergäbe das also 512GB), wären das Größenverhältnis zw. Cache und RAM nicht so gut wies auf dem ersten Blick ausschaut.

 

[mariahellwig]

Hat AMD nicht seine komplette Entwicklung umgekrempelt und setzt künftig auf automatisierte Design-Werkzeuge? Statt auf Handarbeit...

Bin mal gespannt was sich von diesen Gerüchten künftig als wahr erweisen wird.

 

[amdfanuwe]

Ich möchte gerne das AMD in den Bereichen wo Intel gute Produkte hat auch konkurrenzfähig ist, so wie zu K7, K8 Zeiten, darauf warte ich wirklich seit Jahren!

Tja, hab ich mir auch Jahrelang gewünscht, hätte den Aktienkurs hochgetrieben .

Spoiler

Leider hat Intel einen Fertigungsvorteil, der sich schwer wettmachen läßt. Zudem verfügen sie über Geldmittel und die Marktmacht um direkte Konkurrenz zu ersticken.
Ich finde es daher schon gut, dass AMD nicht mehr versucht Intel hinterher zu hecheln sondern sich auf die eigenen Stärken besinnt. Letztendlich ist AMD ein Wirtschaftsunternehmen und muß Geld verdienen.

Als Programmierer sehe ich schon den Vorteil, den die APUs bringen und mit Kaveri erst richtig bringen werden.
Parallele Datenverarbeitung wird sehr einfach. Man schreibt seine Daten in ein Array, in den for each Zweig die Funktion die mit den Daten ausgeführt werden soll und schon können massiv parallel auf der GPU das Array bearbeitet werden.
Bisher mußten erst einige OpenCl Devises und Buffer initialisiert werden, die Daten zur GPU gesendet werden, Ergebnisse zurückgeschickt etc. Lohnt sich nur bei größeren Datenmengen. Bei Kaveri wird sich das auch schon für kleine Arrays lohnen, da ja nichts mehr kopiert werden muß.
Die Programmierer müssen nur mal anfangen, Microsoft AMP oder AMDs Bolt C++ Library zu nutzen.
Wenn das geschieht, wird manche "nur CPU" recht blass aussehen.

Spekulation on:
Hat Excavator überhaupt noch herkömmliche FPU, SSE, AVX? Werden diese Befehle vielleicht schon von der GPGPU verarbeitet? Könnte AMD mit einer 512 Operanden breiten AVX Einheit werben.
Spekulation off.

Da sehe ich schlechte Chancen für eine reine Excavator CPU.

Spoiler

Die müßte schon so überragend sein, dass sich AMD einen ordentlichen Gewinn davon versprechen würde.
Man darf auch nicht zusehr darauf schauen, was aktuell sinnvoll wäre sondern muß in Betracht ziehen, was in Zukunft benötigt wird. Reines Multithreading wird nur in wenigen Fällen sinnvoll eingesetzt und da, wo es aktuell benutzt wird um Daten parallel zu bearbeiten, ist der Einsatz der GPGPU sinnvoller und mittlerweile einfacher zu handhaben.

Wo ist der Bedarf für eine herkömmliche CPU in ein paar Jahren?

HPCs werden mit GPUs ausgerüstet, sollte eine gute APU effektiver sein.
Server für Handel, Soziale Netzwerke, also alles mit massiven Benutzerandrang dürften eher Probleme mit der Bandbreite als mit der CPU Leistung haben, da reichen kleine effektive Microserver.
Business und Home PCs, da reicht die Leistung schon lange.
Gaming? Multithreading wird kaum unterstützt und mit den neuen Konsolen werden Games wohl auch mehr auf GPGPU setzen.
Bleibt noch das Ersatz-Geschäft für bestehende Anlagen. Da dort fast überall Intel drin ist, ist das auch keine Option für AMD.

 

[Complicated]

@LoRDxRaVeN:
A0-Silizium von nem spekulativen Excavator-Server-Die. Full-Revision-Spins brauchen ca. ein halbes Jahr, d.h. wenn sie ne Bx oder besser C-Version haben wollen, könnte es jetzt schon allererste Testchips (eben A0) gegeben haben. Wenn die sch...e waren, sprich überhaupt nicht funktionieren, dann braucht man umso länger für die Fehlersuche und wenn man dann den Fehler gefunden hat, darf man wieder ~6 Monate warten. Für 2014 wäre das dann zu spät gewesen.

Dreh doch mal die Argumetation um: Da AMD eine B oder C-Revision haben wollte (wegen der Komplexität/Redesign/WaveScalar?) haben sie entsprechend schon sehr früh angefangen (vielelicht sogar vor Steamroller?) zu entwickeln. Der Entwicklungszweig ist schon reif für Excavator und daher gibt es auch schon A0-ES. Auf 20nm will man nicht warten, da der Prozess teuer ist und es zu lange dauert bis Wirtschaftlichkeit gegeben ist im Vergleich zu 28nm der zwar verspätet in die Gänge kommt aber bis zum C-Stepping sehr gut ausgereift ist für hohe Yields und grosse Dies mit viel GPU Fläche.

Das Problem an der Sache ist der L3-Cache. Den braucht es wohl für die reinen CPU-Tasks. Der braucht dann halt von der Fläche her ähnlich viel wie die GPU. Also heißt es quasi entweder APU mit CPU+GPU, oder CPU mit CPU+massig L3.

Die Frage ist doch auch für wen der L3 Cache einen Vorteil bringt. Im HPC Bereich bauen immer mehr Server externe GPUs ein oder Xeon Phi. Das heisst die Software wird auch dafür geschrieben. Bis zum erscheinen von Excavator wird diese Software auch in die darunter liegenden Performancebereiche "gesickert" sein. Nur wer investiert die Unsummen für diese Zusatzkarten, die Nvidia und Intel anbieten für ein 1-2 Sockel Server? Hier kann man schon damit rechnen, dass in 2 Jahren die Entwickung des HSA Standards voll durchschlägt (man muss vieleicht auch damit rechnen und entsprechend alles dafür tun im Bereich Entwicklung!) und entsprechend APUs wesentlich mehr Performance Potential haben als ein ebenso "teurer" (in Bezug auf Platz auf dem Die) L3 Cache Verschwendung ist. AMD hat FCL und RMB in APUs die L3 nicht brauchen.

Die anderen Märkte hat amdfanuwe ja schön umrissen. Wozu einen L3 Cache? Intel muss sogar mit L4 Cache arbeiten um den Datenaustausch zwischen GPU, Stacked RAM und CPU überhaupt möglich zu machen mit ihrem Design. Ich denke da geht sehr viel vom Fertigungvorteil verloren. Wie Opteron schon hingewiesen hat kostet LLC und GPU ähnlich viel Diefläche

 

[Opteron]

Dreh doch mal die Argumetation um: Da AMD eine B oder C-Revision haben wollte (wegen der Komplexität/Redesign/WaveScalar?) haben sie entsprechend schon sehr früh angefangen (vielelicht sogar vor Steamroller?) zu entwickeln. Der Entwicklungszweig ist schon reif für Excavator und daher gibt es auch schon A0-ES. Auf 20nm will man nicht warten, da der Prozess teuer ist und es zu lange dauert bis Wirtschaftlichkeit gegeben ist im Vergleich zu 28nm der zwar verspätet in die Gänge kommt aber bis zum C-Stepping sehr gut ausgereift ist für hohe Yields und grosse Dies mit viel GPU Fläche.

Äh .. ja, wenn Steamroller 2001 fertig gewesen wäre, wär er 2002 rausgekommen. Glaube nicht, dass sie früher anfangen hätten können, die BD-ARchitekturen bauen ja mehr oder minder aufeinander auf. Erstmal mussten sie BDv1/2 entbuggen, wenn sie da gleichzeitig mit Steamroller angefangen hätten, muss man prarallel die gleichen Probleme lösen *und* hat kein Testsilizium. Das wär ziemlich blöde. Außerdem sieht man ja die Entwicklungszeiträume recht gut in diversen Linkedin Profilen, z.B:

January 2011 – December 2012 (2 years) Sunnyvale, CA

Project Excavator (XV)

March 2010 – January 2011 (11 months) Sunnyvale, CA
Project: PileDriver(PD)

June 2006 – March 2010 (3 years 10 months) Sunnyvale, CA

Project: Bulldozer (BD)

http://www.linkedin.com/pub/david-li/1/689/33

Eine Früher-anfangen-Möglichkeit seh ich da nicht, laut digitimes vom Mai, haben sie was gehört, dass XV sogar erst 2015 käme, mit ein weiterer Grund nicht mit 28nm zu rechnen.

Die Frage ist doch auch für wen der L3 Cache einen Vorteil bringt. Im HPC Bereich bauen immer mehr Server externe GPUs ein oder Xeon Phi. Das heisst die Software wird auch dafür geschrieben. Bis zum erscheinen von Excavator wird diese Software auch in die darunter liegenden Performancebereiche "gesickert" sein. Nur wer investiert die Unsummen für diese Zusatzkarten, die Nvidia und Intel anbieten für ein 1-2 Sockel Server? Hier kann man schon damit rechnen, dass in 2 Jahren die Entwickung des HSA Standards voll durchschlägt (man muss vieleicht auch damit rechnen und entsprechend alles dafür tun im Bereich Entwicklung!) und entsprechend APUs wesentlich mehr Performance Potential haben als ein ebenso "teurer" (in Bezug auf Platz auf dem Die) L3 Cache Verschwendung ist. AMD hat FCL und RMB in APUs die L3 nicht brauchen.

Hatte letztens dazu ne Diskussion dazu im 3DC, das Problem bei den GPUs in Zukunft ist das, die Daten für die ganzen 1000 Shadercores herzubringen und anzuliefern. Da gibts dann nen kleinen unscheinbaren Nebeneffekt, nämlich den Stromverbrauch. Daten über den RAM-Kontroller übers Die zu scheuchen ist energieaufwändig, ein Cache spart in der Masse gut Energie. Ein großer Cache wäre also auch für APUs interessant, wobei ich nicht ganz sicher bin, wie die Energie-Rechnung bei HMC als L3/L4 aussähe, das ist dann ja quasi auch schon wie ein RAM-Zugriff. Die Diskussion war eher über Rechenkern-nahe L1/L2-Caches.