AMDs "Excavator" - 4. Modul Generation Spekulation

[OBrian]

Hmm, Cache ist eigentlich immer gut. Auch die GPU wird mehr Cache bekommen müssen, um die Bandbreitenproblematik abzumildern (selbst wenn diese doch einigermaßen abgehobene Wave-Architektur nicht dabei ist). Also wenn, dann würde ich einen Cache für alles dranbauen, d.h. auf den CPU und GPU zugreifen können.

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.

Ich denke durchaus, daß das so kommen wird, aber wohl nicht schon mit XV. Die FPU nimmt ja prozentual immer weniger Platz weg, und man müßte die Module total umstricken, um sie auszubauen. Dieser Schritt wird erst bei einem größeren Architekturwechsel kommen, wenn man sowieso alles umstricken muß. XV dürfte aber noch recht eindeutig zur BD-Familie gehören. Zudem muß man dann auch wirklich sicher sein, jeglichen alten Code ordentlich schnell auf andere Art und Weise abarbeiten zu können.

 

[Opteron]

Ich denke durchaus, daß das so kommen wird, aber wohl nicht schon mit XV.

Ne das gehört ins Reich der Ammenmärchen, die GPU wird *nie* die CPU-interne FPU ersetzen. Geht nicht und man sah ja auch 2011 an der AMD-Studie fürs Jahr 2018 was da geplant wurde: 256bit FMACs (statt 128 ), viel Cache und viel GPU.

 

[Complicated]

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.


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.

Danke für die Linkedin Quelle. Die war mir nicht bekannt bis dato. Ist damit natürlich vom Tisch

Bei der Betrachtung was mehr Strom verbraucht (also mit oder ohne L3 Cache) sollte man allerdings berücksichtigen, dass wenn die Diefläche mit viel LLC Cache genutzt wird, eben weniger GPU CUs verbaut weden können und wieder externe GPU/XEON Phi(TCU) Steckkarten nötig werden. Kann man sich die externen TCU-Karten sparen, fällt die Gleichung wieder zu ungunsten des LLC. Natürlich kann das im Desktop und Mobil wiederum für Unausgeglichenheit sorgen, da dort eben ohne solche TCU-Karten gearbeitet wird in der Regel.

 

[ONH]

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

schliesst meiner Meinung nach nicht aus das das Steamroller und Excavator sich stark in den Zeiträumen überschneiden, denn bei dem Linked in Profil fehlt offensichtlich Steamroller.

Da bleibt nicht viel anderes möglich als das er nur mit den Server Versionen beschäftigt, was aber nichts an der Überschneidung der Beiden Entwicklungnszeiträume Ändert.

 

[gruffi]

Sobald AMD es schafft einen L3 in ihre APU zu integrieren - ok.

Aber nur, wenn du mit L3 Stacked Memory meinst. Ein L3 in der aktuellen Form macht für AMDs APUs wenig bis gar keinen Sinn. Die haben ja schon recht üppige L2 Caches, die völlig ausreichen. Bei Jaguar sogar für bis zu 4 Kerne/Threads innerhalb einer CU.

 

[Complicated]

schliesst meiner Meinung nach nicht aus das das Steamroller und Excavator sich stark in den Zeiträumen überschneiden, denn bei dem Linked in Profil fehlt offensichtlich Steamroller.

Stimmt...das spricht ja eher für meine Iterpratation, dass der Profilinhaber eben nicht an Steamroller arbeitet sondern seit März 2010 an XV während andere noch mit SR beschäftigt sind. Ausser SR wird von AMD komplett übersprungen, lol. Das können wir aber glaub ich ausschließen
Ist natürlich auch die Frage was die Person überhaupt macht. Kaffee bringen? CPU Design? GPU?

Edit:
Hab den Job kurz gechecked von dem Mitarbeiter:
MTS Physical Design Engineer

Er arbeitet übrigens nicht mehr an Excavator sondern seit letztes Jahr Dezember an "High Performance ARM core"

Laut Job Beschreibung http://amd.jobs/hyderabad-ind/mts-design-engineer/37131947/job/
Ist das auch ein "Pre-silicon and system level design"

Job Description: Job Description

The candidate will be responsible for participating in the pre-silicon block and system level design. The candidate will also be responsible for Front-End chip implementation including design, synthesis and execution flows that starts with RTL coding and ends with the delivery of a netlist package ready for physical design. Responsible for synthesis, netlist generation, timing and logical equivalency checks, floorplanning, budgeting, clock methodology and timing constraint management. Candidate will work in collaboration with Physical Design Engineers in chip level planning and integrations.

