D3D12_FEATURE_DATA_ARCHITECTURE1 結構 (d3d12.h)

提供每個配接器架構詳細數據的詳細數據,讓您的應用程式更能針對特定配接器屬性進行優化。

注意這個結構是在 Windows 10 1703 版中引進, (Creators 的 Update) 取代D3D12_FEATURE_DATA_ARCHITECTURE結構。 如果您的應用程式以 Windows 10 版本 1703 (Creators 的 Update) 或更高版本為目標,請使用 D3D12_FEATURE_DATA_ARCHITECTURE1 (和 D3D12_FEATURE_ARCHITECTURE1)
 

語法

typedef struct D3D12_FEATURE_DATA_ARCHITECTURE1 {
  UINT NodeIndex;
  BOOL TileBasedRenderer;
  BOOL UMA;
  BOOL CacheCoherentUMA;
  BOOL IsolatedMMU;
} D3D12_FEATURE_DATA_ARCHITECTURE1;

成員

NodeIndex

在多配接器作業中,這表示裝置的實體適配卡相關。 請參閱 多配接器系統NodeIndex 會在呼叫 CheckFeatureSupport 之前由應用程式填寫,因為應用程式可以擷取每個適配卡架構的詳細數據。

TileBasedRenderer

指定硬體和驅動程式是否支援以磚為基礎的轉譯器。 如果硬體和驅動程式支援以磚為基礎的轉譯器,運行時間會將此成員設定為 TRUE

UMA

指定硬體和驅動程式是否支援UMA。 如果硬體和驅動程式支援UMA,運行時間會將此成員設定為 TRUE

CacheCoherentUMA

指定硬體和驅動程式是否支援快取一致的 UMA。 如果硬體和驅動程式支援快取一致的 UMA,運行時間會將此成員設定為 TRUE

IsolatedMMU

SALOut

指定硬體和驅動程式是否支援隔離的記憶體管理單位 (MMU) 。 如果 GPU 接受 CPU 頁面數據表屬性,例如 MEM_WRITE_WATCH (,則運行時間會將此成員設定為 TRUE,如需詳細資訊,請參閱 VirtualAlloc) 和 PAGE_READONLY (,如需詳細資訊,請參閱記憶體保護常數) 。

如果 為 TRUE,應用程式必須小心不要使用這些分頁表屬性的記憶體搭配 GPU,因為 GPU 可能會以非預期的方式觸發這些分頁表屬性。 例如,GPU 寫入作業可能會比應用程式預期的還要粗細,特別是從著色器內寫入。 某些寫入 watch 頁面可能會顯示為已變更,即使 GPU 寫入對它們的影響並不明顯。 與上傳和回寫堆積使用案例相關聯的 GPU 作業適用於寫入 watch 頁面,但偶爾可能會產生可以安全地忽略的誤判。

備註

如何使用 UMA 和 CacheCoherentUMA

D3D12 應用程式應該擔心管理記憶體落地,並提供最佳的堆積屬性。 D3D12 應用程式可以透過管理 D3D12_HEAP_TYPE_DEFAULT堆積中的資源落地,在許多 GPU 架構中保持簡化並正常執行。 這些應用程式只需要針對 DXGI_MEMORY_SEGMENT_GROUP_LOCAL 呼叫 IDXGIAdapter3::QueryVideoMemoryInfo ,而且必須能夠容忍該D3D12_HEAP_TYPE_UPLOAD和D3D12_HEAP_TYPE_READBACK來自該相同的記憶體區段群組。

不過,這類簡單的設計對於推送限制的應用程式而言太過受限。 因此,D3D12_FEATURE_DATA_ARCHITECTURE可協助應用程式更妥善地優化基礎配接器屬性。

某些應用程式可能想要更妥善地針對離散適配卡進行優化,並採用管理系統記憶體和視訊記憶體預算的額外複雜度。 如果上傳堆積的大小與預設紋理的大小不同,記憶體使用率幾乎會加倍。 支援這類優化時,應用程式可以偵測兩個落地預算或辨識 UMA為 false

有些應用程式可能想要更妥善地針對整合式/UMA 適配卡進行優化,特別是想要在行動裝置上延長電池使用時間的應用程式。 當UMA上不一定需要時,簡單的 D3D12 應用程式會強制在具有不同屬性的堆積之間複製數據。 不過,UMA 屬性本身包含相當模糊的 GPU 設計灰色區域。 請勿假設 UMA 表示所有 GPU 可存取的記憶體都可以自由存取 CPU,因為它無法存取。 有一個屬性更接近該類型的思考: CacheCoherentUMA

CacheCoherentUMA為 false 時,可以使用單一落地預算,但 UMA 設計通常受益於三個堆積屬性。 透過上傳和回寫資源和堆積的使用方式移除資源複製的機會,可提供記憶體的CPU存取權。 不過,這類機會並不明確。 因此,應用程式應該小心;建議在各種「UMA」 系統中進行和實驗,因為可能需要啟用或排除特定裝置識別碼。 瞭解 GPU 記憶體架構,以及堆積類型如何轉譯為快取屬性。 成功的可能性可能取決於每個處理器讀取或寫入數據的頻率、數據存取的大小和位置等等。對於進階開發人員:當 UMA 為 true 且 CacheCoherentUMAfalse 時,這些適配卡的最獨特特性是上傳堆積仍會合併寫入。 不過,某些 UMA 配接器受益於預設和上傳堆積的無 CPU 存取和寫入合併屬性。 如需詳細資訊,請參閱 GetCustomHeapProperties

CacheCoherentUMA 為 true 時,應用程式可以更強烈地放棄堆積的屬性,並使用相當於上傳堆積的自定義堆積。 寫入 ToSubresource 所提供的零複製 UMA 優化通常受到鼓勵,因為更多案例只會受益於共用使用量。 記憶體模型非常適合更多案例和更廣泛的採用。 某些邊角案例可能仍然存在,其中無法輕易取得優點,但比其他選項更罕見且較不有害的情況。 針對進階開發人員: CacheCoherentUMA 表示記憶體階層中的大量快取也會在 CPU 與 GPU 之間整合或整合。 最獨特的可觀察特性是上傳堆積實際上是在 CacheCoherentUMA 上回寫。 針對這些架構,上傳堆積上的寫入合併用法通常是一項損害。

大部分的單一配接器應用程式都應該忽略低階詳細數據。 一如往常,單一配接器應用程式可以簡化環境,並確保 CPU 寫入以上傳堆積時,會使用可寫入合併的模式。 較低層級的詳細數據有助於強化多配接器應用程式的概念。 多配接器應用程式可能需要充分瞭解配接器架構屬性,以選擇最佳的自定義堆積屬性,以有效率地在配接器之間移動數據。

規格需求

需求
標頭 d3d12.h

另請參閱

核心結構

D3D12_FEATURE