News Intel Meteor Lake: Grafikeinheit bekommt L4-Cache, CPU-Teil exklusiv den L3

[ETI1120]

In der Regel behält TSMC die alten Fertigungslinien bei. Das sieht man ja an der Grafik mit der Einnahmeverteilung.

Es gibt natürlich Ausnahmen.
20 nm war die letzte Generation mit Planartransistoren. Als TSMC FinFet eingeführt wurde, hat TSMC 20 nm mit FinFet als 16 nm bezeichnet. Es gibt aber immer noch ein sehr geringes Volumen mit 20 nm.

Die 10-nm-Fertigung war von Anfang an als kurzfristiger Zwischenschritt auf 7 nm geplant. Hier wurde das Equipment für 7 nm weiterverwendet. Nur Apple hat größeres Volumen auf 10 nm fertigen lassen, aber auch hier gibt es immer noch ein sehr geringes Volumen.

Soweit ich es verstehe plant TSMC die Kapazitäten für 7 nm, 5 nm und 3 nm beizubehalten, aber es werden dann andere Produkte mit diesen Fertigungsanlagen in der selben Strukturbreite hergestellt. Dafür werden dann auch neue Spezialitätenprozesse entwickelt.

Zum Thema Fertigungsstraßen. Ich denke nicht, dass man sich eine Halbleiterfertigung als Fließbandfertigung vorstellen kann. Es gibt AFAIK keinen linearen Ablauf durch die Fertigung. Das wäre auch schwer zu realisieren, weil die einzelnen Teilprozesse, wie z. B. Lithografie, Ätzen oder Abscheidungsprozesse verschiedene Zeitkonstanten haben. Die Prozesse werden auf Auslastung des Equipments optimiert und nicht auf kurze Durchlaufzeiten der Chips. So viel ich weiß verbringen die Chips die meiste Zeit im Herstellungsprozess mit warten.

 

[[wege]mini]

Alle Halbleitertechnik bewegt sich an der Oberfläche der Siliziumscheiben.

Und was man baut, kann man stapeln. Ohne Hochhäuser, wären moderne Großstädte nicht einmal denkbar.

ist das ganze ohne L4-Cache 2.5D und mit L4-Cache 3D.

So habe ich das auch verstanden und meine Meinung dazu, zum Ausdruck gebracht.

mfg

p.s.

Oder was glaubst du, wer in einem Hochhaus wohnt? Das sind weder P noch E Cores. Das ist Cache.

 

[CDLABSRadonP...]

Kannst Du mir bitte erklären wo das Problem sein soll mit dem liefern können?

Die beiden Abschnitte gehörten zusammen:

Ich bin mir ziemlich sicher, dass es umgekehrt ist. AMD füllt die Portfoliolücken, um überhaupt genügend liefern zu können.

Was oft vergessen wird: Das aktuelle Portfolio wurde vor dem Hintergrund der zweiten Miningkrise gebaut. Entsprechend wichtig war es auch, bzgl. Nodes mehrgleisig zu fahren. Und das hat AMD geschafft. Egal welcher Node knapp werden sollte, irgendwas hätten sie immer noch anbieten können.

Jetzt ist das ziemlich wurscht; aber es war halt wahrscheinlich Teil der Entscheidungsgrundlage.
Darüber hinaus ist es halt gut, etwas anbieten zu können, wenn die nächste Entwicklung sich verzögert. Und Phoenix hat sich dann ja auch in der Praxis verzögert.

 

[Piktogramm]

Joa gute Punkte, könnte alles irgendwie passen. Das mit L3 und CPU only weil auf einem Chip dachte ich mir auch schon. Die Frage ist halt wirklich, wo der L4 sitzt. Im GPU-Die vermutlich nicht, würde den aufblähen und weil er in teurer Fertigungsstufe kommt,ä zu teuer machen weil zu groß. Also bleiben ja nur noch 2 Sachen: SoC oder Base. Die Base Tile war bisher immer der, der die schlechteste Fertigungsstufe hat, da braucht es nicht das beste. Genau hier wäre für kostengünstige Lösung ein L4 ziemlich gut aufgehoben. Im SoC weiß ich nicht, auch der ist meist nicht State-of-the-Art gefertigt, aber he, mal sehen was sie zaubern.

Ich habe irgendwie nicht mitbekommen, dass es hier weiterging..
Nach den Patenten die hervorgekramt werden, scheint der L4 im Base-Tile untergebracht zu sein (wenn vorhanden). Das hatte ich als unrealistisch verworfen. An sich könnte das BaseTile mit passiver Vertratung und ein paar Induktiven, wie kapazitiven Elementen günstig in >=45nm gefertigt werden (reine Vermutung). Wenn das BaseTile aber Sram vorhalten soll muss dieses riesige Die durch deutlich modernere und viel teurere Prozesse durch. Denn auch wenn Sram nicht so gut mit den kleineren Prozessnodes skaliert, ohne EUV geht auch bei DDR5 nichts mehr:
https://www.techinsights.com/blog/s...m-euv-lithography-euvl-memory-techstream-blog

So ein riesiges Die durch einen EUV Prozess zu schleusen wird unglaublich teuer. Ich kann mir kaum vorstellen, dass das so im Massenmarkt landet.

@Piktogramm
Du schreibst von letze chance einen Cache Treffer bei l4 zu haben. Wie sieht es denn aus wenn ne Anwendung von sich aus ne sehr niedrige missrate von l1 zu l2 schon hat und damit ne sehr hohe hitrate. Wie wird es dann weiter gehen von l2 zu l3 und dann l4 wenn dazwischen ebenso ne super hitrate ist. Wird das dann immer weniger Wirkung zeigen die höhere Ebene dann?

Das ist von Anbeginn der CPU-Caches das Selbe Lied. Caches sind immer viel kleiner als der Hauptspeicher, können also komplett zufällige Zugriffsmuster nicht kompensieren. Bei Zugriffsmustern, die perfekt vorhersagbar sind und dank Prefetch 100% Trefferrate erreichen braucht es auch nur kleine Caches und ein guter Teil liegt ungenutzt rum. Bei allen Zugriffsmustern dazwischen tauscht man Flächenbedarf, Kosten, Energiebedarf für Caches gegen Performancevorteile bei Cachetreffern.
Gut sieht man das bei den 3D Caches von AMD CPUs. Bei Aufgaben die vom Zugriffsmuster her sehr lokal und gut vorhersehbar laufen wie zB 7zip bringen die Caches kaum etwas. Bei Spielen hingegen bringt es viel.

Und wenn man nun das ganz noch verschärft mit 2 x die selbe Anwendung. Schmeißt dann die erste die Infos der zweiten dann aus dem Cache raus oder was passiert in diesen Fall dann? Weil ist ja nicht viel langsamer geworden von 1 auf 2 gleiche Anwendung.

Ich habe gerade keine Ahnung, wie welche CPU mit welchem Betriebssystem wie ihre Caches verwaltet. Sehr vereinfacht war bei Spectra/Meltdown ja auch ein Problem, dass die Speicherbereiche verschiedener Prozesse im Cache vorgehalten wurden. Sodass entsprechend lesender "Speicherzugriff" über Prozessgrenzen (verschiedene Anwendungen) hinweg möglich war. Eine Möglichkeit das zu unterbinden war es die Caches und TLBs zu fluschen. Also den Speicherzustand einer Anwendung komplett aus den Caches zu kegeln. Damit kann man das Problem vermeiden, bei Wechsel zwischen Prozessen (Kontextwechsel) geht da aber extrem viele Prozessorzyklen sinnlos ins Land. Wie es aktuell gemacht wird entsprechenden Datenabfluss zu vermeiden, ohne bei jedem Anlass Caches und TLBs zu vermeiden weiß ich nicht.

Ist zudem ebenso die Frage wie sich das ganze mit dem cache und der onboard gpu und deren Aufbau sich so auswirken wird.

Tendenziell immer gut, jedoch mit bekannten Grenzen je nach Anwendungsfall. Da kann man ja auch wieder auf AMD zeigen. Die RDNA3 Karten sind ja auch ganz gut unterwegs, bis die lokalen Caches für den Anwendungsfall zu klein geworden sind.

 

[ETI1120]

Ich habe irgendwie nicht mitbekommen, dass es hier weiterging..
Nach den Patenten die hervorgekramt werden, scheint der L4 im Base-Tile untergebracht zu sein (wenn vorhanden). Das hatte ich als unrealistisch verworfen. An sich könnte das BaseTile mit passiver Vertratung und ein paar Induktiven, wie kapazitiven Elementen günstig in >=45nm gefertigt werden (reine Vermutung).

Das Gute am Base Tile ist, dass es relativ klein ist.
Ganz billig wird das Teil nicht, da TSV benötigt werden.

(Hot Chips 34)

Mit SRAM werden ein paar Prozessschritte mehr notwendig sein, als nur mit TSV, Kapazitäten und Metallisierung. Da auf dem Base Tile sehr viel Platz ist, spielt es keine Rolle, ob die SRAM-Zellen ein bisschen größer auffallen. Also sollte es kein Problem sein, wenn Intel auch für die Variante mit Cache den Intel 16 Prozess einsetzt, der für das Base Tile geplant ist
https://www.computerbase.de/2022-08/meteor-lake-tsmc-baut-mehr-chips-als-intel-fuer-next-gen-cpu/

Denn auch wenn Sram nicht so gut mit den kleineren Prozessnodes skaliert, ohne EUV geht auch bei DDR5 nichts mehr:
https://www.techinsights.com/blog/s...m-euv-lithography-euvl-memory-techstream-blog

Samsung hat EUV Prestige-Projekte gefahren. So richtig Nutzen hat es Samsung nicht gebracht. Die DRAM -Konkurrenz verwendet AFAIK noch kein EUV.
Siehe auch:
https://www.computerbase.de/2022-11/dram-fertigung-micron-fertigt-ohne-euv-als-erster-1-chips/

So ein riesiges Die durch einen EUV Prozess zu schleusen wird unglaublich teuer.

TSMC hat bei N6 EUV eingeführt, um die Kosten zu senken. Mit EUV werden weniger Masken als mit DUV benötigt. Intel wird erst bei Intel 4 EUV einsetzen, also nicht für den Base Die.

Ich kann mir kaum vorstellen, dass das so im Massenmarkt landet.

Die Chips mit L4-Cache werden in guten Business-Notebooks laden. Da werden auch ordentlich Stückzahlen verkauft. Nur landen diese Geräte nicht bei Media Markt.

 

[latiose88]

Gut sieht man das bei den 3D Caches von AMD CPUs. Bei Aufgaben die vom Zugriffsmuster her sehr lokal und gut vorhersehbar laufen wie zB 7zip bringen die Caches kaum etwas. Bei Spielen hingegen bringt es viel.