Da muss man sich jetzt eigentlich nur noch fragen wie lange es dauert wenn das pre-silicon Design fertig ist bis es erste Engeneering Samples gibt. Ich halte es durchaus für möglich 9 Monate später ES aus der Produktion laufen zu lassen.

Edit2:
Das ist ja eine geniale Quelle!
Der hier hat an Steamroller und Excavator zeitgleich das selbe gemacht:
http://www.linkedin.com/in/davidjrandolph
Nov 2011 bis Juli 2012
* debugged/verified BD core x86 and AMD64 steamroller(SR) and excavator(XV) micro-architectures and microcode.

Und dann ab zu Intel gewechselt! Also die kennen beide auch schon richtig gut.

 

[Atombossler]

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.

Ganz einfach, weil die APUs bisher gegen eine 4Modul CPU nicht anstinken können und es prozesstechnisch bisher nicht möglich erscheint eine 4Modul APU zu bauen.
Erst wenn das möglich ist (Excavator?) können Sie von mir aus die reinen CPUs einstellen. Ob die GPU dann da tot mit idled ist mir dann auch egal.

 

[Complicated]

Nicht anstinken können wobei? Die Benchmarks, welche immer bei Desktop-Test verwendet werden enthalten doch meist eben die Software, welche von den zusätzlichen Modulen am wenigesten profitiert. Da stehen 3 Moduler FX-6xxx gleich schnell da mit weniger Verbrauch und deutlich besserer Effizienz. Eine 2 Modul APU hat hier reichlich Reserven die in Software ausgenutzt werden können und werden, wie immer mehr Berichte zeigen.

Das wäre doch mal ein Interessantes Projekt für die Redaktion: Ein HSA Benchmark Parcour der 2-Modul APUs vs. 4 Modul CPUs gegenüberstellt.

 

[Atombossler]

Nicht anstinken können wobei? Die Benchmarks, welche immer bei Desktop-Test verwendet werden enthalten doch meist eben die Software, welche von den zusätzlichen Modulen am wenigesten profitiert. Da stehen 3 Moduler FX-6xxx gleich schnell da mit weniger Verbrauch und deutlich besserer Effizienz. Eine 2 Modul APU hat hier reichlich Reserven die in Software ausgenutzt werden können und werden, wie immer mehr Berichte zeigen.

Das wäre doch mal ein Interessantes Projekt für die Redaktion: Ein HSA Benchmark Parcour der 2-Modul APUs vs. 4 Modul CPUs gegenüberstellt.

Ok, das war zu subjektiv.
Ich beziehe das auf meinen Workload (den eben so keiner kennt), dh. x264/Catia/SolidWorks/ProEng./Hypermill/Mastercam+eigene Soft.
Da bedeuten eben 2 Module weniger auch gleich 50% weniger Leistung.
Das einzige was da in deren Benchmarkparcours enthalten ist, ist x264 und der skaliert mit zusätzlichen Modulen/Cores vorzüglich.
Mit OpenCL ist er sogar langsamer als ohne.

 

[Markus Everson]

Bei der Betrachtung was mehr Strom verbraucht (also mit oder ohne L3 Cache) sollte man allerdings berücksichtigen, dass wenn die Diefläche mit viel LLC Cache genutzt wird, eben weniger GPU CUs verbaut weden können und wieder externe GPU/XEON Phi(TCU) Steckkarten nötig werden.

Die externe Steckkarte wird mit ihrem PowerBudget von 200 Watt (und mehr) auf absehbare Zeit weiterhin Kreise um die APU drehen. Das ist also kein Entweder oder sondern die Frage wo die Transistoren/Fläche den größten Nutzen bringt. LLC bringt Potentiell allen Anwendungen Performancegewinne, sollte also eigentlich immer wünschenswert sein.

 

[amdfanuwe]

Na, da AMD ja mittlerweile 220W CPUs anbietet würde es mich nicht wundern, wenn auch 220W APUs erscheinen.

 

[sompe]

Schonmal ne 125W APU gesehen?

 

[unl34shed]

200W wäre schon cool, FX6 + 7770 ABER da muss was besseres als DDR3 her, sonst wird das Teil nicht schneller als ein aktueller A10

 

[Markus Everson]

Na, da AMD ja mittlerweile 220W CPUs anbietet würde es mich nicht wundern, wenn auch 220W APUs erscheinen.

