Hitman (2016) Episode 2: DX12 mit bis zu 60 Prozent Leistungsplus - und Problemen

[Locuza]

Dies erwähnte Locuza im Zusammenhang mit Pascal Spekulationen die aktuell kursieren, dass man die context switch Kosten eventuell reduzieren konnte.

Das ist übrigens keine Spekulation, dass steht im Pascal White-Paper, siehe Dev-Blog mit allen nötigen Verlinkungen:
Inside Pascal: NVIDIA's Newest Computing Platform | Parallel Forall

Compute Preemption is another important new hardware and software feature added to GP100 that allows compute tasks to be preempted at instruction-level granularity, rather than thread block granularity as in prior Maxwell and Kepler GPU architectures. Compute Preemption prevents long-running applications from either monopolizing the system (preventing other applications from running) or timing out. Programmers no longer need to modify their long-running applications to play nicely with other GPU applications. With Compute Preemption in GP100, applications can run as long as needed to process large datasets or wait for various conditions to occur, while scheduled alongside other tasks. For example, both interactive graphics tasks and interactive debuggers can run in concert with long-running compute tasks.

In contrast, the Kepler [Und auch Maxwell] GPU architecture only provided coarser-grained preemption at the level of a block of threads in a compute kernel. This block-level preemption required that all threads of a thread block complete before the hardware can context switch to a different context. However when using a debugger and a GPU breakpoint was hit on an instruction within the thread block, the thread block was not complete, preventing block-level preemption.

Das behandelt nur Compute-Aufgaben, aber Rendering-Instructions sollten ebenfalls profitieren.

 

[Gast20190527]

DX12 funktioniert bei Hitman nun nicht mehr.
Gab zwar ein Steam Update mit dieser Info: News - All News
Aber DX12 ist nun komplett hinüber. Wenn man das Spiel in DX12 öffnen startet es halt Hintergrundprozess und nichts weiter passiert.
Langsam wirds lächerlich.

ich hab noch nicht ein spiel erlebt das mit DX12 problemlos funktioniert hat bisher. Das dauert halt alles noch ne weile. Hitman hab ich auf DX11 gespielt die ganze zeit, da es auf DX12 direkt abgeschmiert ist.

 

[openSUSE]

Das ist übrigens keine Spekulation, dass steht im Pascal White-Paper, siehe Dev-Blog mit allen nötigen Verlinkungen:
Inside Pascal: NVIDIA's Newest Computing Platform | Parallel Forall




Das behandelt nur Compute-Aufgaben, aber Rendering-Instructions sollten ebenfalls profitieren.

Ok, sie können zwichen Compute aufgaben nun etwas granularer wechseln und das "Stalling" dadurch etwas abmildern. Der Kontextwechsel, vor allem bei Grafik- und Compute-Aufgaben, aber bleibt.
Und daher ändert es auch nichts an der ganzen Asynchronous Shader schwäche bei Nvidia. Somit scheint ja Nvidia indirekt zuzugeben das Pascal kein Asynchronous Shader können wird.

Edit---
Wobei die AMD Implementierung mal wieder deutlich mehr ermöglicht UND schon jetzt in Hardware implementiert ist.
DX12: AMD erweitert Asynchronous Compute um Quick Response Queues

To address this problem, we have introduced the idea of a quick response queue. Tasks submitted into this special queue get preferential access to GPU resources while running asynchronously, so they can overlap with other workloads. Because the Asynchronous Compute Engines in the GCN architecture are programmable and can manage resource scheduling in hardware, this feature can be enabled on existing GPUs (2nd generation GCN or later) with a driver update ...

 

[cl55amg]

@ Locuza

Danke für die Info.

Ok, sie können zwichen Compute aufgaben nun etwas granularer wechseln und das "Stalling" dadurch etwas abmildern. Der Kontextwechsel, vor allem bei Grafik- und Compute-Aufgaben, aber bleibt. Und daher ändert es auch nichts an der ganzen Asynchronous Shader schwäche bei Nvidia. Somit scheint ja Nvidia indirekt zuzugeben das Pascal kein Asynchronous Shader können wird.

