Prognose-Board: Wie geht es bei AMD weiter? Entwicklungen / Strategien / Maßnahmen, die AMD betreffen bzw. die AMD treffen könnte

Das wäre ein lösbares Problem, aber AMD kann und/oder will es nicht lösen. Wang hat es vor ca. einem halben Jahr in einem Interview gesagt, dass es das bei Navi nicht geben wird. Jedenfalls für Gaming.
 
Eine Gaming-Vega in 7nm wird nicht kommen.
Ist das schon in "Stein gemeisselt"?
Gibt ja immer noch andere Aussagen, Sinn würde eine 7nm Version auf jeden Fall machen, jedenfalls für mich, da mir die jetzigen zu stromhungrig sind.
Vor allem muss AMD weiterhin Druck auf nv machen, von der Rohleistung her ist die Vega ja nicht weit von der neuen nv Generation entfernt.
 
Wenn überhaupt glaube ich wird es noch sowas wie eine "Frontier Edition" mit einem recht hohen Preis geben. Es gab ja zumindest Hinweise auf eine 16 GB Version neben der 32 GB Version, aber das kann auch genauso gut für eine WX/Pro-Version sein.
 
Der Chip ist an sich der selber nur Lechte Verbesserungen und ein eben ein größeres Speicherinterface und eben in 7nm
 
Genau das trifft auf Vega20 aber nicht zu, Vega20 ist viel viel größer als ein reiner Shrink von Vega20.

Soviel größer ist Vega20 auch nicht. Für DP ein paar mehr Transistoren und 2 HBM Interfaces zusätzlich. Macht nicht das meiste aus.
Vergiss nicht, dass der I/O Bereich nicht gut skaliert.
Zudem ist Vega10 schon mehr auf HPC ausgerichtet und vieles an Board, das bei Gaming nicht benötigt wird.
Macht keinen Sinn das Vega10 Design auf 7nm zu shrinken. Dann schon lieber einen neuen reinen Gaming Chip der mit Navi ja auch bald ( Sommer 2019?) kommt.
 
Das wäre ein lösbares Problem, aber AMD kann und/oder will es nicht lösen. Wang hat es vor ca. einem halben Jahr in einem Interview gesagt, dass es das bei Navi nicht geben wird. Jedenfalls für Gaming.

