> > > > Next-Gen GPU: Warum ein Multi-Chip-Ansatz für Navi alles andere als trivial ist

Next-Gen GPU: Warum ein Multi-Chip-Ansatz für Navi alles andere als trivial ist

Veröffentlicht am: von

amd-radeonIn der vergangenen Woche sorgt die Meldung, dass AMDs Navi-Architektur die Mittelklasse bedienen und keine High-End-GPU werden würde, für großes Aufsehen. In den Kommentare entbrannte dabei auch eine Diskussion darüber, ob AMD eine Navi-GPU mit beispielsweise 2.048 Shadereinheiten entwickelt, damit diese die Mittelklassse bedienen kann. Per Multi-Chip-Module (MCM) analog zu den Ryzen-(Threadripper)-Prozessoren könnten dann aber einfach zwei oder vier solcher Navi-Module verwendet werden, um eine entsprechend leistungsstärkere GPU anzubieten.

Als Basis für diese Gedankengänge dient AMDs eigene Beschreibung der Navi-Architektur, denn in früheren GPU-Roadmaps war immer die Rede von NextGen Memory und Scaleability. Während für NextGen Memory nur die Rede von GDDR6 oder HBM3 sein kann, bezieht sich Scaleability wohl auf eben diesen Ansatz: Die Architektur soll entsprechend breiter aufgestellt werden, indem es verschiedene Ausbaustufen gibt. Prinzipiell ist dies bei den aktuellen Architekturen von AMD und NVIDIA heute schon der Fall, allerdings sprechen wir dann noch immer von monolithischen Chips, die im Falle von NVIDIAs GV100 inzwischen 815 mm² groß sind. Bei den Prozessoren sind wir inzwischen bei ähnlichen Größen angekommen. Für die Ryzen-Threadripper- und Epyc-Prozessoren verwendet AMD aber ein MCM-Design bestehend aus vier Dies zu je 213 mm² = 852 mm². Intel hingegen bleibt dem monolithischen nich immer Treu und erreicht damit inzwischen 720 mm² für Knights Corner und 698 mm² für Skylake SP/X.

Also spielen wir eine GFX10/Navi-Architektur im MCM-Design einmal durch und schauen uns dabei vor allem die technischen Hürden an, die sich auch für MCM bei den Prozessoren bereits zeigen:

Ein MCM-Design für GPUs hätte hinsichtlich der Fertigung und Kosten große Vorteile. Anstatt eines großes Chips werden mehrere kleinere, deren Ausbeute gut ist und deren Fertigungskosten gering sind, zusammengeschaltet. Der Overhead eines MCM-Designs gegenüber einem monolithischen Ansatz beträgt laut AMD etwa 10 % (für Epyc/Ryzen Threadripper 777 mm² zu 852 mm²). Für das Beispiel der Prozessoren liegen die  Kosten für das MCM-Design beim Faktor 0,59 gegenüber einem monolithischen Design. Diese Werte dürften sich auch in etwa so auf eine GPU übertragen lassen.

Auch bei NVIDIA wird an MCM-Design für GPUs geforscht. Dabei kommen GPU-Module (GPM) zum Einsatz, welche zum Beispiel in einem Mesh mit weiteren solchen Modulen in einem MCM zusammengebracht werden. Es handelt sich dabei um spezielle MCM-GPUs, die auf die Bedürfnisse in einem MCM angepasst sind. Damit erreichen die Forscher eine um den Faktor fünf reduzierte interne GPU-Kommunikation über einen internen Interconnect und gleichzeitig kann die Leistung des einzelnen GPM um 22,8 % gesteigert werden. 

Ein schneller Interconnect ist das größte Problem

Schwierig wird es bei den grundsätzlichen Funktionsweisen einer GPU. Einige der Herausforderungen eines MCM-Designs einer GPU zeigen sich auch schon bei den Prozessoren. Für Ryzen, Ryzen Threadripper und Epyc verwendet AMD den eigens entwickelten Infinity Fabric zur Kommunikation der einzelnen Dies untereinander, aber auch für die Anbindung nach außen. Hier spielen vor allem die Speichercontroller eine Rolle, was sich im Falle von Ryzen Threadripper in den unterschiedlichen Speichermodi Non-Uniform Memory Access (NUMA) und Uniform Memory Access (UMA) äußert. Auch bei den Ryzen-Prozessoren zeigt sich eine gewisse Abhängigkeit von schnellem Speicher und möglichst geringen Latenzen innerhalb der CCX-Cluster.

