News Erste Lebenszeichen von Direct3D12 - AMD auf der Gewinnerseite

[User-News]

Anandtech hat erste Benchmarks mittels der Star Swarms Demo unter einer Vorabversion von Windows 10 und experimentellen Grafiktreibern durchgeführt.

Besonders aufschlußreich ist das folgende Schaubild, denn danach könnten besonders kleine APUs der A6 und A8 Serie von Direct3D12 profitieren:

Bildquelle: Anandtech

Jedoch sind die Benchmarks mit Vorsicht zu genießen. Sowohl das Betriebssystem, als auch die Treiber befinden sich in einem (frühen) Beta Stadium.

Es wird noch ein Großteil des Optimierungspotentials brachliegen. Sowohl bei Mantle, als auch beim (vermeintlich) jüngeren Direct3D12.

Zum Artikel auf Anandtech: The DirectX 12 Performance Preview: AMD, NVIDIA, & Star Swarm

Update: Das folgende Schaubild zeigt auf, dass die Grafikkarten von AMD in Relation zu ihren Gegenstücken von nVidia stärker von Direct3D12 profitieren:

Bildquelle: Anandtech

Für Spieler wird der (kostenlose) Wechsel auf Windows 10 somit beinah zu einem Muss. Über hundert Studios sollen bereits an Direct3D12 Titeln arbeiten.

 

[Unbekannter Krieger]

Verstehe ich diese Artikelseite richtig, dass die Frametimes einer 290X mit Mantle und DX12 besser sind als die einer 980?
http://www.anandtech.com/show/8962/the-directx-12-performance-preview-amd-nvidia-star-swarm/8

 

[SPINA]

Nein, da geht es um die Latenz in Millisekunden (niedrige Werte sind besser). Das heißt sie sollten gleichauf liegen mit leichtem Vorteil für nVidia.

Wenn man die Direct3D11 Kurve bei AMD außer Acht lässt, pendelt sich der Wert bei rund 30ms ein. Bei nVidia sind es mit rund 20ms etwas weniger.

 

[Unbekannter Krieger]

Ach so, die y-Achse zeigt die Latenz in Millisekunden. Und die horizontale Achse zeigt den Zeitverlauf?

Der Großteil der DX12- und Mantle-Graphen scheint mir aber bei <= 25 zu liegen, Nvidias DX12-Graph bei 11 bis 13. Also sollte die Differenz bei weniger als 20 liegen. Ausreißer gibt es ja bei beiden genug.

 

[SPINA]

Ach so, die y-Achse zeigt die Latenz in Millisekunden. Und die horizontale Achse zeigt den Zeitverlauf?

Statt dem Zeitverlauf, könnte es auch die Gesamtzahl der gerenderten Frames sein.

Also sollte die Differenz bei weniger als 20 liegen. Ausreißer gibt es ja bei beiden genug.

Mit 20ms wollte ich nicht die Differenz beziffern, sondern den Mittelwert bei der GeForce GTX 980 (grob über den Daumen gepeilt). Zwischen 20ms und 30ms (im Mittel und ohne größere Ausreißer) sollte man keinen Unterschied spüren. Sowohl auf der Radeon R9 290X, als auch bei der GeForce GTX 980 sollte der Spielverlauf demnach flüssig anmuten. Bemerkbar werden sich längere Frametimes erst ab 50ms machen und wirklich störend wird es erst ab (geschätzten) 60/70ms. Allerdings ist der Eindruck stark subjektiv. Menschen nehmen solche schwankenden Latenzen unterschiedlich wahr und es hängt sehr von der Szene im Spiel ab. Bei einem hektischen Spielgeschehen, werden längere Latenzen eher auffallen, als bei behäbigen Kameraschwenks.

 

[Complicated]

Leider sind die Benchmarks so nicht valide, wie Anand in seinem Update zeigt:
http://www.anandtech.com/show/8962/the-directx-12-performance-preview-amd-nvidia-star-swarm/6