Er hat meine ich genau gesagt, für NAVI wird es noch nicht kommen.
Und weil hier einige schreiben MultiGPU für`s Gaming sei tot. Ja so wie es bisher war. Extra Treiberanpassungen/Profile etc + Microruckler.
Wir sprechen hier aber von einer technisch anderen Umsetzung. Für das OS wird das eine GPU sein im innern dann aber mehrere GPU chiplets. Das verlagert die Treiberbproblematiken der Vergangenheit in die Hardware.
Microruckler wären in meinen Augen dann zu vermeiden wenn man eine hohe Anzahl Chiplets hätte und diese alle an einem Bild rendern. Dann wären die Bildausschnitte die jeder Chiplet für sich berechnet klein genug so das zwischen nicht so komplexen Bildbereichen und sehr komplexen Bildbereichen keine großen Zeitdifferenzen mehr auflaufen würden und so einfach "gewartet" werden kann aber aufs ganze gesehen keine Ruckler entstehen....

Andere Lösung eine "KI" analysiert die zu berechnenden Bilder und passt automatisch die Bildbereiche dynamisch an die ein Chiplet berechnen soll/muss. Auch so könnte das Delta klein gehalten werden... Die Idee könnte man noch weiter spinnen - nicht ein Bild sondern ein Set aus Bildern analysiert die KI. So kann die Auslastung der Chiplets zur Laufzeit optimiert werden. Im Frame 1 hat Chiplet A einen komplexeren Bildbereich berechnet (hat mehr Zeit in Anspruch genommen) in Frame 2 bekommt es eine einfachere Szene zugewiesen und so wären z.B. nach Frame 2 wieder alle Chiplets im "Takt".
Die Ausgabe erfolgt dann optimiert im Bilderset...

Kurz bezüglich der Technik - ich hatte die Aussage so interpretiert. AMD arbeitet an so etwas definitiv - nur für NAVI wird eine solche Lösung noch nicht kommen. Ich meine auch diese Aussage wurde im Zuge getätigt als vermehrt solche Spekulationen am aufkochen waren.

Ich frage mich ob mit Sony ein neues Feature in NAVI Einzug hält...
 
Zuletzt bearbeitet:
Macht so ein Chiplet-Design, noch dazu mit sehr vielen Chiplets, denn überhaupt Sinn bei Grafikkarten? Die GPU besteht im Gegensatz zur CPU doch aus sehr vielen gleichartigen Recheneinheiten. Der trifftigste Grund wäre die Skalierbarkeit. IO gibts ja nur zum PCIe-Bus und VRAM. Und jedes Chiplet kostet auf dem Interposer Geld, weil es ja miteinander verdrahtet werden will. Das kann man doch schlecht ins Unendliche ausdehen. Bei den Epycs ist ordentlich Geld im Spiel, da kann man das machen.
 
Und jedes Chiplet kostet auf dem Interposer Geld, weil es ja miteinander verdrahtet werden will.

Einen Interposer kann man auch in älteren Nodes (14nm, 22nm usw.) fertigen, ohne dass der Preis oder die Yield-Rate leiden muss.
 
Bei den Epycs ist ordentlich Geld im Spiel, da kann man das machen.

Bei EPYC wird doch kein Interposer verwendet.

Ich habe den Eindruck, du bringst da was durcheinander.
Interposer benötigt man zum Kontaktieren von HBM mit seinen 5000 µBump Kontakten auf 90 mm² und wenn es darum geht viele Verbindungen mit geringem Energieaufwand zwischen den Chips zu realisieren.
Zudem kostet ein passiv Interposer auch nicht das meiste. Hab was von ~ $1,- für Vega gelesen.
Chiplets haben nichts mit Interposer zu tun. Ciplets sind auch nur normale Chips, die halt nur in Verbindung mit anderen Chips ein funktionierendes Ganzes ergeben. Die ca. 100 - 150 Anschlüsse eines ZEN 2 CPU Chiplets lassen sich gut auf normalem Trägermaterial kontaktieren.
 
Einen Interposer kann man auch in älteren Nodes (14nm, 22nm usw.) fertigen, ohne dass der Preis oder die Yield-Rate leiden muss.
In welchem Node auch immer - bei 64 Chips braucht man sicherlich mehr Verdrahtungsebenen.
Ob das Ding nun Interposer, Chipträger oder sonstwie heißt - das Ding halt, wo die Chiplets drauf sind. Mir kam spontan der eine Name in den Sinn, ein anderer Name tut es aber auch.
 
Also der normale Chipträger. Kommt halt darauf an, wieviele Ebenen der haben muß. Bei Threadripper und EPYC hat man ja schon mehrere Ebenen. Bei ROME dürften es weniger sein.
Aber wie kommst du auf 64 Chiplets und dass die untereinander verbunden sein müssen? Irgendwann ist Ende wegen TDP, Komplexität, Größe des Verbindungschips oder des Bus Systems. Muß ja alles noch effizient und rentabel bleiben.
 
Also der normale Chipträger. Kommt halt darauf an, wieviele Ebenen der haben muß. Bei Threadripper und EPYC hat man ja schon mehrere Ebenen. Bei ROME dürften es weniger sein.
Aber wie kommst du auf 64 Chiplets und dass die untereinander verbunden sein müssen? Irgendwann ist Ende wegen TDP, Komplexität, Größe des Verbindungschips oder des Bus Systems. Muß ja alles noch effizient und rentabel bleiben.

Mehr als 4-5 Chip lohnen sich nicht zumal der leistungsunterschied zu gross wird und auch Massen GPU mit mehrere Dies benötigen würden.
 
Macht so ein Chiplet-Design, noch dazu mit sehr vielen Chiplets, denn überhaupt Sinn bei Grafikkarten? Die GPU besteht im Gegensatz zur CPU doch aus sehr vielen gleichartigen Recheneinheiten. Der trifftigste Grund wäre die Skalierbarkeit. IO gibts ja nur zum PCIe-Bus und VRAM.
Es gibt auch noch die Radeons mit SSD onBoard.
 
Macht so ein Chiplet-Design, noch dazu mit sehr vielen Chiplets, denn überhaupt Sinn bei Grafikkarten?

Ich würde sagen ja (es ist die selbe Funktionsweise wie MultiGPU Systeme schon praktizieren - nur mit dem Vorteil das gewisse Probleme im system eine Ebene nach unten wandert und so keine Effekte mehr auf Treiber-Ebene etc. zu beachten sind).
Die Aufgabe der GPU sind meist hoch parallelisierbar. Der Vorteil aus AMD Sicht wäre ja wie bei CPU Chiplets gegeben. Man hat eine Maske aber dank 1/2/4 Chiplets Produkte für die verschiedenen Leistungsklassen. [weiterer denkbarer Anwendungsfall man hat ein Lowpower GPU Chiplet und Power GPU Chiplet - so könnte man für Mobile in einer GPU den Desktop betrieb super "günstig" (bezogen auf Energieverbrauch) fahren - bei benötigter Leistung arbeiten die beiden dann zusammen]
Und auch bei GPU`s wird man nicht beliebig die GHZ weiter nach oben treiben können.

