HLSL でのリソース バインドResource Binding in HLSL

このセクションでは、Direct3D 12 と共に上位レベル シェーディング言語 (HLSL) の Shader Model 5.1 を使用するいくつかの具体的な機能について説明します。This section describes some specific features of using High Level Shading Language (HLSL) Shader Model 5.1 with Direct3D 12. すべての Direct3D 12 ハードウェアは Shader Model 5.1 をサポートしているため、このモデルのサポートはハードウェアの機能レベルに依存しません。All Direct3D 12 hardware supports Shader Model 5.1, so support for this model does not depend on what the hardware feature level is.

リソースの種類と配列Resource types and arrays

Shader Model 5 (SM5.0) のリソース構文では、リソースに関する重要な情報を HLSL コンパイラに中継するために "register" キーワードを使用します。Shader Model 5 (SM5.0) resource syntax uses the "register" keyword to relay important information about the resource to the HLSL compiler. たとえば、次のステートメントでは、スロット t3、t4、t5、t6 でバインドされた 4 つのテクスチャの配列を宣言しています。For example, the following statement declares an array of four textures bound at slots t3, t4, t5, and t6. t3 はこのステートメントの中で示される唯一のレジスタ スロットで、4 つから成る配列の最初の要素になります。t3 is the only register slot appearing in the statement, simply being the first in the array of four.

Texture2D<float4> tex1[4] : register(t3)

HLSL の Shader Model 5.1 (SM5.1) のリソース構文は、移植を容易にするために既存のレジスタ リソース構文に基づいています。Shader Model 5.1 (SM5.1) resource syntax in HLSL is based on existing register resource syntax, to allow easier porting. HLSL の D3D12 リソースは、論理レジスタ空間内の仮想レジスタにバインドされます。D3D12 resources in HLSL are bound to virtual registers within logical register spaces:

  • t - シェーダー リソース ビュー (SRV) 用t – for shader resource views (SRV)
  • s - サンプラー用s – for samplers
  • u - 順序指定されていないアクセス ビュー (UAV) 用u – for unordered access views (UAV)
  • b - 定数バッファー ビュー (CBV) 用b – for constant buffer views (CBV)

シェーダーを参照するルート署名は、宣言されたレジスタ スロットと互換性がある必要があります。The root signature referencing the shader must be compatible with the declared register slots. たとえば、ルート署名の次の部分は、スロット t0 から t98 を含む記述子テーブルを記述しているため、テクスチャ スロット t3 から t6 の使用と互換性があります。For example, the following portion of a root signature would be compatible with the use of texture slots t3 through t6, as it describes a descriptor table with slots t0 through t98.

DescriptorTable( CBV(b1), SRV(t0,numDescriptors=99), CBV(b2) )

リソース宣言は、次のように、スカラー、1D 配列、または多次元配列になる場合があります。A resource declaration may be a scalar, a 1D array, or a multidimensional array:

Texture2D<float4> tex1     : register(t3,  space0)
Texture2D<float4> tex2[4]     : register(t10)
Texture2D<float4> tex3[7][5][3]   : register(t20, space1)

SM5.1 では、SM5.0 と同じリソースの種類と要素の種類を使用します。SM5.1 uses the same resource types and element types as SM5.0. 宣言の制限はより柔軟になり、ランタイムまたはハードウェアの制限のみで制約されます。Declaration limits are more flexible now and constrained only by the runtime/hardware limits. "space" キーワードは、宣言された変数がどの論理レジスタ空間にバインドされるかを指定します。The "space" keyword specifies to which logical register space the declared variable is bound to. "space" キーワードを省略した場合は、既定の空間インデックス 0 が暗黙的にその範囲に割り当てられます (したがって、上記の tex2 範囲は space0 にあります)。If the "space" keyword is omitted, the default space index of 0 is implicitly assigned to the range (so the tex2 range above resides in space0). register(t3, space0) は、register(t3, space1) とも、t3 を含む可能性がある別の空間にあるどの配列とも競合することはありません。register(t3, space0) will never conflict with register(t3, space1) or any array in another space that might include t3.

