Bericht GPU-Chiplets bei AMD: Das steckt im Patentantrag zur besseren Shader-Auslastung

Ja, das klingt machbar, wenn die Bauteile nahe beinander sind wie bei der APU, aber es wird wahrscheinlich auch in Zukunft daran kranken, dass man zuviele Anpassungen in Software bzw. Treiber machen muss für zu seltene Anwendungsfälle. Wenn es ein Entwickler macht, würde man es bestimmt zuerst in den Konsolen sehen.
 
  • Gefällt mir
Reaktionen: yummycandy und LamaMitHut
Das eigentliche Problem mit den bisherigen APUs von AMD ist, dass der einzige reale Anwendungsfall Games sind. Und dann kommt immer das Problem hoch, dass sie in der Leistung den dGPUs hinterherhinken. Zumindest sieht es so aus, dass sie wohl bald für viele Ansprüche bei FullHD genügen.

So wie ich es verstehe:
  • AMD hat auf der Hardwareseite alles vorbereitet, dass man Programmieraufgaben auf CPU und GPU verteilen kann.
  • Aber das Verteilen auf CPU und GPU und die Kommunikation müssen die Programmierer zu Fuß machen.
  • Und die Unterstützung von OpenCL, der einzig verfügbaren Programmierschnittstelle war euphemistisch ausgedrückt suboptimal.
  • OpenCL ist praktisch gescheitert. Nvidia hat Cuda durchgesetzt. AMD hat sich für HIP entschieden.
Und so ist die kuriose Realität, dass Anwendungssoftware die dGPUs von Nvidia nutzt weit verbreitet ist. Während es ein riesen Aufwand ist die dGPU von AMD zu nutzen. So wie ich es verstehe ist es für die APU noch viel schlimmer.

Der einzige Weg wie AMD das Ändern kann ist einerseits die ROCm auch für die Game-GPUs und die APUs nutzbar zu machen. Und noch wichtiger Systembibliotheken bereitzustellen, in denen die Benutzung der GPUs gekapselt ist.

Der Scheidepunkt wird die AIE sein. Wenn sich AMD wieder darauf beschränkt eine gute Hardware einzubauen, wird das ein Flop. Wie gesagt die iGPU der APU kann man wenigstens fürs Spielen verwenden. Für die AIE gibt es ohne dass Software dafür geschrieben wird, keine Anwendung. Aber der Vortrag von Victor Peng gibt wenigsten ein bisschen Anlass zur Hoffnung.

Ich habe oft genug geschrieben, das es nachvollziehbar ist, dass AMD 2015 alles auf das Pferd HPC gesetzt hat. Damals wurde das Thema HSA beerdigt und der Fokus auf ROCm gelegt. Inzwischen ist ROCm ziemlich vollständig und reift wohl auch aus. Aber das Tempo mit dem dies für den Desktop verfügbar wird ist erschreckend langsam. Hier ist ein klares Statement von AMD überfällig.

Zum Abschluss:
Bei Phoronix gab es neulich Benchmarks mit Blender für AMD- und für Nvidia-Karten. Bei AMD wurde HIP eingesetzt bei Nvidia Cuda und Optix.
  1. Bezogen auf die theoretischen Rechenleistung der Shader skaliert HIP vergleichbar wie Cuda. (Bei Phoronix nicht ersichtlich)
    1657119043237.png
  2. Die Nvidia-Karten (mit Cuda) haben eine erheblich höhere Performance bei Blender. Der Grund liegt darin, dass RDNA eine domainspezifische Architektur ist. RDNA benötigt weit weniger Rechenleistung um Games gut darzustellen. Wenn es aber auf die Rechenleistung ankommt, haben die RTX3000 deutlich mehr zu bieten.
  3. RTX3000-Karten haben mit Optix eine erheblich höhere Leistung als mit Cuda. Das ist kein Wunder, denn beim Raytracing sollte die Raytracinghardware nutzen. HIP nutzt aktuell nicht die Raytracing-Einheiten von RDNA 2. In den nächsten Monaten soll die Unterstützung kommen.
 
  • Gefällt mir
Reaktionen: incurable und ComputerJunge
@ETI1120 Der eigentliche Clou an AMDs Lösung soll sein, daß sich entgegen früherer Lösungen der Programmierer nicht darum kümmern muß, wieviele GPU Teilkomponenten vorhanden sind. Vielmehr soll die Hardware sich weiterhin nach außen als eine GPU präsentieren. Es wird aber sicherlich weiterhin Unterschiede geben, wie man die GPUs der verschiedenen Hersteller am optimalsten mit Aufgaben füttert. AMD soll das aber spätestens mit RDNA2 für die Hersteller weitaus einfacher gelöst haben, als noch mit GCN.
Es wird also mindestens einen vereinfachten HW Scheduler geben müssen, der unabhängig von der Aufgabe die Häppchen optimal verteilt. Ob man dann programmatisch noch Einfluß nehmen kann, weiß ich nicht.
 
