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

ルート署名を HLSL Shader Model 5.1 で指定することは、C++ コードでの指定に代わる方法です。Specifying root signatures in HLSL Shader Model 5.1 is an alternative to specifying them in C++ code.

HLSL ルート署名の例An example HLSL Root Signature

ルート署名は、HLSL では文字列として指定できます。A root signature can be specified in HLSL as a string. この文字列の内容は、ルート署名を構成する要素を記述する句の、コンマ区切りの集合です。The string contains a collection of comma-separated clauses that describe root signature constituent components. ルート署名は、1 つのパイプライン状態オブジェクト (PSO) に対するすべてのシェーダーで同一であることが必要です。The root signature should be identical across shaders for any one pipeline state object (PSO). 以下に例を示します。Here is an example:

ルート署名バージョン 1.0Root Signature Version 1.0

                         "DENY_VERTEX_SHADER_ROOT_ACCESS), " \
              "CBV(b0, space = 1), " \
              "SRV(t0), " \
              "UAV(u0, visibility = SHADER_VISIBILITY_GEOMETRY), " \
              "DescriptorTable( CBV(b0), " \
                               "UAV(u1, numDescriptors = 2), " \
                               "SRV(t1, numDescriptors = unbounded)), " \
              "DescriptorTable(Sampler(s0, numDescriptors = 2)), " \
              "RootConstants(num32BitConstants=1, b9), " \
              "DescriptorTable( UAV(u3), " \
                               "UAV(u4), " \
                               "UAV(u5, offset=1)), " \

              "StaticSampler(s2)," \
              "StaticSampler(s3, " \
                             "addressU = TEXTURE_ADDRESS_CLAMP, " \
                             "filter = FILTER_MIN_MAG_MIP_LINEAR )"

ルート署名バージョン 1.1Root Signature Version 1.1

ルート署名バージョン 1.1 では、ルート署名の記述子とデータに対するドライバー最適化が可能です。Root Signature Version 1.1 enables driver optimizations on root signature descriptors and data.

                         "DENY_VERTEX_SHADER_ROOT_ACCESS), " \
              "CBV(b0, space = 1, flags = DATA_STATIC), " \
              "SRV(t0), " \
              "UAV(u0), " \
              "DescriptorTable( CBV(b1), " \
                               "SRV(t1, numDescriptors = 8, " \
                               "        flags = DESCRIPTORS_VOLATILE), " \
                               "UAV(u1, numDescriptors = unbounded, " \
                               "        flags = DESCRIPTORS_VOLATILE)), " \
              "DescriptorTable(Sampler(s0, space=1, numDescriptors = 4)), " \
              "RootConstants(num32BitConstants=3, b10), " \
              "StaticSampler(s1)," \
              "StaticSampler(s2, " \
                             "addressU = TEXTURE_ADDRESS_CLAMP, " \
                             "filter = FILTER_MIN_MAG_MIP_LINEAR )"

この定義では以下のようなルート署名になります。次の点に注目してください。This definition would give the following root signature, noting:

  • 既定のパラメーターの使用。The use of default parameters.
  • b0 と (b0, space=1) が競合しないb0 and (b0, space=1) do not conflict
  • u0 はジオメトリ シェーダーからのみ認識できるu0 is only visible to the geometry shader
  • u4 と u5 はエイリアスであり、ヒープ内の同じ記述子を指しているu4 and u5 are aliased to the same descriptor in a heap


HLSL ルート署名言語は、C++ ルート署名 API に密接に対応しており、同等の表現力があります。The HLSL root signature language closely corresponds to the C++ root signature APIs and has equivalent expressive power. ルート署名は、一連の句をコンマで区切って指定します。The root signature is specified as a sequence of clauses, separated by comma. 句の順序は重要です。解析の順序でルート署名内のスロット位置が決まるためです。The order of clauses is important, as the order of parsing determines the slot position in the root signature. それぞれの句は 1 つまたは複数の名前付きパラメーターを受け取ります。Each clause takes one or more named parameters. ただし、パラメーターの順序は重要ではありません。The order of parameters is not important, however.