AMD erreicht in seinen Prozessoren eine Die-zu-Die-Bandbreite von 42,7 GB/s und eine Systembandbreite von bidirektionalen 170,7 GB/s. Im Falle von GPUs sind selbst diese kombinierten 170,7 GB/s aber viel zu wenig, denn wir sprechen hier von Speicheranbindungen im High-End-Bereich von 512 bis 1.024 GB/s – also dem Vielfachen dessen, was derzeit über Infinity Fabric möglich ist. Wie wichtig ein schneller Interconnect aber ist, zeigte die Vorstellung des NVSwitch von NVIDIA, der den NVLink-Interconnect über 16 GPUs mit bis zu 7,2 TBit/s verteilt, was etwa 900 GB/s entspricht und damit der Bandbreite des Speichers entspricht. Speicherbandbreite ist das eine, innerhalb einer GPU werden allerdings auch Terabyte an Daten pro Sekunde von und zu den L1-, L2- und L3-Caches geschoben. Eine GPU aus zwei oder mehr Dies teilt sich einige dieser Ressourcen und muss daher untereinander kommunizieren.

Bandbreite ist das eine Thema, Stromverbrauch das andere. Ein Interconnect ist nicht nur hinsichtlich der Anbindung alles andere als trivial, sondern auch was die Leistungsaufnahme betrifft. Ein NVSwitch kommt auf eine Leistungsaufnahme von knapp unter 100 W wenn alle 576 NVLink-Lanes verwendet werden. Aber auch wenn auf einem GPU-Package deutlich weniger Lanes benötigt würden, wäre die Leistungsaufnahme ein Hauptthema für den Einsatz eines solchen Interconnects.

Am Ende ist entscheidend, wie schnell sich der HBM an die einzelnen Dies anbinden ließe. Die UMA/NUMA-Modi der AMD-Prozessoren zeigen das Problem deutlich auf auf einer ähnlichen Ebene wäre dies auch für eine GPU die technische Herausforderung.

MCM-GPU benötigt spezielle Rendermodi

Aus Sicht der Fertigung wäre der notwendige Interconnect also eine recht große Hürde für ein MCM-Design einer GPU. Es kommen aber noch weitere hinzu.

Wie teilt sich ein GPU aus mehreren Dies die Arbeit auf? Hier kommt natürlich recht schnell der Multi-GPU-Ansatz ins Spiel – mit all seinen Nachteilen. Die Diskussion um Alternate Frame Rendering (AFR) und Split Frame Rendering (SFR) haben in der Vergangenheit bewiesen, dass sie nicht der Weisheit letzter Schluss sind. Auch das eigentlich für SLI namensgebende Scan-Line Interleave ist nach heutigen Erkenntnisse keine Maßnahme, um das Rendering eines Frames sinnvoll auf zwei oder mehr GPUs zu verteilen.

Am effektivsten dürfte ein Checker Board/Supertiling sein, also eine Aufteilung des zu berechnenden Frames in mehrere kleine Bereiche. Beim Ray Tracing und dem 3D-Rendering mit Workstation-Karten kommt eine solche Technik bereits zum Einsatz und hat sich hier als relativ effektive Methode herausgestellt. Allerdings sprechen wir dabei noch nicht von einem Echtzeit-Rendering mit 60 FPS, was Auswirkungen auf die Darstellung der gerenderten Frames hat. Eine Art Load Balancer müsste sicherstellen, dass alle Bereiche des Frames zur gleichen Zeit durch die zwei oder mehr GPUs berechnet werden und absolut zeitgleich ausgegeben werden. Wie gesagt, all diese Probleme kennen wir schon von Multi-GPU-Ansätzen wie SLI und CrossFire und die enormen Herausforderungen auf Seiten der Hardware haben wohl auch dazu geführt, dass Multi-GPU-Rendertechniken für das Gaming eine immer geringere Rolle spielen.

