Chesterfield schrieb:
Das erinnert mich an die HD6870, mehr Cores als HD5870 dank 5D Design.
Die Probleme bei TeraScale sind an der Stelle aber etwas anders gelagert gewesen, weswegen es ja auch TeraScale 3 gab.
TeraScale war eine astreine VLIW-Architektur. Jeder Pixel war ein "Thread", der auf einem "Kern" lief, dieser hatte 5 ALUs, die über einen VLIW-Befehl angesprochen wurde. Das Konzept dahinter war auch nicht "Dumm", hatte nur das Problem, dass im ein Teil der ALUs brach liegen konnte. Bei TeraScale 3 wurde das auf VLIW 4 verändert (4D), weil dann in der regel r, g, b und der Alpha-Kanal abgedeckt wird. Ging auch nicht optimal auf, war aber besser.
Hier reden wir von einem Multi-Chip ansatz.
Chesterfield schrieb:
2x chipletts bedeutet sicher auch, eine Optimierung der Software . Ob das gut geht?? Bin gespannt
Jain, es kommt darauf an. 3dfx Voodoo 2 und später die VSA-100 waren für die Software (Spiel) nur wie eine GPU, hier hat der Treiber - was damals deutlich leichter war - die Zeilen auf die beiden Karten aufgeteilt. Durch diese Aufteilung gab es quasi eine fast perfekte Skalierung.
Das wird AMD für diesen Teil schwerere fallen, weil bei moderneren Spielen deutlich mehr "Kommunikation" notwendig ist, jedoch hat AMD bereits mit CDNA 2 und nun CDNA 3 erfahrungen sammeln können und auch Apple zeigt mit dem M1 und M2 Ultra, wie das gehen könnte.
Das Hauptproblem ist die Bandbreite zwischen den Chips, die sich aber durch entsprechende Nähe der Chips sowie einem passenden Interconnect gelöst werden kann - AMD hat hier seit Jahren am Infinty Fabric dahin gearbeitet.
Das zweite Problem ist der Cache und wie dieser mit den Daten umgeht und wie dann die Arbeitslast zwischen den Chips aufgeteilt wird. Da heute aber selbst AMD einen Tiled-Based-Renderer nutzt, ist auch das keine unlösbare Aufgabe, in dem man - wie z.B. Cinebench es macht - die Kacheln vorbereitet und als Arbeitsaufträge in die Queue schreibt und sich die Chips nach und nach die Kacheln abholen, so schnell wie sie eben sind. Hier ist die Frage nur, wie die Arbeit gleichmäßig aufgeteilt wird und die Wartezeit minimiert wird.
incurable schrieb:
Es gibt keinen effizienten Weg, zwei vollständige GPUs miteinander zu koppeln.
Bewirb dich mal bei AMD genau dafür, du kannst dann sicher ganz viel Geld einsparen und die Aktionäre sind dankbar.
C.J. schrieb:
azu kommt noch, dass AMD imho bei so einem Plan direkt auch auf drei Chips gegangen wäre, um den margenträchtigen Highend-Bereich mit abzugrasen.
Nein, nicht unbedingt. Gerade wenn sie hier den Treiber darauf vorbereiten müssen, dass er damit ordentlich arbeitet und sie die Auslastung nach oben korrigieren.
bei einer Mittelklassekarte kann man hier und dort mal entsprechende Probleme "verzeihen". Ein großen "Chip" wiederum, der mit den großen Nvidias konkurriert, könnte sowas das Genick brechen und damit auch AMD, weil hier deutlich weniger Verständnis ist für solche Spielereien.
Ansonsten weitgehend eine gute Ausführung, nur lässt du den Treiber außer acht, der sogar seit RDNA 3 bei AMD wieder etwas "mehr" Arbeit hat. Der Command-Processor scheint etwas entschlackt worden zu sein und ein Teil dessen Aufgaben sind in den Treiber gewandert. Das ist jetzt nur "Hörensagen" aus vielen verschiedenen Kommentaren.
Ansonsten: Nein, die Effizienzprobleme, gerade auch im 2D-Betrieb sind nicht auf den Multi-Chip-Ansatz zurückzuführen. Das zeigt sich gerade auch bei 7800 und 7900 mit "aktuellesten" Messungen. Die Probleme der Effizienz sind allgemeinerer Natur.