Ich habe gerade keine Ahnung, wie welche CPU mit welchem Betriebssystem wie ihre Caches verwaltet. Sehr vereinfacht war bei Spectra/Meltdown ja auch ein Problem, dass die Speicherbereiche verschiedener Prozesse im Cache vorgehalten wurden. Sodass entsprechend lesender "Speicherzugriff" über Prozessgrenzen (verschiedene Anwendungen) hinweg möglich war. Eine Möglichkeit das zu unterbinden war es die Caches und TLBs zu fluschen. Also den Speicherzustand einer Anwendung komplett aus den Caches zu kegeln. Damit kann man das Problem vermeiden, bei Wechsel zwischen Prozessen (Kontextwechsel) geht da aber extrem viele Prozessorzyklen sinnlos ins Land. Wie es aktuell gemacht wird entsprechenden Datenabfluss zu vermeiden, ohne bei jedem Anlass Caches und TLBs zu vermeiden weiß ich nicht.


Tendenziell immer gut, jedoch mit bekannten Grenzen je nach Anwendungsfall. Da kann man ja auch wieder auf AMD zeigen. Die RDNA3 Karten sind ja auch ganz gut unterwegs, bis die lokalen Caches für den Anwendungsfall zu klein geworden sind.

Ok habe auch ich schon gemerkt gehabt.In der hinsicht schein ein Videoumwandlungsprogramm auch so sich zu verhalten wie dein Beispiel von 7Zip
Das erklärt auch die geringe Missrate von L1 zu L2 Cache aber auch da scheint es wohl grenzen zu geben.Wo es zwischen l1 und l2 Cache keine Vorteile mehr gibt und auch von 32 auf 64 MB beim L3 Cache auch keinen Unterschied gibt,ist es spätestens zwischen 16 und 32 MB aber wieder anderst.Hier verliert dann die CPU dann doch an Leistung.Ich dachte ja das L3 Cache keinen Nutzen davon zieht weil die geringe Missrate ja dann nicht mehr abhängig vom L3 Cache wäre.Dem scheint es aber doch nicht zu sein.Es kann also wohl so gute Missraten zu haben wie es will,indirekt ist es dann doch vom L3 Cache abhängig.

Wie verhält es sich bei 2 gleichen Programmen.Werfen die sich gegenseitig aus dem Cache raus oder wird gleiche Arbeiten effizient zusammen gelegt und woher wissen die beiden gleichen Programme welcher Inhalt wo gespeichert wird und wie machen die das das keine Fehler dadurch entstehen?
Und mir ist aufgefallen das 2 gleichzeitig dann doch ne kleine Zeit beim Umwandeln kostet.
Bei einen 8 Kerner kostet es 50 % an Leistung und beim 16 Kerner so um die 25% an Leistung.Ist das also dem Cache geschuldet und kann man sowas auch auf 0 Optimieren oder wird kein CPU Hersteller diese Limits umgehen können weil die Schuld an die Programme liegt.

Oder woran erkennt man von was die Leistung einbricht.Von der Software oder von der Hardware.Bei GPU kostete 2 gleichen Programme gleichzeitig ebenso an Leistung.Also kann man sagen es liegt an der Software?
Und ich gehe dann davon aus das man zwar die Leistungskosten reduzieren kann,aber halt nicht auf 0.Es sei denn die CPU Hersteller machen ne CPU so breit,das man das ebenso machen kann.

Wobei ich habe gelesen Apples CPU könne das ohne Leistungsverlust packen.Warum weil die CPU so breit ist,das diese ja eh mehr gleichzeitig machen könne ohne Leistungverluste.Wobei so ein direkter Test mit Zeitmessung ich so noch nicht gesehen hatte.Nur einfach mal auf die schnelle kurz getestet mit einem Programm mehrere gleichzeitig an Videos aber nicht 2 x der selbe Prozess einer selben Anwendung.

Ich bin gespannt ob dann L4 Cache ich auch Profitiere.Wenn schon das mehr an L3 Cache keine wirkung zeigt,dann mal sehen wie es mit L4 Cache so aussehen wird.Erwarte jedoch keine Welten weil der Nutzen beim Ram ebenso immer weniger wird.Vielleicht gibt es da ja tricks um noch mehr herauszuholen wer weis.

 

[Volker]

Das Gute am Base Tile ist, dass es relativ klein ist.
Ganz billig wird das Teil nicht, da TSV benötigt werden.

Bei Intel darf man immer nie vergessen, wie sie ihre Fabriken auslasten. Früher war es immer so, wenn die CPUs in eine neue Fertigung gehen, rücken Chipsätze usw nach. Sodass ältere Fabs immer ausgelastet waren. Das Kartenhaus brach von 22 zu 14 und dann zu 10 nm halt total zusammen, weil sich oben alles verzögerte, wurde es hinten knapp. Doch die alten Fabs gibt es ja weiterhin, einige wurden aufgerüstet, aber längst nicht alle. Und Fabs die nix oder nur ein wenig machen kosten auch Geld.

Bei Lakefield hat Intel die Base Tile in 22FFL gefertigt, was quasi eine Mischung aus 22 und 14 nm ist - aber im Kern hat trotzdem viele Jahre alt ist. Darauf haben sie dann 10 nm gesetzt. Und das ist für sie je nach Fab-Lage dann auch heute eine Option. Denn sie wollen als Foundry ja auch Intel 16 oder sowas anbieten, also richtig oldschool Zeugs. Der Chiplet/Tile-Ansatz bietet eben halt viele Optionen, am Ende könnte selbst GloFo irgendwas bauen, wenn sie die günstigsten im Markt sind, TSMC ist der teuerste, aber die brauch man eben für das beste

 

[Oberst08]

@Volker : Auf dem Bild sind 12 Gen4 PCIe Lanes angegeben. Bedeutet das, dass MTL nur für den Ultra Mobile Bereich gedacht ist? Denn eigentlich hat man ja immer 8 Lanes für die GPU, dann würden aber nur noch 4 Lanes über NVME bleiben, man könnte daher keine zweite NVME verbauen.
Das würde dann auch erklären, warum Desktop Modelle auf der Generation wenig Sinn machen, Intel scheint hier voll auf die kleinen und mobilen Geräte zu zielen. Und bei denen hatte man ja schon früher auch Geräte mit einer kleinen dGPU mit 4 Lanes Anbindung (damit würden dann ja auch genügend Lanes für 2 NVME bleiben).

 

[DevPandi]

Mit LPDDR5 Dual Channel 128 Bit kommt eine performante GPU aber nicht weit.

Nein, weit kommt sie damit nicht. Wir reden hier aber nicht von performanten GPUs, sondern in der Regel von APUs, die in Notebooks verwendet werden und dort die Einstiegsklasse sowie ggf. die untere Mittelklasse kanibalisieren soll.

Bei GDDR6x hat mal 20 statt 8 Gb/s je Pin, das als 96 Bit Interface plus Infinity Cache statt an 128 Bit DDR5 bringt etwa Faktor 2 an Bandbreite.

Gleichzeitig benötigt GDDR6X deutlich mehr Energie als LPDDR5-RAM, dazu kommen andere Probleme bei einer APU.

Genoa-X vs. SapphireRapids+HBM wird wohl abermals so dastehen.

Wobei man nicht vergessen darf, dass SapphireRapids+HBM wohl eher gegen eine Mi300 antreten darf. Zudem zeigt das, dass auch AMD an "ähnlichen" Konzepten arbeitet, was man später bei den APUs bringen kann: Basetile und darauf angesetzt CPU, GPU und Co.

Die Frage ist am Ende, welche Kosten es verursacht und ob man daraus dann direkt einen nutzen zieht.

Da hilft auch L4 eDRAM nicht viel weiter ...

Tut er nicht? Seltsam, du erwähnst selbst den Infinity Cache, der eben sehr wohl dabei hilft, dass man das SI "schmaler" auslegen kann, da der Cache Anfragen abfangen kann. Es hat ein paar Gründe, warum Intel hier den L4 einbringt, warum AMD bei RDNA den Infinity Cache (aka L3 (verkappter L4)) integriert hat und warum NVIDIA bei Ada den L2-Cache drastisch hat anwachsen lassen.

Intel hat zudem vor Jahren schon vergeblich eDRAM integriert.

Vergeblich? Da würde ich dir mal empfehlen dir die verschiedenen Tests durch zu lesen und wie die Iris Pro-Modelle im Vergleich zu den normalen Iris-Modellen abgeschnitten haben und ebenso auch dir mal die Tests zu den "Desktop-Ablegern" an zusehen, die mit einem massiven Taktmalus in bestimmten Szenarien dennoch sehr gut mithalten konnten. Der 5775C konnte bei der GPU damals die APUs von AMD schlagen, was alles andere als "üblich" war. Und ebenso konnten die Prozessoren mit deutlich höher takenten Modellen mithalten bei Spielen, weil der eDRAM die Abhängigkeit vom RAM minimiert hatte. Dazu waren die Prozessoren sehr effizient.

Das Hauptproblem damals - wie auch heute: Es gibt immer einen Kosten-Nutzen-Analyse und man wählt den Weg, der bei den geringsten Kosten die beste Leistung liefert und ich meine in diesem Fall nicht Geld.

Natürlich konnte AMD und Intel auch APUs designen mit einem eigenen RAM-Controller für die GPU, hat nur ein paar Nachteile, weil damit die Komplexität der APU stark ansteigt, dazu steigt die Komplexität des Sockels und ebenso der Layouts für Mainboards. Dazu kommen dann extra kosten für weitere RAM-Bausteine, die aufgelötet werden müssen,

Dazu würde in diesem Fall ein Vorteil wieder elemeniert, der Leistung bringen kann und auf den AMD, NVIDIA, Intel aber auch MS und Co hinarbeiten: Unified Memory. Der große Vorteil von den APUs ist, dass viele Daten sowohl im VRAM als auch RAM vorliegen, weil sowohl GPU als auch CPU immer wieder daran etwas machen müssen und das abgelichen wird. AMD hat mit "SAM" - oder eben der PCIe2.1/3.0 Spezifikation zum "64-Bit"-Adressraum - dort bereits eine Hürde beseitigt für sich. NVIDIA ist nachgezogen und Intel hat von Anfang an ihre Architektur auf "SAM" ausgelegt. Unter DX12 kommen jetzt die Funktionen, dass man nur noch ein Abbild im VRAM hat.

Und auch ein "kleines" GDDR6-Interface mit Infinity-Cache und dann noch den normalen RAM-Controller bringt an der Stelle nicht viel, weil erneut die Komplexität steigt und das an zwei Stellen. Man hat den L4/Infinty Cache und zwei unterschiedliche RAM-Controller. Und ich verschweige an der Stelle mal die ganzen Probleme, die das auf dem internen Bus auslöst.

