Test Tomb Raider Benchmark: DirectX 12 ist da, aber mehr Leistung gibt es nicht

[noxon]

Oder On-the-Fly-Kompression einbauen.

Während eines Level-Loads könnte man das vielleicht noch machen, obwohl das Laden der Level dadurch langsamer würde, aber heut zu Tage werden Texturen ja alle während des Spiels direkt von Platte in den Speicher gestreamt.
Da müssen die schon direkt in dem entsprechenden Format vorliegen und können nicht erst alle on the fly komprimiert werden. Es wäre jedenfalls unnötig verschenkte Leistung, die man gut für andere Dinge verwenden kann.

Häh? 6 oder 7 Kerne bedeutet doch Multicore, oder hab ich da was falsch verstanden?

Ne. 6 ist natürlich Multi.

So wie ich dich verstanden habe, sagtest du aber, dass durch die gute Multicoreoptimierung der neuen Konsolenspiele DX12 überflüssig würde.
Das ist aber nicht der Fall.
Gerade weil die neuen Spiele jetzt so stark parallelisieren wird eine API benötigt, die das auch auf dem PC beherrscht und dafür war DX11 einfach nicht in der Lage. Mit DX11 lassen sich nämlich gerade mal 3 Kerne effizient ausnutzen, was für Portierungen alter Konsolen-Titel noch ok war, da die auch meistens nur auf 3 Kerne optimiert waren, aber 6 Kerne kann der Treiber definitiv nicht mehr effektiv auslasten.

 

[II n II d II]

@noxon
Achso, jetzt haben wir's.

Ich hatte überfällig geschrieben, nicht überflüssig. Und zwar aus genau dem von dir geschriebenen Grund.

Und halt, dass prinzipiell nicht so viel zusätzlicher Entwicklungsaufwand der Studios in Hinblick auf DirectX12 nötig sein dürfte, da die Multiplattformtitel ja sowieso schon auf mehr Kerne hin optimiert werden.

 

[kisser]

Je nach dem, wie eine API aufgebaut ist lassen sich bestimmte Aufgaben eben mehr oder weniger effizient bearbeiten und hier ist DX12 nun mal klar im Vorteil.

Man kann mit Dx11 alles machen, was man auch mit Dx12 machen kann und kann das ebenso performant machen. Es ist nur aufwendiger
zu programmieren, weil DX11 eben Flaschenhälse hat, die es mit Dx12 nicht gibt, z.B die Draw-Calls.

Darüber hinaus erlaubt Dx12 Zugriff auf HW Features, die nicht via Dx11 angesprochen werden können (AC), was sich ebenfalls positiv auf die Geschwindigkeit der SW auswirken kann.

AC ist ein API-Feature und kein HW-Feature.

Ergänzung (14. März 2016)

DX12 als API ist nicht nur anderer Sprit, sondern auch eine andere Motorkonfiguration.

Wenn aus dem Motor aber schon alles an Leistung rausgeholt wird, dann wird es mit einer anderen Konfiguration nicht schneller.

 

[noxon]

@noxon
Achso, jetzt haben wir's.

Ich hatte überfällig geschrieben, nicht überflüssig. Und zwar aus genau dem von dir geschriebenen Grund.

Oh sorry. Ist mal wieder typisch für mich. Ich lese nur das was ich lesen will. Nicht das was dort wirklich steht.

Man kann mit Dx11 alles machen, was man auch mit Dx12 machen kann und kann das ebenso performant machen. Es ist nur aufwendiger
zu programmieren, weil DX11 eben Flaschenhälse hat, die es mit Dx12 nicht gibt, z.B die Draw-Calls.

Wie kommst du denn auf die Idee?
Wie ich zuvor schon mal beschrieben habe bietet DX12 zum Beispiel neue Kompressionsverfahren für Texturen. Wie willst du das mit DX11 erledigen?

Mit DX12 kannst du so viele Dinge anstellen, die du mit DX11 nicht kannst. Das führt nicht nur zu besserer Performance, sondern auch zu neuen Algorithmen und Problemlösungen, die man so in DX11 nicht mehr lösen kann.

