News AMDs „Steamroller“-Architektur und der kleine Schwenk zurück

Aber auch Fetch, L1I, L2 sind neben den Decodern und diversen Caches bei Steamroller
sehr viel grösser und breiter (auf mehr Durchsatz) ausgelegt als bei Zambezi. Damit sind die Schwachstellen von BD grösstenteils richtig benannt und beseitigt.
Dazu noch der Loop Cache welcher zusammen mit den doppelt vorhandenen Decodern den meisten Gewinn verspricht. Steamroller wird wirklich eine Dampfwalze, die Frage ist nur wie stark ist die Konkurrenz bis dahin?


Denn was bringt eine auf Durchsatz angelegte Architektur bei BDv1 mit schnellen INT's und eingentlich einer nicht gar schwachen FPU, wenn der Fetch und die Decoder keine Arbeit bereitstellen können?


Wenn die Software bis Steamroller etwas besser auf MT optimiert ist, wird das eine extrem potente Architektur. Bulldozer done right! Aber auch für ST sieht es damit sehr, sehr gut aus.

Aber auch schon Piledriver verspricht schon gewisse Verbesserungen und Beseitigung einiger Flaschenhälse (grössere op Caches, freigeschaltete Dividiereinheit, weitere Handoptimierungen,
teilweise bessere Latenzen, Verbrauchsoptimierungen) Ist aber eigentlich nur ein neues Stepping,
die richtige BDv2 wird Steamroller.
 
Zuletzt bearbeitet:
Man muss natürlich auch bedenken, dass AMD die Kompromisse bei der ersten Bulldozer-Generation nicht aus Lust und Laune gemacht hat. Die wollten dort Transistoren einsparen, wo es nach ihrer Ansicht am ökonomischsten möglich war, ohne die Leistung allzusehr zu beeinträchtigen.

Durch die genannten Optimierungen wird Steamroller tendenziell wieder eine deutlich "dickere" CPU. Wobei ich auch der Meinung bin, dass das die richtige Entscheidung ist. AMD hat bei den ersten Bulldozern nicht nur Fett, sondern reichlich wichtige Muskeln weggeschnippelt.

Aber das zusätzliche "Gewicht" von Steamroller muss dann wieder durch neue Energiespartricks und vor allem das neue Fertigungsverfahren ausgeglichen werden. Besonders Letzteres ist mal wieder ein Glücksspiel, auf das die Entwickler bei AMD jetzt noch weniger Einfluss haben, als zuvor, weil sie jetzt ja nur noch gewöhnlicher Kunde bei GF sind.

Andererseits, bei "externen Kunden" gibt man sich ja meist mehr Mühe, sie zufrieden zu stellen. :evillol:
 
Nun die 28NM Fertigung ist ja nur ein halfnode Shrink.
Und anscheinend läuft 28NM Bulk und HP bei GF schon jetzt recht gut. Bis Steamroller gibt es da noch ne Menge Optimierungspotential.
 
Mal eine Laienhafte Frage, damit ich das etwas besser verstehe.
Wenn man bei der CPU Transistoren einspart, dann macht man das ja nicht, weil die Geld kosten, sondern weil mehr Transistoren auch mehr Strom brauchen. Sehe ich das richtig so?
 
Was man so liest will AMD bei 28NM auf SOI verzichten und auf Bulk setzen,
da teuer und verspricht in dem Fall wenig Vorteile. (zumindest bei Kaveri/Kabini)
Bei 32NM SOI hatte man sich auch mehr von SOI versprochen. Und über den
Vishera Nachfolger weiss man ja noch nix.

Aber bei 22/20NM oder 14NM will man wohl wieder auf (FD-)SOI setzen.
 
Zuletzt bearbeitet:
@Kowa - beim internen Speichercontroler hat AMD schon Performance-mässig profitiert.Die
Athlon 64 in Dual-Channel-Mode haben den P4 einfach weggeblasen.:D
 
Wenn man bei der CPU Transistoren einspart, dann macht man das ja nicht, weil die Geld kosten, sondern weil mehr Transistoren auch mehr Strom brauchen. Sehe ich das richtig so?

Schaltzeit spielt auch eine wichtige rolle. Weiteres ist es sehr sinnvoll Gatter zu reduzieren.
Für kleine Schaltungen kann man sogar sogenannte KV-Diagramme oder ähnliche Techniken anwenduen um unnötige Schaltungen zu beseitigen oder zu verbessern.