Intels Ansatz hier einen L4-Cache und bei AMD ggf. später in den APUs einen Infinity-Cache vor den RAM-Controller zu setzten, sind eine gute Methode, um den Bandbreiten-Bedarf zu reduzieren und haben gleichzeitig den Vorteil, dass man auch Energie spart - das sieht man gut an den 5800X3D und 7800X3D sowie 7950X3D (der 7900X3D existiert nicht).

Eigene Controller für GPU und CPU-Teil sind kontraproduktiv und lassen die Kosten bei der Komplexität stark ansteigen bei gleichzeitig nur geringem nutzen.

Denke RDNA4 könnte es werden.

Nein, ganz ehrlich, so sehr ich auch meine 7900 XTX mag und so sehr ich AMD mag: RDNA4 wird sicher eine gute GPU, aber sie werden höchstens mit NVIDIA gleichziehen in der nächsten Generation, sie "schlagen", daran glaube ich nicht und dafür gibt es mehrere Gründe.

Der Umbau der CU zu Vec32+32/Vec64 bei den CU war notwendig, man sieht aber - ebenso wie Ampere und auch jetzt Ada, dass hier vieles noch Zukunftsmusik ist und die effektive Auslastung erst mit 1440p und 2160p wirklich "zu nimmt". Ampere, Ada und RDNA3 "lieben" hohe Auflösungen. Es müssen hier viele Daten für die selben Operationen zusammen kommen für die optimale Auslastung. AMD hat hier einen "kniff" gefunden, dass RDNA3 auch mit "weniger" Daten gut ausgelastet werden kann (Unabhängige Operationen innerhalb des gleichen Tasks), ist hier aber weiter auf das Compiler-Team angweisen, da wir quasi wieder ein VLIW2-Konzept haben. RDNA3 ist viel Zukunftsmusik und ebenso wie NVIDIA bei Ada bei der "RT-Performance" auf die Entwickler angewiesen ist, dass diese ihre RT-Shader für SER aufbereiten und optimieren, ist AMD darauf angewiesen, dass Entwickler ihre Shader so entwickeln, dass der Compiler möglichst viele Optimierungen darauf anwenden kann.

Ebenso hat AMD bei RT einiges an Hausaufgaben zu machen, sie haben vieles bei RDNA3 verbessert, aber eben noch nicht genug und sie müssen einen Weg finden, wie der Ansatzt aus TMU + RT-Kern möglichgst effizient zusammen arbeitet, gleichzeitig die Flexibilität behält. Aktuell verschenkt man auf RDNA2 und RDNA3 sehr viel RT-Leistung, weil viele Entwickler nicht verstehen, dass sie bei der BVH-Suche und anschließend der Treffer-Ermittlung viel mehr Freiheiten haben und stark optimieren können. AMD zeigt das leider auch nicht so wirklich ... AMD wird hier sich NVIDIAs-Ansatz annähern müssen, wenn sie aufholen wollen.

AMD hat hier einiges zu tun und vor allem muss AMD endlich auch stärker auf der GDC und Co auftreten und sich "Forschungspartner" suchen, wie NVIDIA es mit CD Projekt getan hat und auch anfangen Studneten zu unterstützen in diesen Bereichen. AMD hat fähige Köpf, aber viel zu wenig Forschungspartner und ich hoffe, dass da von Xilinx einiges zu AMD rüberschwappt.

AMDs Problem war eigentlich nie die Hardware, sondern dass sie sich nie Forschungspartner gesucht haben, die ihre Entwicklungen puschen und zeigen, was möglich ist.

TSMC hat bei N6 EUV eingeführt, um die Kosten zu senken. Mit EUV werden weniger Masken als mit DUV benötigt. Intel wird erst bei Intel 4 EUV einsetzen, also nicht für den Base Die.

Ich finde, dass "Kosten" immer zu Abstrakt sind, um die Vorteile von EUV gegenüber DUV zu zeigen. Man benötigt ja nicht nur weniger Masken und damit auch weniger Belichtungsschritte, sondern die einzelnen Schritte werden auch wieder "resistenter" gegenüber Fehlern.

 

[Matthias B. V.]

Und auch ein "kleines" GDDR6-Interface mit Infinity-Cache und dann noch den normalen RAM-Controller bringt an der Stelle nicht viel, weil erneut die Komplexität steigt und das an zwei Stellen. Man hat den L4/Infinty Cache und zwei unterschiedliche RAM-Controller. Und ich verschweige an der Stelle mal die ganzen Probleme, die das auf dem internen Bus auslöst.

Intels Ansatz hier einen L4-Cache und bei AMD ggf. später in den APUs einen Infinity-Cache vor den RAM-Controller zu setzten, sind eine gute Methode, um den Bandbreiten-Bedarf zu reduzieren und haben gleichzeitig den Vorteil, dass man auch Energie spart - das sieht man gut an den 5800X3D und 7800X3D sowie 7950X3D (der 7900X3D existiert nicht).

Eigene Controller für GPU und CPU-Teil sind kontraproduktiv und lassen die Kosten bei der Komplexität stark ansteigen bei gleichzeitig nur geringem nutzen.

L4 Cache halte ich auch für unglücklich. Aber denke irgendwann würde man vlt. nur noch L1 und L2 auf den CPU / GPU Wafern fertigen und den L3 komplett separat in eine Lage darunter anbringen. Dafür umso größer...

Dies könnte genannte Probleme beseitigen wenn es schnell und nah genug angebunden werden kann.

Unterschiedliche Controller und Zugriffe sehe ich ebenso kritisch.

Nein, ganz ehrlich, so sehr ich auch meine 7900 XTX mag und so sehr ich AMD mag: RDNA4 wird sicher eine gute GPU, aber sie werden höchstens mit NVIDIA gleichziehen in der nächsten Generation, sie "schlagen", daran glaube ich nicht und dafür gibt es mehrere Gründe.

Der Umbau der CU zu Vec32+32/Vec64 bei den CU war notwendig, man sieht aber - ebenso wie Ampere und auch jetzt Ada, dass hier vieles noch Zukunftsmusik ist und die effektive Auslastung erst mit 1440p und 2160p wirklich "zu nimmt". Ampere, Ada und RDNA3 "lieben" hohe Auflösungen. Es müssen hier viele Daten für die selben Operationen zusammen kommen für die optimale Auslastung. AMD hat hier einen "kniff" gefunden, dass RDNA3 auch mit "weniger" Daten gut ausgelastet werden kann (Unabhängige Operationen innerhalb des gleichen Tasks), ist hier aber weiter auf das Compiler-Team angweisen, da wir quasi wieder ein VLIW2-Konzept haben. RDNA3 ist viel Zukunftsmusik und ebenso wie NVIDIA bei Ada bei der "RT-Performance" auf die Entwickler angewiesen ist, dass diese ihre RT-Shader für SER aufbereiten und optimieren, ist AMD darauf angewiesen, dass Entwickler ihre Shader so entwickeln, dass der Compiler möglichst viele Optimierungen darauf anwenden kann.

Ebenso hat AMD bei RT einiges an Hausaufgaben zu machen, sie haben vieles bei RDNA3 verbessert, aber eben noch nicht genug und sie müssen einen Weg finden, wie der Ansatzt aus TMU + RT-Kern möglichgst effizient zusammen arbeitet, gleichzeitig die Flexibilität behält. Aktuell verschenkt man auf RDNA2 und RDNA3 sehr viel RT-Leistung, weil viele Entwickler nicht verstehen, dass sie bei der BVH-Suche und anschließend der Treffer-Ermittlung viel mehr Freiheiten haben und stark optimieren können. AMD zeigt das leider auch nicht so wirklich ... AMD wird hier sich NVIDIAs-Ansatz annähern müssen, wenn sie aufholen wollen.

AMD hat hier einiges zu tun und vor allem muss AMD endlich auch stärker auf der GDC und Co auftreten und sich "Forschungspartner" suchen, wie NVIDIA es mit CD Projekt getan hat und auch anfangen Studneten zu unterstützen in diesen Bereichen. AMD hat fähige Köpf, aber viel zu wenig Forschungspartner und ich hoffe, dass da von Xilinx einiges zu AMD rüberschwappt.

AMDs Problem war eigentlich nie die Hardware, sondern dass sie sich nie Forschungspartner gesucht haben, die ihre Entwicklungen puschen und zeigen, was möglich ist.

Ich finde, dass "Kosten" immer zu Abstrakt sind, um die Vorteile von EUV gegenüber DUV zu zeigen. Man benötigt ja nicht nur weniger Masken und damit auch weniger Belichtungsschritte, sondern die einzelnen Schritte werden auch wieder "resistenter" gegenüber Fehlern.

Evtl.. wurde ich auch falsch verstanden. Ich ging nicht davon aus dass AMD Nvidia dominiert sondern dass man sie schlagen kann.

Wenn man will kann man durch das Chiplet Design große Chips mit mehr Shadern bei niedrigerem Takt herstellen kann wo Nvidia Probleme bekommt. Ob man es dann macht ist was anderes...

Zudem sind es viele "Low-Hanging Fruits" mit denen man über Entwicklungspartner und Treiberoptimierungen ungenutztes Potenzial freischalten kann. Nvidia hat hier schon mehr optimiert und demnach weniger Spielraum.

 

[ETI1120]

Nein, ganz ehrlich, so sehr ich auch meine 7900 XTX mag und so sehr ich AMD mag: RDNA4 wird sicher eine gute GPU, aber sie werden höchstens mit NVIDIA gleichziehen in der nächsten Generation, sie "schlagen", daran glaube ich nicht und dafür gibt es mehrere Gründe.

Wenn man will kann man durch das Chiplet Design große Chips mit mehr Shadern bei niedrigerem Takt herstellen kann wo Nvidia Probleme bekommt. Ob man es dann macht ist was anderes...

Ich denke David Wang und Rick Bergmann waren bei ihrem Interview in Japan klar genug. https://www.itmedia.co.jp/pcuser/articles/2303/13/news035_5.html (Über DeepL gut lesbar)

AMD wird auch bei RDNA4 bei den Gaming GPUs nicht auf maximale Leistung gehen, sondern wird sich an dem orientieren was sie für ca. 1000 USD Grafikkartenpreis auf den Markt bringen können.

Ich finde das realistisch, da es für AMD sehr schwer wird die 1000 USD Marke zu knacken. Wie gut Nvidia mit den aktuellen Preisen zurecht kommt werden wir im Laufe des nächsten Jahres sehen. Ich halte es für gut möglich dass Nvidia wie bei den RTX2000 das ganze aussitzen wird. Die hat sich schlussendlich auch sehr gut verkauft. Obwohl viele über die zu hohen Preise gegiftet haben

