次の方法で共有

ルート署名の制限

  • [アーティクル]

ルート署名は主要な不動産であり、考慮すべき厳しい制限とコストがあります。

メモリの制限とコスト

ルート署名の最大サイズは 64 DWORD です。

この最大サイズは、一括データを格納する方法としてルート署名の不正使用を防ぐために選択されます。 ルート署名の各エントリには、この 64 DWORD 制限に対するコストがあります。

  • 記述子テーブルのコストはそれぞれ 1 DWORD です。
  • ルート定数は 32 ビット値であるため、それぞれ 1 DWORD のコストがかかります。
  • ルート記述子 (64 ビット GPU 仮想アドレス) のコストはそれぞれ 2 DWORD です。

静的サンプラーには、ルート署名のサイズにコストはありません。

パフォーマンス コスト

パフォーマンス コスト (間接参照のレベル) は、ルート定数の場合は 0、ルート記述子の場合は 1、記述子テーブルの場合は 2 です。 ルート署名が大きく、最速のメモリから少し遅いメモリにオーバーフローした場合 (一部のハードウェアで発生する可能性があります)、ルート署名の最後にオーバーフローする項目のパフォーマンス コストに 1 を追加します。

オーバーフローは、ルート引数スペースに対して 16 DWORD の固定サイズなど、ハードウェア上で発生する可能性があります。 入力アセンブラーを使用すると、この制限がさらに 1 つ減る可能性があります。 この場合、ルート署名が 15 または 16 DWORD ネイティブ メモリに対して大きすぎると、メモリが少し遅くなります。 他のハードウェアでは、固定のネイティブ ルート引数メモリがありません (そのため、オーバーフローの状況は発生しません)。

すべてのハードウェアで、ルート引数が変更された場合、ドライバーは、すべてのルート引数のバージョンを維持する必要があります (ドライバーによってバージョン管理されていない記述子ヒープやバッファー リソースなどの他のストレージとは異なります)。 オーバーフロー状態が発生するハードウェアでは、変更が発生した場所に応じて、ネイティブ領域またはオーバーフロー領域のみをバージョン管理する必要があります。 バージョン管理の量は、明らかに必要最小限に抑える必要があります。

一般に、次のガイドラインを考慮してください。

  • 必要に応じて小さなルート署名を使用しますが、大きなルート署名の柔軟性とバランスを取る必要があります。
  • パラメーターが頻繁に変更される可能性が最も高いように、または特定のパラメーターのアクセス待ち時間が短いことが重要な場合は、最初に、大きなルート署名にパラメーターを配置します。
  • 便利な場合は、定数バッファー ビューを記述子ヒープに配置するよりも、ルート定数またはルート定数バッファー ビューを使用します。

静的サンプラー

静的サンプラー (状態が完全に定義され、変更できないサンプラー) はルート署名の一部ですが、64 DWORD の制限にはカウントされません。 サンプラーを静的として定義できる場合、サンプラーを記述子ヒープの一部にする必要はありません。

静的サンプラーの使用にパフォーマンス コストはかからず、ルート署名には静的サンプラー (ルート署名に格納されるか、一部のハードウェア上の予約領域に格納されます) と動的サンプラー (サンプラー記述子ヒープに格納) を混在させることができます。 記述子ヒープ内のサンプラーは動的に割り当て、インデックスを作成できます。静的サンプラーでは割り当てられません。

静的サンプラーは、HLSL シェーダーのルート署名の一部として記述できます (HLSL でのルート署名の指定参照)。

ルート署名 の