yummycandy schrieb:
@ETI1120 Der eigentliche Clou an AMDs Lösung soll sein, daß sich entgegen früherer Lösungen der Programmierer nicht darum kümmern muß, wieviele GPU Teilkomponenten vorhanden sind. Vielmehr soll die Hardware sich weiterhin nach außen als eine GPU präsentieren.
Das ist der Kern von allen 4 Patenten, es ist nach außen eine GPU.

Was ich beschrieben habe ist nicht redern sondern GPGPU. Hier müssen die Programmierer explizit Programmieraufgaben der GPU zuweisen. Und Cuda ist die Programmierschnittstelle die sich durchgesetzt hat.
 
  • Gefällt mir
Reaktionen: incurable
Colindo schrieb:
Ich bezog mich aufs "Probleme lösen." Dabei denke ich an den Aufbau des I/O-Die von Zen 2, den L3-Cache von RDNA 2, die WGPs mit eigenem L1-Cache von RDNA, die Implementierung von Raytracing in die Shaderstruktur etc. Das sind alles innovative Lösungen fernab der Ordinarität bei denen mindestens der Kernaspekt war, eine Verteilungslogik zu erstellen, die die Recheneinheiten gut auslastet.
Na klar, verkauf ruhig weiter den Rückschritt auf eine Northbridge als "innovative Lösung" und mehr Cache oder die Implementierung von Raytracing als zusätzliche Verteilungslogik.

Alles weitab von diesem Patent, aber Hauptsache mal irgendwas in den Ring geworfen.
Ergänzung ()

Novasun schrieb:
Ehm nein. SLI und Crossfire waren noch so aufgebaut das jede GPU an einem eigenen Bild arbeitete... Das macht AMD nicht mehr. Alle arbeiten an einem Bild - und die Workunits müssen bei AMDs Ansatz eben nichts mehr von einander wissen... Denn der Boss hat saubere Arbeitspakete geschnürt...
Wenn man 3D-Lasten "sauber" trennen könnte, wären SLI und Crossfire noch am Leben. Sind sie aber nicht.
Ergänzung ()

Vitec schrieb:
Anscheinend dürfte das aber nicht ganz so wirtschaftlich sein, umsonst wird nicht in die Chiplet Richtung geforscht und optimiert. Bei AMD war das Chiplet bis 3700 auch nicht so effektiv, aber bis dahin eine finanziell sehr gute Möglichkeit um Boden gut zu machen.
Bei Zen und Zen+ gab es im Massenmarkt keine Chipsletten, sondern nur zwei monolihtische SOCs, eines mit und eines ohne integrierte Grafik.
Ergänzung ()

ETI1120 schrieb:
Es ist offensichtlich dass die Verbindungen in einer aus gestapelten Chiplets aufgebauten GPU oder CPU sind kürzer als auf einem monolithischen Die. Also ist auch die Verteilung der Last viel einfacher.

Natürlich gibt es Gründe warum man es aktuell noch nicht macht.
  • Durch das Hybrid Bonding mit einem Abstand von 9 µm steht jetzt die Verbindungstechniktechnik bereit. Der 3D V-Cache war nur der Anfang.
  • Die Stromzufuhr durch die vertikalen Verbindungen (TSVs) ist nicht trivial, da sie mit Schaltkreisen interagiert. Deshalb sind sogenannte Keep Out Zonen erforderlich.
  • Und das große Problem ist dass Logikschaltkreise viel Verlustwärme abgeben. Und die muss abgeführt werden. Die thermische Simulation von Stacks und die Lösungssuche für die Wärmeabfuhr aus Stacks sind aktuell große Forschungsthemen.
"Forschungsthemen" :D Während Du Dich über kurze Signalwege freust kommt die Abteilung Thermodynamik mit der ganz großen Keule um die Ecke und zeigt mit dem extragroßen Schaumstofffinger auf die Temperatursensoren.
Ergänzung ()

SoDaTierchen schrieb:
Der Zugriff auf dem VRAM findet gestützt durch den Infinity-Cache an denselben VRAM statt.
Nicht wenn Du Deine Recheneinheiten gern ausgelastet hättest. (ich hab gehört, das ist grundsätzlich eine Gute Idee ;-))

SoDaTierchen schrieb:
Außerdem wird der Scheduler so umstrukturiert (2-Level-Binning), dass dieser effizienter mit Chiplets umgehen kann, was den Overhead reduzieren dürfte.
Achso, na dann. Das hat bestimmt noch NIE vorher jemand versucht. :D