Edit---
Wobei die AMD Implementierung mal wieder deutlich mehr ermöglicht UND schon jetzt in Hardware implementiert ist.
DX12: AMD erweitert Asynchronous Compute um Quick Response Queues

Ja es muss weiterhin ein Context Switch gemacht werden, aber dieser wird dann weniger kosten. Man kann eine Schwäche durch eine andere Stärke wieder ausgleichen. Am Ende zählt die Gesamtleistung ...

 

[Locuza]

Ich persönlich habe an der Stelle nichts anderes für Pascal erwartet, schnelleres Switching, aber kein Mix aus 3D- und Compute-Warps.
Die praktische Frage ist aber am Ende, ob das eine nennenswerte Rolle spielt?
Bei Ashes tut es das auf jeden Fall bisher:
Ashes of the Singularity DirectX-12-Leistungsexplosion (Seite 3) - ComputerBase

Der Vorsprung bei Async Compute off auf on wächst bei der Fury X gegenüber der 980Ti von 12% auf 29% an.
AMD scheint bisher pro GPU und Spiel so im Rahmen von 5-15% zu gewinnen.
Nvidia verliert dagegen ein paar % bei Maxwell, mit Pascal gibt es vielleicht nur noch 1% Verlust.
Letztendlich interessiert den Kunden aber nur, wie gut die Performance ist und die hängt nicht einzig und allein von einer Sache ab.


Die QRQ ist interessant für Occulus, dazu gibt es aber noch glaube ich keine guten Vendor-Vergleiche.
Computerbase hat einen bei der Vive angestellt:
VR Benchmarks: So viel Leistung brauchen Spiele - ComputerBase

Hier stellt sich kein Vorteil für AMD heraus, Valve verwendet aber auch keine Asynchronen Time Warps, entsprechend läuft es dort klassisch ab.

 

[cl55amg]

Bei Ashes tut es das auf jeden Fall bisher:
Ashes of the Singularity DirectX-12-Leistungsexplosion (Seite 3) - ComputerBase

Der Vorsprung bei Async Compute off auf on wächst bei der Fury X gegenüber der 980Ti von 12% auf 29% an.
AMD scheint bisher pro GPU und Spiel so im Rahmen von 5-15% zu gewinnen.
Nvidia verliert dagegen ein paar % bei Maxwell, mit Pascal gibt es vielleicht nur noch 1% Verlust.
Letztendlich interessiert den Kunden aber nur, wie gut die Performance ist und die hängt nicht einzig und allein von einer Sache ab.

Die Messwerte zu AoS sind ja bekannt, genauso wie die Tatsache, dass dieses Spiel unheimlich schlecht optimiert ist.
Es läuft wirklich sehr schlecht ohne erkennbaren Grund...(besonders auf Nvidia GPUs)
Dieses Spiel würde ich nicht als Basis für eine zukünftige Einschätzung nehmen.

 

[Locuza]

Ich persönlich halte Abstand von der Bewertung, ob das Spiel jetzt sehr schlecht läuft oder nicht, aber es leider das einzige Spiel was DX11 und DX12 unterstützt und daneben einen Schalter für Multiengine on/off anbietet.
Das Spiel ist in der Hinsicht ein Bewertungsparadies, es spuckt auch selber alle Frame-Times und Daten heraus.
Es ist ein Spiel in dem AMD auf jeden Fall sehr viel gewinnt.

Das geht auch anders, Tomb Raider läuft leider sehr bescheiden bei AMD unter DX12, obwohl es auch Multiengine verwendet und gar zeitlich befristet ein Konsolenexklusiver Titel mit MS sponsering war.

Gears of War und Quantum Break wird man vermutlich erst ab Mai richtig bewerten können, wenn UWP-Apps Vsync off erlauben.

Hitman ist irgendwie, naja...
Die Ergebnisse von Episode 1 und 2 unterscheiden sich, DX12 verhält sich fragil und eine allgemeine Bewertung ist leider auch noch nicht möglich.

 

[Laggy.NET]