Update: Oxide Games has emailed us this evening with a bit more detail about what's going on under the hood, and why Mantle batch submission times are higher. When working with large numbers of very small batches, Star Swarm is capable of throwing enough work at the GPU such that the GPU's command processor becomes the bottleneck. For this reason the Mantle path includes an optimization routine for small batches (OptimizeSmallBatch=1), which trades GPU power for CPU power, doing a second pass on the batches in the CPU to combine some of them before submitting them to the GPU. This bypasses the command processor bottleneck, but it increases the amount of work the CPU needs to do (though note that in AMD's case, it's still several times faster than DX11).

This feature is enabled by default in our build, and by combining those small batches this is the likely reason that the Mantle path holds a slight performance edge over the DX12 path on our AMD cards. The tradeoff is that in a 2 core configuration, the extra CPU workload from the optimization pass is just enough to cause Star Swarm to start bottlenecking at the CPU again. For the time being this is a user-adjustable feature in Star Swarm, and Oxide notes that in any shipping game the small batch feature would likely be turned off by default on slower CPUs.

If we turn off the small batch optimization feature, what we find is that Mantle' s batch submission time drops nearly in half, to an average of 4.4ms. With the second pass removed, Mantle and DirectX 12 take roughly the same amount of time to submit batches in a single pass. However as Oxide noted, there is a performance hit; the Mantle rendering path's performance goes from being ahead of DirectX 12 to trailing it. So given sufficient CPU power to pay the price for batch optimization, it can have a signifcant impact (16%) on improving performance under Mantle.

Hier sind noch 16% Durchschnittlich zu den Mantle-Werten hinzu zu fügen.

 

[SPINA]

Es ist immerhin zu begrüßen, dass Anandtech überhaupt ein solches Update zur Klarstellung veröffentlicht. Das schmälert in meinen Augen nicht den Aussagegehalt des Benchmarkparcours, sondern steigert ihn gewissermaßen noch. Natürlich unter der Gesichtspunkt, dass es sich um eine "Preview" handelt. Ein einzelne Direct3D12 kompatible Demo (gebencht mit Vorabversionen von Display Drivern) hat nun einmal einen eingeschränkten Charakter.

Ich frage mich bloß, wieso diese bremsende SBO bei schwachen Hauptprozessoren vorher niemanden aufgefallen ist; also bereits im Jahr 2014. Schließlich war Star Swarm die Vorzeigedemo für Mantle auf die sich jede größere Website mit Grafikkartentests gestürzt hat. Hätte das nicht Oxide oder sogar AMD frühzeitig auffallen müssen? Das Catalyst Team hat sich doch bestimmt mit allen am Markt befindlichen Mantle Demos und Games eingehend auf der Suche nach Bottlenecks beschäftigt. Soviele gibt es schließlich nicht und in letzter Zeit ist es ziemlich still um Mantle geworden.

Allerdings ändert das Update wenig am Fazit, was ich weiter oben gezogen habe. Direct3D12 ist mehr als nur vielversprechend. Außerdem geht es nicht darum, wieweit Mantle technisch überlegen ist. Die Spieleentwickler werden ihre Wahl unter anderen Gesichtspunkten treffen.

 

[Complicated]

Natürlich. Das spricht absolut für einen Test, wenn solche Situationen per Update auf diese Weise kommuniziert werden. Ich meinte dies als Ergänzung zu deinem Startbeitrag und die angepasste Relation der erzielten Werte. Hier bietet Mantle eben zusätzliche Vorteile die etwas mehr Performance (Immerhin 16% und damit immer vor der DX12 Lösung) rauskitzeln können. Auch soll es die Aufmerksamkeit auf andere kommende Tests lenken, denen diese Einstellung entgeht, damit man nachfragen kann in den Redaktionen.

 

[FHen1979]

Ob Mantle und Direct X 12 in der Zukunft beide koexistieren, wird man sehen. Aber AMD hat mit Mantle einen Stein ins Rollen gebracht, der wichtig war.

 

[Nosyboy]