Es ist offensichtlich, dass bei RDNA3 etwas schiefgelaufen ist, die angekündigte Effienzsteigerung von 50 % blieb aus. Obwohl ein neuer Prozess verwendet wurde, der wie Zen 4 zeigt ganz massiv zur Effizienz beiträgt.

Klarer werden wir das ganze sehen, wenn auch Phoenix und Navi 32 draußen sind.

IMO ist die Entwicklung der iGPUs bei AMD und Intel viel kritischer für Nvidia als alles was AMD oder Intel für den Desktop auf die Beine stellen. Das Geschäft mit den kleinen Mobil-GPUs ist sicher nicht so margenträchtig wie eine 4090 für den Desktop, aber es bringt Marktdurchdringung und Umsatz.

Die iGPUs werden sich nie mit der Spitze der dGPUs messen können. aber gut genug für Full HD wird für sehr viele Käufer gut genug sein. Bei den Notebooks kommt hinzu dass das Powerbudgets begrenzt ist.

Wie sich der PC-Gaming Markt entwickelt werden die nächsten 2 Jahre zeigen. Die Käufer entscheiden ob sie den Trend zu immer teureren Grafikkarten mitmachen oder nicht. Ich kann das ganze nicht so recht nachvollziehen, da für mich das Spielprinzip immer wichtiger als die Grafikqualität war. So lange das Spielerlebnis durch schlechte Darstellungsqualität leidet, ist mir die Grafikqualität wichtig*). Ich weis andere haben hier ein anderes Empfinden als ich.

*)Extrembeispiel: Ich habe Mal von einem Spiel gehört (C64) da mussten die Spielfiguren durch einen blauen Pool mit gelben Haien schwimmen. Ein paar Leute die ich kenne hatten zuerst nur einen Schwarzweis Monitor am C64 hängen. Da waren die Haie nicht mehr zu erkennen ...

Ich finde, dass "Kosten" immer zu Abstrakt sind, um die Vorteile von EUV gegenüber DUV zu zeigen. Man benötigt ja nicht nur weniger Masken und damit auch weniger Belichtungsschritte, sondern die einzelnen Schritte werden auch wieder "resistenter" gegenüber Fehlern.

Kosten ist immer eine gute Umschreibung, wenn man wie ich kein ausreichendes Detailwissen über den Prozess hat. Also hat mich dein Einwurf Mal wieder gezwungen etwas genauer zu suchen, .

Dabei ist mir auch klar geworden, warum in den Fachforen von Masken und nicht von Belichtungsschritten die Rede ist:

Citation:
C. A. Mack, Field Guide to Optical Lithography, SPIE Press, Bellingham, WA (2006).

Die Belichtung (Align and Expose) ist nur ein Teilschritt und die eigentliche "Arbeit" wird bei Etch, Implant gemacht.

In wie weit ein einzelner Belichtungsschritt bei EUV niedrigere Fehlerraten hat als ein einzelner Belichtungsschritt mit DUV kann ich nicht beurteilen. Mit EUV können Strukturen mit einem einzigen Belichtungsschritt abgebildet werden, für die mehrere Belichtungen mit DUV erforderlich sind (Multi Patterning). Die reduzierte Anzahl der Schritte reduziert natürlich die Gesamtfehlerrate. Was soweit ich es verstehe, sich auf die Totalausfälle (D₀) und parametrische Fehler auswirkt.

Und auch ein "kleines" GDDR6-Interface mit Infinity-Cache und dann noch den normalen RAM-Controller bringt an der Stelle nicht viel, weil erneut die Komplexität steigt und das an zwei Stellen. Man hat den L4/Infinty Cache und zwei unterschiedliche RAM-Controller. Und ich verschweige an der Stelle mal die ganzen Probleme, die das auf dem internen Bus auslöst.

Intels Ansatz hier einen L4-Cache und bei AMD ggf. später in den APUs einen Infinity-Cache vor den RAM-Controller zu setzten, sind eine gute Methode, um den Bandbreiten-Bedarf zu reduzieren und haben gleichzeitig den Vorteil, dass man auch Energie spart - das sieht man gut an den 5800X3D und 7800X3D sowie 7950X3D (der 7900X3D existiert nicht).

Du hast recht 2 Speicherinterfaces am Chip sind zu komplex und für diesen Markt zu teuer. Ein großer Systemcache passt besser um das Bandbreitenproblem der iGPU zu mildern.

Meine Meinung ist, dass Intel das Potential der freien Chipfläche auf dem Base Tile nutzen will. Ich habe meine Zweifel, ob es mit der verwendeten Verbindungstechnik gut genug für den L3-Cache wäre. Also hat Intel einen L4-Cache kreiiert.

Bei AMD sieht es ganz anders aus. Die APUs sind monolithisch und ein Infinity Cache ist zusätzliches Silizium das kostenmäßig voll durchschlägt. Natürlich wäre das schön zu haben, aber wer wird das auch noch wollen wenn es bezahlt werden muss?

Und hiervon muss man nicht nur die Endkunden, sondern zuerst die OEMs überzeugen. Und das fällt Intel bekanntermaßen viel leichter als AMD.

 

[DevPandi]

Aber denke irgendwann würde man vlt. nur noch L1 und L2 auf den CPU / GPU Wafern fertigen und den L3 komplett separat in eine Lage darunter anbringen.

AMD geht ja bei CDNA3/MI300 diesen Schritt. Der L3-Cache wird zusammen mit den HBM-Controllern auf den Basetile verbannt. Damit die Wege dann möglichst kurz sind, werden CCD und GCD auf diesen gesetzt.

Ich rechne ehrlich gesagt auch mit so einer Lösung bei AMD für "frühestens" RDNA4, eher bei RDNA5, dass dann ein großer MCD mit dem Infinity Cache als Basis genutzt wird und auf diesem dann die GCD gesetzt werden.

Dafür umso größer...

AMD/Intel oder NVIDIA könnten dann wirklich den L3/Infinity-Cache auf einen großen Die in N7 oder Co legen und dann auf diesen N3 GCDs und CCDs. Das hält die Wege kurz und der L2-Cache ist ja schon das verbindene Hauptelement in einer GPU

dass man sie schlagen kann.

Ich sprach auch nicht von dominieren und habe das auch nicht so verstanden. Die Sache ist nur die, dass AMD aktuell immer noch zu viel aufzuholen hat. AMD kann bei Rasterizer mithalten, bei RT befindet man sich je nach Optimierungsgrad auf dem Level von Ampere. Bei RT gibt aber NVIDIA aktuell den Takt an, weil sie viele Studenten unterstützen und auch Spieleentwickler bei der RT-Implementation. AMD muss hier aufholen und gleichzeitig die Entwickler unterstützen und schulen. AMD und Intel geraten hier ins hintertreffen. Intel hat bei RT sehr lange Zeit die CPU im Fokus - hier gibts dazu ja auch schöne Artikel von Daniel Pohl dazu.

AMD kann hier aktuell nur aufholen, schlagen nein und dominieren schon garnicht, außer AMD nimmt mal ein paar Millionen und zwar dann eher 3-stellig, besser 4-stellig und geht kooperationen mit Unis und Co ein. Ich habe hier Hoffnung auf Xilinx, dass die ihre Kultur bei AMD bei Software und Kooperationen etablieren.

Wenn man will kann man durch das Chiplet Design große Chips mit mehr Shadern bei niedrigerem Takt herstellen kann wo Nvidia Probleme bekommt. Ob man es dann macht ist was anderes...

Was unweigerlich zu einem Auslastungsproblem führt. Es braucht ja eben nicht nur genug Daten, sondern auch immer genug Daten mit dem gleichen Befehl. Leider gibt es nicht das perfekt parellisierbare Problem.

Zudem sind es viele "Low-Hanging Fruits" mit denen man über Entwicklungspartner und Treiberoptimierungen ungenutztes Potenzial freischalten kann.

Mit den Entwicklungspartnern müsste AMD aber eben mal anfangen.

 

[ETI1120]

Ich rechne ehrlich gesagt auch mit so einer Lösung bei AMD für "frühestens" RDNA4, eher bei RDNA5, dass dann ein großer MCD mit dem Infinity Cache als Basis genutzt wird und auf diesem dann die GCD gesetzt werden.

Die Umsetzung bei RDNA 3 hat den Vorteil, dass sie relativ preiswerte Technik (Fanout) verwendet und skalierbar ist. Ich habe jetzt nichts gesehen, das darauf hindeutet, dass die Verbindung zwischen L3 Cache und Rest-GPU das Problem ist. Es würde mich sehr wundern, wenn AMD diese Anordnung schon nach einer Generation wieder verwirft. Ich vermute dass AMD erheblich größeren Bedarf hat, die Rest-GPU (ALUs, Graphic Pipeline, ...) zu verbessern.

Preislich spielen CDNA und RDNA in ganz anderen Welten. Ich bin inzwischen erheblich skeptischer was die Umsetzung der ganzen GPU-Patente bei RDNA betrifft. AMD muss das was sie ausgeben wieder reinholen. Und dies erscheint mir bei CDNA und XDNA sehr viel realistischer als bei RDNA.

Wenn es ums träumen geht, würde ich hoffen, dass auch die IO-Funktionen aus der kleinsten Rest-GPU herausgeholt werden und dass dieses GCD dann für GPUs und APUs genutzt werden kann.

AMD kann hier aktuell nur aufholen, schlagen nein und dominieren schon garnicht, außer AMD nimmt mal ein paar Millionen und zwar dann eher 3-stellig, besser 4-stellig und geht kooperationen mit Unis und Co ein.

Für RT wird IMO AMD nicht so viel Geld in die Hand nehmen. Es gibt viel drängendere Probleme auf der Softwareseite wie z. B. GPGPU oder der ML-Stack

Andererseits hat es natürlich auch keinen Sinn einen 5090-Konkurrenten zu bringen, wenn man bei Blender und anderen Rendering-Tools nicht Mal im Ansatz mit der 5090 mithalten kann. Aber selbst wenn die Karte bei Blender und den anderen Rendertools mit der 5090 mithalten könnte, wie viel billiger müsste die Karte sein, dass die Leute die seit Jahren mit Nvidia-Karten arbeiten die AMD Karte auch nur in Erwägung ziehen?

Ich habe hier Hoffnung auf Xilinx, dass die ihre Kultur bei AMD bei Software und Kooperationen etablieren.

Hier war es zumindest ein deutliches Signal, dass Victor Peng die Führung beim Aufbauen des AI-Software-Stacks bekommen hat.

 

[Piktogramm]

Das Gute am Base Tile ist, dass es relativ klein ist.

Das Basetile ist flächig unter GPU-, IO-, SOC- und CPU-Die. Ich würde ganz im Gegensatz sagen, dass das Base-Tile recht groß ist. Grob über den Daumen gepeilt ist das die Größe eines AlderLake Chips. Imho ist das ein recht großes Die.