Wenn aus dem Motor aber schon alles an Leistung rausgeholt wird, dann wird es mit einer anderen Konfiguration nicht schneller.

Es kann aber nicht die volle Leistung aus dem Motor herausgeholt werden, weil das Auto ständig an der Ampel anhalten muss, damit der nachfolgende Verkehr wieder aufholen kann.
Mit DX12 ist es möglich während du an der Ampel stehst noch andere Arbeiten mit dem Motor durchzuführen bis der nachfolgende Verkehr aufgeholt hat und ihr gemeinsam alle wieder bis zur nächsten Ampel vorrücken könnt.
Das geht mit DX11 nicht. Dort stehst du an der Ampel und dein Motor dreht Däumchen.

 

[kisser]

Wie kommst du denn auf die Idee?
Wie ich zuvor schon mal beschrieben habe bietet DX12 zum Beispiel neue Kompressionsverfahren für Texturen. Wie willst du das mit DX11 erledigen?

Texturen habe ich jetzt hierbei nicht betrachtet, die Kompressionsverfahren dienen ohnehin überwiegend der Einsparung von Speicherplatz. Besser aussehen wird dadurch nichts.

Mit DX12 kannst du so viele Dinge anstellen, die du mit DX11 nicht kannst. Das führt nicht nur zu besserer Performance, sondern auch zu neuen Algorithmen und Problemlösungen, die man so in DX11 nicht mehr lösen kann.

Nein. Beides APIs sind gleichwertig bezüglich ihrer Möglichkeiten.

Es kann aber nicht die volle Leistung aus dem Motor herausgeholt werden, weil das Auto ständig an der Ampel anhalten muss, damit der nachfolgende Verkehr wieder aufholen kann.
Mit DX12 ist es möglich während du an der Ampel stehst noch andere Arbeiten mit dem Motor durchzuführen bis der nachfolgende Verkehr aufgeholt hat und ihr gemeinsam alle wieder bis zur nächsten Ampel vorrücken könnt.
Das geht mit DX11 nicht. Dort stehst du an der Ampel und dein Motor dreht Däumchen.

Das mag vielleicht für AMD gelten, für Nvidia aber nicht. Man schaue sich dazu nur mal an, wie sich die reale Performance im Bezug zur theoretischen Rechenleistung verhält.

 

[SuddenDeathStgt]

...rennt ganz gut in 4K mit ner GTX 980 - und sieht lecker aus find ich

Das sieht mal richtig lecker aus und es ist schon traumhaft, wie sich das alles entwickelt und was da noch für Steigerungen folgen werden. Ich kann mich ja noch an S/W & Sprites sehr gut erinnern.^^

 

[noxon]

Texturen habe ich jetzt hierbei nicht betrachtet, die Kompressionsverfahren dienen ohnehin überwiegend der Einsparung von Speicherplatz. Besser aussehen wird dadurch nichts.

Nein. Die sehen auch besser aus. (Weniger Artefekte. Die Kompression ist ja nicht verlustfrei)

Nein. Beides APIs sind gleichwertig bezüglich ihrer Möglichkeiten.

Ja ne, is klar. Kannst du dir aber auch selbst alles ergooglen in Zusammenhang mit dem DX12 Begriff.
Async Shaders
Command Buffer Recording, Command List und Command Queues
Pipeline State Objects
Descriptor Heap und Desciptor Tables
Bundles
3D engine, compute engine, copy engine
und so weiter und so fort.

Ein Beispiel was mit DX11 nicht so gut möglich sein wird, aber mit DX12 schon ist übrigens auch Low Latency VR Rendering.
Auch dafür eignet sich DX11 nicht besonders.

Das mag vielleicht für AMD gelten, für Nvidia aber nicht. Man schaue sich dazu nur mal an, wie sich die reale Performance im Bezug zur theoretischen Rechenleistung verhält.

Das hat mit AMD und nVidia nicht das Geringste zu tun.

 

[alQamar]