Was sehr interessant ist, die Kosten von Schaltungen.
Das Bsp SSD. NAND sind soviel ich weiß am Günstigsten und mit Ersatzschaltungen kann man jedes Gatter auch ausschließlich mit NAND zusammenschließen.
Dazu gibt es auch nutzvolle Gesetze wie "Satz von de Morgan" ect.,

Bsp eine "Äquivalente Boolesche Ausrücke":
//° = komplimintär

(°b V (a &b)) & (a & b) = a&b wenn man Schritt für Schritt eine Umformung macht.

Verglichen zu vor der Vereinfachung, ist dieSchaltung größer und benötigt mehr Zeit zum Schalten, eventuell gibt es mehr Fehler => Leckströme ect können entstehen
Hoffe ich hab das noch richtig in Erinnerung xD

Was man so liest will AMD bei 28NM auf SOI verzichten und auf Bulk setzen,
Was ich auch klug finde, denn dann hat man zu Not auch TSMC ^^ oder ?
 
Zuletzt bearbeitet:
MikelMolto schrieb:
Mal eine Laienhafte Frage, damit ich das etwas besser verstehe.
Wenn man bei der CPU Transistoren einspart, dann macht man das ja nicht, weil die Geld kosten, sondern weil mehr Transistoren auch mehr Strom brauchen. Sehe ich das richtig so?

Es kommt darauf an, eigentlich beides. Spart man Transitoren ein, spart man Waferfläche, die eben kostet. Ob nun mehr oder weniger Transitoren "weniger Strom verbrauchen" kann man nichteinmal pauschal sagen. Mehr niedrig getaktete Transistoren können weniger brauchen als weniger höher getaktete und umgekehrt. Statische und Dynamische Leckage sind da wichtige Begriffe.
Wie gesagt, kann man nicht pauschal beantworten!

Fishlike schrieb:
Ist es sicher, dass es 28nm Bulk wird?
Die Aussage seitens AMD ware in die Richtung "all our 28nm products will be bulk". Vll. findet dir Google damit etwas mehr :)
Aber nach aktueller Informationslage ist es Bulk für alle 28nm CPUs/APUs

LG
 
LoRDxRaVeN schrieb:
Woher beziehst du die Information, dass die Integerpipes selbst (auch) ein Problem (Flaschenhals) waren (sind)? Nach dem was ich so gelesen habe, ist dies nicht der Fall. Wenn ich das richtig in Erinnerung habe, krebst BDv1 irgendwo um IPC 1 herum (genauere Werte sind hier völlig irrelvant), was eben bedeutet, dass mit der zweiten Pipe noch mehr als genug Reserven vorhanden sind.
Auch war die Rede davon (schon vor der Einführung von BD), dass Wald- und Wiesencode im Schnitt auch nur eine IPC von 1,5 zulässt.
Bei den Zahlen bin ich mir nicht mehr ganz sicher, aber der Punkt ist eben, dass die Integerpipes viel eher ständig verhungern und nicht mit Daten gefüttert werden, anstatt einen Flaschenhals darzustellen!LG

Noch sind sie kein Flashenhals, aber wenn das Frontend verbessert wird, die Decoder verstärkt und dediziert werden pro Integercluster, dann werden die zwei Int-Pipelines der nächste Flaschenhals sein.

Und wenn man von Durchschnitt spricht und so was wie eine IPC von 1,5 hat, dann muss man bedenken, dass bei diesem Durchschnitt auch Werte mit 3 enthalten sein können und wenn der maximalwert auf 2 beschränkt wird, dann sinkt auch der Durchschnitt. Also mit Durchschnitswerten kann man schlecht argumentieren.

Es hat schon seinen Sinn warum der Athlon und Phenom drei Int-Pipelines hatten und warum auch der Core 2 Duo und die nachfolgeprozessoren mit 3 Int-Pipelines daherkommen. Die IPC steigt nun mal dadurch. Und wenn im Jahr 2006 diese 3 Int-Pipelines sinvoll waren, dann sind sie im Jahr 2012 noch sinnvoller, den die Programme werden nicht anspruchslosen mit der Zeit, sondern genau umgekehrt.
 
