News DirectX 12: Nvidia-Treiber soll Async Compute nachreichen

[crazy_tomcat]

Schwanzlängenvergleiche?

 

[ampre]

Einfach nur ein Sportlicher Wettbewerb!

 

[GUN2504]

Ich hab mal meine R9 durchlaufen lassen.




sieht ähnlich wie bei Ampre aus, obwohl ich nicht wirklich an der Aussagekraft des Benchmarks glaube.
Die gibt es wohl erst mit 2-3 AAA-Titeln, welche das AC unterstützen und nicht von Nvidia aufgrund der Marktmacht eingebremst werden.

 

[ampre]

Der Test sagt sehr viel aus. Er sagt schon mal aus das der Rasterizer und der Polygonendurchsatz schon mal kein Problem für die AMD Karten darstellen. Das sah unter DX11 noch anderster aus.

Der Test würde mich mal mit einer Nvdia Karte der 900 Generation interessieren. Bei Suddendeath sieht man ja das die Karte ganz schön einbricht bei steigender Auflösung.

 

[pipip]

GUN2504

Das witzige ist, eigentlich sehr ironisch, falls Pascal tatsächlich kaum Verbesserungen liefert, werden alle AMD Games optional eigentlich wie Gameworks titel für NV (Sprichwort PhysX) sein (TressFX setzt auf AS zum Beispiel). Der Unterschied ist, AMD setzt hier auf einen total offenen Standard, denn NV dann aber eventuell versäumt hat, einfach weil sie die Performance Spitze unter DX11 sein wollten. Ob sich das rächt oder nicht wird sich zeigen, aber es kann durchaus sein, dass man bis Volta unter DX12 bei den einen oder anderen Titel eventuell das nachsehen haben wird.

Und wie schon gesagt, Marktanteile sind nicht in Stein gemeißelt. Es gibt genug Leute die aufrüsten wollen aber auf den neuen Prozess warten. Grafikkarten werden eher getauscht als Prozessoren, trotzdem tauschen manche allein nur wegen 5-10% und wegen einer kleineren Fertigung. Wie sieht es dann aus, wenn man von 28 auf 16 nm wechselt und dann noch in der Mittelklasse HBM Speicher bekommen könnte ?

Ich muss aber gestehen, da Hawaii durchaus gut abschneiden könnte, werde ich wohl noch länger kein Upgrade machen und vllt sogar auf die 2nd Generation der 16 nm FinFet Grafikkarten warten. Da gönne ich mir zuvor wahrscheinlich ein Zen 8 Core, wobei zugegeben, ich aktuell auch hier kein Bedarf sehe, upzugraden.
Tatsache ist doch, viele rüsten eher aufgrund von kribbelnden Finger auf, als das, dass sie wirklich was neues bräuchten.

 

[foofoobar]

Ich hab noch was im Golem Forum gefunden:

http://forum.golem.de/kommentare/pc...t/95111,4262866,4263794,read.html#msg-4263794

Autor: Ext3h 11.09.15 - 13:38

Die Async Shader sind dummerweise auf AMD-Karten absolut essentiell, ohne bekommt man die Shader nicht ausgelastet. Kann sich also effektiv kein Entwicklerstudio leisten auf die zu verzichten, zumal sind die Teile sehr angenehm zu verwenden da man damit auch "problemlos" Shader mit "relativ" kleinen Dimensionen (nur ein paar hundert bis tausend Threads pro Kernel) verwenden kann ohne dass damit die Leistung einbricht.

Der "fehlende Treibersupport" für die Async Queues bei Nvidia ist auch nur die halbe Wahrheit:
Ja, man kann Worstcases konstruieren in denen der Treiber bei Nvidia im Vergleich zur AMD-Hardware(!) komplett versagt. Und ja, Nvidia kann da noch per Treiber einige der Worstcases abfangen.

Aber:
AMD ist da nicht nur "ein bisschen" stärker was die Hardware angeht. Nvidia unterstützt mit Maxwell V2 in Hardware genau 32 parallel abgearbeitete Shader-Aufrufe. Nicht mehr und nicht weniger. Nur primitives Interleaving, keine Dependency-Managment oder ähnliches, das geht dann alles nur über Umweg über die CPU, oder Umweg über den VRAM.

AMD spielt da in einer komplett anderen Größenordnung. Pro ACE 64 Calls, wobei Dependency-Graphen in Hardware pro ACE aufgelöst werden. Und das sind gleich 8 ACEs pro Karte. Macht mit GCN 1.1 und 1.2 jeweils 512 Jobs die parallel abgearbeitet werden können. Bei GCN 1.0 aufgrund von nur 2 ACEs nur 128 Jobs.

