次の方法で共有

記述子テーブルの高度な使用

次のセクションでは、記述子テーブルの高度な使用に関する情報を提供します。

レンダリング呼び出し間の記述子テーブル エントリの変更

記述子テーブルを設定するコマンド リストが実行のためにキューに送信された後、アプリケーションは、GPU が参照を使用し終わったことをアプリケーションが認識するまで、GPU が参照する可能性がある記述子ヒープの部分を CPU から編集してはなりません。

作業の完了は、GPU の進行状況を追跡するための API フェンス、またはレンダリングが表示に送信されたことを確認するのを待つなどのより粗いメカニズムを使用して、厳密なバインドで決定できます。アプリケーションに適したものは何でもかまいません。 記述子テーブルが指す領域のサブセットのみがアクセスされることをアプリケーションが認識している場合 (シェーダーでのフロー制御など)、他の参照されていない記述子は変更しても解放されます。 アプリケーションがレンダリング呼び出し間で異なる記述子テーブルを切り替える必要がある場合、アプリケーションで選択できる方法がいくつかあります。

  • 記述子テーブルのバージョン管理: コマンド リストによって参照される記述子の一意のコレクションごとに個別の記述子テーブルを作成 (または再利用) します。 以前に設定した領域を記述子ヒープで編集および再利用する場合、アプリケーションはまず、GPU がリサイクルされる記述子ヒープの任意の部分を使用して終了したことを確認する必要があります。
  • 動的インデックス作成: アプリケーションは、描画/ディスパッチによって異なる (または描画内で変化する) オブジェクトを記述子ヒープの範囲に配置し、それらすべてをまたぐ記述子テーブルを定義し、シェーダーからシェーダーの実行中にテーブルの動的インデックス作成を使用して、使用するオブジェクトを選択できます。
  • ルート署名に記述子を直接配置する。 ルート署名スペースが限られているため、このように管理できるのはごく少数の記述子だけです。

記述子テーブルのバージョン管理を使用する場合、記述子ヒープから出た記述子メモリは、グラフィックス パイプラインによって参照されるすべての一意の記述子セットに対して、実行、実行キュー、または任意の時点で記録される可能性があるすべてのコマンド リストに対して書き込まれる必要があります。

D3D12 では、記述子ヒープと記述子テーブルを使用して管理されるオブジェクト型のバージョン管理をアプリケーションに対して行う必要があります。 この利点の 1 つは、アプリケーションが、コマンド リストの送信ごとに常に新しい記述子テーブル のバージョンを定義するのではなく、できるだけ記述子テーブルの内容を再利用できることです。 ルート署名は、D3D12 ドライバーが自動的にバージョン管理する領域です。

複数の記述子テーブルを一度にルート署名 (つまりパイプライン) にバインドする機能により、アプリケーションは必要に応じて、さまざまな頻度で記述子参照のセットをグループ化および切り替えることができます。 たとえば、アプリケーションでは、ほとんど変更されない大きな静的記述子テーブルの少数 (おそらく 1 つだけ) を使用できます。また、シェーダーから動的インデックスを使用してテクスチャを選択することで、基になる記述子ヒープ メモリ内の領域が必要に応じて設定されます。 同時に、アプリケーションは、記述子テーブルのバージョン管理手法を使用して、各描画呼び出しによって参照されるセットが CPU から切り替えられるリソースの別のクラスを維持できます。

範囲外のインデックス作成

シェーダーから記述子テーブルの境界外インデックスを作成すると、ハードウェア状態記述子であるかのように任意のインプロセス メモリを読み取り、ハードウェアが何を行うかの結果と共に生きる可能性を含め、ほとんど未定義のメモリ アクセスが発生します。 これによりデバイスのリセットが発生する可能性がありますが、Windows はクラッシュしません。

シェーダー派生関数と分岐インデックス作成

(派生計算をサポートするために) 2x2 スタンプで実行されているピクセル シェーダー呼び出しが、記述子テーブルの外からサンプリングするさまざまなテクスチャ インデックスを選択し、特定のピクセルに対して選択されたサンプラー構成とテクスチャがテクスチャ座標派生からの LOD 計算を必要とする場合、LOD 計算とテクスチャ サンプリング プロセスは、2x2 スタンプの各テクスチャ ルックアップに対してハードウェアによって個別に実行されます。 パフォーマンスに影響を与えます。

記述子テーブル の