[UPDATE] Ashes of the Singularity Beta 2: Acht Grafikkarten im DX12-Shootout

Windows 10 ist seit Längerem verfügbar und zeitgleich damit auch DirectX 12. Doch wirklich sauber auf DirectX 12 portierte oder programmierte Spiele gibt es bisher kaum. Deshalb muss es nun die neue Beta 2 von "Ashes of the Singularity" richten.

Übersicht, Einführung und Testsystem

Wir haben diesen Benchmark eines noch unfertigen Spiel bereits mehrmals getestet (etwa beim Launch von AMDs Radeon R9 Nano) - einschließlich der uns damals aufgefallenen Treiber- und vor allem Hardware-Probleme bei Nvidia-Grafikkarten.

Damals dauerte es nicht lange, bis Nvidia mit passenden Treibern den vermeintlichen technischen Rückstand nicht nur aufholen, sondern sogar noch in einen leichten Vorsprung umkehren konnte.

Natürlich haben wir die neue Beta 2 des Benchmark erst einmal getestet und festgestellt, dass bezüglich des asynchronen Verarbeitens und Ausschöpfens diesbezüglicher DirectX-12-Merkmale eine enorme Schippe draufgelegt wurde.

Nachdem wir von AMD einen speziellen Launch-Treiber bekamen, haben wir selbstverständlich und fairerweise auch bei Nvidia einen optimierten Treiber angefragt. Allerdings wurden wir recht schmallippig auf den aktuellen Treiber 361.91 WHQL verwiesen; mehr Hinweise gab es leider keine.

Jedenfalls drängt sich dieses Spiel mit jeder Menge beweglicher KI auf einem recht großen Areal für diese Art der DirectX-Programmierung geradezu auf. Damit stellt sich letztendlich aber auch die Frage nach Sinn und Realitätsbezug für die üblichen Spiele anderer Genres, die bei weitem nicht auf so eine extensive Nutzung angewiesen sind.

Konkret geht es hier um die DirectX-12-Funktion "Asynchronous Shading/Compute", die ein paralleles und vor allem asynchrones (also voneinander in der Reihenfolge komplett unabhängiges) Abarbeiten von Grafikaufgaben (Shading) und reinen Berechnungen (Compute) ermöglicht. Dadurch kann die Latenzzeit bei sauberer Implementierung und voller Unterstützung durch die Hardware enorm sinken, was sich im Gegenzug in einer deutlich gesteigerten Performance ausdrückt.

Rufen wir uns dazu noch einmal kurz das Schema der Abläufe in DirectX 11 in Erinnerung. Was wir sehen, ist eine synchrone Abarbeitung notwendiger Abläufe, die sich wie Perlen auf einer Kette aneinander reihen. Ein Ausbrechen aus dieser starren Struktur ist nicht möglich, so dass man so eine Befehlskette deutlich einkürzen und aufsplitten muss, wenn man wenigstens einigermaßen effizient bleiben will.

Mit DirectX 12 lässt sich diese künstlich aufgebaute Warteschlange trefflich aufteilen, so dass viele Aufgaben parallel und zeitlich versetzt ausgeführt und abgeschlossen werden können. Das klappt bei dem hier und heute getesteten Benchmark recht gut, so dass man schon einen einigermaßen repräsentativen Vorgeschmack auf das bekommt, was maximal möglich scheint.

Allerdings kommt  hier auch wieder unser Hinweis auf den Realitätsbezug von eben ins Spiel, denn nicht alles lässt sich bis ins Letzte sinnvoll parallelisieren bzw. asynchron verarbeiten. Das klappt schon dann nicht mehr, wenn Ergebnisse vorweggenommen werden müssten bzw. der Verwaltungsaufwand für das Aufgaben- und Ergebnissmanagement den praktischen Nutzen übersteigt.

AMD hat sich bereits seit einigen Generationen mit der Hardware-mäßigen Implementierung solcher asynchronen Lösungen beschäftigt, so dass Designs wie Tonga, Hawaii und Fiji bestens dafür gerüstet scheinen. Nvidia dagegen scheint sich mit Kepler und Maxwell offensichtlich (noch) recht schwer zu tun, wenigstens eine Software-mäßige Behebung dieser fehlender Funktionalität anzupeilen, die dann eine merkliche Linderung des Mankos verschaffen könnte.

Dass dem noch nicht so ist, zeigt die nachfolgende Grafik ziemlich deutlich: Während die AMD-Karten durch die Aktivierung dieses Features in der Benchmark-INI deutlich zulegen können, müssen die Nvidia-Karten im Gegenzug sogar leichte Einbußen verbuchen.