Mit SRAM werden ein paar Prozessschritte mehr notwendig sein, als nur mit TSV, Kapazitäten und Metallisierung. Da auf dem Base Tile sehr viel Platz ist, spielt es keine Rolle, ob die SRAM-Zellen ein bisschen größer auffallen. Also sollte es kein Problem sein, wenn Intel auch für die Variante mit Cache den Intel 16 Prozess einsetzt, der für das Base Tile geplant ist
https://www.computerbase.de/2022-08/meteor-lake-tsmc-baut-mehr-chips-als-intel-fuer-next-gen-cpu/

Tendenziell laufen Caches etwas flotter als Sram vom Arbeitsspeicher, da bin ich gespannt, wie sehr man da auf die kleinsten Nodes verzichten kann.

Bei Lakefield hat Intel die Base Tile in 22FFL gefertigt, was quasi eine Mischung aus 22 und 14 nm ist - aber im Kern hat trotzdem viele Jahre alt ist. Darauf haben sie dann 10 nm gesetzt. Und das ist für sie je nach Fab-Lage dann auch heute eine Option. Denn sie wollen als Foundry ja auch Intel 16 oder sowas anbieten, also richtig oldschool Zeugs. Der Chiplet/Tile-Ansatz bietet eben halt viele Optionen, am Ende könnte selbst GloFo irgendwas bauen, wenn sie die günstigsten im Markt sind, TSMC ist der teuerste, aber die brauch man eben für das beste

Das Base-Tile von Lakefield entspricht ja eher mit dem SOC-Die. Da war der große Teil Logik vom Uncore drauf. Zudem war Base vom Lakefield im Vergleich zu Meteor eine ganze Ecke kleiner.

Wie verhält es sich bei 2 gleichen Programmen.

Jedes Programm bekommt vom Betriebssystem eine eigene ProzessID und ist damit ein eigenständiges Programm, "gleich" gibt es in dem Sinne nicht.

Werfen die sich gegenseitig aus dem Cache raus oder wird gleiche Arbeiten effizient zusammen gelegt und woher wissen die beiden gleichen Programme welcher Inhalt wo gespeichert wird und wie machen die das das keine Fehler dadurch entstehen?

Ich bekomme das nicht verständlich, allumfassend oder gar richtig auf Anhieb erklärt. Da müsstest du selbst mal in die Untiefen der Speicherverwaltung auf Ebene von Betriebssystemen bis runter zu µProzessoren und deren Speicherverwaltung hinabsteigen.

Und mir ist aufgefallen das 2 gleichzeitig dann doch ne kleine Zeit beim Umwandeln kostet.
Bei einen 8 Kerner kostet es 50 % an Leistung und beim 16 Kerner so um die 25% an Leistung.Ist das also dem Cache geschuldet und kann man sowas auch auf 0 Optimieren oder wird kein CPU Hersteller diese Limits umgehen können weil die Schuld an die Programme liegt.

Wenn es mehr aktive Threads als Cores gibt, gibt es Kontextwechsel. Was auf Ebene von Betriebssystemen und Prozessoren bedeutet, dass unproduktive Aufgaben für diesen Kontextwechsel erfolgen. Da gibt es keinen unmittelbar Schuldigen, das liegt mehr oder weniger schlicht daran, wie wir als Menschheit Computer bauen.

Wobei ich habe gelesen Apples CPU könne das ohne Leistungsverlust packen.Warum weil die CPU so breit ist,das diese ja eh mehr gleichzeitig machen könne ohne Leistungverluste.Wobei so ein direkter Test mit Zeitmessung ich so noch nicht gesehen hatte.

Da Apples ARM Prozessoren kein SMT unterstützen, kann immer nur ein Prozess je CPU-Kern laufen. Da nutzt die Breite der CPU nichts. Entweder ist es diesem einem Prozess möglich die vorhandenen 8Pipelines der BigCores zu nutzen, oder nicht.
Im Zweifelsfall hat Apple darauf geachtet, dass Kontextwechsel und etwaige Cacheflushes zügig erfolgen und was auch hilft ist schlicht und ergreifend der im Vergleich zu x86 CPUs deutlich fixer angebundene Festspeicher. Zusätzlich hat Apple mit MacOS das Verhalten des Betriebssystem unter Kontrolle, kann also an allen wichtigen Stellen optimieren.

 

[ETI1120]

Das Basetile ist flächig unter GPU-, IO-, SOC- und CPU-Die. Ich würde ganz im Gegensatz sagen, dass das Base-Tile recht groß ist. Grob über den Daumen gepeilt ist das die Größe eines AlderLake Chips. Imho ist das ein recht großes Die.

Was Intel mit Meteorlake hinlegt ist technologisch mit CoWoS-S von TSMC zu vergleichen. Im Vergleich zu den CoWoS-S üblichen Interposern ist das Base Tile klein. Die Interposer von CoWoS-S sind meist größer als das Recticle Limit was zusätzliche Kosten verursacht. Das habe ich gemeint aber nicht geschrieben.

 

[DevPandi]

Die Umsetzung bei RDNA 3 hat den Vorteil, dass sie relativ preiswerte Technik (Fanout) verwendet und skalierbar ist. Ich habe jetzt nichts gesehen, das darauf hindeutet, dass die Verbindung zwischen L3 Cache und Rest-GPU das Problem ist.

Habe ich etwas von Problemen mit dem L3/Infinity-Cache geschrieben? Nein! Es geht an dieser Stelle eher darum, wie AMD - wenn Sie es denn weiter verfolgen - bestimmte Probleme bei der Synchronistation der Daten zwischen möglichen GCDs minimiert/eleminiert.

Wenn man es genau nimmt, dann besteht eine GPU bereits heute "intern" bereits aus GCDs - die Shader-Engines - die alles, was eine GPU benötigt mitbringt. Die Daten werden hier durch den L2-Cache synchron gehalten und dienen auch dem Austausch der Daten zwischen den Shader-Engines. Der L3-Cache ist aktuell beim Infinty-Cache ein Puffer, der Anfragen an den RAM abfängt.

AMD hat verschiedene Patente gezeigt, ob AMD diese auch umsetzt, darüber kann man spekulieren. Deren aktuellen Lösung ist, dass über den L2/L3-Cache eine schnelle Verbindung gelegt wird in den Patenten. Bei CDNA3 und bei der Mi300 geht AMD einen anderen Weg, den sie angekündigt haben. Der Base-Tile enthält den L3-Cache zusammen mit den Memory-Contollern und dem IO-Interface.

Etwas "ähnliches" kann auch für zukünftige RDNA-Entwicklungen erwarten, ob es kommt, keine Ahnung, ein entsprechender Basetile mit dem Infinty-Cache und den RAM-Controllern würde aber einige Probleme relativ elegant und einfach lösen und hätte den primären Vorteil, dass man sich bei dem Interconnect zwischen den GCD etwas weniger Gedanken machen muss.

Zudem - und dass ist der entscheidende Punkt - widerspricht, besser steht meine Spekulation nicht in Widerspruch dazu, "dass sie relativ preiswerte Technik (Fanout) verwendet und skaliierbar ist". AMD hat bisher 3 Chips für RDNA3 in "Planung" wovon 2 Chips auf dem Markt sind: Navi31 und Navi33. Aktuell gibt es ein relativ großen GCD und kleine MCDs und dazu eben einen Monolith. Für Navi32 ist ein "mittlere" GCD geplant, wir haben also 4 Chips. In meiner Überlegung - wenn wir jetzt darauf hinaus gehen - kann es theoretisch auch bei 4 Chips bleiben: Kleine, mittlere und große Basetiles mit 128 Bit SI, 256 Bit SI und 384 Bit SI und der entsprechende Menge an Infinity-Cache und "kleine" GCDs, die vielleicht nur noch 2 Shader Arrays beherbergen. Am Ende planzt man dann 2 GCD auf ein Basetile, 4 GCD und 6 GCD. In den alten Prozessen werden also "größere" Chips gefertigt, da die Prozesse gut erprobt sind und man auch da ggf. auslasten muss, hat man hier zwar dann "teurere" Chips, gleichzeitig hat man dann aber bei den teuren Prozessen kleinere Chips - die "etwas" günstiger werden und kann hier die "noch" schlechte Yield-Rate kompensieren.

Ich vermute dass AMD erheblich größeren Bedarf hat, die Rest-GPU (ALUs, Graphic Pipeline, ...) zu verbessern.

RDNA3 hat das gleiche Problem, dass NVIDIA bei Ampere und auch bei ADA hat und das Problem werden weder NVIDIA noch AMD wirklich lösen können, was die ALUs angeht: Ein Teil der ALUs liegen brach, weil nicht genug Daten pro Thread/Task zusammen kommen. Das wird sich auch so in der nächsten Zeit nicht ändern. AMD hat hier einen minimalen Vorteil, hier muss aber der Shadercode mitspielen.

NVIDIA benötigt für die optimale Auslastung für die Shader 2 Threads mit Vektoren, die 64 Elemente fassen pro SM, AMD benötigt pro CU auch 2 Threads, auch mit 2 Vektoren die 64 Elemente fassen, oder 2 Threads, die genug unabhängige Operatoren haben, dass pro Thread 2 Vektoren mit 32 Elementen zusammen kommen.

Für letzteres muss entweder der Compiler mit entsprechenden Techniken zur Flussanalyse und Co erweitert werden - weil in der GPU ja keine "OoO"-Technik in den CUs implementiert wurde - was die CU auch massiv aufblähen würde - so dass hier VLIW-Technik eingesetzt werden, oder die Entwickler müssen bereits entsprechende Vorgehnsweisen selbst einplanen und dem Compiler dabei helfen.

Das die 7900 XTX entsprechend der ALUs agieren kann, sieht man gerade an Dead Island 2, hier schafft die 7900 XTX 7 % im Mittel und 15 % bei 99,9%. Und genauso sieht man es bei Spielen wie Call of Duty: Vanguard. Hier schiebt sich die Karte quasi die Erwartungen erfüllend bei der ALU-Anzahl zwischen 4080 und 4090. Man schafft mit 20 % mehr ALUs also ca. 15 %, während die 4090 mit 33 % ca. 25 % drauf legt. Die Karten fügen sich also gut ineinander.

Es würde mich sehr wundern, wenn AMD diese Anordnung schon nach einer Generation wieder verwirft.

Warum? AMD, NVIDIA, Intel und Co sind alles Firmen, die entsprechende Produkte planen und testen und im Lauf feststellen, dass es noch besser geht und haben entsprechend auch nach einer Generation auch den nächsten Schritt gemacht. AMD hat bei Zen auch nicht den Ansatz der ersten Iteration bei Epyc bei behalten und hat mit Zen 2 das Konzept quasi auf Links gedreht.