Hat jemand eine Ahnung wann es den DX12 für Rise of Tomb Raider geben wird für diejenigen die es über die Xbox App / Windows 10 Store erworben haben und auf dem Windows 10 PC spielen wollen?

Ich habe das Gefühl, dass es bis jetzt noch gar keine Patches gab.

 

[VikingGe]

Naja, kisser sagt nur, dass man mit beiden APIs dasselbe Ergebnis erzielen kann, nicht, dass man sie auf dieselbe Art und Weise erzielen kann. Das dürfte zumindest für die einfachsten Feature Level im Großen und Ganzen stimmen, siehe D3D 11.3.

Außer eben bei der Performance. D3D11 hat eben ein härteres Draw Call-Limit und man kann eben nicht jeden Draw Call vermeiden, zumal D3D11 wie gesagt auch kein Indirect Multidraw unterstützt und man damit zwangsläufig mehr Draw Calls braucht als in Vulkan, D3D12 oder - festhalten - OpenGL. Andere Gründe hab ich vor einigen Beiträgen genug aufgezählt. Dazu komt dann eben die Zustandsvalidierung bei jedem popeligen Zustandswechsel.

Was du da aufzählst, ist lediglich die Art und Weise, wie Dx12 etwas erledigt. Da haben die alten APIs eben andere Entsprechungen für, die letztenendes aber genau das gleiche machen.

Command Buffer Recording, Command List und Command Queues

Gab es in den alten APIs nicht, letztenendes ist das aber funktional äquivalent zu einer Sequenz von Funktionsaufrufen.
Bei OpenGL 1.x gab es sowas übrigens schonmal, nannte sich Display List. Im Grunde witzig, dass ein ähnliches Feature nach so vielen Jahren wieder aufgetaucht ist.

Pipeline State Objects

Entspricht der State Machine in OpenGL. Keine Ahnung, wie genau das bei D3D11 aussieht, das arbeitet aber wohl auch irgendwie mit globalen Zuständen. Das wird einfach nur dezentralisiert, damit man mal sowas wie Multicore-Skalierung hinbekommt.

Descriptor Heap und Desciptor Tables

Descriptor Sets sind die Binding Points für Texturen, Buffer und Konsorten. Ebenfalls nichts neues, nur die Art und Weise, wie man sie anspricht, ist neu.

Bundles

Sagt mir jetzt ehrlich gesagt nichts, zumal es den Begriff in der Vulkan- und OpenGL-Welt nicht gibt.

3D engine, compute engine, copy engine

Da weiß ich auch nicht, wofür Microsoft sich da jetzt wieder so unklare Namen ausgedacht hat, aber wahrscheinlich sind damit einfach nur die verschiedenen Queue-Familien gemeint. Die explizite Zuordnung war früher nicht nötig (=> Treiber), am Rendering-Prozess ändert sich dadurch aber nichts.

Was soll eigentlich die Streiterei um Async Compute? Lest euch doch mal die Dokumentation zu dem Thema durch. Das "Feature", ist in erster Linie ein Nebeneffekt davon, dass man verschiedene Queues in D3D12 explizit ansprechen kann und muss. Letztenendes sind mehrere Execution Engines quasi eine Art SMT für Grafikkarten, und ein gewisser Hersteller kann dadurch eben Vorteile für sich verbuchen, und ein gewisser anderer Hersteller hat damit eben Probleme.

 

[Nai]

Letztenendes sind mehrere Execution Engines quasi eine Art SMT für Grafikkarten, und ein gewisser Hersteller kann dadurch eben Vorteile für sich verbuchen, und ein gewisser anderer Hersteller hat damit eben Probleme.

Mit diesem Vergleich wäre ich etwas vorsichtig, da es auf einer komplett anderen Ebene als "herkömmliches" SMT, welches jede moderne Graphikkarte ja auch bereits in sehr weiter form (64-fach bei Maxwell, 40-fach bei GCN) hat, stattfindet.

 

[Scorp78]

