spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Mir scheint du hast da ein bissl was falsch verstanden. Resource Bindings sind nicht wirklich Teil des Pipeline State Object. Insbesondere Vertex- und Index Buffer Bindings. Die sind Teil der Command List...

Ich seh kein wirkliches Problem. Es war ja auch bisher eigentlich so, dass Shader, Rasterizer State, Blend State etc. logisch zusammengehört haben. Du erzeugst nun halt am Anfang für jede dieser Kombinationen ein Pipeline State Objekt...

Man kann das sicher auch irgendwie hashen und ablegen, aber erstmal stimme ich dot zu: es war doch jetzt schon so, dass man in jeder halbwegs komplexen Engine DrawCalls mit allen notwendigen Parametern sammelt und sortiert. Dann hast Du doch pro DrawCall eh einen Gesamt-Blob. Entweder man lässt sich jetzt was wirklich Cleveres einfallen, um wiederkehrende DrawCalls dynamisch zu erkennen und die Blobs vom letzten Frame wieder zuzuordnen. Oder man lagert das Problem an die nächsthöhere Schicht aus und reicht nur ein Interface raus, mit dem sich die Nutzer des Renderers abstrahierte Blobs anlegen können. Der Blob könnte dann z.B. "dieses Modell mit diesem Material" sein, und die Engine kann dann in diesem Blob ablegen, welches Pipeline Object sie für den ShadowMap Pass angelegt hat usw.

Ich theoretisiere hier aber nur rum, weil mir leider bisher die Zeit gefehlt hat, tatsächlich mal was damit zu machen.

Tatsächlich stellt PSO-Management eins der häufigsten Probleme dar. Wenn deine Engine (wie viele Engines) ein DX11 (oder sogar DX9) orientiertes Design hat, ist das weitgehend inkompatibel mit vielen DX12 Konzepten. Der einzige Vorteil den du dann hast, ist, das du mal siehst was du dem Treiber bisher zugemutet hast! ()

Also: Idealerweise würdest du dein Usercode/Highlevel-Render-Code/etc (wie bereits von dot und Schrompf angesprochen) so designen das du im Voraus weißt was für Pipelines du brauchst. D.h. du könntest PSOs wie Assets behandeln und einfach mit allen anderen Assets laden. Dafür brauchst du Kontrolle über deine Pipeline, also keine fein granulares "SetXYZ"-Stateinterface mehr. Mit einem "Stateless-Rendering"-Design (einfach mal googlen) bekommst du das quasi "umsonst". Das hat viele nette Nebeneffekte, dein Rendercode wird deutlich sauberer, dein Spiel bekommt keine "zufälligen" Framespikes usw...

Falls ein Refactoring für dein Highlevel-Code nicht möglich ist dann gibt es natürlich andere Optionen. Viele Engines haben eine art Statemanager in dem Pipeline-States getracked werden. Wenn du einen Draw/Dispatch absetzt wird ein neues PSO erzeugt (oder ein altes, äquivalentes PSO aus einem Dictionary geladen). Der Ansatz funktioniert selbst mit "DX9-Style" Interfaces aber kann extreme Framedrops zur Folge haben. Das Problem ist nämlich, dass die Zeit zum Compilen von PSOs gern mal im Millisekundenbreich liegen kann. Um das zu vermeiden kannst du eine Liste von den am häufigst genutzten PSOs führen und beim Programmstart erstellen. Wie du an die Informationen kommst bleibt dir überlassen, das kann so simpel sein wie, einfach das Spiel zu spielen und sich alle erzeugten PSO-Beschreibungen zu dumpen, fertig! (Doom macht das z.B. so mit deren Vulkan Implementierung).

Damit wirst du aber sicherlich keine optimale Performanz erreichen können. Dafür ist es absolut notwendig dein Design auf einer hohen Ebene zu ändern:

"DX12-Backends profitieren von Applikationswissen und sollten so flach wie möglich sein. Einen DX11-Treiber zu emulieren wird zwangsläufig in schlechter(er) Performanz enden"

Zitat von »LukasBanana«

Ein wesentlicher Unterschied scheint mir im Moment vor allem das Erstellen eines Pipeline-State Objekts zu sein.

Auch andere Konzepte unterscheiden sich deutlich von DX11/GL. PSOs sind nur eines von vielen Puzzleteilen (aka Stolpersteinen??) die notwendig sind um ein wirklich performantes DX12-Backend zu bekommen.