Diese Umschaltoption und die Ähnlichkeit der Ergebnisse haben uns dann auch dazu bewogen, DirectX 11 aus Zeitgründen diesmal im weiteren Verlauf außen vor zu lassen und uns auf den nachfolgenden Seiten nur noch auf DirectX 12 und die (mögliche) Nutzung des asynchronen Shading/Compute zu konzentrieren. Wir testen fairerweise später alle Karten mit der jeweils für sie besser passenden Methode.

Testsystem

Zum Einsatz kommt das bereits seit Längerem genutzte Testsystem, an dem es auch diesmal keine Änderungen gab:

Technische Daten
Testsystem:
Intel Core i7-5930K @4,2 GHz
Alphacool-Wasserkühlung (Nexxxos-CPU-Kühler, VPP655-Pumpe, Phobya Balancer, 24-cm-Radiator)
Crucial Ballistix Sport, 4x 4 GByte DDR4-2400
MSI X99S XPower AC
1x Crucial MX200, 500-GByte-SSD (System)
1x Corsair Force LS 960-GByte-SSD (Anwendungen, Daten)
Be Quiet Dark Power Pro, 850W-Netzteil
Windows 10 Pro (alle Updates)
Treiber:
AMD: Radeon Software 15.301 B35 (Beta-Treiber für die Presse, Februar 2016)
Nvidia: ForceWare 361.91 WHQL
Gaming-
Benchmarks:
Ashes of the Singularity Beta 2 (Press)

Da der Benchmark eine sehr interessante Log-Datei bietet, aus der man deutlich detailliertere Informationen entnehmen kann als nur dem einfachen Benchmark-Ergebnisüberblick im Spiel, haben wir unseren Interpreter aktualisiert und sogar noch funktionell erweitert. Denn gerade bestimmte Details wie die Frame-Verläufe sind für die Beurteilung hilfreich und wichtig.

Framerates und -verläufe

Framerates

Betrachten wir zunächst die tatsächlich erreichbaren FPS sowohl im Durchschnitt als auch im nicht uninteressanten Minimum. Dafür nutzen wir insgesamt drei Bildschirmauflösungen: Full-HD (1920 x 1080 Pixel, 1080p), WQHD (2560 x 1440 Pixel, 1440p) und Ultra-HD (3840 x 2160 Pixel, 2160p). Wir haben die Ergebnisse aller drei Auflösungen jeweils mit dem Preset "High" ermittelt und in scrollbaren Galerien zusammengefasst.

Besonders die minimalen FPS geben eher den subjektiven Eindruck wieder, wenn es doch einmal ruckelt. Bis auf wenige Ausnahmen haben hier die schnelleren der Nvidia-Karten die Nase leicht vorn. Doch so ein Endwert kann auch deutlich täuschen, wie wir gleich noch sehen werden.

Frame-Verläufe

Nutzen wir nun den Interpreter und fassen die protokollierten Einzel-Frames zu einem 180-Sekunden-Kurvenverlauf zusammen, denn genau so lange läuft auch der Benchmark. Das Ergebnis is eine schöne FPS-Kurve, die die wechselnden Lasten der Szenen und die Reaktionen der Karten aufzeigt:

Frame Time und Smoothness

Doch auch diese Darstellung ist noch viel zu grob, um ein wirklich passendes Abbild unserer subjektiven Wahrnehmung zu erhalten. Hier helfen jetzt nur noch die tatsächlichen Renderzeiten weiter. Da unterschiedlich schnelle Karten in der zur Verfügung stehenden Zeit auch unterschiedlich viele Frames rendern, nutzen wir im Interpreter ein komplexes mathematisches Verfahren, welches die größten Abweichungen anders gewichtet als konstante Abläufe, so dass die subjektiv wahrnehmbaren Ruckler und Drops erhalten bleiben.

Die Auflösung von 2560 x 1440 Pixeln, samt den Voreinstellungen für "High", ist für uns ein regelrechter Glücksfall, weil die schnelleren Nvidia-Karten durch die höhere CPU-Last schneller ins Limit rennen. Auch wenn die Frame-Verläufe und FPS-Werte eigentlich nichts dergleichen vermuten ließen, zeigen die Frame-Time-Analysen dann doch Erstaunliches: Das sieht durch die Drawcall-spezifische CPU-Limitierung so aus, als hätte man hier mit einer Schere glatt abgeschnitten.

Smoothness

Bewerten wir nun noch die sogenannte Verlaufsglätte ("Smoothness"), also den Zeitunterschied zwischen den einzelnen Frames als relative Differenz. Dies hilft, jeden subjektiv störender Ruckler oder Sprung auch in der grafischen Darstellung noch besser zu erkennen, ohne dass die eigentliche Renderzeit diese Kurve beeinflusst.