Selbst wenn man jetzt berücksichtigt, dass die AMD-Karten insgesamt ca. 4x so viele Threads benötigen um "ausgelastet" zu sein (aufgrund der Shader-Architektur die nur jeweils alle 4 Takte eine Instruktion aus einem bestimmten Thread abarbeiten kann), macht das immer noch eine 4x (512/32/4) so hohe Auslastung der Shader, und das obendrein aufgrund des Dependency-Managments in Hardware noch mal mit wesentlich weniger Randfällen wo ein CPU-Roundtrip notwendig würde.

(Die Anzahl der Hardware-Queues ist übrigens zwischen Nvidia und AMD absolut nicht vergleichbar. AMD mapt jede Software-Queue auf eine Hardware-Queue, kann dafür aber problemlos auch einfach alle 64 Jobs für jeweils eine ACE sowohl aus einer einzelnen(!!!) Queue als auch als allen der ACE zugeordneten Queues ziehen. Nvidia verteilt die Jobs aus den Software-Queues gleichmäßig auf die 32 Hardware-Queues, kann dafür aber pro Queue nur jeweils den aller vordersten Job aktivieren.
GCN 1.2 mit den HWS (2x HWS + 4 ACE anstelle von 8 ACE) ist übrigens noch mal perverser, eine HWS kann sich jeweils wie 2 einzelne ACE verhalten wenn Dependencies berücksichtigt werden müssen, ohne Dependencie-Managment hingegen schafft die dann sogar bis zu 128 Jobs aus einer einzigen Queue parallel abzuarbeiten.)

Ok, und nun um das Thema abzuschließen:
Was aktuell weder AMD noch Nvidia machen, ist Jobs bereits CPU-seitig zu gruppieren. Sprich wenn zwei Jobs den gleichen Kernel verwenden, aber eine zu niedrige Dimension haben, diese automatisch zu einem größeren Job mit einer höheren Dimension (Threadanzahl) zu verbinden.
AMD hat das aktuell (noch) nicht nötig, da jede Arbeitslast die Nvidia überhaupt noch bewältigen kann problemlos durch die Hardware abgefangen wird.
Bei Nvidia hingegen ist das unumgänglich, anders lassen sich die doch relativ niedrigen Hardware-Limits nicht umgehen. Das wird dann allerdings wieder merkbar zu Ungunsten der CPU-Laste gehen, und es gibt auch da wieder Sonderfälle (e.g. wenn Abhängigkeiten zwischen Jobs bestehen) in denen diese Optimierung schlichtweg nicht anwendbar ist.


Man merkt leider doch recht deutlich, dass die gesamten letzten GPU-Generationen von Nvidia bis einschließlich Maxwell V2 auf DX11 zugeschnitten sind. Ja, man hat ein paar Spezialeinheiten verbaut die einem die von Microsoft vorgegebenen Feature-Level garantieren. Allerdings ist die Hardware überhaupt nicht auf die effektiv von AMD diktierte nebenläufige Ausführung zugeschnitten. Das kommt frühestens mit der nächsten Generation.

http://forum.golem.de/kommentare/pc...t/95111,4262866,4264141,read.html#msg-4264141

Autor: Ext3h 11.09.15 - 17:17

Größtenteils Erkenntnisse aus dem Thread hier:
https://forum.beyond3d.com/threads/dx12-async-compute.57188/

Zu mindestens das mit den 32 Jobs bei Nvidia / 64 Jobs pro ACE / (bis zu) 128 Jobs pro HWS ist dort als Ergebnis raus gekommen.

Das 1:1-Mapping von HW- und Software-Queues bei AMD ist ein undokumentiertes Verhalten, erscheint allerdings plausibel da maximal 64 Queues auf GCN 1.1 und 1.2 reserviert werden können, danach steigt der Treiber aus. Bei GCN 1.0 nur 2. Das Verhalten ist experimentell bestätigt, möglicherweise wird diese Koppelung später noch im Treiber gelockert. Ergebnisse entsprechen genau der Anzahl der in Hardware vorhandenen Queues.

Verhalten von GCN bezüglich optimaler, bzw. minimaler Last für vollständige Auslastung, siehe Whitepapers von AMD zu den GCN 1.0, 1.1 und 1.2. Fiji (GCN 1.2, Fury X) z.B. braucht min 16k Threads für vollständige Auslastung - bei optimierten Kerneln. Skaliert bis zu 40k Threads.

