D3D12_FEATURE_DATA_ARCHITECTURE1構造体 (d3d12.h)

各アダプターのアーキテクチャの詳細に関する詳細を提供します。そのため、アプリケーションは特定のアダプター プロパティに対してより適切に最適化できます。

構文

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

SAL: Out

ハードウェアとドライバーが分離メモリ管理ユニット (MMU) をサポートするかどうかを指定します。 ランタイムは、GPU が MEM_WRITE_WATCH などの CPU ページ テーブルのプロパティを受け入れ、VirtualAllocを参照) と PAGE_READONLY (詳細については、「メモリ保護定数のを参照)、このメンバーを 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 が誤った認識できます。

一部のアプリケーションでは、統合/UMA アダプター、特にモバイル デバイスでのバッテリ寿命の延長に関心があるアダプターの最適化を強化したい場合があります。 単純な D3D12 アプリケーションは、常に UMA で必要ではない場合、属性が異なるヒープ間でデータをコピーすることを強制されます。 ただし、UMA プロパティ自体は、GPU 設計の合理的にあいまいな灰色の領域を包含します。 UMA は、GPU アクセス可能なすべてのメモリを CPU アクセス可能にすることを意味するとは限りません。 CacheCoherentUMA、その考え方に合ったプロパティがあります。

CacheCoherentUMA が誤った場合、1 つの常駐予算を利用できますが、UMA 設計は一般的に 3 つのヒープ属性の利点を得られます。 アップロードと読み取りバックのリソースとヒープを賢明に使用してリソースのコピーを削除し、メモリへの CPU アクセスを提供する機会が存在します。 しかし、このような機会は明確ではありません。 そのため、アプリケーションには注意が必要です。また、特定のデバイス ID を有効または除外することが保証される可能性があるため、さまざまな "UMA" システム間での実験をお勧めします。 GPU メモリ アーキテクチャと、ヒープの種類がキャッシュ プロパティにどのように変換されるかを理解することをお勧めします。 成功の可能性は、各プロセッサがデータの読み取りまたは書き込みを行う頻度、データ アクセスのサイズと局所性などに依存する可能性があります。高度な開発者の場合: UMA が true で、CacheCoherentUMA が false場合、これらのアダプターの最もユニークな特性は、アップロード ヒープがまだ書き込み結合されていることです。 ただし、一部の UMA アダプターは、既定のヒープとアップロード ヒープの CPU アクセスなしプロパティと書き込み結合プロパティの両方からメリットがあります。 詳細については、GetCustomHeapProperties の を参照してください。

CacheCoherentUMA が当てはまる場合、アプリケーションはヒープの属性を破棄し、アップロード ヒープと同等のカスタム ヒープをどこでも使用することをより強く楽しめることができます。 WriteToSubresource によって提供されるようなゼロ コピー UMA の最適化は、より多くのシナリオが単に共有使用の恩恵を受けるので、より一般的に推奨されます。 メモリ モデルは、より多くのシナリオとより広範な導入に非常に役立っています。 いくつかのコーナーケースは、利点が簡単に得られない場合がまだ存在するかもしれませんが、他のオプションよりもはるかにまれで有害ではないはずです。 上級開発者向け: CacheCoherentUMA は、メモリ階層内の大量のキャッシュも CPU と GPU の間で統合または統合されることを意味します。 最もユニークな観測可能な特性は、アップロード ヒープが実際に CacheCoherentUMA書き戻されるということです。 これらのアーキテクチャでは、アップロード ヒープでの書き込み結合の使用は一般的に有害です。

大多数の単一アダプター アプリケーションでは、低レベルの詳細を無視する必要があります。 通常どおり、単一アダプター アプリケーションではランドスケープを簡略化し、ヒープをアップロードするための CPU 書き込みで、書き込み結合に優しいパターンを使用できます。 下位レベルの詳細は、マルチアダプター アプリケーションの概念を強化するのに役立ちます。 多くの場合、マルチアダプター アプリケーションでは、アダプター間でデータを効率的に移動するための最適なカスタム ヒープ プロパティを選択するのに十分なアダプター アーキテクチャプロパティを理解する必要があります。

必要条件

要件	価値
ヘッダー	d3d12.h

関連項目

コア構造 の

D3D12_FEATURE