Und ob es so viele sein müssen ist die Frage. Denn wenn man pro Bild arbeitet müssen die Bereiche ja "nur" hinreichend klein werden damit das zeitliche Delta der Berechnung dieser Bereiche klein genug wird um nicht in die Mikroruckler-Problematik zu kommen.
Und bei Contentherstellung wird der Vorteil riesig in meinen Augen. Das wird ja heute schon praktiziert. Jede GPU/CPU rendert ein Frame...
 
Aber wie kommst du auf 64 Chiplets und dass die untereinander verbunden sein müssen? Irgendwann ist Ende wegen TDP, Komplexität, Größe des Verbindungschips oder des Bus Systems. Muß ja alles noch effizient und rentabel bleiben.
Ich habe nur "sehr viele" in eine Zahl verwandelt. Die Idee mit "sehr vielen" Chiplets stammt nicht von mir.
OK, sie müssen natürlich nicht alle jeweils mit allen kommunizieren, aber irgendwohin müssen die Daten ja schon wandern innerhalb der GPU, und das möglichst schnell.
 
Eine GPU zerteilen stelle ich mir dann doch etwas einfacher vor. Man braucht ja nur den "Arbeitsaufteiler" im großen IO-DIE unterbringen und der allein muss wissen, wie er die Aufgaben verteilt. In dem Fall kann es egal sein, ob ein Chiplet einen oder 256 Shader hat; sie bekommen einfach die Arbeit zugeteilt, rechnen dran herum und geben sie wieder zurück.
Und der "Arbeitsaufteiler" müsste dann nur noch die gerechneten Ergebnisse wieder zusammensetzen.

Wenn ich die Funktion der Grafikshader nicht völlig mißverstanden habe, ist wohl kaum Kommunikation zwischen den (Shader-)Chiplets notwendig.
 
Niedriger Spannung wer gut bei 1500mhz läßt sich mal eben 30% Energie Einsparn wenn man selbst Hand Anleget
 
Einerseits gibt es die Gerüchte über Ryzen-3000 von Adoredtv. Aber andererseits ist es sehr ruhig um AMD.

Mal vorneweg: wenn AMDs neue Ryzen-3000 wirklich so gut werden sollten, warum sollte AMD das alles schon am 9.1.19 auf der CES verkünden? Damit würden sie ihre guten Verkäufe der aktuellen Ryzen-2000 kaputt machen, weil AMDs Ryzen immer noch extrem vom DIY-Markt lebt. Entweder die Ryzen-3000 stehen vor der Türe (was ich bezweifle) oder es wird nicht viel Infos dazu am 9.1.19 geben.

Zur Roadmap für den Ryzen-3000:
1) Eigentlich sollte das Desktop-7nm-Die für Ryzen-3000 von Globalfoundries kommen. Die Aufgabe des 7nm-Prozesses von GF dürfte die ursprüngliche Zeitplanung eher nach hinten verschoben haben, also in Richtung H2-2019, wenn nicht noch später. Wollte man beim urspünglichen Ansatz bleiben, wäre wohl eher eine zusätzliche Verzögerung zu erwarten.
2) Andererseits hat TSMC nun unerwartet 7nm-Kapazitäten für H1-2019 frei, weil die Orders der neuen 7nm-Mobilephone-SoCs gekürzt wurden, sodass AMD nun mehr ordern könnte und die zusätzlichen Wafer womöglich sogar günstiger wären. Aber welche Designs hat AMD bereits fertig, die man sofort ordern könnte? Bisher sind nur das etwa 75mm² kleine Epyc2-Die sowie das 331mm² große Navi-20 Die bekannt.
3) Da Epyc-2 noch in der Validierungs-Phase ist, dürfte er für frühzeitige, große Orders ausfallen. Das 331mm² große Navi-20 Die dürfte auch nicht sehr interessant für große Orders sein: es ist viel zu groß für die anfängliche 7nm-Produktion mit hoher Defect-density und ist nicht für Gaming optimiert; zuletzt würden wohl die nötigen Treiber zu lange fehlen.