Auch hierfür haben wir den Extremfall als direkte Gegenüberstellung parat, indem wir das Beispiel von eben für die subjektive Wahrnehmung heranziehen. AMDs R9 Fury X bietet über den gesamten Verlauf das deutlich rundere und ruhigere Bild. Warum das so ist, sehen wir gleich noch, denn wir haben auch alle Daten zu CPU und Treiber statistisch genau ausgewertet.

Zwischenfazit: Renderzeiten und Frame-Verläufe

Besonders in den Szenen, wo in der Totalen haufenweise Künstliche Intelligenz (KI) in Aktion zu sehen ist und dementsprechen viel Rechenlast anfällt, können sich alle AMD-Karten besonders gut in Szene setzen.

Bemerkenswert ist hier vor allem die ältere Radeon R9 390X, die es eher mit einer werksübertakteten GeForce GTX 980 Ti aufnehmen kann als mit einer deutlich langsameren GeForce GTX 980. Die übertaktete Radeon R9 390 wiederum macht aus der ebefalls übertakteten GeForce GTX 980 genauso Kleinholz wie aus der GeForce GTX 970, die deutlich zurückgelassen wird.

In Full-HD kann auch die Radeon R9 380X noch recht gut überzeugen, während die sehr hoch übertaktete GeForce GTX 960 keinen Blumentopf gewinnen kann.

Natürlich ist es nur ein einzelner Benchmark, der zudem nicht für alle Umstände und Konstellationen wirklich belastbare pauschale Aussagen treffen kann, aber es ist immerhin mal ein Anfang der aufzeigt, wohin der Zug fahren könnte.

Limits und Renderzeiten

Ursachen für Limitierungen und Zeitverluste

Bevor wir die Daten auswerten, wollen wir aber noch einen Blick auf die Zeitschiene dessen werfen, was wir Eingangs als "Befehlskette" unter DirectX 11 (und älter) bezeichnet haben. Wir sehen einerseits die sehr ungleiche Auslastung der CPU-Kerne durch die Grafik und andererseits den langen Weg bis hin zum Auftauchen und Einblenden des wirklich sichtbaren Ergebnisses (im Log als Present Time bezeichnet). Auffällig ist auch die sehr lange Zeit, die in Treiber und CPU verloren wird.

Betrachten wir uns nun das Ganze unter DirectX 12. Die parallele Auslasung der einzelnen CPU-Kerne steigt signifikant und auch die im Treiber benötigte Zeit verteilt sich besser auf einzelne Threads. Damit ist man zwar in der Summe nicht schneller, verkürzt aber die Zeit bis zum Erscheinen der fertigen Ausgabe deutlich!

Batches (Drawcalls)

Zunächst stellen wir die Anzahl der GPU-Command (Batches) pro gerendertem Frame gegenüber, die sich von CPU zu CPU und zwischen den Herstellern gar nicht so gravierend unterscheiden:

CPU-Zeit

Allerdings ist dies nur der Ausgangswert, denn nun müssen wir uns anschauen, wie sich diese Last auf die CPU verteilt. Dazu werten wir den prozentualen Anteil der tatsächlich genutzen CPU-Zeit aus, die auch bei guter Parallelisierung in der Summe natürlich immer auch ein Spiegelbild der Gaming-Performance ist. Schnellere Karten geben mehr FPS als langsamere aus, so dass in der gleichen Zeit logischerweise auch mehr Aufgaben abgearbeitet werden müssen:

CPU-Bound

Wann aber limitiert dann die CPU? Sie limitiert genau dann, wenn die Parallelisierung (z.B. Hardware-bedingt) zu niedrig ausfällt und die Jobs in der CPU faktisch in wenigen Threads geradezu stecken bleiben, obwohl nicht ausgelastete Kerne vorhanden wären. Oder aber die CPU macht trotz guter Parallelisierung einfach dicht, weil das Limit der CPU-Rechenkapazität erreicht ist.

Man darf ja auch nicht vergessen, dass bei einer hohen Parallelisierung unverhältnismäßig mehr Daten gleichzeitig bewegt werden. Hier ist ebenfalls an jeder Schnittstelle zwischen Hard- und Software ein Engpass möglich und auch dafür müss ja fast immer die CPU herhalten.

Je höher die Grafikkarte mit Berechnungen belastet wird, umso mehr hat die CPU Zeit zum Luft hohlen. Das sieht man deutlich, wenn man die einzelnen Auflösungen vergleicht. Was jedoch positiv auffällt, ist die Ausnahmestellung der Radeon R9 Fury X, die die CPU selbst dann noch "schont", wenn ähnlich schnelle Karten den Rechenknecht bereits malträtieren. Der Zugewinn an Parallelisierbarkeit ist selbst zwischen Hawaii und Fiji noch extrem hoch.