Guten Tag zusammen.
Also ich kann nur sagen das Direkt x12 der Hammer ist. Es ist von den Frames nicht besser das ist richtig . In dem Sinne gibt es keine Leistungssteigerung. Aber wenn die Frames im Spiel einbrechen , läuft das Bild weit aus flüssiger weiter als unter Direkt x11 . Mein System ist ein Amd fx8350 mit einer Asus gtx970 oc . Ich spiele auf einem Casio Laser/Led Hybrid Beamer (1280x800 mit 2,20m Leinwand Diagonale ) Es läuft so geil jetzt das ich über die ersten Schritte der Entwickler bei Direkt x12 mal nicht meckern will. Viele hier tun den Entwicklern mal echt unrecht . Klar das Spiel wurde viel zu schnell für den Pc auf den Markt geschmissen und hat viele Leistungseinbußen noch. Und das es in der Kapitalistischen Welt Preisabsprachen und Manipulation gibt keine Frage. Aber die Entwickler wären ganz schön blöd an so einem mit liebe im Detail Spiel , nicht dran zu arbeiten das es flüssig läuft. Das Spiel ist alles andere als dahin geklatschter Müll ! In 25 Jahren ist mir schon viel Mist an Spielen ins Haus gekommen das hier gehört zu den schönsten Detail verliebtesten Spiele die ich je gesehen habe. Auf dem Beamer ist es eine Augenweide Und mal ehrlich wieviele Millionen Spieler haben eine Amd Grakka ? Soviel Bestechungsgeld kann niemals geflossen sein diesen Marktanteil zu ignorieren! Man gibt sich vieleicht erst mühe mit Nvidia Karten weil die da immerhin auch Geld reingesteckt haben, aber das wird alles noch gepatcht . Hier geht es um zisch Millionen Amd Grakka Spielern Weltweit ,was da ein Geld verloren geht so blöd kann man nicht sein. ^^ Abwarten und Tee trinken halt.. So schauts auf meinem Beamer aus

 

[SuddenDeathStgt]

Hi & welcome @CB!

Endlich mal jemand der nicht nur "Zahlen sieht" & das lässt doch hoffen.^^ Übrigens, Beamer klingt gut, bis auf die Resi, aber lt. Bildchen ist es gar nicht sooo ausgefranst.

 

[noxon]

Naja, kisser sagt nur, dass man mit beiden APIs dasselbe Ergebnis erzielen kann, nicht, dass man sie auf dieselbe Art und Weise erzielen kann. Das dürfte zumindest für die einfachsten Feature Level im Großen und Ganzen stimmen, siehe D3D 11.3.

Naja, es stimmt natürlich, dass du mit DX11.3 12_1 ziemlich viele Features realisieren kannst. Es ist praktisch DX12 nur etwas anfängerfreundlicher, aber das ist auch nicht vergleichbar mit DX11 für Windows 7. Wenn man von einem DX11 Spiel redet, dann läuft das für gewöhnlich auch auf Windows 7. Also nicht mit 11.3 und dort fehlt dir also einiges an Features.
Man kann also nicht wirklich behaupten die APIs können das Selbe. Jedenfalls nicht, wenn man realistisch bleiben möchte. DX11.3 wird niemand anstelle von DX11.0 verwenden und deswegen auf die Kundschaft der Windows 7 User verzichten.

Selbst DX11.3 würde ich realistisch gesehen nicht als identisch bezeichen. Selbst wenn die Resultat identisch aussehen mögen so besteht doch schon ein ehrheblicher Performanceunterschied. In dem Fall von den selben Fähigkeiten zu sprechen ist nicht gerade fair.
Sie sind im Endeffekt eben nicht das selbe, sonst könnte man ja auch sagen, dass die x86 API das selbe könnte wie DX12, weil ich es mit einem Raytracer genau so gut auf den Schirm zaubern könnte.

Entspricht der State Machine in OpenGL. Keine Ahnung, wie genau das bei D3D11 aussieht, das arbeitet aber wohl auch irgendwie mit globalen Zuständen. Das wird einfach nur dezentralisiert, damit man mal sowas wie Multicore-Skalierung hinbekommt.