Nehme ich aber den Gedankengang von Adoredtv mit dem Chiplet-Ansatz auf, sehe ich ein mögliche Option: sollte sich das Zen2-Chiplet für Epyc doch einigermaßen gut takten lassen (es ist ja angeblich auf Effizienz getrimmt, und nicht auf Takt), könnte AMD dann nicht womöglich seine Strategie um eine Option ergänzen, und evtl. doch entsprechend dem Gedankengang von Adoredtv nun frühzeitige Highend-Ryzen-3000-CPUs (mit bis zu 16Cores aber weniger guter Latency) auf Basis dieser Chiplets planen? Die Chiplets sind fertig entwickelt und könnten womöglich nun weit billiger von TSMC zu haben sein, als ursprünglich geplant. Das große I/O-Die für Epyc-2 sollte sich relativ schnell für Ryzen-3000 anpassen lassen: ein Design zu stutzen geht ungleich schneller, als eine neue Umsetzung; zumal könnte für erste Exemplare womöglich gar das 435mm²-große I/O-Die verwendet werden, bis die kleine Variante fertig ist. Man bedenke: die aktuellen Ryzen benutzen für Desktop und Server das selbse Die. Warum nun anfänglich für Ryzen-3000 nicht den gleichen Ansatz?

Bezüglich der widersprüchlichen Gerüchte hierzu, die von einem monolithischen Die sprechen: ein monolithisches Die war vermutlich ursprünglich für Ryzen-3000 bei GF geplant, um maximale Takte uns niedrige Latenzen zu erzielen. Ich bezweifle, dass der Entwicklungsstand bei TSMC für ein solches Die weit genug ist. Die große Frage wäre deshalb, ob der Ansatz mit den bereits verfügbaren Zen2-Chiplets für Epyc Sinn ergeben könnte? Dieser Ansatz mag womöglich erst für den Nachfolger von Raven-Rigde und womöglich auch für die kommenden Konsolen geplant gewesen sein. Aber warum nicht doch jetzt schon was für Desktop auf diesem Ansatz bringen, wenn man damit doch gute Multicore-Ryzen-3000 hin bekäme. Speed-optimierte Ryzen-3000 auf der Basis eines monolithischen Dies für Gaming kann man ja dann immer noch parallel auf den Markt bringen, da ich davon aus gehe, dass Ryzen-3000 vermutlich dann sowieso auf verschiedenen Dice aufbauen dürfte: die kleinen Versionen von Ryzen-3000 werden vermutlich auch noch länger auf dem aktuellen Zen+-12nm-Die basieren, ganz einfach aus Kostengründen und um auch GF weiter auszulasten.
 
Zuletzt bearbeitet:
@BR
1) Wann sollten denn die 7nm von GF ursprünglich kommen? Waren doch erst für Ende 2019 in Planung.
2)
Bisher sind nur das etwa 75mm² kleine Epyc2-Die sowie das 331mm² große Navi-20 Die bekannt.
Du meinst das 7nm CPU-Chiplet und VEGA-20.
3) Mach dir keine Gedanken wegen Yield bei GPU. Da kann man mit "Reserve" Shader einiges retten.