Zeit im Treiber

Wir haben auch gesehen, dass ein nicht unbedeutender Anteil der Renderzeit eines Frames im Treiber "verbraten" wird. Hier verliert AMD im Vergleich zu Nvidia deutlich mehr Zeit. Landläufig spricht man gern vom Treiber-Overhead, allerdings darf man auch nicht aus den Augen lassen, dass der Treiber bei vielen asynchron ablaufenden Vorgängen mehr Aufwand zu bewältigen hat.

Present Time

Dies ist die Zeit, die für die Ausgabe an den Betrachter zur Verfügung steht und die sich quasi am Ende der Bearbeitungskette befindet. Die zwischen den Auflösungen sehr schwankenden Gesamtzeiten liegen einerseits an den unterschiedlichen Ursachen für die CPU-Limitierungen (wie bei den Frame-Zeiten bereits erwähnt) und der mit der Auflösung steigenden Grafiklast auf den Karten.

Limitiert die GPU bereits deutlich, sind diese Zeiten meist extrem niedrig, weil die anteilige Zeit zur Berechnung bereits verhältnismäßig hoch ausgefallen ist.

Zwischenfazit: Renderzeiten

Auch hier hat AMD vor allem mit den aktuellen Karten deutlich die Nase vorn, da echte Parallelisierung und asynchrone Abarbeitung mehr bringen als ein mögliches Treiber-seitiges Aufsplitten einzelner Aufgaben als Software-Lösung. Die Relevanz für den Alltag muss natürlich schon hinterfragt werden, allerdings könnte es ja so in Zukunft mehr und intensiver genutzt werden.

Multi-GPU im Detail

SFR: Rendern queerbeet mit DirectX 12

Zunächst machen wir eine kurze Bestandaufnahme: Das abwechselnde Rendern von Einzelbildern (AFR) auf beispielsweise zwei Karten kann durchaus zur Erhöhung der durchschnittlichen und maximalen Framerate führen, birgt als fragiles System aber auch jede Menge Unwägbarkeiten und Fehlerquellen.

Zum einem müssen alle Ressourcen doppelt vorgehalten werden - es liegen also auf jeder Karte identische Daten im Speicher - und andererseits kommt diese Konstellation sehr schnell aus dem Takt, wenn beispielsweise zwei Frames aufeinander folgen, deren Bearbeitungszeit sehr unterschiedlich lang ausfällt.

Das Ergebnis ist dann ein mögliches Hoppeln und Ruckeln der Ausgabe, das man auch subjektiv deutlich wahrnehmen kann. Die einzelnen Sync-Verfahren und Framepacing beziehungsweise FPS-Limiter schaffen da zwar etwas Abhilfe, aber es ist und bleibt Kosmetik.

DirectX 12 setzt mit dem SFR-Vefahren (Split-Frame-Rendering) ähnlich wie bei Raytracern auf die Aufteilung des Bildes in mehrere Tiles (Bildauschnitte).  Beide Karten nutzen zwar immer noch überwiegend die eigenen Ressourcen, jedoch nicht mehr fürs komplette Bild, sondern nur für den zugewiesenen Ausschnitt. Das spart am Ende nicht nur Speicher, sondern reduziert auch Übertragungszeit und anfallende Datenmengen.

Da jede Karte nur noch die zugewiesenen Tiles berechnen muss und nicht mehr einen kompletten Frame, ist die im Ernstfall anfallende Wartezeit dann wesentlich geringer, bis der fertige Frame ausgegeben werden kann.

Framerates und Frame-Verläufe

Wir testen jeweils die schnellste AMD- und Nvidia-Karte in verschiedensten Konstellationen, da die Zeit für eine noch größere Auswahl am Ende fehlte. Allerdings muss man auch voranstellen, dass trotz Extreme-Preset und übertakteter 6-Kern-CPU (12 Threads) stets und ständig CPU-Limits auftraten, was zu am Ende sehr ähnlichen Ergebnissen führte. Hätten wir weitere, langsamere Karten miteinander oder mit den schnelleren kombiniert und/oder die CPU heruntergetaktet, wären lediglich noch mehr Unwägbarkeiten hinzugekommen.

Wir wollen uns aber nicht von den zunächst sehr ähnlichen FPS-Zahlen täuschen lassen, denn der Teufel steckt wie immer im Detail. Als direkten Vergleich haben wir auch die beiden Einzelkarten mit dem Extreme-Preset getestet:

Spätestens bei den Frame-Verläufen sehen wir wieder deutlichere Unterschiede, wobei die GeForce-Grafikkarten die niedrigeren Min-FPS liefern. Dies belegt auch, dass Absolutwerte meist für die Katz sind:

Die Renderzeiten der Frames decken sich im Verlauf ziemlich gut und direkte Ausreißer - wie sonst bei SLI oder Crossfire üblich - sieht man auch kaum. Da sind die Einzelkarten schon anfälliger.

Gleiches sagt uns auch die Auswertung der Verlaufsglätte, bei der die Multi-GPU-Kombinationen nicht schlecht abschneiden.

Die Anzahl der Batches pro Frame liegt wieder eng beieinander, was aufgrund gleicher Renderinhalte auch kaum verwundert.

Was jedoch sofort ins Auge springt, ist die brutal und ansatzlos einsetzende CPU-Limitierung im Multi-GPU-Betrieb! Obwohl zwischen der langsamsten Kombination und der schnellsten Einzekarte leistungsmäßig nur etwa sieben FPS liegen, schnellt die Quote der limitierten Frames auf die Höchstmarke von 100 Prozent.

Je nach Performance fällt auch der Zeitanteil der in der CPU "verbrauchten" Gesamtrenderzeit entsprechend hoch aus - aber das kennen wir ja schon vom letzten Kapitel:

Gleiches gilt auch für den Zeitanteil, der auf den Treiber entfällt:

Die Present Time ist erneut Fury-Domäne. Man sieht also trotz ähnlicher FPS-Werte an jeder Ecke noch deutliche Unterschiede, die auch den subjektiven Gesamteindruck der Bildqualität beeinflussen.

Zwischenfazit: Multi-GPU

Immerhin sind die Grenzen zwischen den Karten unterschiedlicher Hersteller und Modellreihen mehr oder weniger eindrucksvoll gefallen. Fast alles kann mit allem und jedem, wobei man sich am Ende natürlich auch nach dem Sinn eines jeden Ergebnisses fragen muss.

GPU- und CPU-Energieaufnahme unter DX12 und DX11

Leistungsaufnahme der Grafikkarten

Wir nehmen die vier schnellsten Karten, die in Ultra-HD noch nicht so extrem GPU-limitiert sind und messen für alle drei Renderpfade zunächst deren Leistungsaufnahme.

Während die Radeon R9 Fury X noch brav am Power-Limit kleben bleibt, schießt die Radeon R9 390X unter DirectX 12 nicht nur durch die Decke, sondern gleich auch noch den Vogel ab: Die um rund 100 Watt höhere Leistungsaufnahme bei aktiviertem "Async Compute" geht im Hinblick auf über 20 Prozent Performance-Zuwachs noch irgendwie in Ordnung, aber bei deaktivierter Option ist es kaum weniger - trotz deutlich niedrigeren Framerates.

Beide Nvidia-Karten quittieren DirectX 12 mit einer gesteigerten Leistungsaufnahme bei nur moderatem Leistungsschub, wobei bei der GeForce GTX 980 Ti nur drei FPS Mehrleistung mit einem Plus von über 45 Watt teuer erkauft werden müssen. Die GeForce GTX 980 bleibt hingegen recht unauffällig.

Leistungsaufnahme der CPU

Natürlich messen wir auch, wie sich die CPU verhält. Die nachfolgenden, reinen CPU-Werte wurden ebenfalls über die volle Benchmark-Laufzeit direkt ermittelt und beinhalten zudem auch keinerlei Spannungswandlerverluste. Egal welche Karte - die Leistungsaufnahme der CPU selbst sinkt zum Teil dramatisch, vor allem jedoch bei den Nvidia-Karten.

Effizienzbetrachtung

Um sinnvolle Aussagen treffen zu können, bilden wir eine Summe aus CPU- und GPU-Leistungsaufnahme. Denn nur in der Gesamtbetrachtung der jeweiligen Wechselbeziehungen lohnt sich auch eine wirkliche Effizienzanalyse. Diese von uns so für jede Konstellation ermittelte Leistungsaufnahme teilen wir dann durch die erzielten durchschnittlichen FPS.

Die GeForce GTX 980 bleibt die effizienteste Karte, wobei die eigentlich etwas langsamere DX12-Option mit aktiviertem "Async Compute" die effizientere ist. Die Radeon R9 Fury X ist zwar noch unter DirectX 11 leicht effizienter, unter DirectX 12 jedoch etwas schlechter und nur leicht besser als die GeForce GTX 980 Ti.

Die Radeon R9 390X ist zwar mit DirectX12 richtig schnell, säuft aber auch wie ein Loch und landet deshalb weit abgeschlagen auf dem letzten Platz. Dass die GeForce GTX 980 im Vergleich zur GeForce GTX 980 Ti vor allem bei DirectX 11 so abfällt, dürfte in ihrem bereits spürbaren Limitierung liegen.