Parallele Ausführung von 64 Jobs pro ACE experimentell für GCN 1.0, 1.1 und 1.2 bestätigt. Bei GCN 1.2 konnte in Sonderfällen 128 Jobs pro Queue bearbeitet werden, Whitepaper legen nahe dass HWS-Einheit aus 2 zusammen geschalteten ACE-Einheiten besteht welche unter bestimmten Umständen Arbeitslast umverteilen können.

Das exakte Verhalten von Maxwell V2 ist ebenfalls undokumentiert und deutlich schwieriger zu testen. Auf jeden Fall scheinbar kein Limit in Software-Queues, außer Speicher-Limit auf der CPU-Seite. Jede Art von Abhängigkeiten zwischen Jobs hat die Performance bei Nvidia zusammen brechen lassen, daher die Annahme dass die Hardware das nicht direkt kann. Möglicherweise doch in Hardware vorhanden, aber bislang nicht vom Treiber unterstützt (unwahrscheinlich, Funktion wäre ansonsten in CUDA verfügbar, dort aber auch nur Synchronisation per Semaphore, sprich zur Laufzeit möglich).
Es war nicht möglich mehr als 32 Jobs parallel auszuführen, weder im Compute- (CUDA) noch im Grafik-Kontext.

Es ist nicht ganz sicher ob Nvidia-GPUs aktuell tatsächlich bereits komplett ausgelastet sind, scheinen aber nahe am theoretischen Limit zu operieren was den Instruktions-Durchsatz angeht. Ob Nvidia zu mindestens noch im Fall von Pipeline-Stalls eventuell von Async-Shadern profitieren kann wurde nicht getestet. Ist allerdings unwahrscheinlich wenn Nvidia tatsächlich alle 32 Queues gleichmäßig befüllt, da damit im schlimmsten Fall nur gleichartige Jobs zur Verfügung stehen die sich alle gegenseitig ausbremsen.



Eigentlich könnten die Architekturen kaum unterschiedlicher sein....
Den 16-40k Threads (4-10 Threads pro Shader) bei der Fury X, stehen bei Maxwell V2 2048 Threads (nur 1 Thread pro Shader, mehr sind möglich bringen aber keine messbaren Vorteile) als Optimum gegenüber. Das Verhältnis von 512 Jobs zu 32 Jobs bewegt sich eigentlich in einer ähnlichen Größenordnung.

Das sind auch zwei komplett unterschiedliche Entwurfsprinzipien. Maxwell wurde darauf getrimmt, mit DX11 optimal zu funktionieren. Unter Aufgebot aller Mittel:
- Architektur auf minimalen Parallelismus und Latenz optimiert
- Massive Optimierung durch den Treiber
- Support für Entwickler um Optimierung der Anwendung auf die Hardware zu gewährleisten

AMD:
- Maximaler Paralellismus für kompromisslose Rohleistung
- Hardware an Anforderungen der Entwickler angepasst
- Neuentwicklung einer API die zur Hardware passt - anstelle den existierenden Treiber an die Hardware an zu passen

Tjoa, und jetzt steht da AMD nun mal mit einem stimmigen Gesamtkonzept aus API und Hardware da. Ein Konzept dass komplett anders ausschaut als man es bei Nvidia gewohnt ist.

 

[Andy1978]

Naj ich hab gestern mein 980 ti zurück geschickt . Ich hatte noch ein Rückgabe Recht . Getan habe ich weil Vorsicht ist besser als Nachsicht . Denn wie gesagt wenn das Stimmt hat uns Nvidia mal wider ordentlich verarscht . Fett auf die Verpackungen Schreiben DirectX 12 uns dann das . Denn ich gebe keine 750€ aus um mir dann 2016 wider eine neue Karte kaufen zu müssen. Sollte sich als viel Wind um nichts heraus stellen , bestelle ich mir halt noch mal eine 980 ti. Ich hab ja noch eine XFX 280X die tut es auch noch

LG
Andy

 

[RayKrebs]

Ich habe auch keine Not. Meine grüne GTX770 behalte ich noch bis Mitte/Ende 2016. Dann entscheide ich wieder neu. Vielleicht kommt dann wieder mal Rot in den PC. Glücklicherweise befinde ich mich nicht in der Zwickmühle und kann entspannt aus der 2.ten Reihe anschauen wie sich das entwickelt.

 

[Naddel_81]