SoDaTierchen schrieb:
Und bedenke: Nur, weil eine Lösung in der Theorie langsamer ist, muss es in der Praxis keine Bedeutung haben. Die Latenzen der Grafik-Pipelines zwischen zwei GPU-Generationen steigen teils deutlich, die Pipelines werden länger. Trotzdem sind die neueren GPUs schneller. Denn die Nachteile bei der Pipelinelänge haben zu großen Vorteilen beim Takt geführt, was mit kürzeren Pipelines nicht möglich wäre.
Das ist ja alles wunderbar, nur ist die Optimierung von Taktraten erstens eine andere Baustelle und zweitens nicht wahnsinnig innovativ.

SoDaTierchen schrieb:
Das heißt selbst der offensichtliche Nachteil bei Multichip-GPUs kann sogar ein Vorteil sein.
Wahrscheinlich wenn miese Auslastung zu geringeren Temperaturen in den Tochterchipsletten führt.
Ergänzung ()

Atent12345 schrieb:
Je nach Aufbau könnte sie sogar fallen, wenn sich die Leitungslängen an manchen Stellen dadurch reduzieren lassen.
Wer Chipsletten stapelt spart Latenz, holt sich stattdesser aber extreme thermische Probleme ins Haus.

Ich rate mal, dass allein dadurch ungestapelte Chipsletten trotz langsamerer Verbindung unterm Strich mehr leisten als gestapelte.
Ergänzung ()

pipip schrieb:
Denn das haben wir damals bei Zen1 auch gelesen.
Und was ist Zen? Ein SOC mit langsamen Kernen, in 2 extrem langsam verbundenen Kerngruppen, und mit im Rückblick geradezu erschreckend begrenzter Leistung im Massenmarkt.

Aber AMD konnte (zur Abwechslung mal ohne Flunkern) mit vielen Kernen werben. Und damit wurde das Ziel Überleben erfolgreich erreicht.
 
Zuletzt bearbeitet:
incurable schrieb:
Ich rate mal, dass allein dadurch ungestapelte Chipsletten trotz langsamerer Verbindung unterm Strich mehr leisten als gestapelte.
Aber hast du es mal ausprobiert?
So groß sind die Einschränkungen bei der Wärmedichte die sinvoll übertragen werden kann nicht.
Da sind moderne LVT CPUs schon der worst case.

Für die gestapelten DIEs gibt es bei TSMC ja mittlerweile sogar extra Wafer mit anderer Ausrichtung der Kristallstruktur um die gute Wärmeleitung nach oben zu haben. Was auch sehr gut funktioniert ist es die IO und Cache Komponenten nach unten zu packen und die power rails über vertikales bb bonding mit den oberen Dies zu verbinden.
 
@incurable : Du übersiehst bei deiner "Argumentation" aber, dass du komplett die Realität ignorierst. Du ziehst Zen als ideal schlechtes Beispiel heran, bedenkst aber nicht, dass AMD durch das Multichip-Design einen Vorteil am Markt hatte, für den Intel erstmal 2 Jahre brauchte um überhaupt halbwegs mitzuhalten. Du bezeichnest höhere Taktraten als "wenig innovativ", aber ganz ehrlich, "mehr Leistung" ist ja noch weniger innovativ, trotzdem ist das das Ziel. Seit über 30 Jahren.

Es ist ja vollkommen okay, dass du dem Multichipdesign keine Zukunft zutraust, weil du Bedenken hast. Aber warum hältst du so stark und teils persönlich angreifend gegen Leute mit anderer Meinung, die im Mittel sogar deutlich bessere Argumente haben als Ironie und unbegründete Behauptungen? Lass doch auch andere Meinungen existieren, wer Unrecht hat und wer nicht wird sich sowieso in spätestens 3 Jahren zeigen.

Ich glaube halt immernoch, dass Multichip-Designs bei GPUs die "Fesseln" monolithischer Designs lösen und in spätestens 2-3 Generationen nicht mehr wegzudenken sind.
 
@incurable
was ist denn mit dir los ? bist du auf einem persönlichem Feldzug gegen Chiplet design oder hast du einfach nur Spaß am negativ sein ?
SoDaTierchen schrieb:
Ich glaube halt immernoch, dass Multichip-Designs bei GPUs die "Fesseln" monolithischer Designs lösen und in spätestens 2-3 Generationen nicht mehr wegzudenken sind.
yup, selbst Nvidia will ja in der nächsten Serie nach der 4xxx auf Chiplet design umsteigen, d.h. die bauen da aktuell jetzt schon ne ganze Weile daran rum.
 
  • Gefällt mir