Detailbetrachtungen

Werfen wir abschließend noch einen Blick auf die jeweils korrespondierenden Leistungsaufnahmewerte für die GPU und die CPU anhand der jeweiligen Framerate-Verlaufskurven:

Wir sehen beispielsweise, dass die Radeon R9 Fury X stellenweise bereits gedrosselt wird, während die Radeon R9 390X mit glühenden Bäckchen vor sich hin bollert.

Der Verlauf der CPU-Last ist hingegen weniger spektakulär, wohl aber die unterproportionale "Sparsamkeit" bei der Radeon R9 390X. Ausgleichen kann dieser Umstand das Gesamtbild jedoch nicht.

Zusammenfassung und Fazit

Trouble-Shooting war angesagt

Wir wollen am Ende nicht unerwähnt lassen, dass nicht alles komplett reibungslos ablief, was uns zum Teil sehr viel Zeit gekostet hat. Vor allem der Multi-GPU-Part hat auch einigen unserer Kollegen den Schweiß auf die Stirn getrieben. Was dem Spiel hingegen wirklich abträglich ist, ist der Umstand, dass "Ashes of the Singularity" nicht im exklusiven Vollbildmodus, sondern nur als rahmenloses Vollbild-Fenster im Vordergrund ("top-most") läuft.

Das wiederum macht diesen Benchmark anfällig für alle möglichen äußeren Einflüsse - vor allem bei Ultra-HD, wo es sehr schnell zu Bandbreitenlimitierungen kommen kann, wenn in der Windows-Installation ein wichtiges Update fehlt. Wer wie wir ein eigentlich "eingefrorenes" Testsystem nutzt, wird so recht schnell und unverhoft auch von solchen Unwägbarkeiten des Betriebssystems eingeholt, was dann schon mal in stundenlanger, frustrierender Problemsuche mündet. Doch am Ende zählt nur das Resultat und nicht der Weg.

Fazit

Schöner Benchmark, interessantes Ergebnis und die wiederkehrende Frage: Was bringt uns dies für den Alltag und die nahe Zukunft? Gönnen wir AMD zunächst diesen kleinen Etappensieg, denn er zeigt uns auch, dass sich meist im Verborgenen betriebene Entwicklungen oder unbeachtet gebliebene Features irgendwann vielleicht doch einmal auszahlen können.

Mit "Asynchronous Shading/Compute" hat AMD ein Pfund, mit dem man wuchern kann - vorerst. Doch wo bleiben all die schönen und optimierten Spiele? Bis sich DirectX 12 wirklich durchgängig etabliert hat und die Entwicklerstudios davon auch vollumfänglich Gebrauch machen, wird noch viel Wasser den Berg hinunterfließen. Diese Entwicklung wird vielleicht dann wirklich greifen, wenn Chips wie Fiji oder Maxwell der näheren Computergeschichte angehören.

Was Pascal kann, weiß keiner. Dass AMD bei Polaris nicht darauf verzichten wird, ist hingegen sicher. Bliebe die Frage im Raum stehen, wie es Nvidia gelingt, Nachteile beim Feature-Set per Software auszugleichen. Machbar ist so etwas durchaus, wie die letzten Treiber für die ältere Beta 1 gezeigt haben. Die Spannung bleibt also erhalten und dies ist somit das Beste, was der Presse und den Kunden passieren kann.

Lassen wir uns einfach überraschen.

