Locuza schrieb:
Das hat an der Stelle nichts mit mogeln zu tun, die API ist vom Feature-Set eben skalierbar.
Und wenn WoW die DX11-API mit FL10 verwendet, dann meinen sie damit auch nicht DX10.
Mogeln war vieleicht zu hart geschrieben. Fassen wir es doch mal zusammen:
Performanceverbesserungen unter d3d erreicht man prinzipiell mit dem geänderten d3d11 to d3d12
Pipeline state objekts
d3d11 erlaubt dabei Assambler, Pixelshader und Rasterizier unabhängig voneinander zu modifizieren, was sich Nvidia teilweise zu nutze macht. Dadurch entstehende Interdependenzen schmecken aber DX12 Hardware nicht. Die separate Festlegung hat unter einer DX11-API eben den Nachteil, dass der Treiber die Daten nicht ausgeben kann, ohne zu wissen ob der Status abgeschlossen ist und warten muss. Das ist eigentlich der Overhead der immer wieder entsteht und auch einen Drawcall Overhead erzeugen kann.
Unter d3d12 werden große Teile der Pipeline (Statusobjects) vereinheitlicht. Hardware und Treibern schmecken dabei nativ änderbare dynamische Anweisungen besser, insbesondere der GPU die nur geringe Mengen der Zustandsdaten direkt in die Hardwareregister kopieren muss, das wiederrum reduziert den Drawcall-Overhead pro Frame.
Command list and bundles
Unter d3d11 erfolgt die gesamte Übergabe der Befehle in einem Contex, um dabei Multithread sinnvoll zu unterstützen, wird der Contex per Engine auch zurückgestellt, der dann wiederrum nicht perfekt auf der Hardware abgebildet werden kann.
d3d12 erlaubt "Commandlist-Bundle" die die Informationen für die zu berechnende Szene ingesamt an die Hardware übermitteln (completely), um damit festzulegen welcher GPU Workload reserviert werden muss, inklusive der Textur- und Bufferressourcen. Jeder Container ist dabei "self contained" und ermöglicht es dem Treiber einen "free threaded" auszuführen. Einziger serieller Prozess bleibt dabei die Datenübermittlung an den Treiber. Hier wissen wir ja das Nvidia womöglich diesen unter d3d12 abfängt und ersetzt (rein spekualtiv - womit auch immer).
d3d12 erlaubt auch eine Addition von Commandlist-Bundle, die eine Weitergabe der Zustandsdaten (state inheritance) ermöglicht, z.B. immer dann wenn die Engine zwei Aufrufe anfordert. Aber selbst dann muss der Treiber nur einmal angesprochen werden, wobei dies eben einem "low coast call" entspricht, was den Overhead zu reduzieren hilft.
Diskriptor head and table
(das ich in Grundzügen beschrieben habe)
Ich glaube daher nicht so wirklich daran, dass es Blizzard gelungen ist dieses Modell auf grundlegende Feature die eine Beschleunigung eben dessen ermöglichen, umzustellen und genau deshalb bricht d3d12 auch ein. Ich verstand es so, dass FL 12.1 und 12.0 nur unter runtime d3d12 (und 11.3 - das ja gar nicht groß genutzt wird und nur übergangsweise bereitgestellt wurde) ausführbar sind. Das müsste das Spiel eigentlich deutlich beschleunigen, wenn man visuell, wie in dem Fall kaum etwas ändert.
Das kann dann auch kaum Skalierbarkeit sein, sondern man spricht womöglich nur optinale Feature an, die einem passen, was mit nativem DX12 aber nichts zu tun haben dürfte. Wer entwickelt denn eine neue Engine die up to date 2016 ist? Ich glaube man bei WoW nur umgesetzt hat was finanziell in den Rahmen passte, man bekommt halt nicht viel dafür.
Was Borderless und UWP angeht, wollte Microsoft auf Sweeny's Einsatz hin UWP auch auf eine Art "open source" für Entwickler öffnen, ob sie das bereits in irgend einer Art und Weise getan haben, weiß ich nicht. Ich glaube eher nicht, wenn man den Aussagen von Blizzard Forenmanagern und Borderlessmode traut.
