注 この構造体は Windows 10 バージョン 1703 (Creators’ Update) で導入され、D3D12_FEATURE_DATA_ARCHITECTURE 構造体に取って代わるものです。アプリケーションが Windows 10 バージョン 1703 (Creators’ Update) 以上をターゲットとする場合は、D3D12_FEATURE_DATA_ARCHITECTURE1 (および D3D12_FEATURE_ARCHITECTURE1) を使用します。
構文
メンバー
NodeIndex型: UINT マルチ アダプター操作において、これはデバイスのどの物理アダプターが該当するかを示します。 Multi-adapter systems を参照してください。 アプリケーションは各アダプターのアーキテクチャに関する詳細を取得できるため、NodeIndex は CheckFeatureSupport を呼び出す前にアプリケーションによって設定されます。 TileBasedRenderer
型: BOOL ハードウェアとドライバーがタイルベース レンダラーをサポートしているかどうかを指定します。 ハードウェアとドライバーがタイルベース レンダラーをサポートしている場合、ランタイムはこのメンバーを TRUE に設定します。 UMA
型: BOOL ハードウェアとドライバーが UMA をサポートしているかどうかを指定します。 ハードウェアとドライバーが UMA をサポートしている場合、ランタイムはこのメンバーを TRUE に設定します。 CacheCoherentUMA
型: BOOL ハードウェアとドライバーがキャッシュ コヒーレント UMA をサポートしているかどうかを指定します。 ハードウェアとドライバーがキャッシュ コヒーレント UMA をサポートしている場合、ランタイムはこのメンバーを TRUE に設定します。 IsolatedMMU
型: BOOL SAL:
Out
ハードウェアとドライバーが分離型メモリ管理ユニット (MMU) をサポートしているかどうかを指定します。
GPU が MEM_WRITE_WATCH (VirtualAlloc の詳細を参照) や PAGE_READONLY (Memory Protection Constants の詳細を参照) などの CPU ページ テーブル プロパティを尊重する場合、ランタイムはこのメンバーを TRUE に設定します。
TRUE の場合、GPU がこれらのページ テーブル プロパティを予期しない方法でトリガーする可能性があるため、アプリケーションはこれらのページ テーブル プロパティを持つメモリを GPU で使用しないよう注意する必要があります。たとえば、GPU の書き込み操作、特にシェーダー内からの書き込みは、アプリケーションが予想するよりも粗い場合があります。特定の書き込み監視ページは、GPU の書き込みがどのように影響したかが明白でなくても、ダーティに見えることがあります。アップロードおよびリードバック ヒープの使用シナリオに関連する GPU 操作は書き込み監視ページで問題なく動作しますが、時折偽陽性が発生する可能性があり、これは安全に無視できます。
解説
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 はアプリケーションが基礎となるアダプター プロパティに合わせてより適切に最適化するのに役立ちます。 一部のアプリケーションは、ディスクリート アダプター向けにより適切に最適化し、システム メモリとビデオ メモリの両方の予算を管理するという追加の複雑さを引き受けたい場合があります。 アップロード ヒープのサイズが既定のテクスチャのサイズに匹敵する場合、メモリ使用率がほぼ 2 倍になる可能性があります。 そのような最適化をサポートする場合、アプリケーションは 2 つの常駐性予算を検出するか、UMA が false であることを認識できます。 一部のアプリケーション、特にモバイル デバイスでバッテリー寿命を延ばすことに関心があるものは、統合/UMA アダプター向けにより適切に最適化したい場合があります。 シンプルな D3D12 アプリケーションは、UMA では必ずしも必要ではない場合でも、異なる属性を持つヒープ間でデータをコピーすることを余儀なくされます。 しかし、UMA プロパティ自体は、GPU 設計のかなり曖昧なグレー ゾーンを含んでいます。 UMA が、すべての GPU アクセス可能メモリを自由に CPU アクセス可能にできることを意味すると仮定してはいけません。実際にはそうではありません。 そのような考え方により近いプロパティがあります: CacheCoherentUMA です。 CacheCoherentUMA が false の場合、常駐性予算は 1 つですが、UMA 設計では通常 3 つのヒープ属性から利益を得ます。 メモリへの CPU アクセスを提供するアップロードおよびリードバック リソースとヒープの賢い使用により、リソース コピーを排除する機会があります。 ただし、そのような機会は明確ではありません。 そのため、アプリケーションは注意する必要があります。さまざまな「UMA」システムでの実験が推奨されます。特定のデバイス ID を有効または除外することが必要になる場合があるためです。 GPU メモリ アーキテクチャとヒープの種類がキャッシュ プロパティにどのように変換されるかを理解することをお勧めします。 成功の実現可能性は、各プロセッサがデータをどれくらいの頻度で読み書きするか、データ アクセスのサイズと局所性などに依存する可能性があります。 上級開発者向け: UMA が true で CacheCoherentUMA が false の場合、これらのアダプターの最もユニークな特徴は、アップロード ヒープが依然としてライト コンバインである点です。 ただし、一部の UMA アダプターは、既定のヒープとアップロード ヒープの CPU アクセスなしとライト コンバインの両方のプロパティから利益を得ます。 詳細については、GetCustomHeapProperties を参照してください。 CacheCoherentUMA が true の場合、アプリケーションはヒープの属性を放棄し、アップロード ヒープと同等のカスタム ヒープをあらゆる場所で使用することをより強く検討できます。 WriteToSubresource が提供するようなゼロコピー UMA 最適化は、より多くのシナリオが単に共有使用から利益を得るため、より一般的に推奨されます。 メモリ モデルは、より多くのシナリオとより広範な採用に非常に適しています。 利益を容易に得られないコーナー ケースは依然として存在するかもしれませんが、他のオプションよりもはるかにまれで、悪影響も少ないはずです。 上級開発者向け: CacheCoherentUMA は、メモリ階層のキャッシュのかなりの部分が CPU と GPU の間でも統一または統合されていることを意味します。 最もユニークな観察可能な特徴は、CacheCoherentUMA ではアップロード ヒープが実際にはライトバックであることです。 これらのアーキテクチャでは、アップロード ヒープでのライト コンバインの使用は通常、デメリットとなります。 低レベルの詳細は、シングル アダプター アプリケーションの大多数では無視して構いません。 通常どおり、シングル アダプター アプリケーションは状況をシンプルにし、アップロード ヒープへの CPU 書き込みがライト コンバイン フレンドリなパターンを使用することを保証できます。 低レベルの詳細は、マルチ アダプター アプリケーションの概念を強化するのに役立ちます。 マルチ アダプター アプリケーションは、アダプター間でデータを効率的に移動するために最適なカスタム ヒープ プロパティを選択できるように、アダプター アーキテクチャのプロパティを十分に理解する必要があるでしょう。要件
ヘッダー: d3d12_xs.h または d3d12_x.hライブラリ: d3d12_xs.lib または d3d12_x.lib
サポートされているプラットフォーム: XBOX Series 本体および XBOX One ファミリ