Zuletzt bearbeitet:
Herdware schrieb:
Man muss natürlich auch bedenken, dass AMD die Kompromisse bei der ersten Bulldozer-Generation nicht aus Lust und Laune gemacht hat. Die wollten dort Transistoren einsparen, wo es nach ihrer Ansicht am ökonomischsten möglich war, ohne die Leistung allzusehr zu beeinträchtigen.
Kompromisse geht man nur ein, wenn man zuwenig R&D-Ressourcen zu Verfügung hat.
Nicht bei der Wahl des Konzepte bzw. der Techniken. Denn das ist das entscheidende Know-How zu erahnen, welche Techniken am Besten bei bestimmter Konfiguartion funktionieren.

Nicht umsonst hat AMD bei Hotchips die Vorteile (Schnelligkeit, Vielseitigkeit) der autmatischen Architektur-Entwicklung betont.

Aber das zusätzliche "Gewicht" von Steamroller muss dann wieder durch neue Energiespartricks und vor allem das neue Fertigungsverfahren ausgeglichen werden. Besonders Letzteres ist mal wieder ein Glücksspiel, auf das die Entwickler bei AMD jetzt noch weniger Einfluss haben, als zuvor, weil sie jetzt ja nur noch gewöhnlicher Kunde bei GF sind.
AMD hat keinen Einfluss auf die Technologie-Entwicklung von FinFET, 450mm, 3D-Stacking, TSV, Multi-Pattering, HKMG 2.Gen, SiGe 4.Gen, usw usw.
Ein Risiko ist die Umstellung von Own-Fabrik zu Foundry-Fabrik sicher gewesen.
Aber das Risko wäre vielelicht längfristig viel größer gewesen, wenn sie ihre Own-Fabrik behalten hätten.

Wie schwer & aufwendig die zukünftige Fertigungs-Entwicklung ist, erkennt man auch selbst bei ASML, die mit den Verkäufen ihrer Anteile die Zukünftige Entwicklungs sichert.

Genauso wie ARM eine Partnerschaft mit TSMC & GF hat, um ihre Architektur & Fertigung zu optimieren, wird es genauso diese Partnerschaften zwischen GF & AMD geben. Also, muss man nicht gleich Anteils-Eigner sein, um bei der Fertigungs-Entwicklung mitreden zu können. Ganz im Gegenteil: GF braucht auch diese Partnerschaft mit AMD, um eine Fertigung für High-Performance-Chip entwickeln zu können.
 
AMD ist ganz klar auf einen anderen Weg. Unverständlich wie hier ständig AMD mit dem Intel Weg verglichen wird.
Intel wird weiter verkleinern und spätestens bei 10nm ist ist dann eh schluss. AMD setzt auf HSA weil AMD meint erkannt zu haben, dass immer weiter verkleinern nicht die wirkliche Lösung für Effizienz und Leistungssteigerung ist.
Wer einfach mal mehr über HSA wissen will, sollte sich diesen Bericht durchlesen.
http://www.tomshardware.de/fusion-hsa-opencl-Geschichte-APU,testberichte-241088.html
Ist halt schon etwas zeitaufwendig das zu lesen, also nichts für den schnellen Basher ala AMD ist doch eh nur scheiße.
Leute wie Manju Hedge (Ageia-Gründer) und eben der Neuzugang John L. Gustafson zielen genau auf die Entwicklung hin die AMD gehen will und wird.
 
@ AMINDIA

Der Artikel ist interessant, aber auch sehr aus AMDs-Sicht geschrieben. Das ist eine Zukunftsvision, aber es muss nicht unbedingt Realität sein/werden.

Ich würde mein Geld eher nicht darauf wetten, dass HSA die Zukunft ist. Jedenfalls nicht im PC-Segment.

Für ARM ist es vielversprechend, denn bei kleinen Mobilgeräten mit vergleichsweise schwachen CPUs muss die GPU schon heute bei jeder Gelegenheit mithelfen, um ein angenehmes Benutzererlebnis zu liefern.
Aber in diesem Marktsegment würde eher noch der Erzkonkurrent Nvidia von sowas wie HSA profitieren, als AMD, die sich vor Jahren komplett daraus zurückgezogen haben.

Bei PCs mit ausgewachsenen x86-CPUs hat man dieses Problem derzeit eher nicht. Es besteht z.B. wenig Bedarf für GP-GPU, wenn die typische x86-CPU-Leistung schon Overkill für 90% aller Anwendungen ist. Das ist ja das Argument, mit dem die AMD-Fans immer kommen, um die in diesem Bereich hinterherhinkenden APUs zu verteidigen.

