Was ist der Hauptunterschied des Pipeline-Prozesses zwischen Vulkan und DX12?

DX12 führt eine neue Funktion der Pipeline mit dem Namen "Bundle" ein. Es scheint, dass dies die Befehlsliste optimieren und an die endgültige Pipeline senden kann. Vulkan erfindet eine andere Pipeline: Die Grafik-Pipeline und die Compute-Pipeline. Die grafische Pipeline scheint genauso zu sein wie das Original. Die Compute-Pipeline wird als Zugriffsquelle für den Bildspeicher verwendet.

Mein CG-Wissen ist ziemlich grundlegend und kann nicht bestätigen, dass die Erkenntnis korrekt ist. Würde jemand freundlicherweise einige Erklärungen dafür liefern - Der Hauptunterschied der Pipelines zwischen ihnen?

Verweise:

• https://msdn.microsoft.com/zh-cn/library/mt617309
• https://www.khronos.org/registry/vulkan/specs/1.0/xhtml/vkspec.html#pipelines

D3D12 verfügt über 4 verschiedene Arten von Befehlslisten: Direkt, Bündeln, Berechnen und Kopieren.

Vulkan hat ähnliche Konzepte, aber sie passieren auf andere Weise. Befehlspuffer werden aus Befehlspools zugewiesen. Befehlspools sind direkt einer Warteschlangenfamilie zugeordnet. Aus einem Pool zugewiesene Befehlspuffer können nur an die Warteschlangenfamilie gesendet werden, für die der Pool erstellt wurde.

Warteschlangenfamilien geben die Arten von Vorgängen an, die die Warteschlange ausführen kann: Grafik-, Rechen- oder Speicherkopiervorgänge. Die Befehlswarteschlangen von D3D12 haben ein ähnliches Konzept, aber in der Befehlslisten-API von D3D12 müssen Sie den Listentyp angeben. Vulkan's erhält diese Informationen von der Warteschlangenfamilie, für die der Pool bestimmt ist.

Der D3D12-Befehlslistentyp "Bundle" scheint auf der Oberfläche den sekundären Vulkan-Befehlspuffern ähnlich zu sein. Sie sind jedoch ganz anders.

Der Hauptunterschied besteht darin, dass Bundles den gesamten Status von ihrer Liste der ausgeführten direkten Befehle erben , mit Ausnahme des gebundenen PSO selbst. Dies umfasst Ressourcendeskriptorbindungen.

Sekundäre Vulkan-Befehlspuffer erben keinen Status von ihrer Ausführungsumgebung für den primären Befehlspuffer, mit Ausnahme von sekundären CBs, die in einem Unterpass einer Renderpass-Instanz (und Abfragen) ausgeführt werden. Und diese erben nur den aktuellen Subpass-Status (und Abfragen).

Dies bedeutet, dass Sie im Vergleich zu D3D-Bundles andere Dinge mit ihnen tun.

Bundles werden manchmal verwendet, um Deskriptortabellen zu ändern und Inhalte zu rendern, unter der Annahme, dass die direkte Befehlsliste, in der sie ausgeführt werden, diese Tabellen eingerichtet hat. Bundles ähneln also leichten OpenGL-Anzeigelisten, nur ohne all die schlechten Dinge, die diese tun. Die Absicht bei Bundles ist also, dass Sie sie einmal erstellen und behalten. Sie sollen kleine Dinge sein.

Sekundäre Vulkan-CBs sind für die Thread-Erstellung von Befehlen für eine einzelne Render-Pass-Instanz unerlässlich. Dies liegt daran, dass eine Renderpassinstanz nur innerhalb einer primären CB erstellt werden kann. Für eine optimale Verwendung von Threads muss es daher eine Möglichkeit geben, Befehle zu erstellen, die in demselben Subpass in verschiedenen Threads ausgeführt werden sollen. Dies ist einer der Hauptanwendungsfälle von sekundären CBs. Die Absicht ist also, dass Sie wahrscheinlich in jedem Frame sekundäre CBs erstellen (obwohl Sie sie wiederverwenden können, wenn Sie möchten).

Letztendlich sollen Bundles und sekundäre CBs separate Probleme lösen. Bundles sind im Allgemeinen von der ausführenden Umgebung abhängig, während sekundäre CBs eigenständiger sind.

Gleichzeitig können sekundäre Vulkan-CBs etwas tun, was Bundles nicht können: Sie können in Warteschlangen nur für Computer ausgeführt werden. Da Vulkan zwischen der primären / sekundären Ebene des Befehlspuffers und den Warteschlangen unterscheidet, an die diese CB gesendet werden kann, ist es in Vulkan möglich, sekundäre Befehlspuffer zu haben, die in Warteschlangen nur für Berechnungen oder nur zum Kopieren ausgeführt werden.

Direct3D 12 kann das nicht mit Bundles machen. Die ExecuteBundleFunktion kann nur in einer direkten Befehlsliste aufgerufen werden. Eine Nur-Kopier-Befehlsliste kann also keine Bundles ausführen.

Zugegeben, da Vulkan außer dem Subpass-Status nichts zwischen sekundären CBs erbt und Rechen- / Kopiervorgänge keine Render-Durchgänge verwenden, kann nicht viel gewonnen werden, wenn solche Befehle eher in eine sekundäre als in eine primäre CB eingefügt werden .

D3D12 hat die gleiche Trennung zwischen Compute-Pipelines und Grafik-Pipelines wie Vulkan. Bei der Ausgabe von Befehlen verfügt D3D12 jedoch nur über einen Pipeline-Bindungspunkt, an den Sie jede Art von Pipeline binden können. Im Gegensatz dazu verfügt Vulkan über separate Bindungspunkte für Computer- und Grafik-Pipelines. Natürlich hat Vulkan keine unterschiedlichen Deskriptor-Bindungspunkte für sie, so dass sich die beiden Pipelines gegenseitig stören können. Wenn Sie jedoch die Ressourcennutzung sorgfältig planen, können Sie einen Versandvorgang aufrufen, ohne die Anforderungen der Grafikpipeline zu stören.

Insgesamt gibt es hier also keinen wirklichen Unterschied in der Pipeline-Architektur.

Der Hauptunterschied zu den Pipelines besteht darin, dass DirectX12 sich auf das Multithreading oder die effizienteste Verwendung mehrerer Kerne konzentriert, je nach Renderstatus eines Objekts.

Vulkan unterteilt die Verwaltung der Threads in verschiedene Arten von Pipelines, die berechnet und grafisch dargestellt werden.

Wie in der Referenz von MSDN angegeben, verwendet DirectX12 PSO (Pipeline State Object). Die Optimierung erfolgt auf diese Weise, indem die Befehle für die Pipeline zuvor vorbereitet werden. Anscheinend verwendet DirectX12 PSO, um ein Objekt mit dem Status des Renderns zu erstellen, um Statusänderungen an der Hardware effizienter zu verwalten.

Ich hoffe, das hilft!