SpartanerTom schrieb:
Ich glaube bei den Konsolen ist für AMD (v.a. in der Vergangenheit) weniger die Marge als der tatsächliche garantierte Umsatz/Cashflow extrem wichtig gewesen.
Dazu kommt auch, dass Sony als auch MS Entwickler sowohl auf Hardware-Ebene als auch Software-Ebene abstellt, die AMD auch für andere Produkte nutzen kann, besser das, was dabei herauskommt.
engineer123 schrieb:
Die Idee von mehr als einem Kern in ner GPU ist doch schon alt, und auch mit den Modellen
Dual-GPU sowieso Crossfire/SLi industrialisiert worden.
Auch wenn die Grundaussage deines Beitrages stimmt, ist dein Beitrag in weiten Teilen falsch, weil er von den falschen Voraussetzungen ausgeht und hier verschiedene Probleme und verschiedene Ebenen mischt.
GPUs waren bereits in den 90er "Mehrkern-Prozessoren", weil sich gerade Aufgaben bei der Bildgenerierung sehr gut skalieren lassen.
SIMD und
SIMT sind hier heute die vorherrschenden Konzepte. 3dfx hatte entsprechend in der Prä-DX7-Ära auch ein einfaches System, wie die Aufgaben zwischen zwei GPUs quasi perfekt geteilt werden können und auch zwischen mehr Kernen. Voodoo 5 5500 als auch die Voodoo 5 6000 funktionieren wunderbar.
Die ersten Probleme - auch mit der "Synchronisation" kamen erst mit DX7 und DX8, aber auch hier hatte 3dfx beim Rampage eine relativ gute Lösung gefunden, in dem man ein getrennte GPU-Architektur entworfen hat. Eine "GPU" (in dem Fall Geometry-Processing-Unit) und eine "PPU" - Pixel-Processing-Unit. Die GPU hätte die T&L-Anweisungen sowie die Vertex-Shader ausgeführt und die PPU dann die Polygone gerastert, mit Texturen versehen und entsprechend die Pixel-Shader ausgeführt.
Das wäre dann in der Form sogar bis 2005/2006 und DirectX9.0c und dem Shader-Modell 3 relativ gut gegangen, bis Direct9.0c quasi die klassische Grafikpipeline über den Haufen geworfen hätte.
Aber auch dafür gab es bei 3dfx sogar schon erste Überlegungen. Es ist seit dem zwar schwerer geworden, aber die Probleme zwischen einem wirklichen "Multi-Chip"-GPU-Design kannst du nicht mit den Problemen eines Multi-GPU-Designs vergleichen.
Crossfire und SLI haben und hatten damals ganz andere Probleme. Während in der Zeit von DX8 und auch bedingt DirectX 9 AFR teilweise sehr gut funktionierte, fingen hier die Probleme erst mit dem Aufkommen der temporalen Effekte an, die heute aber allgegenwärtig sind in vielen Effekten, ohne dass man es mitbekommt. In diesem Fall gibt es - auch beim SFR - natürlich ein Problem mit der Datensynchronisation, soweit richtig, aber das liegt eben am Multi-GPU-Ansatz und den Wegen zwischen den Chips und den dadurch entstehenden Latenzen.
In einem echten Multi-Chip-GPU-Design können die Probleme der Synchronisation als auch Latenz jedoch ganz anders gelöst werden und sind daher quasi "nicht existent". Denn die Probleme der Synchronisation der Daten und der Latenz hat man heute sogar in monolithischen GPUs, da die Datenpfade entsprechend weit sind und die Caches viele Rechenwerke auf einmal versorgen müssen.
engineer123 schrieb:
Ergebnis: Es funktioniert einfach nicht richtig, weil man Stand heute es nicht geschafft hat die Arbeit
der mehrfach-Kerne voll und zu 100,00% zu synchronisieren.
Micro-Ruckel-ruckel-ruckel.
Was erneut primär für ein Multi-GPU gespannt gilt, besonders wenn es im AFR-Modus arbeitet. Würde man hier bereits in einen SFR-Modus gehen, könnten einige Probleme umgangen werden, gleichzeitig wäre aber keine Skalierung von bis zu 100 % mehr möglich.
Gerade ein SFR-Modus lässt sich heute auf Ebene des Treibers aber immer leichter umsetzen, da egal ob NVIDIA, Intel oder AMD, alle Grafikkarten mit einem Tiled-Based-Renderer arbeiten und das zu berechnende Bild in entsprechende Kacheln geteilt wird, die als Arbeitspakete von der GPU abgearbeitet werden.
Und hier ist dann auch der entscheidende Punkt, warum man ein Mutli-GPU-Design nicht mit einem Mutli-Chip-GPU-Design vergleichen kann. AMD hat nicht umsonst ein Patent in diesem Bereich, der die Kommunikation mehrere GPUs über einen L3-Cache definiert, hier kann man theoretisch aber auch den L2-Cache des GCD bei AMD nehmen, die über einen entsprechenden Link verfügen, der beide L2 als "Datenautobahn" verbinden. Klar entsteht dann eine gewisse Latenz zwischen dem L2-1 und dem L2-2, nur kann entsprechend eingepreist werden. Am Ende skalieren dann zwei GCD nicht zu 100 % - was ohne hin einen absoluten Idealwert darstellt, der kaum oder nie erreicht wird - aber vielleicht zu 80 - 90 %, was auch sehr gut ist.
Ebenso könnte man - AMD zeigt es bei CDNA3 - auch noch mal auf ein anderes System setzten und den Infinty-Cache zusammen mit dem RAM-Controller in ein Basetile auslagern und dann die GCDs auf diese setzten, was die Signalwege verkürzt und den Infinity-Cache zur Synchronistation nutzt.
Klar, AMD müsste hier natürlich noch einige Probleme lösen, die durchaus auch harte Nüsse sind, aber die Probleme einer echten Mutli-Chip-GPU lassen sich nur bedingt mit denen einer Mutli-GPU vergleichen. Eine Mutli-Chip-GPU ist nach "Außen" im Software-Stack nämlich eine GPU, keine Mutli-GPU, wie es bei Crossfire und SLI der Fall war.
.