Nicht unmöglich, wenn auch wenig Wahrscheinlich. Aber auch bei identischer TDP würde die GPU meines Erachtens noch immer Kreise um die APU ziehen weil sie eben nur ein Aufgabengebiet mit maximaler Effizienz zu erledigen hat und keine Bremsklötze (zum Beispiel in Form geteilter Bandbreite) mitschleppen muss.

 

[Complicated]

Es gibt allerdings eine recht große Leistungslücke zwischen den mit diskreten GPUs ausgestatteten Systemen und den reinen CPU Systemen. Hier ist eine Server-APU anzusiedeln. Sie muss nicht diskrete GPUs ersetzten, bringt aber in Systemen ohne diskrete GPU einen deutlichen Leistungssprung. Und wenn APU Systeme mit GPUs gepaart werden summiert sich dies eben auch. Es ist auch ein völlig anderer Kostenfaktor in der Programmierung wenn HSA Systeme betreut werden mit einfachem Code von Wald und Wiesen Programmierern oder eben, wie AMD es ja genannt hat "Ninja-Programmierer" die Programmierung von reinen Tesla-GPUs sehr teuer und aufwendig realisieren.

 

[Duplex]

Mann wie oft muss ich Dich noch auf den Rockchip hinweisen?
http://globalfoundries.com/newsroom/2013/20130617.aspx

Den Link sehe ich zum ersten mal.
Im Artikel wird erwähnt das man auf GF Prozess gesetzt hat weil die Yields von 28nm HKMG hoch genug sind.
Das würde für AMD bedeuten das Richland nicht wegen dem 28nm Prozess nachgeschoben wurde, sondern weil man im Design Bugs entdeckt hat,
eine neue Revision/Respin von Kaveri ohne schwere Fehler wird mehrere Monate dauern können, deshalb startet man so spät.
Was ich nicht verstehe ist warum "PD" nicht auf 28nm geschrinkt wurde, auch wenn es nur ein Halfnode Prozess ist, es sollte einfacher sein eine alte Architektur in neuer Fertigung zu bauen.

 

[Markus Everson]

Es gibt allerdings eine recht große Leistungslücke zwischen den mit diskreten GPUs ausgestatteten Systemen und den reinen CPU Systemen. Hier ist eine Server-APU anzusiedeln. Sie muss nicht diskrete GPUs ersetzten, bringt aber in Systemen ohne diskrete GPU einen deutlichen Leistungssprung.

Genau so sehe ich das auch. Lediglich das Beispiel mit dem Potentiell eingespaarten Xenon Phi schien mir unrealistisch.

 

[Bobo_Oberon]

Den Link sehe ich zum ersten mal. ...

Die Meldung habe ich nicht nur hier gesehen.

... Im Artikel wird erwähnt

In einem "Newsroom" werden keine Artikel, sondern werbende Firmenmeldungen verlautbart. Das ist so ziemlich das Gegenteil von einem Artikel.

... das man auf GF Prozess gesetzt hat weil die Yields von 28nm HKMG hoch genug sind.
Das würde für AMD bedeuten das Richland nicht wegen dem 28nm Prozess nachgeschoben wurde, sondern weil man im Design Bugs entdeckt hat,
eine neue Revision/Respin von Kaveri ohne schwere Fehler wird mehrere Monate dauern können, deshalb startet man so spät. ...

Doppelt/dreifacher Rückschluß/Mutmaßung?! Wir wissen schlicht immer noch nicht, weswegen etwas verschoben wird!

Womöglich sitzt AMD (wie Intel übrigens auch) auf einer Halde Prozessoren. Seit mehreren Quartalen sind die Absatzzahlen für x86-Desktop-Prozessoren geschrumpft!

... Was ich nicht verstehe ist warum "PD" nicht auf 28nm geschrinkt wurde, auch wenn es nur ein Halfnode Prozess ist, es sollte einfacher sein eine alte Architektur in neuer Fertigung zu bauen.

Mag ja sein ... aber auch ein Shrink kostet Geld, bindet Ressourcen und garantiert per se NICHT die Absatzkrise zu überwinden.

MFG Bobo(2013)

 

[BavarianRealist]

...Was ich nicht verstehe ist warum "PD" nicht auf 28nm geschrinkt wurde, auch wenn es nur ein Halfnode Prozess ist, es sollte einfacher sein eine alte Architektur in neuer Fertigung zu bauen.