Aber edas ist alles nur Spekulation und Vermutungen. Wir werden mal sehen was passiert.

Für RT wird IMO AMD nicht so viel Geld in die Hand nehmen. Es gibt viel drängendere Probleme auf der Softwareseite wie z. B. GPGPU oder der ML-Stack

Bei GPGPU und dem ML/DL-Stack ist AMD relativ gut aufgestellt, auch mit der Fusion mit Xilinx. Klar, es könnte besser sein, CUDA wird AMD aber nicht brechen und entsprechende Arbeiten an ROCm laufen weiter voran. Im HPC-Bereich kann man ROCm bereits sehr gut verwenden und auch für andere Beschleunigung, die aktuell über CUDA läuft, kann man bereits sehr gut damit arbeiten. Hier ist das Problem eher ein altbekanntes von AMD: Bis auf "Dokumentation", kommt leider nicht viel Unterstützung von Seitens AMD. Auch hier liegt die Hoffnung auf der Übernahme durch Xilinx und dass diese eine bessere Softwaresupport-Kultur bei AMD mitbringen und da meine ich nicht die Pflege der Software.

RT wiederum ist eine sehr große Baustelle und AMD und Intel geraten hier massiv in Zugzwang, wenn beide Firmen nicht versuchen möglichst bald auch entsprechend irgendwie den Takt mit zu gestalten und auch wenn die erste RT-Implementierung von Intel nicht schlecht ist und AMD mit RDNA3 vieles besser macht, hier dominiert aktuell NVIDIA und zwar auf allen ebenen, nicht nur bei Spielen, sondern auch im professionellen Bereich.

NVIDIA kann sich bei CUDA relativ gemütlich zurück lehnen, den Markt haben sie weitgehend fest im Griff. Das geht sogat soweit, dass Leute GPGPU als "Erfindung" von NVIDIA ansehen und ATi/AMD vorwerfen, dass sie ja hier nur NVIDIAs "Innovationskraft" ausnutzen und stören wollen und sie ja deswegen OpenCL "ünterstützt" haben und dabei vollkommen vergessen, dass ATi mit der FireStream-API über ein Jahr vor NVIDIA ihr Produkt vorgestellt hat und NVIDIA hier "ATi" quasi hinterher liefen.

Bei DL/ML ist NVIDIA zwar medial in "Techforen" stark vertreten und das erweckt bei manchen den Eindruck dass auch hier CUDA quasi der Goldstandard ist, zum Glück ist dem aber nicht so und die meisten Entwickler greifen auf die DL-Frameworks von Google (Tensorflow) oder Meta (PyTorch) zurück, die weitgehend darauf ausgelegt sind, dass man Hardware unabhängig. Gerade Xilinx bringt hier viel Erfahrung mit und war Forschungspartner für viele Projekte. Xilinx "Übernahme" ist für AMD hier absolutes Gold, weil man hier auf die Kompetenz von Xilinx zurück greifen kann. Klar, hier in den News scheint es so, dass NVIDIA vollkommen dominant ist, dass sind sie aber nicht wegen CUDA, sondern weil sie an der Stelle die beste Hardware fürs Training haben. Klar, AMD muss bei den eigenen Matrix/Tensor-Kernen aufholen, hier müssen Sie aber primär dann nur den "Treiber" für die Frameworks entsprechend stemmen und stehen nicht in Konkurenz zu CUDA.

HPC/GPGPU und ML/DL sind also Felder, bei denen AMD eher bei Consumern, die solche Seiten wie hier lesen, als abgeschlagen angesehen werden, im professionellen Bereich aber immer noch als Alternative - und nicht nur eine "günstige" - wahrgenommen werden und entsprechend auch Aufträge bekommen. Ein Problem hat AMD in diesem Bereich eher - und damit der Zirkelschluss zum ersten Absatz dieses Abschnittes - bei Anwendungen für Content-Creators. Im OpenSource-Bereich - Blender und Co - werden entsprechend Implementationen in der Regel von Entwicklern vorgenommen, die einen akuten Bedarf danach haben oder weil sie von den Herstellern unterstützt werden oder Hersteller auch entsprechende Ressourcen bereit stellen. Wenn AMD hier irgendwann "besser" sein will, dann müssen Sie Ressourcen für Blender und Co freischaufeln/schaffen, die die Entwickler dort unterstützen. Hier haben wir ein klassisches Henne-Ei-Problem. AMD schneidet nicht schlecht ab, aber auch eben nicht so gut, wie möglich wäre. Die Leute kaufen daher NVIDIA, weil es läuft und der Softwaresupport da ist. Die großen Firmen wiederum "optimieren" nicht für AMD, weil die Kundenbasis fehlt, wodurch wieder ... Zirkelschluss.

Und bei RT droht AMD - und Intel - an dieser Stelle das gleiche Schicksal und genau deswegen ist es wichtig, dass AMD hier Ressourcen frei macht und auch das Geld in die Hand nimmt. Noch ist es für AMD von Vorteil, dass MS und Sony bei den nächsten Iterationen vermutlich wieder auf sie setzten wird, aber die Frage ist, wie lange noch. Intel schickt sich mit Xe an, dass sie hier durchaus eine Alternative zu AMD werden können. Auf der XBox wird bereits weitgehend heute DX12 "verwendet", Sony verwendet auf der PS5 auch Vulkan und ihre eigene API, die sie entsprechend aber anpassen können.

NVIDIA legt bei RT aktuell eine Geschwindigkeit an den Tag, die wirklich rasant ist. Mit Quake 2 RTX, Minecraft RTX, Portal RTX und nun Cyberpunk 2077 "Overdrive" bestimmt NVIDIA aktuell die Entwicklung von Pathtracern und Denoisern. Klar, die Pathtracer werden alle schön in DX12 oder Vulkan geschrieben, so dass sie überall laufen, gleichzeitig implementiert NVIDIA aber immer mehr Hardware- und Treiber- sowie Softwarefeatures über ihre NVAPI und bestimmt nicht nur, sondern dominiert die Entwicklung in diesem Bereich und zwar auf eine Art und Weise, die dazu führen kann, dass AMD und Intel zwar nicht sofort und vermutlich auch nicht in der nächsten Generation, aber auf lange Sicht ein richtiges Problem bekommen den Rückstand aufzuholen.

NVIDIA ist sehr gut darin geschlossene Systeme zu schaffen - CUDA - die es für Konkurrenten fast unmöglich macht die entsprechende Vormachtstellung zu knacken und für viele Entwickler sind diese Systeme anfangs durch den Support durch NVIDIA und Co ein Schlaraffenland, bis NVIDIA entsprechend die Preise quasi nach belieben anziehen kann - was wir ja bei Ampere bedingt und nun bei Grace und Ada zu sehen bekommen. Sich dann aus dieser Abhängigkeit zu lösen, ist mit größten Schmerzen verbunden in der Entwicklung und mit horenden Kosten für alle beteiligten.

Noch können AMD und Intel hier NVIDIA etwas entgegen setzen, denn bisher sind fast alle "Pathtraver"-Spiele Showcases und Forschungsarbeiten, aber grade Cyberpunk 2077 und der Pathtracer da zeigt sehr gut, dass Pathtracing auch in einem modernen Spiel bereits spielbare Frameraten und das sogar ohne DLSS2/FSR2 und schon garnicht mit DLSS3/FG erreichen können. In FHD schaffft eine 3080 bereits mit 30 fps spielbare Frameraten, die 4090 kratzt an 70 fps, bei1440p sind die 4080 und 4090 mit 30 fps dabei. NVIDIA setzt mit sochen Techdemos entsprechende Marker, sowohl in den Köpfen der Spieler aber auch bei den ganzen Entwicklern. Auf der nächsten GDC wird es vermutlich wieder viele Vorträge von NVIDIA geben die dann genau Cyberpunk 2077 Overdrive abhandeln und welche Optimierungen NVIDIA mit SER und Co erreicht hat. Im Mittel ist NVIDIA bei Ada ca. 30 % schneller in RT als RDNA3 - das war davor noch schlimmer - mit den ganzen Optimierungen auf NVIDIA und SER schafft eine 4080 150 - 175 % und eine 4090 schafft sogar bis zu 300 % mehr fps. Was Ada hier mit RDNA3 abzieht ist nicht mehr nur ein Kampf eines Kampfsportlers gegen einen Laien, sondern hier nimmt ein Mensch und tritt mit dem Fuß auf ein Insekt und zermalmt es regelrecht.

AMDs glück sind hier die Konsolen, doch wie lange hält das an? Klar, für viele ist DLSS2 und DLSS3/FG aktuell das "Aushängeschild" für NVIDIA und zeugt von deren "Genialität", aber weder DLSS2 noch FG sind wirklich "neu" - das meine ich nicht negativ - sondern beruhen auf Techniken, die man in anderen Bereichen seit Jahren nutzt. Checkerbox-Rendering, "temporales" Supersampling - was aus der Fotografie kommt für hochauflösende Bilder - und Co, das existiert bereits alles und entsprechend konnte AMD hier auch schnell ein Konkurrenzprodukt bringen und selbst Intel ist mit XeSS relativ schnell dabei gewesen. Gleiche bei GSync, seit 2010 - DisplayPort 1.2 - gibt es die entsprechenden Funktion für adaptive Bildwiederholfrequenzen und entsprechend konnte AMD auf NVIDIAs GSycn anworten. NVIDIAs ist sehr gut darin, bestehende Technologien "properitär" zu adaptieren und dann durch ein mega geniales Marketing es so hinzustellen, dass es entweder ohne "ihre" Technik nicht mehr geht (damals das 32-Bit-Rendering der Riva TNT gegen Voodoo 3, oder Hardware T&L, obwohl damals die Spiele quasi noch in DX6 geschrieben wurden und Hardware T&L erst mit DirectX8 dann den Durchbruch hatte) oder diese vollkommen überlegen ist, weil sie ja eine "geheime Zutat" dafür haben (GSycn und bedingt auch DLSS).

NVIDIAs Stärke ist nur bedingt in Hardware und Software zusuchen, sondern NVIDIAs Stärke ist Marketing sowie der Support von Entwicklern, die Kooperation mit Firmen und die Unterstützung von "Wissenschaftlern" in der praktischen Umsetzung, auch in der "Ausbildung".

