次の方法で共有

ルート署名の制限

  • [アーティクル]

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

メモリの制限とコスト

ルート署名の最大サイズは 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 でのルート署名の指定」を参照してください)。

ルート署名