Sieht auch so in DX11 aus. Du kannst sie aber nur bedingt manipulieren, da recht viele Abhängigkeiten zwischen den unterschiedlichen States bestehen.
Mit nem PSO in DX12 werden die Zustände alle schön in ein immutable object gekapselt, wodurch sie alle wunderbar vor Nebeneffekten geschützt werden. Dadurch ist es auch möglich sie an jeder beliebigen Stelle in der Pipeline durch anlegen zusätzlicher Kopien zu verändern.
Ganz im Gegensatz zum bisherigen DX11 wo man dort doch recht eingeschränkt war in den Möglichkeiten wo man Änderungen an den States vornehmen konnte.

Sagt mir jetzt ehrlich gesagt nichts, zumal es den Begriff in der Vulkan- und OpenGL-Welt nicht gibt.

Bundles nennt MS nur kleine Mini Command Lists die sich einmal zusammenstellen und dann sehr effektiv wiederverwenden lassen ohne dann immer wieder neu berechnet zu werden.
Wenn du also immer wieder eine Hand von identischen DrawCalls mit unterschiedlichen resources verknüpfen willst wäre das so ein Anwendungsfall.
Dann erstellst du so ein Bundle und verknüpfst diese Bundle immer wieder mit neuen Resources. Die DrawCalls für das Bundle fallen dabei aber nur einmal an.

Da weiß ich auch nicht, wofür Microsoft sich da jetzt wieder so unklare Namen ausgedacht hat, aber wahrscheinlich sind damit einfach nur die verschiedenen Queue-Familien gemeint. Die explizite Zuordnung war früher nicht nötig (=> Treiber), am Rendering-Prozess ändert sich dadurch aber nichts.

Genau. Das sind die unterschiedlichen Engines. Du kannst in der 3D Engine natürlich immer noch darw calls, compute commands und copy commands unterbringen, aber das bringt auch mehr overhead mit sich, da die Engine auch recht schwergewichtig ist.
Wenn du lediglich etwas per DirectCompute berechnen willst und keine DrawCalls benötigst, dann kannst du die etwas leichtgewichtigere compute engine verwenden die etwas effizienter arbeitet. Musst du hingegen nur Daten im Speicher hin und her kopieren reicht auch die copy engine. Für texture-streaming und solche Dinge eventuell vollkommen ausreichen.
Der Vorteil von DX12 ist ja, dass du jetzt mehrere dieser Engines parallel starten kannst und so mehere command queues parallel ausführen kannst.

 

[Scorp78]

Hallo
Danke für die Begrüßung.
Nein ich schaue wirklich nicht nur auf die Framerate. Ich bin mit Doom und Wolfenstein die ersten 3d Ego shooter spielen groß geworden . Pixel cm groß lool ^^ Ich schaue auf den Inhalt das Tomb Raider 2013 war ja schon so der knaller . Das die nochmal so einen draufgesetzt haben , hätte ich nie gedacht . Und zum Beamer , man darf sich nicht durch die 1280x800 Pixel täuschen lassen . Der Beamer hat Dlp , da ist ein Spiegelchip mit über 2 Millionen Spiegelchen verbaut die 6000 mal pro Sekunde schwingen. Hat den Vorteil das kein Lcd Display verbaut ist und Lichtleistung fliegen geht . Durch dieses 6000mal schwingen verwischen die Pixel leicht ineinander das Bild ist dadurch gestochen Scharf und der Beamer hat 0 Reaktionszeit . Dank Laser und dlp kann man auch Licht anlassen und das Bild ist trotzdem super zu sehen. Fals sie auf die Idee kommen sich einen zuzulegen kann ich den Casio XJ-A257 nur empfehlen. Alle Leute die beim mir waren und zu Hause auf dem Fernseher in Full Hd zocken waren neidisch

 

[SuddenDeathStgt]