Erstelle einen neuen Thread im Artikel-Forum über dieses Thema
Dieser Thread ist für Kommentare geschlossen
29 Kommentare
    Dein Kommentar
  • Anonymous
    Sehr interessant.

    Unter DX11 war es ja bisher so, dass man mit AMD-Karten schneller ins CPU-Limit rennt, während die Nvidiakarten nicht so viel CPU-Leistung benötigten. Das Blatt wendet wendet sich unter DX12 scheinbar komplett, da Nvidia das Asynchronous Shading auf die CPU in Form einer Emulation auslagern muss. Alles wie bisher, nur legen die AMD-Karten noch stärker zu, da das Feature beim neuesten AOTS-Build intensiver genutzt wird. Da kann man nur hoffen, dass die Pascalarchitektur da umfassend gegensteuert.

    Es wäre schließlich blöd, wenn weiterhin nur AMD-Karten das nativ per Hardware unterstützen würden.
    0
  • FormatC
    Warten wirs ab, es wird wieder etwas spannender :)
    0
  • TenDance
    Mein Highlight des Tests ist ja SFR. Weniger weil das klingt als würde damit das Ende der SLI/CF-Profile eingeläutet werden, sondern eher weil man damit offenbar die bislang so häufig brachliegenden GPUs der Prozessoren nutzen könnte.
    Dadurch scheint das Konzept AMDs seine APUs mit GPUs zu paaren endlich zu einem vernünftigen Ergebnis zu führen. Und auch die iGPU der Intel Prozessoren wäre zu was nütze. Interessant hier natürlich vor allem die Iris Pro in den broadwells.
    Natürlich muss man ein Auge auf die TDP dabei halten, gerade für Übertakter ist eine doch recht große GPU auf dem die nicht immer dem Wunsch nach mehr Prozessorleistung zuträglich.
    Dass man dergleichen bereits mit einem durchaus prozessorlastigen Spiel testen kann klingt geradezu perfekt, da viele Spiele die CPU nicht ganz so fordern und ein negativer Einfluss durch die aktive iGPU dann schwerlich auffallen würde.
    0
  • FormatC
    Du vergisst aber den Input-Lag, der zusätzlich entsteht. Das wird sich auch mit SFR nicht ändern, zumal ich fast glaube, dass man uns bei Ashes gerollt hat, und nur ein optimiertes AFR zum Einsatz kommt. Zumindest anhand der Log-Files sieht das fast so aus.
    1
  • kleinstblauwal
    Sehr interessanter Test. Jetzt wo der Artikel der fertig werden musste raus ist, wäre ja Zeit für ein paar Extras. Wie sieht es mit der Leistungsaufnahme aus? Ändert die sich unter DX12, erhöht sie sich, weil brachliegende Rechenwerke jetzt genutzt werden und nach Watt schreien. Erhöht sich unterm Strich durch die gestiegene Leistung bei AMD trotzdem die Effizienz? Wenn man das ganze dann aufgeschlüsselt auf CPU und GPU wissen möchte, fällt mir nur eine Person ein, die man fragen kann.

    Eigentlich sollte man sich für AMD freuen, dass deren Karten so gut abschneiden. Allerdings wird daraus wahrscheinlich kein Umsatz, selbst wenn die Verhältnisse für kommende DX12-Titel ähnlich aussehen.
    Der NVidia-Nutzer sieht, dass die FPS mit einer anderen Grafikkarte deutlich besser ausfallen könnten, und kauft dann aus Gewohnheit wahrscheinlich wieder was grünes, weil die bis dahin erschienen Pascals vielleicht besser dastehen als Maxwell jetzt und weil er mal in einem Forum gelesen, dass die Treiber von ATi ja so schlecht seien.
    Der Radeonnutzer hingegen, sieht, dass seine aktuelle Karte mit DX12 einen kräftigen Schub erhalten hat und schiebt seine nächste Investition auf.
    0
  • FormatC
    Was glaubst Du, was ich seite heute früh um 6.00 Uhr mache? :P
    0
  • kleinstblauwal
    Im Forum schreiben (während du die Benches durchlaufen lässt)?
    0
  • Lauch81
    Interview with Nvidia engineer about DirectX 12: https://www.youtube.com/watch?v=Dnn0rgDaSro
    0
  • FormatC
    1. Ich besitze nicht nur einen Arbeitsplatz, sondern fünf
    2. Männer sind Multitaskingfähig
    0
  • amd64
    Hehe ... huch hab ich das jetzt während der Arbeitszeit geschrieben?
    Ich freu mich schon auf die Fanboy Battles in den Foren :D
    0
  • FormatC
    Es ist immer Arbeitszeit :D
    0
  • ShieTar
    Quote:
    Du vergisst aber den Input-Lag, der zusätzlich entsteht. Das wird sich auch mit SFR nicht ändern, zumal ich fast glaube, dass man uns bei Ashes gerollt hat, und nur ein optimiertes AFR zum Einsatz kommt. Zumindest anhand der Log-Files sieht das fast so aus.


    Das musst du genauer erläutern, warum sollte ein echtes SFR noch zusätzlichen Input-Lag erzeugen? Im Gegensatz zum AFR ist es doch so das beim SFR die Grafikkarten immer nur mit dem jeweils nächsten Frame beschäftigt sind, und nicht schon mit dem übernächsten. Daher sollte die Latenz im SFR tatsächlich nur halb so hoch sein wie im AFR.
    0
  • FormatC
    Ich lehne mich jetzt mal aus dem Fenster und behaupte, hier kommt gar kein echtes SFR zum Einsatz, sondern irgendein - nein, Fake schreibe ich jetzt nicht. Da stehe ich übrigens nicht allein da und warte erst mal genüsslich ab, was die Kollegen noch so herausfinden. Die Werte passen einfach nicht zusammen.

    Echtes SFR hat kein Lag, richtig. Nur haben wir hier wohl keins. Weiß der Geier, was DX12 und Oxide da so treiben...
    0
  • TenDance
    Auf der einen Seite könnte man sagen: solange es lagfrei ist und funktioniert, kann es uns egal sein ob sie endlich AFR hinbekommen haben oder es etwas Neues ist. Perfekt wäre es natürlich wenn man die renderpipeline komplett zerlegen könnte und Teilbereiche aufteilt. Dann könnte man eine GPU kaufen welche massig Polygone zeichnet und eine andere welche besonders gut das blending beherrscht.
    Meiner Ansicht nach hat Microsoft im Rahmen der "FFXV"-Techdemo für Dx12 damals sogar angekündigt dass man mit Dx12 die Graphik an sich von der GPU berechnen lassen könnte während die Nachbearbeitung von der iGPU übernommen wird.
    Und ja, einige Messwerte bezüglich der Skalierung der Karten sehen merkwürdig aus. Dass die Furys in einem nicht-VRAM-limitierten Szenario nicht schneller laufen als Hawaii... sollte auch AMD nicht freuen. In Tests Deiner Kollegen hat AMD zuweilen sogar noch mehr Luft auf die 980Ti rausgeholt mit den Fiji-Chips - ich glaube Fiji ist durch seine Doppeltonga-Konfiguration einfach ein sehr spezieller Chip der manchmal funktioniert und manchmal einfach an irgendwelchen Flaschenhälsen hängt. So richtig rund wirkt auf mich nur die Nano, was die für 175W bietet ist klasse.
    P.S.: Ich gehe davon aus dass euer Betatreiber inhaltlich dem heitigen Crimson-Release entspricht, oder kann man da noch leichte Verbesserungen erwarten? Vermutlich würde ein Nachtest ohnehin erst nächsten Monat Sinn ergeben. Finale Spielversion, passender nVidia-Treiber...
    0
  • FormatC
    Der Treiber ist der gleiche :)

    Der Unterschied fällt bei einigen Kollegen deshalb größer aus, weil sie Referenzkarten nutzen, die stets ins thermische Limit rennen. Das wiederum ist Äpfel-Birnen-Kompott, wenn gleichzeitig R9 390X mit im Test sind, die es als Referenz gar nicht gibt. Nur werde ich mich dazu nicht auslassen. :)
    0
  • Michalito
    Ja, zuerst einmal gute Besserung und eine ausgiebige Idle-Zeit. Danke für das Effizenz Update mit seperater GPU / CPU Messung. Hammer, so genau liefert das kein anderer im Netz. Many THX. Fazit für mich: Die 380 (x) macht ihre Sache ganz gut im Hinblick auf AS, und wird bei mir in kürze eine 7870 ablösen. In 1080p wird das wohl reichen, bis endlich ein OLED Monitor in 2160p oder besser noch 4k bei mir einzieht. 2 Jahre dauert das bestimmt noch..
    0
  • Mirage_DU
    Tia die 290/390er Serie war noch nie ein Kostverächter was Strom angeht. Das sieht man auch jetzt nach dem Artikel Update mal wieder. Wie hoch liegt denn bei der verwendeten 390X das Power Limit? Wurde es ohne zusätzliche Einstellungen via Afterburner oder ähnlichem von der Karte durchbrochen?
    0
  • Michalito
    @Mirage
    PWL der MSI ist 375 W geht aber noch mehr..
    http://www.tomshardware.de/amd-radeon-r9-390x-r9-380-r7-370-grafikkarten,testberichte-241836-11.html
    Und durchbrochen wurde es nicht, hier gingen bis zu 333 Watt
    0
  • Mirage_DU
    Ok dann geht es ja. Säuft zwar wie ein Loch durch stärkere Auslastung ist aber noch innerhalb der Vorgaben. Ich hatte es so verstanden als wenn des Power Limit überschritten wurde, hatte jetzt aber selber keine konkreten Zahlen parat. Bin aber nach wie vor gespannt was die nächste Generation bringt. AMD hat ja eine deutlich gesteigerte Effizienz versprochen. Mal schauen ob sie zu NVidia aufholen können.
    0
  • Michalito
    Bis wir den großen AMD Chip sehen ist es aber 2017. Und dann ist auch Big Pascal am Start. Aber, vlt. macht halt nicht nur Effizienz sondern diesmal Featureset der HW diesmal unter DX 12 den Unterschied. AS wie dieser Artikel zeigt, man wird das Thema halt noch Beobachten müssen. Toll finde ich auch diue kommende 10 Bit Farbtiefe.
    0