NVIDIA hat verstanden, dass Entwickler-Support das wichtigste ist und ebenso wie wichtig Marketing bei Consumern ist und entsprechend agiert NVIDIA. AMD hat fähige Entwickler für Hardware und Software, sie müssen aber - und da ist es egal ob HPC, GPGPU, ML oder eben nun Spiele - jetzt auch mit RT - die Diskussionen und die Entwicklungen mit gestalten, nicht nur reagieren, wenn sie mit NVIDIA mithalten wollen und dafür müssen sie Geld in die Hand nehmen. AMD droht - und so ehrlich bin ich zu mir selbst - es bei den GPUs aktuell genau das, was AMD mit Bulldozer erlebt habt, nämlich die vollkommene Bedeutungslosigkeit.

 

[ETI1120]

Habe ich etwas von Problemen mit dem L3/Infinity-Cache geschrieben? Nein! Es geht an dieser Stelle eher darum, wie AMD - wenn Sie es denn weiter verfolgen - bestimmte Probleme bei der Synchronistation der Daten zwischen möglichen GCDs minimiert/eleminiert.

Du hast nicht geschrieben, dass es Probleme mit dem Infinity Cache gibt. Aber wenn die Anbindung des Inifinity Cache über Fanout funktioniert, wieso sollte AMD hier etwas ändern?

AMD verwendet bei Zen 2, Zen 3 und Zen 4 organische Substrate, um die CCDs mit dem IOD zu koppeln Diese Technologie ist für die Bandbreiten-Anforderungen einer CPU gut genug. Fanout mit oder ohne Siliziumbrücken sind nicht notwendig und würden nur die Kosten erhöhen. Also hat AMD hier bisher nichts geändert.

Bei Zen 5 kommt es IMO darauf an, welche Chiplets verwendet werden. D. h. falls AMD bei den CPUs weiterhin nur CCD und IOD verwendet, wird AMD voraussichtlich beim organischen substrat bleibe.Falls AMD etwas wie das folgende verwendet, könnte AMD auch bei den CPUs Fanout benötigen.

US20220101179A1_DirectConnected_MachineLearning_Accelerator - Fig 2B

Bei RDNA3 sind die Bandbreitenanforderungen zwischen Inifinity Cache und Rest-GPU erheblich höher als bei den CPUs. Deshalb hat AMD hier ein Fanout als Lösung gewählt.

Die große Schwäche beim Advanced Packaging von Intel ist IMO, dass Intel offensichtlich nichts mit Fanout im Angebot hat. Meteor Lake liese sich IMO mit Fanout hervorragend umsetzen und wäre damit billiger. Sinnvoll finde ich das Verwenden eines Interposer bei Meteor Lake nur wenn er aktiv ist.​

Bei CDNA2 sind die Bandbreitenanfordungen zwischen einem HBM-Stack und dem GCD so hoch, dass Fanout nicht mehr genügt. Deshalb werden HBMs-Stacks dutch Siliziumbrücken mit den GCDs gekoppelt. Das ganze sitzt auf einem Fanout und AMD nennt es Elevated Fanout Bridge (EFB)

AMD hat verschiedene Patente gezeigt, ob AMD diese auch umsetzt, darüber kann man spekulieren. Deren aktuellen Lösung ist, dass über den L2/L3-Cache eine schnelle Verbindung gelegt wird in den Patenten.

Es muss schnell sein (Latenz & Bandbreite*), es sind sehr viele Verbindungen**) erforderlich. Wenn AMD eine GPU aus einzelnen GCDs integrieren will müssendie Scalable Data Fabrics der einzenen GPU-Chiplets miteinander gekoppelt werden. All dies ist nur mit Siliziumbrücken möglich.

US20200409859A1 Fig 3​

*) Die Brücke muss es ermöglichen, dass die GCD mit derselben Bandbreite auf den Speicher der anderen GCDs wie auf den eigenen zugreifen kann. (Hotchips 34, Frage und Antwort zu CDNA2-Vortrag)
**) Forrest Norrod nannte in einem Interview 20 000 Verbindungen.

Bei CDNA3 und bei der Mi300 geht AMD einen anderen Weg, den sie angekündigt haben. Der Base-Tile enthält den L3-Cache zusammen mit den Memory-Contollern und dem IO-Interface.

AMD hat Varianten mit passiver Brücke und Varianten mit aktiver Brücke gezeigt. Kern dieser Patente war immer die Verbindung zwischen den GCDs. Wo die Memorycontroller sitzen spielt für diese Patente eigentlich keine Rolle. Die IO wurde in diesen Patenten gar nicht extra gezeigt.

Da gibt es auch ein extremeres Patent, Chiplets auf Chiplets, die mit Brücken gekoppelt werden:

US 20220320042A1 Fig 7

Auch hier wollen wir eine RDNA sehen. So wie das Memory Module angekoppelt ist spricht es sogar dafür. Aber ein solcher Wurf ist IMO für RDNA auf absehbare Zeit viel zu teuer.

Etwas "ähnliches" kann auch für zukünftige RDNA-Entwicklungen erwarten, ob es kommt, keine Ahnung, ein entsprechender Basetile mit dem Infinty-Cache und den RAM-Controllern würde aber einige Probleme relativ elegant und einfach lösen und hätte den primären Vorteil, dass man sich bei dem Interconnect zwischen den GCD etwas weniger Gedanken machen muss.

Sobald AMD beschließt auch bei RDNA Multi-GCD-GPUs zu machen, wird auch bei RDNA eine Siliziumbrücke notwendig. Dann wird man auch sehen, ob die Brücke aktiv oder passiv wird, ob sie oben oder unten (Sockel) angeordnet wird.

Bei CDNA3 ist Brücke zwischen 2 XCD (Accelerator Compute Die) aktiv. Sie wird Mal AID (Active Interposer Die) oder Mal Base Die genannt. Die beiden XCD sitzen auf dem AID. Die Frage ist, ob die ganze Fläche des AID tatsächlich genutzt wird. Nur wenn die ganze Fläche tatsächlich genutzt wird, ist es tatsächlich elegant. Aber die MI300 APU ist so teuer, dass es auf ein paar mm² totes Silizium nicht wirklich ankommt.

Was aber AMD bisher noch nicht verraten hat, ist wie die 4 Base Dies gekoppelt werden. Erst eine schnelle und ultra breite Kopplung macht aus der ganzen Geschichte eine APU. Da die Kopplung auf den Fotos nicht zu erkennen ist, muss sie unter den Base Dies sein. Deshalb gehe ich von einer passiven Brücke aus. Mit Hybrid Bonding und einem Pitch von 6 µm muss sie gar nicht so groß sein.

CDNA und RDNA sind verschiedene Welten.
Die RX7900XTX hat eine Speicherbandbreite von 960 GB/s
HBM3 ermöglicht je Stack eine Bandbreite von bis zu 819 GB/s, wir werden es bald wissen welches Tempo die MI300 erreicht. Die H100 gibt sich AFAIK mit läppischen 600 GB/s je Stack zufrieden.

Neben den anderen Anforderungen an die Speicherbandbreite unterscheidet sich auch der Verkaufspreis ganz erheblich. Auch die GPU-Variante (ich nehme an 1 AID + 2 XCDs) wird preislich deutlich über einer RX7900XTX liegen.

Zudem - und dass ist der entscheidende Punkt - widerspricht, besser steht meine Spekulation nicht in Widerspruch dazu, "dass sie relativ preiswerte Technik (Fanout) verwendet und skaliierbar ist". AMD hat bisher 3 Chips für RDNA3 in "Planung" wovon 2 Chips auf dem Markt sind: Navi31 und Navi33. Aktuell gibt es ein relativ großen GCD und kleine MCDs und dazu eben einen Monolith. Für Navi32 ist ein "mittlere" GCD geplant, wir haben also 4 Chips. In meiner Überlegung - wenn wir jetzt darauf hinaus gehen - kann es theoretisch auch bei 4 Chips bleiben: Kleine, mittlere und große Basetiles mit 128 Bit SI, 256 Bit SI und 384 Bit SI und der entsprechende Menge an Infinity-Cache und "kleine" GCDs, die vielleicht nur noch 2 Shader Arrays beherbergen. Am Ende planzt man dann 2 GCD auf ein Basetile, 4 GCD und 6 GCD. In den alten Prozessen werden also "größere" Chips gefertigt, da die Prozesse gut erprobt sind und man auch da ggf. auslasten muss, hat man hier zwar dann "teurere" Chips, gleichzeitig hat man dann aber bei den teuren Prozessen kleinere Chips - die "etwas" günstiger werden und kann hier die "noch" schlechte Yield-Rate kompensieren.

Der GCD von Navi 31 hat ca 300 mm², der GCD von Navi 32 hat ca 200 mm². Da ist noch Luft nach oben. Und wahrscheinlich wird es N3E, was auch noch ein bisschen Skalierung bringt.

Deshalb IMO wird AMD bei RDNA4 bei einem GCD bleiben.

Das die 7900 XTX entsprechend der ALUs agieren kann, sieht man gerade an Dead Island 2, hier schafft die 7900 XTX 7 % im Mittel und 15 % bei 99,9%. Und genauso sieht man es bei Spielen wie Call of Duty: Vanguard. Hier schiebt sich die Karte quasi die Erwartungen erfüllend bei der ALU-Anzahl zwischen 4080 und 4090. Man schafft mit 20 % mehr ALUs also ca. 15 %, während die 4090 mit 33 % ca. 25 % drauf legt. Die Karten fügen sich also gut ineinander.

Du greifst Dir 2 Spiele raus, bei denen die 7900XTX sehr gut abschneidet. Da kann sie bei der auf die Shaderanzahl normierten Performance mit Nvidia mithalten.
Wie sieht es mit der Effizenz aus? Liegt sie da auch auf dem Niveau von Nvidia?

Im Mittel liegt die 7900XTX bei der Performance ziemlich gleich auf mit der RTX4080. D. h. auf die Shader normiert liegt sie hinten. Außerdem ist Effizienz der RTX4080 besser.

Dann gibt es noch Spiele bei denen die 7900XTX von der Performance erheblich schlechter aussieht.

Soweit ich es mitbekommen habe ist es nicht so, dass die 7900XTX bei allen neuen Spielen (bei denen AMD den Treiber quasi von Hand optimieren kann) sich von der RTX4800 absetzen kann.

Warum? AMD, NVIDIA, Intel und Co sind alles Firmen, die entsprechende Produkte planen und testen und im Lauf feststellen, dass es noch besser geht und haben entsprechend auch nach einer Generation auch den nächsten Schritt gemacht. AMD hat bei Zen auch nicht den Ansatz der ersten Iteration bei Epyc bei behalten und hat mit Zen 2 das Konzept quasi auf Links gedreht.

Und dieses Konzept mit Zen 3 und Zen 4 beihalten.

Sam Naffziger hat erklärt wieso AMD bei Zen 2 auf das Chiplet-Konzept umsteigen musste:

Bei GPGPU und dem ML/DL-Stack ist AMD relativ gut aufgestellt, auch mit der Fusion mit Xilinx. Klar, es könnte besser sein, CUDA wird AMD aber nicht brechen und entsprechende Arbeiten an ROCm laufen weiter voran. Im HPC-Bereich kann man ROCm bereits sehr gut verwenden und auch für andere Beschleunigung, die aktuell über CUDA läuft, kann man bereits sehr gut damit arbeiten. Hier ist das Problem eher ein altbekanntes von AMD: Bis auf "Dokumentation", kommt leider nicht viel Unterstützung von Seitens AMD. Auch hier liegt die Hoffnung auf der Übernahme durch Xilinx und dass diese eine bessere Softwaresupport-Kultur bei AMD mitbringen und da meine ich nicht die Pflege der Software.

Bei GPGPU ist AMD nur im HPC-Bereich (CDNA) einigermaßen gut aufgestellt.

Aber ansonsten ist es mau.

IMO muss man 2 Ebenen unterscheiden:

1. Programmieren der GPU
2. Programmieren die Möglichkeit geben über das Verwenden von Bibliotheken die GPU einzubinden

Was ich damit meine ist, nicht jede Person die Software schreibt, will sich mit der GPU-Programmierung auseinander setzen.

AMD erzählt in letzter Zeit wiederholt wie toll ROCm ist. Hier hat AMD auch ordentlich Arbeit reingesteckt. Allerdings gibt es von AMD bis heute keine klare Roadmap wie ROCm und vor allem HIP außerhalb des HPC verfügbar werden soll.

Dazu gehört auch, dass AMD HIP für RDNA überhaupt erst verfügbar macht.

RT wiederum ist eine sehr große Baustelle und AMD und Intel geraten hier massiv in Zugzwang, wenn beide Firmen nicht versuchen möglichst bald auch entsprechend irgendwie den Takt mit zu gestalten und auch wenn die erste RT-Implementierung von Intel nicht schlecht ist und AMD mit RDNA3 vieles besser macht, hier dominiert aktuell NVIDIA und zwar auf allen ebenen, nicht nur bei Spielen, sondern auch im professionellen Bereich.

Beim Professionellen Bereich haben wir wiederum das leidige Theme HIP. Wie soll jemand etwas ohne HIP-RT für AMD-GPUs programmieren?

Bei den Games sehe ich das ein bisschen anders. Beim Rastern bringt RDNA3 die versprochene Performance nicht auf die Straße und hat Boden auf Nvidia verloren. Beim Raytracing konnte RDNA3 den Rückstand verkürzen.

NVIDIA kann sich bei CUDA relativ gemütlich zurück lehnen, den Markt haben sie weitgehend fest im Griff.

Hier finde ich den Ansatz gut, den AMD mit HIP verfolgt. HIP orientiert sich sehr stark an Cuda und kann auch sehr effizient für Nvidia Grafkkarten kompiliert werden.

Das eröffnet zumindest die Chance, dass jemand in Cuda geschriebene Software auf HIP portiert. Ob sich Leute überreden lassen HIP zu verwenden, um für Nvidia zu programmieren? Das wird hart.

Das geht sogat soweit, dass Leute GPGPU als "Erfindung" von NVIDIA ansehen und ATi/AMD vorwerfen, dass sie ja hier nur NVIDIAs "Innovationskraft" ausnutzen und stören wollen und sie ja deswegen OpenCL "ünterstützt" haben und dabei vollkommen vergessen, dass ATi mit der FireStream-API über ein Jahr vor NVIDIA ihr Produkt vorgestellt hat und NVIDIA hier "ATi" quasi hinterher liefen.

Und hier haben wir wieder etwas was sich Execution nennt.
Die war damals bei AMD und ATI nie so überragend, heute ne gute Idee, morgen ne schlechte Idee. Bei Nvidia gab es eben einen Plan und der wurde konsequent entwickelt und umgesetzt. Und wenn man etwas konsequent entwickelt und umsetzt, spielt es eben keine Rolle, ob man etwas später angefangen hat.

Bei AMD kam natürlich dazu, dass die Entwicklungsbudgets nach 2010 zusammengestrichen wurde.

Bei DL/ML ist NVIDIA zwar medial in "Techforen" stark vertreten und das erweckt bei manchen den Eindruck dass auch hier CUDA quasi der Goldstandard ist, zum Glück ist dem aber nicht so und die meisten Entwickler greifen auf die DL-Frameworks von Google (Tensorflow) oder Meta (PyTorch) zurück, die weitgehend darauf ausgelegt sind, dass man Hardware unabhängig.

Die nächsten zwei Jahre werden spannend. Wie viele der KI-Hardware-Startups können sich tatsächlich am Markt etablieren?

Gerade Xilinx bringt hier viel Erfahrung mit und war Forschungspartner für viele Projekte. Xilinx "Übernahme" ist für AMD hier absolutes Gold, weil man hier auf die Kompetenz von Xilinx zurück greifen kann.

IMO war die AIE einer der wichtigsten Gründe warum AMD Xilinx gekauft hat und der Grund warum sich Xilinx aufkaufen lies.

AMD hätte es unmöglich schaffen können abseits vom HPC etwas bei KI auf die Beine zu stellen. Und Xilinx war zu klein, um das Potential der AIE zu heben.

Klar, hier in den News scheint es so, dass NVIDIA vollkommen dominant ist, dass sind sie aber nicht wegen CUDA, sondern weil sie an der Stelle die beste Hardware fürs Training haben. Klar, AMD muss bei den eigenen Matrix/Tensor-Kernen aufholen, hier müssen Sie aber primär dann nur den "Treiber" für die Frameworks entsprechend stemmen und stehen nicht in Konkurenz zu CUDA.

HPC/GPGPU und ML/DL sind also Felder, bei denen AMD eher bei Consumern, die solche Seiten wie hier lesen, als abgeschlagen angesehen werden, im professionellen Bereich aber immer noch als Alternative - und nicht nur eine "günstige" - wahrgenommen werden und entsprechend auch Aufträge bekommen.

Hier wollen einige Firmen unbedingt eine Alternative zu Nvidia. Und deshalb sehen sie über Unzulänglichkeiten bei AMD hinweg und helfen AMD.

Hier wird sich in den nächsten 2 Jahren zeigen, ob sich AMD und Xilinx wechselseitig auf ein neues Niveau heben können.

Ein Problem hat AMD in diesem Bereich eher - und damit der Zirkelschluss zum ersten Absatz dieses Abschnittes - bei Anwendungen für Content-Creators. Im OpenSource-Bereich - Blender und Co - werden entsprechend Implementationen in der Regel von Entwicklern vorgenommen, die einen akuten Bedarf danach haben oder weil sie von den Herstellern unterstützt werden oder Hersteller auch entsprechende Ressourcen bereit stellen. Wenn AMD hier irgendwann "besser" sein will, dann müssen Sie Ressourcen für Blender und Co freischaufeln/schaffen, die die Entwickler dort unterstützen. Hier haben wir ein klassisches Henne-Ei-Problem. AMD schneidet nicht schlecht ab, aber auch eben nicht so gut, wie möglich wäre. Die Leute kaufen daher NVIDIA, weil es läuft und der Softwaresupport da ist. Die großen Firmen wiederum "optimieren" nicht für AMD, weil die Kundenbasis fehlt, wodurch wieder ... Zirkelschluss.

Hier war ich ehrlich gesagt sehr enttäuscht wie lange es gedauert hat, bis die HIP-Schnittstelle bei Blender in Betrieb gehen konnte und wie lange es jetzt wieder dauert bis HIP-RT für Blender verfügbar wird. Und das trotzt massiver Unterstützung von AMD.

Ich finde die Entscheidung von 2015 nach wie vor richtig, die wenigen Resourcen in die Entwicklung von ROCm zu konzentrieren. Nur damit konnte AMD wenigstens im HPC Fuss fassen. Aber so langsam müssen eben die nächsten Schritte kommen.

Dauerhaft erfolgreich kann AMD nur werden, wenn mit und für die verfügbaren RDNA-Grafikkarten GPGPU programmiert wird. Aber momentan ist das eigentliche Problem, überhaupt programmieren zu können.

Und bei RT droht AMD - und Intel - an dieser Stelle das gleiche Schicksal und genau deswegen ist es wichtig, dass AMD hier Ressourcen frei macht und auch das Geld in die Hand nimmt. ...

Ich habe mich im Detail nicht mit RT beschäftigt.

Was Nvidia eindeutig von AMD und Intel unterscheidet, ist wie zielstrebig und konsequent Nvidia sich Ziele setzt und diese dann auch umsetzt. Und sich eben dann nicht dafür feiert, sondern die nächsten Ziele setzt. Nvidia hat in den letzen beiden Jahrzehnten immer gut abgeliefert und dabei konsequent mehrere neue Geschäftsfelder aufgebaut bzw. zugekauft.

AMD arbeitet erst seit Lisa Su und Mark Papermaster an Bord sind konsequent. Forrest Norrod hat in einem Interview ausdrücklich schlechte Execution als das Hauptproblem von AMD in den 2000er Jahren genannt.

Wie Du andeutest steht und fällt AMD im Gamingbereich mit den Konsolen. Im PC-Markt ist AMD nach wie vor ein Underdog.

Das Nvidia durch neue Technologien den Performance-Hunger der Spiele und die Leistungsfähigkeit der GPUs pusht hat meiner Meinung nach klare Gründe. Nvidia kann keine APUs anbieten. AMD und Intel bieten immer stärkere APUs an.

Nur wenn der Performance-Hunger der Spiele kontinuierlich weiter steigt kann Nvidia die APUs auf Abstand halten. Das Problem für Nvidia ist der Notebookmarkt. Auf dem Desktopmarkt werden die APUs mit ihrem beschränkten Power-Budget immer nur Einsteigerlösungen bieten können.

Im Notebookmarkt ist das Powerbudget beschränkt und nur für ein Teilsegment des Marktes können sich die dGPUs wirklich austoben. in den nächsten Jahren wird der Anteil der Notebooks zunehmen, die keine dGPU mehr haben. Dafür sorgen sowohl AMD als auch Intel. Gaming-Notebooks mit starken dGPUs werden weiter nachgefragt und es werden IMO nur die schwachen dGPUs in den Notebooks seltener werden. Es sind nicht die margenträchtigen GPUs. Aber wie es so treffend heißt, auch Kleinvieh macht Mist.

Im Desktopmarkt bin ich wirklich gespannt wie es weitergeht. Die RTX4090 wird gut laufen, weil die Creators auf diese Karten setzen. Da sind wir einer Meinung. Diese haben aktuell und auf absehbare Zeit nur die Option bei Nvidia zu kaufen. Aber wie geht es mit den kleineren Karten weiter?

Wie viele Leute sind bereit die Preisspirale bei den Gaming-Grafikkarten mitzudrehen?