Das kann ich mir gut vorstellen & solch eine Bilddiagonale "plättet" dann halt auch entsprechend.^^ Übrigens, danke für den Tipp und sieht ganz gut aus.
Ein dickes Plus ...die Graka muss bei solch einer Resi nicht heftig "ackern" & wenn das Bild dadurch auch noch gestochen scharf wirkt bzw ist, dann ist das natürlich auch nicht zu verachten und mal schauen, vielleicht gönn ich mir so etwas auch mal ...

 

[kisser]

Nein. Die sehen auch besser aus. (Weniger Artefekte. Die Kompression ist ja nicht verlustfrei)

OK, dann sind die sicher auch unter Dx11 verfügbar.

Ja ne, is klar. Kannst du dir aber auch selbst alles ergooglen in Zusammenhang mit dem DX12 Begriff.

Ich brauche da nichts zu ergooglen, denn ich weiß was eine API ist.

Ergänzung (15. März 2016)

Naja, kisser sagt nur, dass man mit beiden APIs dasselbe Ergebnis erzielen kann, nicht, dass man sie auf dieselbe Art und Weise erzielen kann. Das dürfte zumindest für die einfachsten Feature Level im Großen und Ganzen stimmen, siehe D3D 11.3.

Absolut korrekt! !
Auch die Level 12_1 Features von Nvidia, wie ROV und CR, sind über DX11 (D3D 11.3) nutzbar.

 

[noxon]

Auch die Level 12_1 Features von Nvidia, wie ROV und CR, sind über DX11 (D3D 11.3) nutzbar.

Und wer nutzt die DX11.3 API? Die ganzen DX11 Spiele von denen hier immer die Rede ist sind es nicht.
DX11.3 ist eine ziemlich sinnlose API. Keiner weiß so wirklich wozu MS die überhaupt eingeführt hat. Wer die damit verbundnen Features nutzen will verwendet DX12 und nicht DX11.3.
Sie ist ja wie DX12 auch auf Windows 10+ beschränkt und erfordert auch die selbe Hardware. Der einzige Unterschied ist zu DX12 ist, dass sie etwas höher abstrahiert und dafür muss man dann auch die deutlich schlechtere Performance in Kauf nehmen.
Warum sollte man also DX11.3 verwenden?

Das einzige, wofür man sie verwenden kann ist, wenn man alte DX11 Titel um neue Features erweitern will, aber nicht auf DX12 umsteigen möchte. Damit dürften diese Dinge dann recht leicht zu implementieren sein ohne das man gleich neue Renderpfade für DX12 implementieren zu müssen.

Wenn man aber im Allgemeinen von DX11 redet, dann spricht man eigentlich nur von DX11.1 womit man auch Spiele für Windows 7 entwickeln kann, denn das ist im Moment noch der größte Markt für die Spieleentwickler.

 

[kisser]

Und wer nutzt die DX11.3 API? Die ganzen DX11 Spiele von denen hier immer die Rede ist sind es nicht.
DX11.3 ist eine ziemlich sinnlose API. Keiner weiß so wirklich wozu MS die überhaupt eingeführt hat. Wer die damit verbundnen Features nutzen will verwendet DX12 und nicht DX11.3.

Kaum ein Entwickler wird es sich leisten können, keinen DX11 Pfad zu implementieren, weil damit alle Windows-OS vor Windows10 außen vor bleiben und auch Karten wie die HD 5xxx/6xxx von AMD und NVidias Fermi. Ob man die neuen Features unter D3D 11.3 auf Win10 nutzt bleibt natürlich dem Entwickler überlassen.

 

[EchoeZ]

Der Übergang dauert lange und geht fliessend. Jetzt noch DX11 Titel mit DX12 Patch, dann DX11/12 Titel, am Ende DX12 mit 'Abwärtskompabilität'

PS Irgendwann muss der User einsehen, dass man aktuelle Titel nicht mehr spielen kann. Irgendwann muss Schluss sein. Meine Graka z.B. ist soo alt, im PC Leben wäre sie schon volljährig und Unterschriftsberechtigt. Bevor die künstlich beatmet werden muss, ziehe ich selbst den Stecker.

 

[Worms]

Schade das DX 12 in diesem Spiel nicht mehr Leistung bringt.