Also die Anforderungen, die das Spiel stellt sind sicherlich nicht übertrieben. Die Detailfülle scheint auf den Screenshots schon enorm zu sein. Wenn ich mal so zurückdenke, sowas hat man bisher noch nicht gesehen.

Man sehe sich das hier an: Hitman (216) Episode 2: DX12 mit bis zu 6 Prozent Leistungsplus - und Problemen - Bild in Originalgrosse (8)
Zommt mal auf 100%. Vor allem die Vegetation wird wirklich sehr sauber dargestellt. Alles schön mit eigenverschattung und vielen Highlights und ohne vegetationsmatsch.
Ich finde, an den Screenshot oben kommt nichtmal Witcher 3 ran.
Hier mal zum Vergleich Blood and Wine The Witcher 3: Blood & Wine - Neue Screenshots zeigen mehr von Toussaint - Bild in Originalgrosse (3)
Achtet mal nur auf die Darstellung der Vegetation, vor allem die Gräser.

Auch wenn der Grafikstil sehr unterschiedlich ist, Qualitativ finde ich Hitman eigentlich besser.
Wäre der Grafikstil nicht ganz so bieder gehalten, würde das alles wohl auch besser zur Geltung kommen.

 

[openSUSE]

Die Messwerte zu AoS sind ja bekannt, genauso wie die Tatsache, dass dieses Spiel unheimlich schlecht optimiert ist.
Es läuft wirklich sehr schlecht ohne erkennbaren Grund...(besonders auf Nvidia GPUs)
Dieses Spiel würde ich nicht als Basis für eine zukünftige Einschätzung nehmen.

Bei Ashes of the Singularity ist ja wohl eindeutig mehr Wert auf DX12 als auf DX11 gelegt worden und das dann Nvidia mit DX12 schwäche ins "straucheln" gerät liegt ja wohl eher an Nvidia als am Spiel.

 

[Locuza]

Ich denke nicht das die Nitrous-Engine einen eindeutigen DX12-Fokus hatte, sondern eher das es eine moderne und zukunftsorientierte Engine ist, die einfach entsprechend gut mit der DX12 Abstraktion zusammenspielt.
Der DX11 Rendercode ist sicherlich auch gut optimiert, die Entwickler haben das früher übrigens auch behauptet, dass sie mehr Zeit in die DX11 Optimierung gesteckt haben, als in (es war glaube ich) Mantle, wo einige den Vorwurf erhoben habe, es sei schlichtweg für Mantle optimiert und man hätte sich gar keine Mühe bei DX11 gemacht.

Eine DX12 Schwäche hat Nvidia nicht per se, dass wird häufig unsinnig dargestellt, weil sich einige an Multiengine festklammern.
Hat AMD eine DX Allgemeinschwäche, weil Tessellation (DX11 Feature) wesentlich schlechter läuft oder Geometry-Shader (DX10 Feature)?
Da wird viel zu weit ausgeholt. (Jedenfalls wenn man sich an einem Feature aufhängt und nicht die allgemeine Situation in den Kontext stellt)

 

[cl55amg]

Bei Ashes of the Singularity ist ja wohl eindeutig mehr Wert auf DX12 als auf DX11 gelegt worden und das dann Nvidia mit DX12 schwäche ins "straucheln" gerät liegt ja wohl eher an Nvidia als am Spiel.

Das Spiel läuft auch unter dem DX11 Renderpfad sehr schlecht und zwar sowohl auf Nvidia als auch auf AMD. Auch unter DX11 läuft das Spiel auf Nvidia GPUs schlechter als auf AMD GPUs.
Sogar wenn kaum Einheiten auf dem Spielfeld sind, hat man wenig fps im Verhältnis und viele drops.

 

[MiezeMatze]

Also früher war es ja so dass wenn ein neues DX rauskam alles besser aussah.

Jetzt haben wir Rise of the Tombraider....bei dem man das schönere VXAO NICHT unter DX12 aktivieren kann.
Und Hitman das in DX11 auch besser aussieht
Und QB das irgendwie immer ******** läuft

 

[9Strike]