Ob Mantle und Direct X 12 in der Zukunft beide koexistieren, wird man sehen. Aber AMD hat mit Mantle einen Stein ins Rollen gebracht, der wichtig war.

Und die Win 7 Liebhaber werden dank Mantle nicht gezwungen das OS zu wechseln.

 

[i-ch]

Aber das gilt doch nur solange es weiterhin Mantle Spiele für Windows gibt. Ich hoffe auf Mantle für Linux, MacOS, ChromOS. Sprich andere Destopsystem. Ich möchte auf Linux oder einem Chromium umsteigen oder bei Win7 bleiben.

 

[yourgreatestfear]

Den wichtigen Punkt der breiteren Verfügbarkeit (bzw. OS-Zwang) mal bei Seite geschoben:

Da beides noch viel zu sehr in den Kinderschuhen steckt ist es schon aberwitzig wie man sich FPS-charts um die Ohren haut.

Mal ehrlich, Mantle will noch nichtmal wie es soll in den Titeln die es mitliefern. Dragon Age Inquisiton hat arge Probleme mit Mantle, nicht nur fehlt der FPS Vorteil auf unzähligen Systemen komplett (teils sogar wirds schlimmer), da kämpft man zudem noch mit ganz anderen Problemen wie extrem längeren Ladezeiten als bei der Nutzung von Dx11.

Solang die APIs weiter mit dem Murks zu kämpfen haben, für jedes Spiel einzeln ein oder gar mehrere Optimierungen bei Treiber und Implementierung nachzufordern, hab ich ehrlich gesagt wenig Hoffnung für eine entspannte Zukunft für die Spieler selbst. Irgendwie sind die API- und Spieleentwickler weit vom Weg abgekommen, wenn man heutzutage jedem Produkt bei dem sie eingesetzt wird noch hinterherrennen muss und mit Treiberupdates, Profilen und anderen Kunstgriffen dem ganzen erst einen Sinn gibt, nachdem man auf dem Markt landet.

Keine Ahnung ob schon in der Konzeption geschlampt wird, man mittlerweile einfach an der Komplexität scheitert oder zuviele Kompromisse bewusst eingegangen werden, weil sonst die ganzen Blasen von Performance und Features platzen, aber mir ist da ein olles OpenGL mit langen Entwicklungszyklen und kleinen Performance/Featuresprüngen lieber .... da stressfreier als Endanwender und Entwickler.

Die Entwickler (egal ob Spiele oder API selbst) sollten sich mal überlegen, ob sie ihren Fokus nicht mal eher auf Stabilität und breite Kompatibilität setzen sollten, statt mit dem Rennen um EyeCandy bei erträglichen FPS sich eine Hölle von Problemen und Abhängigkeiten einzufangen, bei der kaum noch ein Spieler fähig ist die zu ertragen ohne Fluchen.
Was dem PC-Spieler fehlt ist stressfreies Zocken und ein sorgloser Spielekauf, ohne das große Fragezeichen obs erträglich laufen wird selbst wenn man aktuelle Hard-/Software hat und ohne Rumbasteln nach Anschaffung ... wie man es mal von den ollen Konsolen kannte. Dieser sich ausweitende Missstand um PC-spiele und das technische HickHack (ewiges Gefühl Betatester zu sein) schädigt sicherlich den Absatz mehr als die paar Kröten die man mit Kiddies verdient, die dem BlingBling folgen wie Motten dem Licht.

 

[drSeehas]

... mir ist da ein olles OpenGL mit langen Entwicklungszyklen und kleinen Performance/Featuresprüngen lieber .... da stressfreier als Endanwender und Entwickler. ...

Leider unterscheidet sich die Implementierung von OpenGL zwischen den Treibern. nVIDIA-OpenGL != AMD-OpenGL.

 

[yourgreatestfear]

Das die Treiber selbst extreme Unterschiede haben, ist mir bewusst.
Aus teils eigener Erfahrung kann ich sagen:

NVidia baut intern workarounds für AAA Titel / OpenGLfeatures und schlampt am Ergebnis rum um Anwendungen lauffähig zu halten ... wenig Probleme etwas lauffähig zu bekommen, Exceptionhandling des Treibers ist recht gut. Aber das Ergebnis hält sich nicht unbedingt an Specs / Programmvorgaben. Indieentwickler und alte Programme brauchen nicht drauf hoffen, das Nvidia ein Problem in Zukunft auch spec-konform löst, solang die gängigen Titel und Massen abgehandelt sind ist es halt persönliches Pech des API-verwenders/Users und ein Fehler der nicht codeseitig zu bereinigen ist kann halbe Ewigkeiten bleiben.

AMD hält sich an Specs aber ist noch Jahre hinterher bei Exceptionhandling und Fehlerfreiheit ... Debugging auf einem AMDsystem ist ne Qual. Je mehr Zeit AMD aber in die Treiber steckt, desto mehr Probleme werden Progs auch spec-konform und anwendungsunabhängig gelöst.

Intel ist Jahre hinterher bei Featureimplementierung, aber ganz ordentlich solang man nicht den letzten Schrei reinkleben will.


OpenGL war von mir nicht als leuchtendes Vorbild der Praxis oder gar als akzeptabler Ersatz erwähnt, sondern in der Absicht aus Entwickler- und Usersicht als Ideal angeführt.

...
Mein Punkt des Ganzen ist, dass APIs und ihre Nutzer selbst sich nicht biegen sollten in der Welt der Systeme. OpenGL krankt immer noch daran, dass kaum ein Hersteller / eine Plattform mal spec-konforme Vollständigkeit bietet, weil man entweder pennt oder kein Interesse an einem gemeinsamen Standard hat, wegen der hauseigenen Alternativen.

Egal ob Mantle oder DirectX oder <whatever next>, wenn der Irrsinn von Ausnahmebehandlungen, Treiber-, Programm- und Systemabhängigkeiten bzw. der Rush durch Versionen nicht nachlässt, werden alle APIs den Spieler mit einem ewigen Betatester-gefühl und den Entwickler mit Mordgedanken belohnen.

Vom derzeitigen Trend der Entwicklung profitieren leider nur wenige Studios und Plattformen, und selbst diese Ansicht ist fraglich da man kaum abschätzen kann was für Potenzial brachliegt/verbrannt wird durch den Mehraufwand auf allen Seiten um APIs.

 

[SPINA]

OpenGL krankt ein wenig an der Komplexität, liest man immer wieder. Das soll bei g|Next besser werden, verspricht Khronos.
Allerdings würde ich mit g|Next nicht in naher Zukunft rechnen. Die Entwicklung zieht sich bestimmt noch in die Länge.

Also hätte AMD noch (!) einen Vorsprung, um mit Mantle unter Linux Fuß zu fassen, bevor g|Next das Zepter an sich reißt.

 

[isigrim]

Ich poste mal hier das, was ich auch im Kaveri-Thread gepostet hab:
Anandtech hat im nunmehr 3. Artikel zu DX12 und StarSwarm die integrierten GPUs gegenüber gestellt. Der Titel spielt nur auf Intel an, im Test geht´s aber auch um Kaveri.
Dabei zeigt sich, dass die integrierten GPUs von AMD deutlich von der reduzierten CPU-Last profitieren können. Die zugegebenermaßen recht einseitigen Tests mit Star Swarm ergeben jetzt schon Zugewinne von teils bis zu 70 % (LQ - A10 7800) oder 63% (HQ - A10 7800) durch die Nutzung von DX12.
Ganz im Gegensatz dazu die Intel iGPUs, die wohl schon in DX11 weitestgehend im GPU-Anschlag laufen. Ein Problem mangelnder Skalierung der GT3e z.B. scheint dabei nach Aussage von Anandtech das Frontend der GPUs zu sein, welches mit den Batch Counts von Star Swarm überfordert ist. Dagegen dreht AMD in allen Bereichen ziemlich auf.

Lustig ist nun, dass man das ganze klein redet:

As for real world games, just as with our other GPUs we’re in a wait-and-see situation. An actual game designed to be playable on Intel’s iGPUs is very unlikely to push as many batch calls as Star Swarm, so the front-end bottleneck and GT3e’s poor performance are similarly unlikely to recur. But at the same time with Intel generally being the least CPU bottlenecked in the first place, their overall gains under DX12 may be the smallest, particularly when exploiting the API’s vastly improved draw call performance.

Also werden jetzt Spiele speziell für die Intel iGPUs programmiert? Das scheint mir die falsche Heransgehensweise zu sein. Denn eigentlich werden die meisten Spiele, die auf derartigen Hardware-Seiten eine Rolle spielen doch für Konsolen und diskrete GPUs entwickelt und die APUs bemühen sich, das irgendwie über die integrierte GPU gestemmt zu bekommen. Oder gibt´s jetzt für Intel dann ein: "Wir testen die iGPUs nur mit einfachen Spielen, sonst fällt auf, dass Intel da immer noch hinterher hängt."
Daher sieht DX12 nach einem ziemlich heftigen Win für AMD aus. Für Intel ist es dagegen weniger glücklich, weil die Schwäche der AMD-CPUs nun nicht mehr so stark ins Gewicht fällt. Das wird aber so nicht dargelegt, sondern man bemüht sich eben darum, das Ganze zu relativieren. Interessant wäre auch, ob das Frontend bei der Gen8 in Broadwell berändert wurde.

Alles in allem dürften jedenfalls gerade Kaveri und Carrizo von DX12 stark profitieren und AMD hat damit das erreicht, was man mit einer neuen API erreichen wollte. (Alles mit Vorsicht zu genießen aufgrund der Einseitigkeit des Tests und des frühen Treiberstatus.)

 

[Complicated]

IMHO zeigt das deutlich was passiert wenn Entwickler nicht Intel x86 als Basis benutzten. Die Konsolen zeigen Wege mehr Performance auf Hardware raus zu holen in Bereichen wo Intels Compiler keine Rolle spielen und schon verwandelt sich eine vermeintliche CPU Schwäche in Gleichstand und die Schwachen GPUs geraten noch weiter ins Hintertreffen. Es bleibt am Ende schlecht programmierte Software.

 

[isigrim]

Klar, aber das ist im Prinzip das Erfolgsgeheimnis von Intel, BruteForce an den richtigen Stellen und ein klein wenig Verzicht auf fairen Wettbewerb.

 

[SPINA]

Die iGPUs der Core i3/i5/i7 Serie spielen schon eine wichtige Rolle, denn sie haben einen relativ hohen Marktanteil, wie die Steamumfragen beweisen. Kein Entwickler kann es sich leisten die HD Graphics zu vernachlässigen. Dass AMD bei den iGPUs wesentlich besser aufgestellt ist, sollte allerdings niemanden verwundern. Die iGPUs von Intel haben nicht nur weniger Rohleistung; schlimmer noch, die vorhandene Rohleistung kommt nicht einmal vernünftig zum Zug. Intel mag mit die besten Treiber für Linux Systeme haben, aber unter Windows schwächeln sie noch immer. An dieser Stelle wird bereits massig Leistung verschenkt. Eine Änderung ist mittelfristig nicht in Sicht. Intel scheint das Problem statt dessen hardwareseitig angehen zu wollen. Die erzielten Geschwindigkeitssteigerungen sind in der Tat nicht ohne, wenn man sich anschaut, wie sich die HD Graphic seit den ersten Westmeres entwickelt hat. Dennoch gibt es einen immensen Rückstand auf AMD, obwohl Intel in dem einen anderen Benchmark Achtungserfolge erzielt hat.

THG berichtet in einem sehr schwammigen Artikel drüber, wie Direct3D12 Techniken wie SLI oder CrossFire überflüssig machen könnte. Ich würde die dort getätigten Aussagen mit höchster Vorsicht genießen, aber wenn sich einiges davon bewahrheitet, könnte es die APUs von AMD beflügeln: Klick