Zur Reduzierung der internen Bandbreite und Aufteilung des Renderings auf die zur Verfügung stehenden Ressourcen verwenden aktuelle GPUs bereits ein Tile Based Rendering. Das Gegenkonzept zu Tile Based Rendering (TBR) ist das Immediate Mode Rendering. Dabei wird der Rasterization-Prozess über den kompletten Frame angewendet, während beim Tile Based Rendering der Frame in viele kleine Tiles, also rechteckige Blöcke aufgeteilt und der Rasterization-Prozess durchgeführt werden kann. Typischerweise sind diese Tiles 16x16 oder 32x32 Pixel groß. Diese Parallelisierung kommt den aktuellen GPUs mit mehreren Tausend Shadern natürlich positiv entgegen. Das Immediate Mode Rendering hingegen ist besonders hinsichtlich des Speicherbedarfs recht aufwendig.

Doch das Tile Based Rendering hat nicht nur Vorteile. Nahezu alle Spiele und weitere Anwendungen sind auf ein Immediate Mode Rendering ausgelegt und dahingehend optimiert. Für die Maxwell- und Pascal-Architektur musste sich NVIDIA daher einige Tricks einfallen lassen, damit das Tile Based Rendering seine Effektivität ausspielen kann. Dazu gehört auch spezieller DirectX-Code, der sich spezifisch an die Triangle-Rasterization richtet. Außerdem belässt das Tile Based Rendering Bereich der Grafik-Pipeline unangetastet. Dazu gehört das Tessellation, Geometry-Setup, Shader und vieles mehr.

Es ist also neben der Problematik des Interconnects auch hinsichtlich der Software und des Renderings keine einfache Lösung für eine MCM-GPU in Sicht bzw. uns nicht bekannt.

Vom Ansatz spannend, doch es gibt Fragezeichen

Die Antwort, ob AMD die Navi-Architektur als MCM-Design auch in das High-End-Segment übertragen kann, werden wir heute nicht beantworten können. Wir wissen ja noch nicht einmal, ob AMD mit Navi wirklich wie vermutet auf die Mittelklasse abzielt oder nicht doch ganz andere Pläne hat.

Dennoch ist es einmal interessant sich über ein MCM-Design einer GPU einmal ein paar Gedanken zu machen, wenngleich diese noch nicht zu einer abschließenden Lösung führen.

Social Links

Ihre Bewertung

Ø Bewertungen: 5

Tags

Kommentare (31)

#22
Registriert seit: 28.01.2016

Leutnant zur See
Beiträge: 1227
Zitat sekas;26268537
Dennoch zeigt HBM mMn dass es möglich ist eine hohe BAndbreite zwischen verschiedenen Chips zu realisieren.

HBM kommuniziert nicht - das tut der Grafikchip mit seinem Speichercontroller (welcher auf HBM Speicher zugreift).

Zitat sekas;26268537
Und ich denke dass somit zwischen 2 GPUs mindestens die selbe bandbreite erreichbar wäre wie zwischen GPU und CPU.

Das wäre deutlich zu langsam. GPU <-> CPU ist mit PCI-E 16 und seinen ~16GBs ist im vergleich zu einer HBM-Speicheranbindung vom 400-500 GBs doch recht dürftig.

Zitat sekas;26268537
Da ist nciht wie bei Spielen die Busanbindung nur im einstelligen bereich ausgelastet.


Welcher Busanbindung ist gemeint?
#23
customavatars/avatar3377_1.gif
Registriert seit: 15.11.2002
www.twitter.com/aschilling
[printed]-Redakteur
Tweety
Beiträge: 30656
Ich kann mich nur auf die MCM-GPU-Studie von NVIDIA beziehen. Diese besagt es sei eine Package Bandbreite von 1,2 TB/s und eine Inter-Modul-Bandbreite von 10 TB/s notwendig. Davon sind wir noch etwas entfernt.
#24
Registriert seit: 05.11.2007
Neckar-Odenwald Kreis
Kapitän zur See
Beiträge: 3596
Oder eine Redundanz der Daten beim VRAM der einzelnen Module um Speicherzugriffe auf den anderen Chip zu minimieren. Im lokalen Speicher bleibt eine Kopie von allem womit gerade gerechnet wird. Der Speicher müsste also mehr wie ein Cache funktionieren.
#25
Registriert seit: 11.07.2013

Obergefreiter
Beiträge: 110
Zitat kozfogel;26268641
HBM kommuniziert nicht - das tut der Grafikchip mit seinem Speichercontroller (welcher auf HBM Speicher zugreift).