Ich habe auch keine Not. Meine grüne GTX770 behalte ich noch bis Mitte/Ende 2016. Dann entscheide ich wieder neu. Vielleicht kommt dann wieder mal Rot in den PC. Glücklicherweise befinde ich mich nicht in der Zwickmühle und kann entspannt aus der 2.ten Reihe anschauen wie sich das entwickelt.

+1
und wehe, die wollen für ihre mittelklasse pascal dann auch wieder 400€ haben und kastrieren sie auf 5,5 GB! dann kaufe ich echt wieder ne AMD nach jahren der nvidia-treue!

 

[Faust2011]

Der Test sagt sehr viel aus. Er sagt schon mal aus das der Rasterizer und der Polygonendurchsatz schon mal kein Problem für die AMD Karten darstellen. Das sah unter DX11 noch anderster aus.

Der Test würde mich mal mit einer Nvdia Karte der 900 Generation interessieren. Bei Suddendeath sieht man ja das die Karte ganz schön einbricht bei steigender Auflösung.

Diese Aussage mag stimmen, ist mir jedoch ein völliges Rätsel. Konkret: Nvidias High-End-Chips wie die Titan (Black) und auch die Titan X haben 6 Rasterizer, während AMD in ihrem Front-End der High-End-Chips (Hawaii, Fiji) nur 4 Rasterizer haben. Meiner Meinung nach arbeiten die Rasterizer völlig unabhängig von der API (DX11, DX12, OpenGL), sondern sind Bestandteil der Graphics-Pipeline, die an dieser Stelle nicht programmierbar ist (es werden eben hier die Geometriepunkte des Vertex-Shaders "rasterized").

Warum soll nun eine Titan (Black, X) mit 6 Rasterizer hier gg. AMD einbrechen, nur weil eine andere API verwendet wird? Oder andersrum: warum werden die 4 Rasterizer einer AMD-Karte unter DX12 besser ausgelastet?

Hmm... beim Schreiben dieses Beitrags könnte eine Erklärung für meine letzte Frage sein, dass der Vertex-Shader besser ausgelastet wird und nun genug Output liefert, damit die 4 Rasterizer (endlich?) genug zu tun haben. Im Umkehrschluss würde das bedeuten, dass unter DX11 die 4 Rasterizer bzw. Frontends der GCN-Chips gar nicht ausgelastet werden, weil die Shader ineffizient arbeiten?!

Kann da mal bitte jemand Ordnung in meine Gedanken bringen?

 

[ampre]

Ich vermute mal es liegt daran das DX11 serielle ist und die parallele GPU deshalb nicht richtig auslasten kann. Bei Nvidia sieht es eher anders rum aus. Da scheint die Schwachstelle der Commandprozessor zu sein der die Rasterizer nicht richtig füttern kann. Der 3dmark Drawcall test hat nicht viel mit Shaderauslastung zu tun da hier ein sehr sehr einfacher Scheder verwendet wurde. Hier wird also nur das Frontend getestet. Das ist Ok bei AMD

 

[Faust2011]

@ampre: Ok, das wäre möglich. Demnach ist AMD seit Jahren seiner Zeit voraus und meistens sogar so deutlich, dass es gar zum Nachteil wird.

GCN-Chips --> entfalten erst mit DX12/Mantle ihre wahre Performance

Bulldozer/FX --> brauchen massivst parallelisierte Software, um ihre wahre Leistung zu zeigen

HBM-Speicher --> war nun mit dem ersten Release in Form der Fury nun nicht der absolute Brüller

AMD APU-Konzept mit HSA-Architektur --> ist auch noch nicht im Markt angekommen.

 

[Nai]

Eigentlich könnten die Architekturen kaum unterschiedlicher sein....
Den 16-40k Threads (4-10 Threads pro Shader) bei der Fury X, stehen bei Maxwell V2 2048 Threads (nur 1 Thread pro Shader, mehr sind möglich bringen aber keine messbaren Vorteile) als Optimum gegenüber. Das Verhältnis von 512 Jobs zu 32 Jobs bewegt sich eigentlich in einer ähnlichen Größenordnung.

Das sind auch zwei komplett unterschiedliche Entwurfsprinzipien. Maxwell wurde darauf getrimmt, mit DX11 optimal zu funktionieren. Unter Aufgebot aller Mittel:
- Architektur auf minimalen Parallelismus und Latenz optimiert