配列リソースのサイズを無制限にすることもできます。これを宣言するには、最初の次元を空または 0 に指定します。An array resource may have an unbounded size, which is declared by specifying the very first dimension to be empty or 0:

Texture2D<float4> tex1[]       : register(t0)

一致する記述子テーブルは次のようになります。The matching descriptor table could be:

DescriptorTable( CBV(b1), UAV(u0, numDescriptors = 4), SRV(t0, numDescriptors=unbounded)

HLSL の無制限の配列は記述子テーブルの numDescriptors で設定された固定数と一致し、HLSL の固定サイズは記述子テーブルの unbounded 宣言と一致します。An unbounded array in HLSL does match a fixed number set with numDescriptors in the descriptor table, and a fixed size in the HLSL does match an unbounded declaration in the descriptor table.

多次元配列は許可されます。これには、サイズが無制限のものも含まれます。Multi-dimensional arrays are allowed, including of an unbounded size. このような多次元配列は、レジスタ空間内で平坦化されます。These multidimensional arrays are flattened out in register space.

Texture2D<float4> tex3[3000][10] : register(t0,space1); // t0-t29999 in space1
Texture2D<float4> tex3[0][5][3]   : register(t5, space1)

リソース範囲のエイリアシングは許可されていません。Aliasing of resource ranges is not allowed. つまり、リソースの種類 (t、s、u、b) ごとに、宣言したレジスタ範囲が重複しないようにしてください。In other words, for each resource type (t, s, u, b), declared register ranges must not overlap. これには無制限の範囲も含まれます。This includes unbounded ranges too. 異なるレジスタ空間で宣言された範囲が重複することはありません。Ranges declared in different register spaces never overlap. 無制限の tex2 は space0 に存在するのに対して無制限の tex3 は space1 に存在するため、これらが重複しないことに注意してください。Note that unbounded tex2 resides in space0, while unbounded tex3 resides in space1, such that they do not overlap.

配列として宣言されているリソースへのアクセスは、インデックスの作成と同じように簡単です。次に例を示します。Accessing resources that have been declared as arrays is as simple as indexing them, for example:

Texture2D<float4> tex1[400] : register(t3);
sampler samp[7] : register(s0);
tex1[myMaterialID].Sample(samp[samplerID], texCoords);

インデックス (上記のコードに含まれている myMaterialIDsamplerID) の使用に対する既定の重要な制限があり、描画またはディスパッチ呼び出しでインデックスの変更は許可されません。There is an important default restriction on the use of the indices (myMaterialID and samplerID in the code above) in that they are not allowed to vary in a draw/dispatch call. インスタンス化に基づくインデックスの変更でさえ、変更としてカウントされます。Even changing the index based on instancing counts as varying.

インデックスの変更が必要な場合は、インデックスに NonUniformResourceIndex 修飾子を指定します。次に例を示します。If varying the index is required then specify the NonUniformResourceIndex qualifier on the index, for example:

tex1[NonUniformResourceIndex(myMaterialID)].Sample(samp[NonUniformResourceIndex(samplerID)], texCoords);

一部のハードウェアでは、この修飾子を使用すると、(スレッド間を含めて) 正確性を確保するための追加コードが生成されますが、パフォーマンス コストの低下はわずかです。On some hardware the use of this qualifier generates additional code to enforce correctness (including across threads) but at a minor performance cost. この修飾子を使用せずに描画またはディスパッチ内でインデックスが変更されると、結果は未定義です。If an index is changed without this qualifier and within a draw/dispatch the results are undefined.

記述子配列とテクスチャ配列Descriptor arrays and texture arrays

テクスチャ配列は DirectX 10 から使用可能になりました。Texture arrays have been available since DirectX 10. テクスチャ配列に必要な記述子は 1 つですが、すべての配列スライスは同じ形式、幅、高さ、および MIP 数を共有する必要があります。Texture arrays require one descriptor, however all the array slices must share the same format, width, height and mip count. また、この配列は、仮想アドレス空間内の連続する範囲を占める必要があります。Also, the array must occupy a contiguous range in virtual address space. 次のコードは、シェーダーからテクスチャ配列にアクセスする例を示します。The following code shows an example of accessing a texture array from a shader.

float3 myCoord(1.0f,1.4f,2.2f); // 2.2f is array index (rounded to int)
color = myTex2DArray.Sample(mySampler, myCoord);

テクスチャ配列では、NonUniformResourceIndex のような修飾子を必要とすることなく、インデックスを自由に変更できます。In a texture array, the index can be varied freely, without any need for qualifiers such as NonUniformResourceIndex.

同等の記述子配列は次のようになります。The equivalent descriptor array would be:

Texture2D<float4> myTex2DArray[] : register(t0); // t0+
float2 myCoord(1.0f, 1.4f);
color = myTex2D[2].Sample(mySampler,myCoord); // 2 is index

配列インデックスには使いにくい float が myTex2D[2] に置き換えられていることに注意してください。Note the awkward use of a float for the array index is replaced with myTex2D[2]. また、記述子配列は、次元に関してより高い柔軟性を提供します。Also descriptor arrays offer more flexibility with the dimensions. この種類 (この例では Texture2D) は変更できませんが、形式、幅、高さ、および MIP 数はすべて、各記述子によって変更できます。The type, Texture2D is this example, cannot vary, but the format, width, height, and mip count can all vary with each descriptor.

テクスチャ配列の記述子配列を使用しても問題ありません。It is legitimate to have a descriptor array of texture arrays:

Texture2DArray<float4> myTex2DArrayOfArrays[2] : register(t0);

それぞれに記述子が含まれている構造体の配列を宣言するのは適切ではありません。たとえば、次のコードはサポートされません。It is not legitimate to declare an array of structures, each structure containing descriptors, for example the following code is not supported.

struct myStruct {
    Texture2D                    a; 
    Texture2D                    b;
    ConstantBuffer<myConstants>  c;
};
myStruct foo[10000] : register(....);

この場合、メモリ レイアウト abcabcabc.... は許可されますが、これは言語の制限であり、サポートされていません。This would have allowed the memory layout abcabcabc...., but is a language limitation and is not supported. これを行うためのサポートされている方法の 1 つを次に示します。ただし、この場合のメモリ レイアウトは aaa...bbb...ccc... となります。One supported method of doing this would be as follows, though the memory layout in this case is aaa...bbb...ccc....

Texture2D                     a[10000] : register(t0);
Texture2D                        b[10000] : register(t10000);
ConstantBuffer<myConstants>   c[10000] : register(b0);

abcabcabc.... というメモリ レイアウトを実現するには、myStruct 構造体を使用せずに記述子テーブルを使用してください。To achieve the abcabcabc.... memory layout, use a descriptor table without use of the myStruct structure.

リソースのエイリアシングResource aliasing

HLSL シェーダーで指定されるリソース範囲は論理的な範囲です。The resource ranges specified in the HLSL shaders are logical ranges. これらは、実行時にルート署名メカニズムを介して具体的なヒープ範囲にバインドされます。They are be bound to concrete heap ranges at runtime via the root signature mechanism. 通常、論理的な範囲は、他のヒープ範囲と重複しないヒープ範囲にマップされます。Normally, a logical range maps to a heap range that does not overlap with other heap ranges. ただし、ルート署名メカニズムにより、互換性のある型のヒープ範囲をエイリアス化 (重複) することができます。However, the root signature mechanism makes it possible to alias (overlap) heap ranges of compatible types. たとえば、上の例の tex2tex3 の範囲は、同じ (または重複する) ヒープ範囲にマップされることがあります。これは、HLSL プログラムでテクスチャのエイリアシングの効果があります。For example, tex2 and tex3 ranges from the above example may be mapped to the same (or overlapping) heap range, which has the effect of aliasing textures in the HLSL program. このようなエイリアシングが必要な場合は、D3D10_SHADER_RESOURCES_MAY_ALIAS オプションを使用してシェーダーをコンパイルする必要があります。これは、Effect-Compiler Tool (FXC) の /res_may_alias オプションを使用して設定します。If such aliasing is desired, the shader must be compiled with D3D10_SHADER_RESOURCES_MAY_ALIAS option, which is set by using the /res_may_alias option for the Effect-Compiler Tool (FXC). このオプションは、リソースがエイリアス化される可能性があるという想定のもとで、特定のロードまたはストアの最適化を妨げることによって、コンパイラが適切なコードを生成するようにします。The option makes the compiler produce correct code by preventing certain load/store optimizations under the assumption that resources may alias.

分岐と派生物Divergence and derivatives

SM5.1 では、リソース インデックス tex2[idx].Sample(…) に対する制限はありません。インデックス idx には、リテラル定数、cbuffer 定数、または補間された値を使用できます。SM5.1 does not impose limitations on the resource index; i.e.,tex2[idx].Sample(…) – the index idx can be a literal constant, a cbuffer constant, or an interpolated value. このプログラミング モデルは非常に高い柔軟性を提供しますが、注意すべき問題がいくつかあります。While the programming model provides such great flexibility, there are issues to be aware of:

  • クアッド全体でインデックスが分岐する場合、ハードウェアによって計算された派生物および LOD などの派生数は未定義になる可能性があります。If index diverges across a quad, the hardware-computed derivative and derived quantities such as LOD may be undefined. この場合、HLSL コンパイラはベスト エフォート方式で警告を出しますが、シェーダーのコンパイルを妨げません。The HLSL compiler makes the best effort to issue a warning in this case, but will not prevent a shader from compiling. この動作は、分岐制御フローで派生物を計算することに似ています。This behavior is similar to computing derivatives in divergent control flow.
  • リソース インデックスが分岐する場合は、ハードウェアが複数のリソースに対して操作を実行する必要があるため、同一インデックスの場合と比較してパフォーマンスが低下します。If the resource index is divergent, the performance is diminished compared to the case of a uniform index, because the hardware needs to perform operations on several resources. 分岐する可能性のあるリソース インデックスは、HLSL コードの NonUniformResourceIndex 関数でマークする必要があります。Resource indexes that may be divergent must be marked with the NonUniformResourceIndex function in HLSL code. そうしないと、結果が未定義になります。Otherwise results are undefined.

ピクセル シェーダーの UAVUAVs in pixel shaders

SM5.0 の場合と同様、SM5.1 では、ピクセル シェーダー内の UAV 範囲に対する制約はありません。SM5.1 does not impose constraints on UAV ranges in pixel shaders as was the case for SM5.0.

定数バッファーConstant Buffers

SM5.1 の定数バッファー (cbuffer) の構文は SM5.0 から変更され、開発者が定数バッファーにインデックスを作成できるようになりました。SM5.1 constant buffers (cbuffer) syntax has changed from SM5.0 to enable developers to index constant buffers. インデックスの作成可能な定数バッファーを有効にするために、SM5.1 では ConstantBuffer "テンプレート" コンストラクトが導入されています。To enable indexable constant buffers, SM5.1 introduces the ConstantBuffer “template” construct:

struct Foo
{
    float4 a;
    int2 b;
};
ConstantBuffer<Foo> myCB1[2][3] : register(b2, space1);
ConstantBuffer<Foo> myCB2 : register(b0, space1);

上記のコードでは、Foo 型でサイズ 6 の定数バッファー変数 myCB1、およびスカラー型の定数バッファー変数 myCB2 を宣言しています。The preceding code declares constant buffer variable myCB1 of type Foo and size 6, and a scalar, constant buffer variable myCB2. 定数バッファー変数には、シェーダー内で次のようにインデックスを作成できるようになりました。A constant buffer variable can now be indexed in the shader as:

myCB1[i][j].a.xyzw
myCB2.b.yy

フィールド "a" と "b" はグローバル変数にはなりませんが、フィールドとして扱う必要があります。Fields ‘a’ and ‘b’ do not become global variables, but rather must be treated as fields. 下位互換性のために、SM5.1 では、スカラー cbuffer に対して古い cbuffer の概念をサポートしています。For backward compatibility, SM5.1 supports the old cbuffer concept for scalar cbuffers. 次のステートメントでは、SM5.0 と同様に、"a" および "b" はグローバルな読み取り専用変数になります。The following statement makes ‘a’ and ‘b’ global, read-only variables as in SM5.0. ただし、このような古いスタイルの cbuffer にはインデックスを作成できません。However, such an old-style cbuffer cannot be indexable.

cbuffer : register(b1)
{
    float4 a;
    int2 b;
};

現在、シェーダー コンパイラは、ユーザー定義の構造体に対してのみ ConstantBuffer テンプレートをサポートしています。Currently, the shader compiler supports the ConstantBuffer template for user-defined structures only.

互換性上の理由から、HLSL コンパイラは space0 で宣言された範囲にリソース レジスタを自動的に割り当てる可能性があります。For compatibility reasons, the HLSL compiler may automatically assign resource registers for ranges declared in space0. register 句で "space" が省略されている場合は、既定の space0 が使用されます。If ‘space’ is omitted in the register clause, the default space0 is used. コンパイラは、first-hole-fits ヒューリスティックを使用してレジスタを割り当てます。The compiler uses the first-hole-fits heuristic to assign the registers. この割り当ては、リフレクション API を介して取得できます。この API は、空間用の Space フィールドを追加するよう拡張されているのに対し、BindPoint フィールドは、リソース レジスタ範囲の下限を示します。The assignment can be retrieved via the reflection API, which has been extended to add the Space field for space, while the BindPoint field indicates the lower bound of the resource register range.

SM5.1 におけるバイトコードの変更Bytecode changes in SM5.1

SM5.1 では、命令内でのリソース レジスタの宣言方法と参照方法が変更されています。SM5.1 changes how resource registers are declared and referenced in instructions. この構文には、グループ共有メモリ レジスタの場合と同様に、レジスタ "変数" の宣言が含まれます。The syntax involves declaring a register “variable”, similar to how it is done for group shared memory registers:

Texture2D<float4> tex0          : register(t5,  space0);
Texture2D<float4> tex1[][5][3]  : register(t10, space0);
Texture2D<float4> tex2[8]       : register(t0,  space1);
SamplerState samp0              : register(s5, space0);

float4 main(float4 coord : COORD) : SV_TARGET
{
    float4 r = coord;
    r += tex0.Sample(samp0, r.xy);
    r += tex2[r.x].Sample(samp0, r.xy);
    r += tex1[r.x][r.y][r.z].Sample(samp0, r.xy);
    return r;
}

これを逆アセンブルすると、次のようになります。This will disassemble to:

// Resource Bindings:
//
// Name                                 Type  Format         Dim    ID   HLSL Bind     Count
// ------------------------------ ---------- ------- ----------- -----   --------- ---------
// samp0                             sampler      NA          NA     S0    a5            1
// tex0                              texture  float4          2d     T0    t5            1
// tex1[0][5][3]                     texture  float4          2d     T1   t10        unbounded
// tex2[8]                           texture  float4          2d     T2    t0.space1     8
//
//
//
// Input signature:
//
// Name                 Index   Mask Register SysValue  Format   Used
// -------------------- ----- ------ -------- -------- ------- ------
// COORD                    0   xyzw        0     NONE   float   xyzw
//
//
// Output signature:
//
// Name                 Index   Mask Register SysValue  Format   Used
// -------------------- ----- ------ -------- -------- ------- ------
// SV_TARGET                0   xyzw        0   TARGET   float   xyzw
//
ps_5_1
dcl_globalFlags refactoringAllowed
dcl_sampler s0[5:5], mode_default, space=0
dcl_resource_texture2d (float,float,float,float) t0[5:5], space=0
dcl_resource_texture2d (float,float,float,float) t1[10:*], space=0
dcl_resource_texture2d (float,float,float,float) t2[0:7], space=1
dcl_input_ps linear v0.xyzw
dcl_output o0.xyzw
dcl_temps 2
sample r0.xyzw, v0.xyxx, t0[0].xyzw, s0[5]
add r0.xyzw, r0.xyzw, v0.xyzw
ftou r1.x, r0.x
sample r1.xyzw, r0.xyxx, t2[r1.x + 0].xyzw, s0[5]
add r0.xyzw, r0.xyzw, r1.xyzw
ftou r1.xyz, r0.zyxz
imul null, r1.yz, r1.zzyz, l(0, 15, 3, 0)
iadd r1.y, r1.z, r1.y
iadd r1.x, r1.x, r1.y
sample r1.xyzw, r0.xyxx, t1[r1.x + 10].xyzw, s0[5]
add o0.xyzw, r0.xyzw, r1.xyzw
ret
// Approximately 12 instruction slots are used.

それぞれのシェーダー リソース範囲は、シェーダー バイトコードに固有の ID (名前) を持つようになりました。Each shader resource range now has an ID (a name) that is unique to the shader bytecode. たとえば、tex1 (t10) テクスチャ配列は、シェーダー バイトコードでは "T1" になります。For example, tex1 (t10) texture array becomes ‘T1’ in the shader bytecode. 各リソース範囲に一意の ID を付与すると、次の 2 つのことが可能になります。Giving unique IDs to each resource range allows two things:

  • 命令内でどのリソース範囲 (dcl_resource_texture2d を参照) にインデックスが作成されているかを明確に識別する (サンプルの命令を参照)。Unambiguously identify which resource range (see dcl_resource_texture2d) is being indexed in an instruction (see sample instruction).
  • 要素の種類、ストライド サイズ、ラスター操作モードなど、一連の属性を宣言にアタッチする。Attaching a set of attributes to the declaration, e.g., element type, stride size, raster operation mode, etc.

範囲の ID は、HLSL の下限宣言とは関連していないことに注意してください。Note that the ID of the range is not related to the HLSL lower bound declaration.

リフレクション リソース バインドの順序 (一番上に表示) とシェーダー宣言命令 (dcl_*) の順序は同じで、HLSL 変数とバイトコード ID の対応を識別するのに役立ちます。The order of reflection resource bindings (listing at the top) and shader declaration instructions (dcl_*) is the same to aid in identifying the correspondence between HLSL variables and bytecode IDs.

SM5.1 の各宣言命令では、3D オペランドを使用して、範囲 ID、下限値、上限値を定義します。Each declaration instruction in SM5.1 uses a 3D operand to define: range ID, lower and upper bounds. レジスタ空間を指定するために、1 つの追加のトークンが出力されます。An additional token is emitted to specify the register space. 範囲の追加のプロパティを伝達するために他のトークンが出力される場合もあります。たとえば、cbuffer または構造化バッファー宣言命令は、cbuffer または構造体のサイズを出力します。Other tokens may be emitted as well to convey additional properties of the range, e.g., cbuffer or structured buffer declaration instruction emits the size of the cbuffer or structure. エンコードの詳細は、d3d12TokenizedProgramFormat.h および D3D10ShaderBinary::CShaderCodeParser で確認できます。The exact details of encoding can be found in d3d12TokenizedProgramFormat.h and D3D10ShaderBinary::CShaderCodeParser.

SM5.1 命令では、(SM5.0 の場合のように) 命令の一部として追加のリソース オペランド情報を出力しません。SM5.1 instructions will not emit additional resource operand information as part of the instruction (as in SM5.0). 現在、この情報は、宣言命令に含まれます。This information is now in the declaration instructions. SM5.0 では、インデックスの作成により宣言との関連付けがわかりにくくなったため、リソースにインデックスを作成する命令では、拡張オペコード トークンにリソースの属性を記述する必要がありました。In SM5.0, instructions indexing resources required resource attributes to be described in extended opcode tokens, since indexing obfuscated the association to the declaration. SM5.1 では、各 ID ("t1" など) は、必要なリソース情報を記述する単一の宣言に明確に関連付けられます。In SM5.1, each ID (such as ‘t1’) is unambiguously associated with a single declaration that describes the required resource information. したがって、リソース情報を記述するための命令で使用されていた拡張オペコード トークンは出力されなくなりました。Therefore, the extended opcode tokens used on instructions to describe resource information are no longer emitted.

宣言以外の命令では、サンプラー、SRV、および UAV のリソース オペランドは 2D オペランドです。In non-declaration instructions, a resource operand for samplers, SRVs, and UAVs is a 2D operand. 最初のインデックスは、範囲 ID を指定するリテラル定数です。The first index is a literal constant that specifies the range ID. 2 番目のインデックスは、インデックスの線形化された値を表します。The second index represents the linearized value of the index. この値は、ルート署名との相関性を高め、インデックスを調整するドライバー コンパイラの負担を軽減するために、(論理的な範囲の先頭ではなく) 対応するレジスタ空間の先頭を基準に計算されます。The value is computed relative to the beginning of the corresponding register space (not relative to the beginning of the logical range) to better correlate with the root signature and to reduce the driver compiler burden of adjusting the index.

CBV のリソース オペランドは 3D オペランドで、範囲のリテラル ID、定数バッファーのインデックス、定数バッファーの特定のインスタンスへのオフセットを含みます。A resource operand for CBVs is a 3D operand, containing: literal ID of the range, index of the constant buffer, offset into the particular instance of constant buffer.

HLSL の宣言の例Example HLSL Declarations

HLSL プログラムは、ルート署名についてすべてを把握する必要はありません。HLSL programs do not need to know anything about root signatures. これらは、仮想 "レジスタ" バインド空間にバインドを割り当てることができます (SRV の場合は t#、UAV の場合は u#、CBV の場合は b#、サンプラーの場合は s#)。また、コンパイラに割り当ての選択を依存して、後でシェーダー リフレクションを使用して結果のマッピングを照会することもできます。They can assign bindings to the virtual “register” binding space, t# for SRVs, u# for UAVs, b# for CBVs, s# for samplers, or rely on the compiler to pick assignments (and query the resulting mappings using shader reflection afterwards). ルート署名は、記述子テーブル、ルート記述子、およびルート定数をこの仮想レジスタ空間にマップします。The root signature maps descriptor tables, root descriptors, and root constants to this virtual register space.

HLSL シェーダーに設定されている可能性のある宣言の例を次に示します。The following are some example declarations an HLSL shader might have. ルート署名または記述子テーブルへの参照がないことに注意してください。Note that there are no references to root signatures or descriptor tables.

Texture2D foo[5] : register(t2);
Buffer bar : register(t7);
RWBuffer dataLog : register(u1);

Sampler samp : register(s0);

struct Data
{
    UINT index;
    float4 color;
};
ConstantBuffer<Data> myData : register(b0);

Texture2D terrain[] : register(t8); // Unbounded array
Texture2D misc[] : register(t0,space1); // Another unbounded array 
                                        // space1 avoids overlap with above t#

struct MoreData
{
    float4x4 xform;
};
ConstantBuffer<MoreData> myMoreData : register(b1);

struct Stuff
{
    float2 factor;
    UINT drawID;
};
ConstantBuffer<Stuff> myStuff[][3][8]  : register(b2, space3)

HLSL 5.1 を使用した動的インデックス作成Dynamic Indexing using HLSL 5.1

Effect-Compiler ToolEffect-Compiler Tool

Direct3D 12 での HLSL シェーダー モデル 5.1 の機能HLSL Shader Model 5.1 Features for Direct3D 12

ラスタライザー順序指定ビューRasterizer Ordered Views

リソース バインドResource Binding

ルート署名Root Signatures

シェーダー モデル 5.1Shader Model 5.1

シェーダー指定されたステンシル参照値Shader Specified Stencil Reference Value

HLSL でのルート署名の指定Specifying Root Signatures in HLSL