RootFlags 句は省略可能であり、0 (フラグがないことを示す既定値) を指定するか、1 つまたは複数の事前定義済みルート フラグ値を OR ‘|’ 演算子で連結して指定します。The optional RootFlags clause takes either 0 (the default value to indicate no flags), or one or several of predefined root flags values, connected via the OR ‘|’ operator. 許可されるルート フラグの値は、D3D12_ROOT_SIGNATURE_FLAGS で定義されています。The allowed root flag values are defined by D3D12_ROOT_SIGNATURE_FLAGS.

以下に例を示します。For example:

RootFlags(0) // default value – no flags

ルート定数Root Constants

RootConstants 句では、ルート署名の中のルート定数を指定します。The RootConstants clause specifies root constants in the root signature. 2 つの必須パラメーターは、cbuffernum32BitConstantsbReg (C++ API の BaseShaderRegister に対応するレジスタ) です。Two mandatory parameters are: num32BitConstants and bReg (the register corresponding to BaseShaderRegister in C++ APIs) of the cbuffer. スペース (C++ API の RegisterSpace) と可視性 (C++ の ShaderVisibility) のパラメーターは省略可能であり、既定値は次のとおりです。The space (RegisterSpace in C++ APIs) and visibility (ShaderVisibility in C++) parameters are optional, and the default values are:

RootConstants(num32BitConstants=N, bReg [, space=0, 
              visibility=SHADER_VISIBILITY_ALL ])

以下に例を示します。For example:

RootConstants(num32BitConstants=3, b3)


可視性パラメーターは省略可能であり、D3D12_SHADER_VISIBILITY からの値の 1 つを指定できます。Visibility is an optional parameter that can have one of the values from D3D12_SHADER_VISIBILITY.

SHADER_VISIBILITY_ALL を指定すると、ルート引数がすべてのシェーダーにブロードキャストされます。SHADER_VISIBILITY_ALL broadcasts the root arguments to all shaders. ハードウェアによっては、これにコストはかかりませんが、その他のハードウェアではデータをすべてのシェーダー ステージにフォークするためのコストがかかります。On some hardware this has no cost, but on other hardware there is a cost to fork the data to all the shader stages. オプションの 1 つ、たとえば SHADER_VISIBILITY_VERTEX を設定すると、ルート引数が単一のシェーダー ステージに制限されます。Setting one of the options, such as SHADER_VISIBILITY_VERTEX, limits the root argument to a single shader stage.

ルート引数を単一のシェーダー ステージに設定すると、同じバインド名をさまざまなステージで使用できます。Setting root arguments to single shader stages allows the same bind name to be used at different stages. たとえば、t0,SHADER_VISIBILITY_VERTEX の SRV バインドと t0,SHADER_VISIBILITY_PIXEL の SRV バインドが有効になります。For example, an SRV binding of t0,SHADER_VISIBILITY_VERTEX and SRV binding of t0,SHADER_VISIBILITY_PIXEL would be valid. しかし、可視性の設定がこれらのバインドのいずれかに対して t0,SHADER_VISIBILITY_ALL の場合は、このルート署名は無効になります。But if the visibility setting was t0,SHADER_VISIBILITY_ALL for one of the bindings, the root signature would be invalid.

ルートレベル CBVRoot-level CBV

CBV (定数バッファー ビュー) 句では、ルートレベル定数バッファーの b レジスタ Reg エントリを指定します。The CBV (constant buffer view) clause specifies a root-level constant buffer b-register Reg entry. これはスカラー エントリであることに注意してください。つまり、ルート レベルに対する範囲を指定することはできません。Note that this is a scalar entry; it is not possible to specify a range for the root level.