Das ist auch leider ein Fehlkonzept was sich hier lange hält. AMD-GPUs besitzen in der Tat eine wesentlich höhere Occupancy (Threads gleichzeitig), zum Beispiel kann die FuryX bis zu 163 840 Threads (40 Threads pro Shader-Kern) gleichzeitig bearbeiten, während eine TitanX bis zu 49 152 Threads (16 Threads pro Shader-Kern) gleichzeitig bearbeiten kann. Diese Occupancy hat weniger was mit Optimierung für sequentiell oder parallel zu tun (keine GPU ist auf sequentiell optimiert), sondern wie viel Ressourcen ein Hersteller seiner GPU für das Latency-Hding spendieren will. Denn GPUs verwenden ein Hyperthreading ähnlich wie Intel-CPUs, nur viel extremer. Wartet ein Thread auf Daten, so kann ein anderer Thread in der Zwischenzeit weiterrechnen. Unter der Annahme, dass die Latenzen auf beiden GPUs ähnlich sind (ich finde hier gerade keine genaue Auflistung), kann eine AMD-GPU wegen mehr Threads pro Shader-Kern auch anfallende Latenzen besser überbrücken. Diese höhere Occupancy ist aber nicht umsonst. Denn will eine GPU mehr Threads gleichzeitig bearbeiten, so benötigt sie auch komplexere "Thread"-Scheduler (eigentlich Warp-Scheduler oder Wavefront-Scheduler) und mehr Register. Beides kostet wiederum DIE-Fläche. Zudem erhöht sich durch eine höhere Occupancy auch immer das Workingset, wodurch die Cache-Effizienz reduziert wird.

GCN 1.2 mit den HWS (2x HWS + 4 ACE anstelle von 8 ACE) ist übrigens noch mal perverser, eine HWS kann sich jeweils wie 2 einzelne ACE verhalten wenn Dependencies berücksichtigt werden müssen, ohne Dependencie-Managment hingegen schafft die dann sogar bis zu 128 Jobs aus einer einzigen Queue parallel abzuarbeiten.

Der Teil kommt mir persönlich komisch vor. Die Reihenfolge in einer Schlange muss für die Korrektheit zwingend erhalten bleiben, es sei denn die Abhängigkeiten sind bekannt (bei einer Bindless API wie DX 12 problematisch) oder die Anwendung fügt selbstständig Dependency-Bars ein (afaik weder in Mantel noch in DX vorhanden). Ähnlich wie die weiteren ACE beschreibungen. Hat jemand eine Quelle dafür? In den AMD-Dokumentationen finde ich nichts dazu.

 

[ampre]

@nai
Aber Sind die ace's nicht so etwas wie Thread scheduler Die asynchron arbeiten?

 

[Nai]

@ Ampre:
Bei GPUs findet die Parallelität auf zwei unterschiedlichen Ebnen statt: Eine GPU kann mehrere unterschiedliche Tasks gleichzeitig berechnen, zum Beispiel kann sie gleichzeitig Rendering, Physik oder KI berechnen (oder vielleicht auch nicht im Falle von NVIDIA ). Zudem nutzt sie auch die viel größere Parallelität innerhalb der Tasks aus, um zum Beispiel mehrere Partikel in einer Physik-Simulation gleichzeitig zu berechnen. Dafür wird ein jeder Task in eine Vielzahl von Threads unterteilt; zum Beispiel starten viele Spiele für jedes Partikel ihrer Physik-Simulation einen Thread auf der GPU.

Für die Task-Parallelität sind die ACEs zuständig. So können die ACEs mehrere Tasks gleichzeitig verwalten und Abarbeiten. Dafür weisen sie nacheinander jedem Thread aus den zu berechnenden Tasks einmalig(!) eine Compute-Unit (CU) zu. Der Thread bleibt auch bis zu seiner Terminierung auf dieser CU und wird nur durch diese CU berechnet. Wegen Multithreading kann eine CU allerdings viele Threads beherbergen. Jede CU hat einen "Thread"-Scheduler, der dafür verantwortlich ist von den Threads, die sich auf der CU befinden, jeden Takt diejenigen Threads auszuwählen, welche die Rechenkerne der CU als nächstes ausführen sollen.

Der Test sagt sehr viel aus. Er sagt schon mal aus das der Rasterizer und der Polygonendurchsatz schon mal kein Problem für die AMD Karten darstellen. Das sah unter DX11 noch anderster aus.