wirkt der interposer dann nicht torzdem wie ein Bus? sollte doch egal sein ob an einem ende ein passiver oder ein aktiver sender sitzt? Im endeffekt sollten sich doch ähnliche datenraten erreichen lassen, oder?


Zitat kozfogel;26268641
Das wäre deutlich zu langsam. GPU <-> CPU ist mit PCI-E 16 und seinen ~16GBs ist im vergleich zu einer HBM-Speicheranbindung vom 400-500 GBs doch recht dürftig.

Sorry sollte nciht GPU - CPU sondern GPU - HBM heißen. PCIe ist natürlich deultich langsamer ;)



Zitat kozfogel;26268641
Welcher Busanbindung ist gemeint?

hier beziehe ich mich auf die PCIe.
bei Spielen ist bspw die leistungseinbuse zwischen 8x PCie 2.0 und 16x PCIe 3.0 sind nahezu vernachlässigbar (bzw waren es vor ein paar jahren mal)
bei Deep learning hingegen ist der Bandbreitenbedarf deutlich größer. und genau darauf ziehlt Nvlink ab (wurde zumindest bei uns so präsentiert)

Hab jetzt allerdings keine tieferen schaltungstechnischen kenntnisse, kann also gut sein dass ich auch falsch liege :D
#26
Registriert seit: 22.02.2010

Bootsmann
Beiträge: 759
PCI ist viel zu langsam für derartige Aufgaben sonst würde man ja auch kein Vram benötigen und alles über den Systemspeicher abwickeln.
PCI 16x dürfte 64GB/s maximal schaffen während sich HBM bei ca 250GB/s je Stack bewegt.

Aber das genau funktioniert ja so einfach nicht weil die Daten auch von anderen Chips benötigt werden. Gerade der lokale Cache (L1-L3) ist ja vorhanden und genau die Daten kriegt man nicht schnell genug in den Nachbarchip damit er damit arbeiten kann. Früher hätte ich evtl. gesagt okay GPU1 berechnet alles innerhalb 50m, GPU2 alles 50m+. Nur heute gibt es soviele Effekte welche alles beeinflussen, geschweige den Echtzeitraytracing was irgendwann kommt das man so eine einfache Trennlinie nicht mehr ziehen kann.
#27
Registriert seit: 28.01.2016

Leutnant zur See
Beiträge: 1227
Zitat sekas;26268747
wirkt der interposer dann nicht torzdem wie ein Bus? sollte doch egal sein ob an einem ende ein passiver oder ein aktiver sender sitzt? Im endeffekt sollten sich doch ähnliche datenraten erreichen lassen, oder?


Der haupt Unterschied ist das es hier eine 1:1 Verbindung ist, und der Chip die alleinige Kontrolle hat - sobald man da ein "switch" einbaut welches Zugriffe verwalten muss, sinkt die Datenrate erheblich und Latzen steigen.

Zitat sekas;26268747
hier beziehe ich mich auf die PCIe.
bei Spielen ist bspw die leistungseinbuse zwischen 8x PCie 2.0 und 16x PCIe 3.0 sind nahezu vernachlässigbar (bzw waren es vor ein paar jahren mal)
bei Deep learning hingegen ist der Bandbreitenbedarf deutlich größer. und genau darauf ziehlt Nvlink ab (wurde zumindest bei uns so präsentiert)

Hab jetzt allerdings keine tieferen schaltungstechnischen kenntnisse, kann also gut sein dass ich auch falsch liege :D



Das liegt daran das über die PCI-E Schnittstelle nur "Ergebnisse" ausgetauscht werden. Die Grafikkarte muss nicht auf Ressourcen im Hauptspeicher zugreifen, solange der eigene speicher reicht. Wenn das passiert, geht die FPS in den Keller - genau dafür braucht man diese hohen Datenraten. Bei einem SLI/CF System zB wird es dadurch umgangen dass die Daten redundant auf jeder GPU gelagert werden - was natürlich bei einem MCM nicht sein sollte.
#28
customavatars/avatar43872_1.gif
Registriert seit: 31.07.2006

