共用方式為


Direct3D 12 Interop

D3D12 可用來寫入元件化應用程式。

Interop 概觀

D3D12 非常強大,並允許應用程式以類似主控台的效率撰寫圖形程式碼,但並非所有應用程式都需要重新建立滾輪,並從頭開始撰寫其轉譯引擎的完整內容。 在某些情況下,另一個元件或程式庫已經更好,或者在其他情況下,部分程式碼的效能與其正確性和可讀性並不一樣重要。

本節涵蓋下列 Interop 技術:

  • 相同裝置上的 D3D12 和 D3D12
  • 不同裝置上的 D3D12 和 D3D12
  • D3D12 和相同裝置上 D3D11、D3D10 或 D2D 的任何組合
  • 不同裝置上的 D3D12 和 D3D11、D3D10 或 D2D 的任何組合
  • D3D12 和 GDI、D3D12 和 D3D11 和 GDI

使用 Interop 的原因

應用程式想要與其他 API 搭配使用 D3D12 Interop 的原因有數個。 以下是一些範例:

  • 累加移植:想要將整個應用程式從 D3D10 或 D3D11 移植到 D3D12,同時在移植程式 (的中繼階段運作,以啟用測試和偵錯) 。
  • 黑箱程式碼:想要讓應用程式的特定部分保持原樣,同時移植程式碼的其餘部分。 例如,可能不需要移植遊戲的 UI 元素。
  • 不可變更的元件:需要使用應用程式未擁有的元件,這些元件不會寫入目標 D3D12。
  • 新的元件:不想要移植整個應用程式,但想要使用使用 D3D12 撰寫的新元件。

D3D12 中 Interop 有四個主要技術:

  • 應用程式可以選擇提供開啟的命令清單給元件,它會將一些額外的轉譯命令記錄到已系結的轉譯目標。 這相當於將備妥的裝置內容提供給 D3D11 中的另一個元件,而且非常適合將 UI/文字新增至已系結的後端緩衝區等專案。
  • 應用程式可以選擇提供命令佇列給元件,以及所需的目的地資源。 這相當於在 D3D11 中使用 ClearStateDeviceCoNtextState API,以提供全新裝置內容給另一個元件。 這是 D2D 等元件的運作方式。
  • 元件可以選擇產生命令清單的模型,可能平行執行,應用程式稍後負責提交。 至少必須跨元件界限提供一個資源。 雖然 D3D12 中的效能更理想,但 D3D11 中的效能較理想,但 D3D11 中的這項相同技術可在 D3D11 中使用。
  • 每個元件都有自己的佇列 () 和/或裝置 (s) ,而應用程式和元件需要跨元件界限共用資源和同步處理資訊。 這類似于舊版 ISurfaceQueue ,以及較新式 的 IDXGIKeyedMutex

這些案例之間的差異在於元件界限之間確切共用的內容。 裝置會假設為共用,但因為基本上是無狀態的,所以並不重要。 索引鍵物件是命令清單、命令佇列、同步物件和資源。 在共用它們時,每一個都有自己的複雜功能。

共用命令清單

Interop 最簡單的方法只需要與引擎的一部分共用命令清單。 轉譯作業完成後,命令清單擁有權會回到呼叫端。 命令清單的擁有權可以透過堆疊進行追蹤。 由於命令清單是單一線程的,因此應用程式無法使用此技術執行唯一或創新的動作。

共用命令佇列

在相同程式中共用裝置的多個元件,可能是最常見的技術。

當命令佇列是共用的單位時,必須呼叫元件,讓它知道所有未完成的命令清單都必須立即提交至命令佇列 (,而且任何內部命令佇列都必須同步處理) 。 這相當於 D3D11 Flush API,而且是應用程式可以提交自己的命令清單或同步處理基本類型的唯一方式。

共用同步處理基本類型

在自己的裝置和/或命令佇列上運作的元件預期模式是接受 ID3D12Fence 或共用控制碼,並在開始工作時接受 UINT64 配對,它會等候,然後第二個 ID3D12Fence 或共用控制碼,以及 UINT64 配對,當所有工作完成時都會發出訊號。 此模式符合 IDXGIKeyedMutex 和 DWM/DXGI 翻轉模型同步處理設計目前的實作。

資源分享

到目前為止,撰寫利用多個元件的 D3D12 應用程式最複雜部分,就是如何處理跨元件界限共用的資源。 這主要是因為資源狀態的概念。 雖然資源狀態設計的某些層面是為了處理命令內清單同步處理,但其他層面在命令清單之間會受到影響,影響資源配置,以及存取資源資料的有效作業集或效能特性。

有兩種處理這種複雜功能的模式,這兩種模式基本上都牽涉到元件之間的合約。

  • 合約可由元件開發人員定義並記載。 這可能很簡單,就像「資源必須在工作啟動時處於預設狀態,而且會在工作完成時回到預設狀態」,或可能有更複雜的規則,允許共用深度緩衝區等專案,而不需要強制中繼深度解析。
  • 當資源跨元件界限共用時,應用程式可以在執行時間定義合約。 它包含相同的兩個資訊片段–資源在元件開始使用時會進入的狀態,而元件在完成時應該將它保留在的狀態。

選擇 Interop 模型

對於大部分的 D3D12 應用程式,共用命令佇列可能是理想的模型。 它允許建立和提交工作的完整擁有權,而不需要額外的記憶體額外負荷來擁有備援佇列,而且不會對處理 GPU 同步處理基本類型的影響。

一旦元件需要處理不同的佇列屬性,例如類型或優先順序,或共用需要跨越進程界限之後,就需要共用同步處理基本類型。

共用或產生命令清單並非由協力廠商元件廣泛使用,但可能廣泛使用於遊戲引擎內部的元件中。

Interop API

12 上的 Direct3D 11主題會逐步引導您使用與本主題中所述的互通性相關的許多 API 介面。

另請參閱 ID3D12Device::CreateSharedHandle 方法,您可以在 Windows 圖形 API 之間共用介面。