CBV(bReg [, space=0, visibility=SHADER_VISIBILITY_ALL ])    //   Version 1.0
CBV(bReg [, space=0, visibility=SHADER_VISIBILITY_ALL,      // Version 1.1

ルートレベル SRVRoot-level SRV

SRV (シェーダー リソース ビュー) 句では、ルートレベル SRV の t レジスタ Reg エントリを指定します。The SRV (shader resource view) clause specifies a root-level SRV t-register Reg entry. これはスカラー エントリであることに注意してください。つまり、ルート レベルに対する範囲を指定することはできません。Note that this is a scalar entry; it is not possible to specify a range for the root level.

SRV(tReg [, space=0, visibility=SHADER_VISIBILITY_ALL ])    //   Version 1.0
SRV(tReg [, space=0, visibility=SHADER_VISIBILITY_ALL,      // Version 1.1

ルートレベル UAVRoot-level UAV

UAV (順序指定されていないアクセス ビュー) 句では、ルートレベル UAV の u レジスタ Reg エントリを指定します。The UAV (unordered access view) clause specifies a root-level UAV u-register Reg entry. これはスカラー エントリであることに注意してください。つまり、ルート レベルに対する範囲を指定することはできません。Note that this is a scalar entry; it is not possible to specify a range for the root level.

UAV(uReg [, space=0, visibility=SHADER_VISIBILITY_ALL ])    //   Version 1.0
UAV(uReg [, space=0, visibility=SHADER_VISIBILITY_ALL,      // Version 1.1
            flags=DATA_VOLATILE ])

以下に例を示します。For example:


記述子テーブルDescriptor Table

DescriptorTable 句はそれ自体が、記述子テーブル句をコンマで区切って連結したリストであり、必要に応じて可視性パラメーターも指定できます。The DescriptorTable clause is itself a list of comma-separated descriptor table clauses, as well as an optional visibility parameter. DescriptorTable 句には、CBV、SRV、UAV、サンプラーが含まれています。The DescriptorTable clauses include CBV, SRV, UAV, and Sampler. これらのパラメーターは、ルートレベル句のものとは異なることに注意してください。Note that their parameters differ from those of the root-level clauses.

DescriptorTable( DTClause1, [ DTClause2, … DTClauseN,
                 visibility=SHADER_VISIBILITY_ALL ] )

記述子テーブル CBV の構文は次のとおりです。The Descriptor Table CBV has the following syntax:

CBV(bReg [, numDescriptors=1, space=0, offset=DESCRIPTOR_RANGE_OFFSET_APPEND ])   // Version 1.0
CBV(bReg [, numDescriptors=1, space=0, offset=DESCRIPTOR_RANGE_OFFSET_APPEND      // Version 1.1

以下に例を示します。For example:

DescriptorTable(CBV(b0),SRV(t3, numDescriptors=unbounded))

必須パラメーター bReg では、cbuffer 範囲の開始 Reg を指定します。The mandatory parameter bReg specifies the start Reg of the cbuffer range. numDescriptors パラメーターでは、連続する cbuffer 範囲内の記述子の数を指定します。既定値は 1 となります。The numDescriptors parameter specifies the number of descriptors in the contiguous cbuffer range; the default value being 1. numDescriptors が数値のときは、このエントリによって cbuffer の範囲 [Reg, Reg + numDescriptors - 1] が宣言されます。The entry declares a cbuffer range[Reg, Reg + numDescriptors - 1], when numDescriptors is a number. numDescriptors が "unbounded" と等しい場合は、範囲は [Reg, UINT_MAX] となります。つまり、アプリは範囲外の領域を参照していないことを保証する必要があります。If numDescriptors is equal to "unbounded", the range is [Reg, UINT_MAX], which means the app must ensure it is not referencing an out-of-bounds area. offset フィールドは、C++ API の OffsetInDescriptorsFromTableStart パラメーター、つまり、テーブルの先頭からの (記述子内の) オフセットを表します。The offset field represents the OffsetInDescriptorsFromTableStart parameter in the C++ APIs, that is, the offset (in descriptors) from the start of the table. オフセットが DESCRIPTOR_RANGE_OFFSET_APPEND (既定値) に設定されている場合は、範囲が前の範囲の直後にあることを意味します。If the offset is set to DESCRIPTOR_RANGE_OFFSET_APPEND (the default), it means the range is directly after the previous range. しかし、特定のオフセットを入力すると、複数の範囲を重ね合わせることができ、レジスタのエイリアシングが可能になります。However, entering specific offsets does allow for ranges to overlap each other, allowing register aliasing.

記述子テーブル SRV の構文は次のとおりです。The Descriptor Table SRV has the following syntax:

SRV(tReg [, numDescriptors=1, space=0, offset=DESCRIPTOR_RANGE_OFFSET_APPEND ])    // Version 1.0
SRV(tReg [, numDescriptors=1, space=0, offset=DESCRIPTOR_RANGE_OFFSET_APPEND,      // Version 1.1

これは記述子テーブルの CBV エントリと似ていますが、指定された範囲がシェーダー リソース ビューに対するものである点が異なります。This is similar to the descriptor table CBV entry, except the specified range is for shader resource views.

記述子テーブル UAV の構文は次のとおりです。The Descriptor Table UAV has the following syntax:

UAV(uReg [, numDescriptors=1, space=0, offset=DESCRIPTOR_RANGE_OFFSET_APPEND ])    // Version 1.0
UAV(uReg [, numDescriptors=1, space=0, offset=DESCRIPTOR_RANGE_OFFSET_APPEND,      // Version 1.1
            flags=DATA_VOLATILE ])

これは記述子テーブル CBV のエントリと似ていますが、指定された範囲が順序指定されていないアクセス ビューに対するものである点が異なります。This is similar to the descriptor table CBV entry, except the specified range is for unordered access views.

記述子テーブル Sampler の構文は次のとおりです。The Descriptor Table Sampler has the following syntax:

Sampler(sReg [, numDescriptors=1, space=0, offset=DESCRIPTOR_RANGE_OFFSET_APPEND ])  // Version 1.0
Sampler(sReg [, numDescriptors=1, space=0, offset=DESCRIPTOR_RANGE_OFFSET_APPEND,    // Version 1.1
                flags=0 ])

これは記述子テーブル CBV のエントリと似ていますが、指定された範囲がシェーダー サンプラーに対するものである点が異なります。This is similar to the descriptor table CBV entry, except the specified range is for shader samplers. サンプラーと他の種類の記述子とを同じ記述子テーブル内で混在させることはできないことに注意してください (これらは別の記述子ヒープに存在するため)。Note that Samplers can’t be mixed with other types of descriptors in the same descriptor table (since they are in a separate descriptor heap).

静的サンプラーStatic Sampler

静的サンプラーは、D3D12_STATIC_SAMPLER_DESC 構造体を表します。The static sampler represents the D3D12_STATIC_SAMPLER_DESC structure. StaticSampler の必須パラメーターはスカラー型の、サンプラーの s レジスタ Reg です。その他のパラメーターは省略可能であり、既定値は以下のとおりです。The mandatory parameter for StaticSampler is a scalar, sampler s-register Reg. Other parameters are optional with default values shown below. ほとんどのフィールドで、一連の定義済みの列挙型が受け入れられます。Most fields accept a set of predefined enums.

StaticSampler( sReg,
              [ filter = FILTER_ANISOTROPIC, 
                addressU = TEXTURE_ADDRESS_WRAP,
                addressV = TEXTURE_ADDRESS_WRAP,
                addressW = TEXTURE_ADDRESS_WRAP,
                mipLODBias = 0.f,
                maxAnisotropy = 16,
                comparisonFunc = COMPARISON_LESS_EQUAL,
                borderColor = STATIC_BORDER_COLOR_OPAQUE_WHITE,
                minLOD = 0.f,         
                maxLOD = 3.402823466e+38f,
                space = 0, 
                visibility = SHADER_VISIBILITY_ALL ])

以下に例を示します。For example:

StaticSampler(s4, filter=FILTER_MIN_MAG_MIP_LINEAR)

パラメーターのオプションは、C++ API 呼び出しの場合とよく似ていますが、borderColor は例外であり、HLSL では列挙型 1 個だけとなります。The parameter options are very similar to the C++ API calls, except for borderColor, which is restricted to an enum in HLSL.

フィルター フィールドには、D3D12_FILTER の 1 つを指定できます。The filter field can be one of D3D12_FILTER.

アドレス フィールドのそれぞれには、D3D12_TEXTURE_ADDRESS_MODE の 1 つを指定できます。The address fields can each be one of D3D12_TEXTURE_ADDRESS_MODE.

比較関数には、D3D12_COMPARISON_FUNC の 1 つを指定できます。The comparison function can be one of D3D12_COMPARISON_FUNC.

境界線の色フィールドには、D3D12_STATIC_BORDER_COLOR の 1 つを指定できます。The border color field can be one of D3D12_STATIC_BORDER_COLOR.

可視性には、D3D12_SHADER_VISIBILITY の 1 つを指定できます。Visibility can be one of D3D12_SHADER_VISIBILITY.

HLSL ルート署名のコンパイルCompiling an HLSL root signature

HLSL ルート署名をコンパイルするメカニズムは 2 つあります。There are two mechanisms to compile an HLSL root signature. 1 つは、ルート署名文字列を特定のシェーダーに、RootSignature 属性を介してアタッチするというものです (下記の例では MyRS1 エントリ ポイントを使用しています)。First, it is possible to attach a root signature string to a particular shader via the RootSignature attribute (in the following example, using the MyRS1 entry point):

float4 main(float4 coord : COORD) : SV_Target

コンパイラによってシェーダーのルート署名 BLOB が作成されて検証され、シェーダー バイト コードと共にシェーダー BLOB に埋め込まれます。The compiler will create and verify the root signature blob for the shader and embed it alongside the shader byte code into the shader blob. コンパイラでは、シェーダー モデル 5.0 以上のルート署名構文がサポートされます。The compiler supports root signature syntax for shader model 5.0 and higher. ルート署名がシェーダー モデル 5.0 のシェーダーに埋め込まれており、そのシェーダーが D3D12 ではなく、D3D11 ランタイムに送信された場合は、ルート署名部分は D3D11 によって無視されます。If a root signature is embedded in a shader model 5.0 shader and that shader is sent to the D3D11 runtime, as opposed to D3D12, the root signature portion will get silently ignored by D3D11.

もう 1 つのメカニズムは、スタンドアロンのルート署名 BLOB を作成するというものです。これは、多数のシェーダーのセットでの再利用を目的とするものであり、スペースを節約できます。The other mechanism is to create a standalone root signature blob, perhaps to reuse it with a large set of shaders, saving space. Effect-Compiler Tool (FXC) では、rootsig_1_0rootsig_1_1 の両方のシェーダー モデルがサポートされます。The Effect-Compiler Tool (FXC) supports both rootsig_1_0 androotsig_1_1 shader models. 定義文字列の名前は、通常の /E 引数を介して指定されます。The name of the define string is specified via the usual /E argument. 以下に例を示します。For example:

fxc.exe /T rootsig_1_1 MyRS1.hlsl /E MyRS1 /Fo MyRS1.fxo

ルート署名の定義文字列は、コマンド ラインで渡すこともできます (例: /D MyRS1=”…”)。Note that the root signature string define can also be passed on the command line, e.g, /D MyRS1=”…”.

FXC コンパイラでのルート署名の操作Manipulating root signatures with the FXC compiler

FXC コンパイラは、HLSL ソース ファイルからシェーダー バイト コードを作成します。The FXC compiler creates shader byte-code from HLSL source files. このコンパイラには多数の省略可能パラメーターがあります。「Effect-Compiler Tool」を参照してください。There are a lot of optional parameters for this compiler, refer to the Effect-Compiler Tool.

HLSL で作成されたルート署名の管理に関する FXC の使用例を次の表に示します。For managing HLSL authored root signatures, the following table gives some examples of using FXC.

Line [パッケージ実行ユーティリティ]Command line 説明Description
11 fxc /T ps_5_1 shaderWithRootSig.hlsl /Fo rs1.fxo ピクセル シェーダー 5.1 ターゲットのシェーダーをコンパイルします。シェーダー ソースは shaderWithRootSig.hlsl ファイル内にあり、この中にルート署名があります。Compiles a shader for the pixel shader 5.1 target, the shader source is in the shaderWithRootSig.hlsl file, which includes a root signature. シェーダーとルート署名は、rs1.fxo バイナリ ファイル内でそれぞれ別の BLOB としてコンパイルされます。The shader and root signature are compiled as separate blobs in the rs1.fxo binary file.
22 fxc /dumpbin rs1.fxo /extractrootsignature /Fo rs1.rs.fxo 行 1 で作成されたファイルからルート署名を抽出します。したがって、rs1.rs.fxo ファイルの内容はルート署名だけとなります。Extracts the root signature from the file created by line 1, so the rs1.rs.fxo file contains just a root signature.
33 fxc /dumpbin rs1.fxo /Qstrip_rootsignature /Fo rs1.stripped.fxo 行 1 で作成されたファイルからルート署名を削除します。したがって、rs1.stripped.fxo ファイルの内容はルート署名のないシェーダーとなります。Removes the root signature from the file created by line 1, so the rs1.stripped.fxo file contains a shader with no root signature.
44 fxc /dumpbin rs1.stripped.fxo /setrootsignature rs1.rs.fxo /Fo rs1.new.fxo それぞれ別のファイルにあるシェーダーとルート署名を結合して、両方の BLOB が含まれているバイナリ ファイルを作成します。Combines a shader and root signature that are in separate files into a binary file containing both blobs. この例の rs1.new.fx0 は行 1 の rs1.fx0 と同一になります。In this example rs1.new.fx0 would be identical to rs1.fx0 in line 1.
55 fxc /T rootsig_1_0 rootSigAndMaybeShaderInHereToo.hlsl /E RS1 /Fo rs2.fxo スタンドアロンのルート署名バイナリ ファイルを作成します。このソースの内容は、ルート署名 1 つだけではない可能性があります。Creates a stand-alone root signature binary file from a source that may contain more than just a root signature. rootsig_1_0 がターゲットであることと、RS1 が HLSL ファイル内のルート署名 (#define) マクロ文字列の名前であることに注意してください。Note the rootsig_1_0 target, and that RS1 is the name of the root signature (#define) macro string in the HLSL file.


FXC を介して使用可能な機能は、プログラムでも D3DCompile 関数を通して利用できます。The functionality available through FXC is also available programmatically using the D3DCompile function. この呼び出しでは、ルート署名付きのシェーダーがコンパイルされるか、スタンドアロンのルート署名がコンパイルされます (rootsig_1_0 ターゲットを設定)。This call compiles a shader with a root signature, or stand-alone root signature (setting the rootsig_1_0 target). D3DGetBlobPartD3DSetBlobPart ではルート署名を抽出して既存の BLOB にアタッチできます。D3DGetBlobPart and D3DSetBlobPart can extract and attach root signatures to an existing blob.  D3D_BLOB_ROOT_SIGNATURE は、ルート署名の BLOB 部分の種類を指定するために使用されます。  D3D_BLOB_ROOT_SIGNATURE is used to specify the root signature blob part type. D3DStripShader では、ルート署名を (D3DCOMPILER_STRIP_ROOT_SIGNATURE フラグを使用して) BLOB から削除します。D3DStripShader removes the root signature (using the D3DCOMPILER_STRIP_ROOT_SIGNATURE flag) from the blob.



シェーダーのオフラインでのコンパイルを強くお勧めしますが、シェーダーを実行時にコンパイルする必要がある場合は、D3DCompile2 の注釈を参照してください。Whereas the offline compilation of shaders is strongly recommended, if shaders have to be compiled at runtime, refer to the remarks for D3DCompile2.



既存の HLSL 資産とともに使用するルート署名を処理できるようにするために、その資産に変更を加える必要はありません。Existing HLSL assets do not need to be changed to handle root signatures to be used with them.


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

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

リソース バインディングResource Binding

HLSL でのリソース バインディングResource Binding in HLSL

ルート署名Root Signatures

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

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

順序指定されていないアクセス ビューの型を指定した読み込みTyped Unordered Access View Loads