Kapitän zur See
Beiträge: 3195
Bei dem Thema haben viele denke ich einfach ne falsche Vorstellung. Gesetzt des Falles, AMD würde Navi wirklich per-Chip-skalierbar machen, dann würde das nicht aussehen, wie ein SLI/CF-Gespann. Man braucht Hardware um effizient zu sein, AFR und SFR sind jedoch Softwarelösungen. Und da greift der Artikel schon an die richtige Stelle. Wenn wir in die Vergangenheit schauen, sehen wir bei 3dfx skalierbare Architekturen. Mit einfachem DX7-Rendering (shaderlos) war es möglich ber SLI zu arbeiten und die Renderchips einfach hochzuskalieren, diese Chips waren jedoch aus heutiger Sicht reine Backends. Bei Spectre/Rampage änderte sich alles aufgrund der neuen DX8-Shaderarchitektur. Man teilte damals in Vertex und Pixelshader auf, Vertexshader Spectre war ein Vertexshader-Zusatzcontroller (transparent für die Architekur, deshalb Spectre) und Rampage war der eigentliche Grafikprozessor mit Pixelshader, welcher wiederum skalierbar war aber eben sehr schwer zu beherrschen. Leider endete damit ja die Story, das ist ja bekannt.
Seit AMDs Xenos und NVs G80 bieten die Hersteller jedoch GPUs mit unified shadern an, welche Geometrie und Pixelberechnungen in denselben Recheneinheiten ausführen und somit eine Chip-Skalierung sehr kompliziert machen. Man unterscheidet nicht länger zwischen Geometriechips und Renderchips sondern wie beim Prozessor zwischen Frontend und Backend. Die einzige Skalierbarkeit, die ich dort sehe, wäre, wenn man hier die Trennlinie zieht. Man braucht einen Frontendchip, der den Framebuffer bildet der dann ALU-Coprozessoren anbindet mit entsprechend hoher Bandbreite. Beispielsweise bräuchte man einen Mainchip, der bis zu 3 Backends anbinden kann mit 3x je 64Bit breitem Interfache, jeder Backendchip kann dann meinetwegen, 2K Shader beinhalten. Das Ganze muss man mit relativ großen Caches versehen, um die Latenzen abzufangen (wie Zen das macht). Zusammenfassend kann man sagen, dass GPU-Skalierung alles andere als umsonst ist, dennoch könnte der Kostenvorteil entscheidend sein. Das Ganze muss auf einem Interposer realisiert werden, da nur dieser schnelle Direktverbindungen in großer Bandbreite ermöglicht und den Stromverbrauch in Grenzen hält. Denn der Stromverbrauch ist die Archillesverse einer Multi-Chip-Architektur. 7nm ist so teuer, dass es erstmals lohnend sein kann, eine MCM-Architektur für GPUs zu designen.
#29
Registriert seit: 30.04.2008
Civitas Tautensium, Agri Decumates
Leutnant zur See
Beiträge: 1051
Zitat Don;26268684
Ich kann mich nur auf die MCM-GPU-Studie von NVIDIA beziehen. Diese besagt es sei eine Package Bandbreite von 1,2 TB/s und eine Inter-Modul-Bandbreite von 10 TB/s notwendig. Davon sind wir noch etwas entfernt.


Das sind Werte weit jenseits der Speicheranbindung einer GPU an den VRAM. Wozu sollte eine GPU-GPU-Verbindung das benötigen? Zumal es hier um die traditionelle Rolle der GPU als Grafikkarte geht, bei der viele Speicherzugriffe auf den VRAM der anderen GPU durch redundante Speicherung völlig überflüssig werden.
#30
Registriert seit: 28.01.2016

Leutnant zur See
Beiträge: 1227
Zitat smalM;26271816
Das sind Werte weit jenseits der Speicheranbindung einer GPU an den VRAM. Wozu sollte eine GPU-GPU-Verbindung das benötigen? Zumal es hier um die traditionelle Rolle der GPU als Grafikkarte geht, bei der viele Speicherzugriffe auf den VRAM der anderen GPU durch redundante Speicherung völlig überflüssig werden.


Die redundante Speicherung ist doch genau das was man damit vermeiden möchte?! Wenn ich eine Verbund aus 4 Modulen habe (ob auf einem PCB oder mehrer zusammengeschlossen sollte der Architektur egal sein) und möchte 16gb VRAM haben müsste ich 64Gb bezahlen (und mit strom versorgen) - wenns 8 Module sind 128 ... da wäre doch die ganze Einsparung durch Chipausbeute wieder dahin. Und die Datanraten kommen mir auch sehr hoch vor, allerdings wenn die Architektur vorsieht dass man auf Cache-speicher des anderen Chips zugreift, dann wird man da wohl nicht drum rum kommen.
#31
Registriert seit: 03.08.2006