Ich denke wir müssen den Entwicklern einfach mehr Zeit geben. Den meisten DX12 Spiele wurde ein DX12 Renderpfad reingedrückt. Die Entwickler brauchen mehr Zeit für die Umstellung, da sie viel mehr Verantwortung haben. Und ich denke es ist wichtig, das sie nicht DX11 Spiele portieren, dass DX12 draufsteht, sondern sie lernen mit DX12 umzugehen, und danach ein DX11 Renderpfad nachliefern. Ich denke so rum ist es wesentlich weniger Fehleranfällig. Problem dabei: DX12 ist Win 10 exklusiv und damit für Entwickler riskant. Und Vulcan kam erst raus. Richtige DX12 Spiele sehen wir erst gegen Ende des Jahres oder Anfang 2017.

 

[Gelöschtes Mitglied 121676]

Hat hier noch einer das Problem, dass er keine Untertitel eingeschaltet bekommt bzw. diese nur sehr sporadisch auch Ingame angezeigt werden?
Des Weiteren ist das Scope beim Sniper sowas von unscharf. Ich habe große Probleme die Mitte zu erkennen...
Spiele auf meiner 780 in Full HD und mit den empfohlenen Einstellungen, aber viel mehr stört mich das mit den Untertiteln -.-

 

[openSUSE]

Das Spiel läuft auch unter dem DX11 Renderpfad sehr schlecht und zwar sowohl auf Nvidia als auch auf AMD.

Deswegen schrieb ich ja :"Bei Ashes of the Singularity ist ja wohl eindeutig mehr Wert auf DX12 als auf DX11 gelegt worden..."

Auch unter DX11 läuft das Spiel auf Nvidia GPUs schlechter als auf AMD GPUs.

Kaum zu glauben aber AMD ist auch mal schneller, kommt in letzter Zeit sogar öfter mal vor.

Sogar wenn kaum Einheiten auf dem Spielfeld sind, hat man wenig fps im Verhältnis und viele drops.

Spiele es öfter auf einem alten Bulldozer mit einer R9 390, spielt sich wunderbar, BESONDERS unter DX12.

 

[PCGH_Phil]

Wegen der vermeintlichen "Blässe" unter DX12. Ich meine mich zu erinnern, das es damals, bei Mantel und BF4 auch einen Fall gab, bei dem BF4 unter Mantle etwas "blässer" oder schlechter belichtet aussah. Auch wenn damals viele (größtenteils Grüne) vermutet hatten, das die Leistungssteigerung daran herrührte, das unter Mantle diverse Grafikoptionen ausgeschaltet werden, wurde dies doch schnell als Bug entlarvt und innerhalb weniger Wochen (oder Tage? Erinnerung lässt nach) behoben. Von daher glaube ich schon, das I7O Interactive dies ziemlich schnell beheben könnte.

Das sieht mir nach einem unter DX12 fehlerhaften bzw. in niedrigerer Auflösung berechnetem Bloom-Shader aus. Eventuell geht das sogar Hand-in-Hand mit dem ebenfalls unter DX12 nicht korrekt funktionierendem Texturmanagement (auch ein Bloom-Shader wird normalerweise wie eine Textur gehandhabt, nachdem er berechnet wurde und schließlich über das finale Bild gelegt). So ein Shader dürfte aber schnell zu fixen sein, wahrscheinlich wesentlich unkomplizierter als die korrekte Verwaltung des Texturbudgets zu basteln. Beim LoD gibt's in diesem speziellen Fall auch noch ein paar Problemchen unter DX12.
Das ist etwas ärgerlich, schließlich ist das schon Episode 2, so langsam sollte das Engine-Grundgerüst mal funktionieren, selbst wenn die Szenarien recht unterschiedlich sind.

Microsoft hätte DX12 wirklich noch ein halbes Jahr oder so in der Entwicklung lassen sollen, die gesamte API und die Interaktion zwischen der und WDDM 2.0 bzw. Windows Display Engine oder UWP wirkt echt noch sehr unrund. Aber da gab's wohl ein bisschen Fracksausen wegen Vulkan und erstarkender OS-Konkurrenz... und jetzt haben wir halt eine API, die sich noch ziemlich Early-Access-mäßig anfühlt...

Gruß,
Phil