Reaktionen: SoDaTierchen
  • Gefällt mir
Reaktionen: Colindo
pvcf schrieb:
@incurable
was ist denn mit dir los ? bist du auf einem persönlichem Feldzug gegen Chiplet design oder hast du einfach nur Spaß am negativ sein ?

...
Nach dem ich hier den ganzen Thread gelesen hab geht es irgendwie bei ihm durchgehend genau gegen einen Hersteller. Was generell ja ok ist wenn man sich so positionieren möchte, aber man sollte glaub ich davon Abstand nehmen andere Personen und ihre Meinungen herabzuwürdigen. Und nichts anderes ist das wenn man anstatt Argumente zu entkräften sich über sie lustig macht. Just my 2 cents. 🤷‍♂️
 
Colindo schrieb:
Ja, das klingt machbar, wenn die Bauteile nahe beinander sind wie bei der APU, aber es wird wahrscheinlich auch in Zukunft daran kranken, dass man zuviele Anpassungen in Software bzw. Treiber machen muss für zu seltene Anwendungsfälle. Wenn es ein Entwickler macht, würde man es bestimmt zuerst in den Konsolen sehen.
https://www.uciexpress.org/why-choose-us

In Verbindung mit Universal Chiplet Interconnect Express könnte das ganze (ein master Chiplet das Aufgaben an an andere Chiplet verteilt) aber wirklich spannend werden. Sowas wäre doch auch und insbesondere im Mobiltelefon, wenn jedes Watt zählt.
 
@LamaMitHut Sowas wird man brauchen, wenn man in Zukunft wie AMD es vorhat fremde Chiplets mit in die Prozessoren integrieren wird. Kein Wunder, dass die einen offenen Standard pushen. Sieht auch so aus als wäre praktisch jeder aus der Branche Mitglied außer Nvidia :D
 
@Colindo

Ist mir aufgefallen, könnte bitter werden wenn intel für spätere Produkte ein Grafikchiplet benötigt. :D
 
  • Gefällt mir
Reaktionen: Colindo
SoDaTierchen schrieb:
Du übersiehst bei deiner "Argumentation" aber, dass du komplett die Realität ignorierst.
Es steht Dir natürlich frei an die heilende Wirkung von zusätzlichen Verteilungsebenen wie in den hier berichteten Patenten zu glauben.

Den Hinweis, dass es sich dabei weder um eine neue Idee handelt, noch dass besagte Idee in der Vergangenheit trotz mehrere Anläufe nennenswerte Erfolge ergeben hätte, dürfte das genaue Gegenteil davon darstellen, "Realität zu ignorieren".
Ergänzung ()

Traumsucher schrieb:
Nach dem ich hier den ganzen Thread gelesen hab geht es irgendwie bei ihm durchgehend genau gegen einen Hersteller
Es geht hier um das Patent genau eines Herstellers. 🤷‍♂️
 
Zuletzt bearbeitet:
incurable schrieb:
Den Hinweis, dass es sich dabei weder um eine neue Idee handelt, noch dass besagte Idee in der Vergangenheit trotz mehrere Anläufe nennenswerte Erfolge ergeben hätte, dürfte das genaue Gegenteil davon darstellen, "Realität zu ignorieren".
dein "Hinweis" wurde mehrfach entkräftet, die Tatsache dass du dies offensichtlich ignorierst grenzt halt an Realitätsverweigerung. egal, willkommen auch in meiner ignorliste
 
pvcf schrieb:
dein "Hinweis" wurde mehrfach entkräftet, die Tatsache dass du dies offensichtlich ignorierst grenzt halt an Realitätsverweigerung.
Wer glaubt die Existenz von SLI, Crossfire, Lucid & Co "entkräften" zu können, muss sich nicht wundern, wenn solche Behauptungen nicht verfangen.
 
incurable schrieb:
Wer glaubt die Existenz von SLI, Crossfire, Lucid & Co "entkräften" zu können, muss sich nicht wundern, wenn solche Behauptungen nicht verfangen.
Lucid sagt mir jetzt nichts, aber was sollen SLI und Crossfire mit dem Thema zu tun haben?
 
  • Gefällt mir
Reaktionen: Colindo
LamaMitHut schrieb:
Lucid sagt mir jetzt nichts, aber was sollen SLI und Crossfire mit dem Thema zu tun haben?
Es geht um die Verteilung einer Last auf mehrere integrierte Schaltkreise, welche Maßnahmen dabei bereits angewendet wurden und welche Effekte sie erzielen konnten bzw können.

Wenn Du mehr Informationen zu Lucid suchst, findest Du sie am einfachsten unter ihrem ersten Namen LucidLogix oder in Verbindung mit ihrer Marke Hydra.
 
Zurück
Oben