記述子テーブルの高度な用法
以下のセクションでは、記述子テーブルの高度な用法について説明します。
レンダリング呼び出し間での記述子テーブル エントリの変更
記述子テーブルを設定するコマンド リストが実行用のためにキューに送信された場合、アプリケーションは、GPU が参照の使用を終了したことが判明するまで、GPU が参照している可能性がある記述子ヒープを CPU から編集しないようにする必要があります。
作業の完了は、API フェンスを使用して GPU の進捗の追跡をしたり、もっと簡単なメカニズム (レンダリングが表示のために送信されるまで待機するなど) を使用したりするなど、アプリケーションに適した方法で厳密に判別できます。 記述子テーブルがポイントする領域の一部だけがアクセスされる (たとえばシェーダーでのフロー制御のため) ことをアプリケーションが認識していれば、他の参照されていない記述子は自由に変更できます。 アプリケーションがレンダリング呼び出し間で記述子テーブルを切り替える必要がある場合、アプリケーションには次のいくつかの選択肢があります。
- 記述子テーブルのバージョン管理: コマンド リストによって参照される記述子の一意のコレクションごとに個別の記述子テーブルを作成 (または再利用) します。 記述子ヒープ上の以前にデータが格納されていた領域を編集して再利用する場合、アプリケーションでは、まず記述子ヒープの再利用される部分を GPU が既に使用していないことを確認する必要があります。
- 動的インデックス作成: アプリケーションは、記述子ヒープの範囲で描画/ディスパッチ (または描画内で変化する) 間で変化するオブジェクトを配置し、それらすべてをまたがる記述子テーブルを定義し、シェーダーからシェーダーの実行中にテーブルの動的インデックス作成を使用して、使用するオブジェクトを選択できます。
- 記述子をルート署名に直接配置。 ルート署名の領域は限られているため、この方法ではごく少数の記述子しか管理できません。
記述子テーブルのバージョン管理を利用する場合は、ある時点で実行中、キューで実行待ち、記録中のいずれかの状態にあるすべてのコマンド リストに対して、グラフィックス パイプラインで参照される固有の記述子セットごとに、記述子ヒープからの記述子メモリを消費する必要があります。
D3D12 では、記述子ヒープと記述子テーブルによって管理されるオブジェクト タイプに対して、アプリケーションでバージョン管理を行う必要があります。 この場合の利点の 1 つは、コマンド リストを送信するたびに新しい記述子テーブルのバージョンを定義するのではなく、記述子テーブルの内容をできるだけ再利用することをアプリケーションで選択できる点です。 ルート署名は、D3D12 ドライバーによって自動的にバージョン管理される領域です。
一度に複数の記述子テーブルをルート署名に (したがってパイプラインにも) バインドできるため、アプリケーションは一連の記述子参照を必要に応じてさまざまな頻度でグループ化し、切り替えることができます。 たとえば、ほとんど変更されない大きな静的記述子テーブル、または基になる記述子ヒープ メモリ内の領域に随時入力が行われる大きな静的記述子テーブルをアプリケーションで少数 (場合によっては 1 つ) 使用し、これにシェーダーからの動的インデックス作成を併用して、テクスチャを選択することができます。 同時に、アプリケーションで別のクラスのリソースを管理し、CPU から記述子テーブルをバージョン管理する手法を使用して各描画呼び出しで参照されるセットを切り替えることができます。
範囲外のインデックス作成
シェーダーから記述子テーブルの範囲外インデックス作成を行うと、メモリ アクセスのほとんどが未定義になります。この場合、ハードウェア状態記述子であるかのように任意の処理中メモリを読み取り、ハードウェアがそれを使用して行う処理の結果と一致する可能性があります。 これによってデバイスがリセットされる可能性がありますが、Windows がクラッシュすることはありません。
シェーダー導関数と多様なインデックス作成
(導関数計算をサポートするため) 2x2 スタンプで実行されているピクセル シェーダーの呼び出しでさまざまなテクスチャ インデックスを選択して記述子テーブルからサンプリングを行う場合、かつ特定のピクセルについて選択されたサンプラーの構成とテクスチャにテクスチャ座標導関数からの LOD 計算が必要である場合は、2x2 スタンプでテクスチャ ルックアップが行われるたびに LOD 計算とテクスチャ サンプリングの処理がハードウェアで独自に実行されるため、パフォーマンスに影響が生じます。
関連トピック