Das große I/O-Die für Epyc-2 sollte sich relativ schnell für Ryzen-3000 anpassen lassen: ein Design zu stutzen geht ungleich schneller, als eine neue Umsetzung; zumal könnte für erste Exemplare womöglich gar das 435mm²-große I/O-Die verwendet werden, bis die kleine Variante fertig ist.
Der große EPYC I/O hat sicherlich einige Funktionen zur Speicher und Cacheverwaltung drauf, die für 2 Chiplets mit 16 Kernen nicht notwendig sind.
Aber schau dir mal einen Summit Ridge bzw. Pinnacle Ridge an. Der hat schon alles drauf und sogar noch 2 IF Links und 2 CCX zuviel. Im Prinzip könnte man SR oder PR mit deaktivierten Kernen direkt als I/O verwenden.
Der Große EPYC I/O kann für AM4 nicht verwendet werden. Der ist ja schon fast größer als der AM4 Sockel. Da ist auf AM4 schlicht kein Platz für den großen I/O und Chiplets vorhanden.

Als aktuell einfachste Lösung fällt mir RavenRidge2018 ein.
RavenRidge auf 24 PCIe Lanes und um 2 zusätzliche IF Links erweitert.

Durch die Massenproduktion wird dieser recht günstig. Voll Funktionsfähige Chips gehen in Notebooks, AIO, embedded und billige Einsteiger APUs.
Teildefekte Chips mit zu großen Fehlern in GPU Bereich können als 4 Core CPUs abgesetzt werden.
Teildefekte Chips mit zu großen Fehlern im CPU Bereich können als I/O für Ryzen3000 APUs verwendet werden.
Selbst Chips mit bei denen nur der I/O Bereich noch funktioniert können für reine Ryzen3000 CPUs verwendet werden.

Demnach ergäbe sich folgendes Linup:
RavenRidge (Picasso) als 2/4 Core APU
RR + Chiplet als 6/8 Core APU
RR + 2 Chiplets als 12/16 Core APU (CPU?)

Inwiefern AMD den GPU Teil beschneidet muß sich zeigen, hängt von TDP und Bandbreite ab. Bei Verwendung einer dedizierten GPU sollte die IGP aber nicht stören, da diese dann abgeschaltet wird.

Vorteile:
Kein weiterer Chip für I/O notwendig, geringer zusätzlicher verifikations Aufwand.
Hoher Yield da fast alles verwendet werden kann.
8 Core 7nm APU sollte fast doppelte Performance wie single Chip 4 Core 12nm APU haben bei gleichem Verbrauch.
Effiziente 6/8 Core Mobile APUs.
APU 2 - 16 Kerne im AM4 Format.
Günstig in Massen herstellbar.
Schnell verfügbar.

Nachteile:
Höhere Latenz durch Chipletdesign.
 
Ich kann mir gut vorstellen, dass AMD in den kommenden Jahren auch Samsung als Foundry etablieren wird.
Erst kürzlich hat IBM bekannt gegeben, dass es u.a. seine Power Prozessoren demnächst in 7nm EUV Technologie bei Samsung fertigen lassen wird.
Vermutlich kommt AMD ein zweites Standbein neben TSMC sehr gelegen. Sonst hätten letztere ab 7nm keine Konkurrenz zu befürchten und könnten quasi die Preise diktieren. Möglicherweise fordern bestimmte Kunden (Konsolen) auch einen zweiten Hersteller.
Mit IBM und seinen fetten HPC-Chips als Kunde ist klar, dass Samsung auch für AMDs CPUs und APUs geeignet ist.
Mal sehen, was aus AMDs Wafer-Abnahmevertrag mit Globalfoundries wird. Ich vermute, dass der sich mit der Zeit in Luft auflöst, wenn Globalfoundries den Bedarf in den entsprechenden Nodes unterhalb von 12nm ohnehin nicht decken kann.

Technologisch sehe ich demnächst fd-SOI wieder im Spiel, allerdings nicht für die CPU-Chiplets sondern für deren Träger, der u.a. das IO beinhaltet. Intel will seinen Träger auch mit einem leistungsarmen Prozess (22nm FFL) fertigen. Es könnte für AMDs Serverprozessoren sinnvoll sein, von einem 14nm bulk Prozess auf einen 22nm (Globalfoundries) oder 18nm (Samsung) fd-SOI Prozess umzuschwenken, der sparsamere und möglicherweise auch günstigere Träger ermöglicht.
MfG
 
Fordern kann man ja recht viel.
Nur wenns halt keinen weiteren Hersteller gibt wird man sich recht schwer tun...
Unterschiedliche HErsteller bedeutet ziemlich sicher auch unterschiedliche Masken. Was für AMD teurer ist.
 
Zurück
Oben Unten