Naja sowohl für AMD-GPUs ist das Benchmark eher eine Worst-Case situation trotz neuen APIs. Wenn man sich mal ausrechnet wie viele Polygone die GPU pro Sekunde als peak schaffen sollte (Beispiel Geforce 980 GTX mit 6 Mil Polygone/s) und wie viele sie tatsächlich in dem Benchmark schafft (10 Mil Polygone/s), dann merkt man dass die Auslastung der GPU mit extrem schlecht ist. Bei AMD-GPUs sieht es nicht viel besser aus.

 

[ampre]

Äh wenn du dich auf den polygonendurchsatz vom 3dmark dx12 drawcalltest beziehst, der ist höher. Eine 290x hat 16.000.000 drawcalls/Sekunde Jeder call hat laut Spezifikation 112-127 Polygonen. Wenn ich mit 112 rechne sind das gut 1.800.000.000, also 1,8 Milliarden Polygonen/Sekunde die die Fury da raus haut. Nvidi liegt trotz 2 rasterizer mehr und doppelter Performance der Rasterizer gut 10-20% hinter AMD.

Ich warte auch noch auf eine Antwort von Suddendeath zum 8k Test. Ich glaube nämlich das hier die Gtx970 hier noch Mals einbricht. Von 720p auf 4k waren es gut 15% drawcallverlust. Merkwürdig ist das es bei AMD zwischen 8k und 720p konstant bei 16.Millionen bleibt. Die Gtx 970 bricht hier von 20 Millionen Drawcalls unter 720p auf 16. Millionen Drawcalls unter 4k ein!

 

[Nai]

Hmmm interessant. Ich verwendete eigentlich das http://partner.amd.com/Documents/MarketingDownloads/en/AMD and DirectX12 JULY2015.pdf als Grundlage meiner Argumentation.

 

[ampre]

Interessant hat da einer Polygonen mit Drawcalls verwechselt?
Ich hab das hier her mit den 112-127 Triangels:
http://www.anandtech.com/show/9112/exploring-dx12-3dmark-api-overhead-feature-test.

Interessant ist auch das kein culling betrieben wird. Die Polygonen werden wirklich gezeichnet.

Ist das dann Zufall das die Polygonen mit den Drawcalls gut übereinstimmen?

https://www.computerbase.de/2015-03...amd-vor-nvidia/#diagramm-3dmark-amd-a10-7850k
http://partner.amd.com/Documents/MarketingDownloads/en/AMD and DirectX12 JULY2015.pdf

Bin gespannt wie das hier weiter geht!

 

[OiOlli]

Es grenzt schon an Hohn und Spott bei Grafikkarten - egal ob rot oder grün - von Zukunftssicherheit zu sprechen.

Da sich die Entwicklung verlangsamt hat, kann man schon darüber sprechen.

Ich meine, ich hab eine Karte drin, die 3 Jahre alt ist und sie reicht oft noch für hohe oder gar höchste Details. Und umgekehrt sind die neuen mittelklassekarten kaum schneller als 3 Jahre alte Highendkarten. Wenn man überlegt, eine 8600 gt nur so schnell, wie eine 6800 gt.

 

[Andy1978]

Da sich die Entwicklung verlangsamt hat, kann man schon darüber sprechen.

Ich meine, ich hab eine Karte drin, die 3 Jahre alt ist und sie reicht oft noch für hohe oder gar höchste Details. Und umgekehrt sind die neuen mittelklassekarten kaum schneller als 3 Jahre alte Highendkarten. Wenn man überlegt, eine 8600 gt nur so schnell, wie eine 6800 gt.

Da geb ich dir Recht .
Weil ich erfahre das gerate am eigene Leib. Ich hab ja meine 980ti zurück geschickt . Deswegen Arbeitet bei mir eine XFX 280X BE in meinem PC. Ich hatte schon Angst ich kann keines der neueren Games vernünftig Spielen . Aber nix da .
Witcher 3 läuft mit 60 FPS alles auf hoch ohne Nvidia Spielereien natürlich . Whatch Dogs auch alles auf hoch auch 60 FPS.
Crysis 3 das selbe . Ich verwende jetzt über all FXAA als Kanten Glättung und 8X AA . Aber das sieht immer noch um einiges besser aus als auf NEX Konsolen .
Nächste Woche bekommen ich eine Sapphire Radeon R9 290X Tri-X OC [New Edition] für 259€ neu und die reicht dann bis ich weis ob Rot oder Grün 2016 oder auch 2017 wer weiß Aber eher Rot . Mir kommt halt vor das AMD die ehrlicher Firma ist und ich die Vermutung habe das sich für AMD unter DX12 das Blatt wenden wird .


LG
Andy