Banned
Beiträge: 1674
Für die neue Architektur die angekündigt ist, erscheint mir die Spekulation über ein MCM in der "like a 3dfx" Art relativ plausibel.

Zitat why_me;26267147
Schöner Text, aber da sind mMn. ein Paar kleine Schnitzer/falsche Annahmen drinne.

Dieser... Artikel... erzeugt halt einen Hintergrundton. Und damit ein Geschmäckle.
Ja, wenn man das so macht wie NV das durchgespielt hat ist das vergebene Müh'. Warum man das so Lang&Breit jedem erklären möchte weiß ich aber nicht.

Nirgendwo gibt es Infos was genau AMD damit vorhat, es wird aber schonmal in einem Artikel aufgeklärt auf welche Art das scheitern kann. Informativ. Verstehste...
Um Kommentare schreiben zu können, musst Du eingeloggt sein!

Das könnte Sie auch interessieren:

NVIDIA Titan V: Volta-Architektur im Gaming-Test

Logo von IMAGES/STORIES/2017/NVIDIA-TITANV

In der letzten Woche hatte NVIDA noch eine Überraschung für uns parat: Die brandneue NVIDIA Titan V wurde vorgestellt. Damit gibt es das erste Consumer-Modell mit der neuen Volta-Architektur, das auch für Spieler interessant sein kann, in erster Linie aber auch professionelle Nutzer ansprechen... [mehr]

Sapphire Radeon RX Vega 64 Nitro+ im Test

Logo von IMAGES/STORIES/2017/SAPPHIRE-VEGA

Heute ist es endlich soweit: Wir können uns das zweite Custom-Design der Radeon RX Vega anschauen. Dabei handelt es sich um die Sapphire Radeon RX Vega 64 Nitro+, die besonders durch die Kühlung auf sich aufmerksam machen will. Drei Slots, drei Axiallüfter und sogar eine spezielle... [mehr]

Mega-Roundup: 14 aktuelle GeForce-Grafikkarten in 11 Blockbuster-Spielen...

Logo von IMAGES/STORIES/2017/GPU_BLOCKBUSER_VGL_ZOTAC-TEASER

In Kooperation mit Zotac Auch in diesem Jahr veranstalteten die Spielepublisher wieder ein regelrechtes Feuerwerk an neuen Videospielen. Vor allem in den letzten Wochen des Jahres wurden zahlreiche neue Triple-A-Titel veröffentlicht, wie beispielsweise ein neues "Call of Duty",... [mehr]

Die ersten Custom-Modelle der GeForce GTX 1070 Ti im Test

Logo von IMAGES/STORIES/LOGOS-2017/GTX1070TI-LOGO

Nach der Vorstellung aller Details dürfen wir heute die Leistungswerte der GeForce GTX 1070 Ti veröffentlichen. Dabei stand uns dieses Mal keine Founders Edition zur Verfügung, die nur von NVIDIA verkauft wird, dafür aber einige Custom-Modelle. Diese stammen aus dem Hause ASUS, Inno3D und... [mehr]

Erstes Custom-Design: ASUS ROG Strix Radeon Vega 64 OC Edition im Test

Logo von IMAGES/STORIES/2017/ASUS-VEGA

Es ist endlich soweit: Wir können uns das erste Custom-Modell der Radeon RX Vega 64 anschauen. ASUS war der erste Hersteller, der ein entsprechendes Modell vorgestellt hat, nun erreichte uns das finale Produkt. Im Zentrum steht natürlich die Frage, welche Verbesserungen ASUS mit der ROG Strix... [mehr]

AMD Radeon RX Vega 64 im mGPU-Test

Logo von IMAGES/STORIES/2017/AMD_RADEON_RX_VEGA_64_56_TEST

In den letzten Tagen war es so weit. Wir hatten endlich Hard- und Software zusammen, um die Radeon RX Vega 64 im mGPU testen zu können. Zum einen halten wir die ASUS ROG Strix Radeon Vega 64 OC Edition in Händen, zum anderen hat AMD den Radeon Software Crimson ReLive Edition 17.9.2... [mehr]