Womöglich will AMD einfach kein Geld mehr für eine reine CPU-Entwicklung ausgeben. Hier läuft man Intel so oder so einfach zu weit hinter her.

 

[Complicated]

Im Artikel wird erwähnt das man auf GF Prozess gesetzt hat weil die Yields von 28nm HKMG hoch genug sind.
Das würde für AMD bedeuten das Richland nicht wegen dem 28nm Prozess nachgeschoben wurde, sondern weil man im Design Bugs entdeckt hat,
eine neue Revision/Respin von Kaveri ohne schwere Fehler wird mehrere Monate dauern können, deshalb startet man so spät.
Was ich nicht verstehe ist warum "PD" nicht auf 28nm geschrinkt wurde, auch wenn es nur ein Halfnode Prozess ist, es sollte einfacher sein eine alte Architektur in neuer Fertigung zu bauen.

Diese Aussage von dir zeugt davon, dass du etwas grundsätzliches bei der Auswahl des Prozesses für ein Design nicht verstanden hast: Nur weil eine Architektur auf einem Prozess gute Yields abliefert ist das noch lange nicht auf eine andere Architektur übertragbar. Jeder Prozess bildet mit jeder darauf designten Architektur eine völlig eigenständige Einheit mit eigenen Stärken und Schwächen. Sehr deutlich konnte man das sehen als AMD und Nvidia ihre GPUs in 40nm bei TSMC in Produktion gaben. Wo mit der HD5000 Serie AMD eine Kehrtwende im Markt schaffte konnte Nvidia bestimmte Problem mit Fermi nur sehr aufwendig und mit viel Aufwand in den Griff bekommen.

Das heisst nicht dass die Architektur oder der Prozess automatisch Schrott sind, sondern dass die Schwächen und Stärken von beiden nicht völlig in den Griff bekommen wurden. Auch wenn es um GPUs geht in diesem Fall ist es recht interessant zu lesen wie Prozesse von Chipdesignern bewertet und in bestimmten Fällen (hier AMD bei Cypress) zu Änderungen im Chipdesign führen können - nicht in der Architektur, sondern in der Entscheidung wo Redundanzen gebildet werden sollen um die Yield zu erhöhen. Und das obwohl der Anbieter des Fertigungsprozesses (hier TSMC) diese Schwachstellen verschweigt oder herunterspielt. Die wollen auch nur verkaufen.

Sehr Interessant vor allem wie die Entscheidungsfindung bei Features vonstatten ging:
The RV870 Story: Process vs. Architecture: The Difference Between ATI and NVIDIA

 

[Opteron]

Sehr deutlich konnte man das sehen als AMD und Nvidia ihre GPUs in 40nm bei TSMC in Produktion gaben. Wo mit der HD5000 Serie AMD eine Kehrtwende im Markt schaffte konnte Nvidia bestimmte Problem mit Fermi nur sehr aufwendig und mit viel Aufwand in den Griff bekommen.

Na das lag aber nur daran, dass ATi clevererweise einen 40nm-Testchip in Form des RV740 hatte. Da machten sie die Erfahrung, dass die Kontakte zw. den Metallebenen sehr kritisch waren, weswegen sie einfach mal die doppelten Kontakte im Design vorsahen. Nvidia wusste das nicht, hatte keine Testchip und viel in die Grube ... *G*

 

[Complicated]

Wie gesagt. Der Artikel beschreibt warum ATi dies damals so entschieden hat und wo die Zweifel waren. Ist echt interesaant.

 

[Opteron]

Wie gesagt. Der Artikel beschreibt warum ATi dies damals so entschieden hat und wo die Zweifel waren. Ist echt interesaant.

Ach den Link hatte ich ganz übersehen, da stehts dann ja mit dem RV740

 

[hot]

Ne das gehört ins Reich der Ammenmärchen, die GPU wird *nie* die CPU-interne FPU ersetzen. Geht nicht und man sah ja auch 2011 an der AMD-Studie fürs Jahr 2018 was da geplant wurde: 256bit FMACs (statt 128 ), viel Cache und viel GPU.

Na, dieses Ammenmärchen hat AMD aber selbst in die Welt gesetzt, mit deren 4-Schritte-Fusion-Fahrplan von 2009. Demnach wär der letzte Schritt die Vollintegration der GPU in die CPU.

 

[Dr@]

Vollintegration ja, bedeutet doch aber nicht, dass die FPU dafür entfernt wird, oder?