Warum sollten sich also Softwareentwickler auf neue Alternativen wie HSA stürzen, wenn keine "Not" besteht, wenn es nicht weh tut? Noch dazu, wenn Intel, die über 80% des PC-Markts dominieren, nicht mit im Boot sitzt?
Erfahrungsgemäß haben es Neuerungen unter solchen Umständen extrem schwer.

Und da wo heute viel GPU-Leistung gebraucht wird (z.B. bei Spielen), ist eine dedizierte Lösung auch in Zukunft zwangsläufig überlegen. Z.B. aufgrund der deutlich besseren Speicheranbindung, die man sich nicht mit der CPU teilen muss, oder der Möglichkeit, auch >100W Verbrauch recht unproblematisch kühlen zu können, was integriert in die CPU nicht möglich wäre usw.

Es gab mal gute Gründe dafür, die Aufgaben der GPU aus der CPU auszulagern. Die sind größtenteils heute noch so gültig, wie in den 80ern und 90ern.

Dass aktuelle GPUs in bestimmten Anwendungen CPUs schlecht aussehen lassen, liegt nur zum Teil an prinzipieller Überlegenheit der GPUs für bestimmte parallelisierbare FP-Berechnungen, sondern auch daran, dass heutige High-End-GPUs auch mal eben ein Vielfaches so groß sind, die High-End-CPUs.
Wenn Intel den Weg geht, die sich durch die ständige Verkleinerung eröffenenden Möglichkeiten unter anderem dafür zu nutzen, den x86-CPUs z.B. mehr parallele FP-Leistung zu verpassen, dann müssen die nicht zwangsläufig hinter GP-GPU-Lösungen zurückstehen.

Wenn man es so sieht, sind die Zukunftspläne von AMD und Intel möglicherweise nicht mal so unterschiedlich. Wo AMD die GPU mit der CPU verschmelzen will, könnte Intel den CPUs die Stärken von GPUs geben und das ohne ohne radikal neue Rechnerarchitekturen und ohne dass die Softwareentwickler dafür auf neue Konzepte wie HSA setzen müssen. Es kommen nur ein paar neue Befehle (z.B. im Bereich AVX) hinzu.
 
AMINDIA schrieb:
AMD ist ganz klar auf einen anderen Weg. Unverständlich wie hier ständig AMD mit dem Intel Weg verglichen wird.
...
Wer einfach mal mehr über HSA wissen will, sollte sich diesen Bericht durchlesen.
http://www.tomshardware.de/fusion-hsa-opencl-Geschichte-APU,testberichte-241088.html
Es ist kein anderer Weg, sondern ein neuer zusätzlich Weg, mit dem AMD den Markt angreifen will.
Da AMD im Gegensatz zu Intel und Nvidia eine führende (führend hießt nicht, vor Intel zu liegen;)) CPU & GPU-Technologie hat, ist es logisch einen neuen Weg mit jenen Technologien zu machen, wo man als einziger eine Technologie auf hohem Niveau hat.

Mit dem Setzten von Neuen Standards kann man besser den Markt dominieren.
AMD hat da viel Erfahrung, da sie ja früher gegen die Centrino-Plattform, Cuda und PhysX ankämpften musste.

Aber was viele nicht erkennnen ist die Entwicklungsgeschwindigkeit die AMD momentan haben kann. Wir sind in einem Thread, in dem die übernächste Architektur der Server & Performance-CPU behandelt wird. Das Problem von AMD war, dass Intel ein viel größeres Entwicklungspotential hatten, wodurch sie bei Core iX mehr Technologien einbauen konnten und mit Larrabee, Itanium & Atom mehr Architekturen entwickeln konnte.

AMD steigt deshalb auf eine automatische statt Handentworfene Architektur-Entwicklung um, was sie jetzt bei Excavator-FPU zeigten. Damit können sie schneller eine effizienitere Architektur entwicklen.

Wie gut eine 100% automatische Entwicklung funktioniert, sieht man bei Jaguar. 2 Jahre nach Bobcat wird Jaguar mit +15% mehr IPC + AVX + AES + SSE 4.x präsentiert. AMD konnte von der automatischen Architektur-Entwicklung von ATI viel lernen.
ARM wird AFAIK auch automatisch entwickelt.

Dazu gab es auch einen Interessanten Bericht, wo die Probleme von der APU-Fertigung erklärt wurden. Das Problem der Fertigung ist, was gut ist für die CPU, ist schlecht für die GPU. Deshalb konnte z.B.: 45nm nicht für eine APU genutzt werden. Bei 32nm hatte man noch zeit, die CPU-Erforschte Fertigung in der Fabriks-Entwicklung auf GPU zu "biegen"/ richten, was länger brauchte und bis dahin Yielde-Probleme hatte.

In den letzten Jahren hatte AMD viele Umstellungen
Own-Fabrik --> Foundry-Fabrik (schneller Fertigungsentwicklung)
Manuelle --> automatische Architekturentwicklung (schnellere Architektur-Entwicklung)
alte dezentierte --> vielseitige Architektur-Entwicklung
(GPU & CPU-Only --> GPU, IP-iGPU, APU, IP-iCPU, CPU)

Die Probleme der alten langsamere & geringeren R&D-Kapazitäten hat AMD in den letzten Jahren sowohl in der Fertigung als auch in der Architektur-Entwicklung "etwas" reduziert.
Dort wo es schon 100% funktioniert @ Architektur & Fertigung funktioniert ist bei GPU & Bobcat-Jaguar bei TSMC.

GF ist zwar schon langsam 100% umgestellt, aber bis man es deutlich sieht, wird noch 1-3 Jahren dauern.
Die Bulldozer-Architektur wird noch Schritt für Schritt auf die automatische CPU-IP umgestellt.

HSA ist jetzt nichts anderes, als dass AMD aus der Vergangenheit des ewingen Technologie-Hinterherlaufen jetzt erstmals in den Angriff zu gehen. Die Klassischen CPU & GPU-Entwicklung laufen ja weiter, welche in Game/Profi-PC und Worktstation & Server weiterhin gebraucht werden. Aber nach der Umstellungsphase läuft die alte klassische CPU-Entwicklung eben viel schneller & Effizienter.

HSA könnte z.B. für die PS4 interessant werden, wenn er laut Gerüchten wirklich Bulldozer + GCN bekommt. Viele wollen aber halt die momentane AMD-Entwicklung nicht sehen und werden erst überstimmt, wenn es später die Zahlen deutlich zeigen. Das war bei Atom in der Atom-Hype-Zeit ja auch nicht anders, wo ich heftig kritisiert wurde, dass Atom zwischen Smartphone & Netbook entwickelt wurde und eigentlich schlecht war.
Erst nachdem AMD im Smartphone-Markt Jahre versagte und Bobcat den Atom demoralisierte verstand es die Masse.

Für AMD war 2012 eigentlich das Jahr des Gleichstands, wo @ GPU die HD7000 das AF-Flimmern, aktzeptierte OpenCL, eine Performance-Krone (Single-GPU), Optimus-Konkurrent Enduro und im HPC-&-Profi-GPU-Markt einen ECC-&-C++ Konkurrenten aufstellen konnte sowie im Notebook-Markt mit Trinity gleichwertige Akku-Zeiten erreicht konnte. 2012 passierten für AMD viele Meilensteine, wo sie nicht mehr Hinterherlaufen mussten.

2013 kommte für AMD klar der Angriff, wo mit Kabini & Kaveri erstmals HSA eingeführt wird und OpenCL-Beschleunigungen erstmals so richtig funktionieren sollte.
Bei Sea-Island ist die spannendste Frage, ob AMD wie in der Vergangenheit zulegen kann und diesesmal Nvidia merklich überholen konn. Oder Nvidia schlägt im Refresh-Jahr wieder etwas zurück.
Steam-Roller wird deshalb interessant, weil es mit der Next-Gen Server-Plattform-Einführung zusammenfällt.
Zwar könnte Kabini Fortschritte im Tablet-Markt machen, aber generell auf einen noch unbeuteden Niveau.

Im Grunde führt AMD nächstes Jahr das ein, was Intel & Nvidia (Next-Gen-CPU und Profi-GPU) und (GK110 und next-Gen Tegra) zusammen einführt und kann an allen Fronten ordentlich dabei sein. Bis auf Smartphone (& Tablet), aber da gibts andere schwere Konkurrenten.
 
Zuletzt bearbeitet:
Ich drück die Daumen für die Jungs von AMD. Macht weiter so und lasst bitte solche Nieten(;)) wie den Bulli in Zukunft aus.
 
Zurück
Oben