Skip to content

[DirectX] Documenting Root Signature Binary representation #131011

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 28 commits into from
Mar 20, 2025
Merged
Changes from 23 commits
Commits
Show all changes
28 commits
Select commit Hold shift + click to select a range
e26ef18
Adding root constant documentation
joaosaffran Mar 3, 2025
4f3930a
Removing union, fix typos
joaosaffran Mar 3, 2025
8fae269
Wrapping text
joaosaffran Mar 3, 2025
7ad5d2b
Removing redundant byte offset reference
joaosaffran Mar 3, 2025
93116c0
Try fix test
joaosaffran Mar 3, 2025
e1d385a
Fix git error
joaosaffran Mar 3, 2025
b390cd2
Adding root descriptor subsection
joaosaffran Mar 4, 2025
46face1
Fix git error
joaosaffran Mar 4, 2025
6a260b3
Try fix test
joaosaffran Mar 4, 2025
82a7de3
Updating Root Descriptor documentation
joaosaffran Mar 4, 2025
b591fd8
Linking Direct X docs to details flags
joaosaffran Mar 4, 2025
583e29c
Detail RootDescriptorFlags enum
joaosaffran Mar 5, 2025
16e3642
Update DXContainer.rst
joaosaffran Mar 6, 2025
3da10bd
Addressing comments
joaosaffran Mar 11, 2025
73c645d
Addressing comments
joaosaffran Mar 11, 2025
fcabc0e
Address PR Comments
joaosaffran Mar 11, 2025
b13609d
Adding Static Sampler Documentation
joaosaffran Mar 12, 2025
4525033
Update DXContainer.rst
joaosaffran Mar 12, 2025
15babc8
Merge branch 'documentation/root-descriptors' into documentation/stat…
Mar 13, 2025
5303de8
make a single PR
Mar 13, 2025
8dc983a
Update DXContainer.rst
joaosaffran Mar 13, 2025
b013080
Update DXContainer.rst
joaosaffran Mar 14, 2025
0bcfa6b
Addressing comments
joaosaffran Mar 17, 2025
787c920
Addressing comments
joaosaffran Mar 19, 2025
351e6bb
Addressing some comments
joaosaffran Mar 19, 2025
32fd3de
Address PR Comments
joaosaffran Mar 19, 2025
7dcad52
Update DXContainer.rst
joaosaffran Mar 19, 2025
a9260e5
Update DXContainer.rst
joaosaffran Mar 20, 2025
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
150 changes: 149 additions & 1 deletion llvm/docs/DirectX/DXContainer.rst
Original file line number Diff line number Diff line change
Expand Up @@ -111,7 +111,7 @@ FXC are marked with \*.
#. `PSV0`_ - Stores Pipeline State Validation data.
#. RDAT† - Stores Runtime Data.
#. RDEF\* - Stores resource definitions.
#. RTS0 - Stores compiled root signature.
#. `RTS0`_ - Stores compiled root signature.
#. `SFI0`_ - Stores shader feature flags.
Comment on lines +114 to 115
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's odd that the order here doesn't match the order of the sections later. Probably makes sense to insert the new content right before the SFI0 section rather than right after.

#. SHDR\* - Stores compiled DXBC bytecode.
#. SHEX\* - Stores compiled DXBC bytecode.
Expand Down Expand Up @@ -400,3 +400,151 @@ SFI0 Part
The SFI0 part encodes a 64-bit unsigned integer bitmask of the feature flags.
This denotes which optional features the shader requires. The flag values are
defined in `llvm/include/llvm/BinaryFormat/DXContainerConstants.def <https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/BinaryFormat/DXContainerConstants.def>`_.

Root Signature (RTS0) Part
--------------------------
.. _RTS0:

The Root Signature data defines the shader's resource interface with Direct3D 12,
specifying what resources the shader needs to access and how they're organized
and bound to the pipeline.

The RTS0 part comprises three data structures: ``RootSignatureHeader``,
``RootParameters`` and ``StaticSamplers``. The details of each will be described
in the following sections. All ``RootParameters`` will be serialized following the
order they were defined in the metadata representation.

Root Signature Header
~~~~~~~~~~~~~~~~~~~~~

The root signature header is 24 bytes long, consisting of six 32 bit values
representing the version, number and offset of parameters, number and offset
of static samplers, and a flags field for global behaviours:

.. code-block:: c

struct RootSignatureHeader {
uint32_t Version;
uint32_t NumParameters;
uint32_t ParametersOffset;
uint32_t NumStaticSamplers;
uint32_t StaticSamplerOffset;
uint32_t Flags;
}


Root Parameters
~~~~~~~~~~~~~~~
Root parameters define how resources are bound to the shader pipeline, each
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit:

Suggested change
Root Parameters
~~~~~~~~~~~~~~~
Root parameters define how resources are bound to the shader pipeline, each
Root Parameters
~~~~~~~~~~~~~~~
Root parameters define how resources are bound to the shader pipeline, each

type having different size and fields.

Each slot of root parameters is preceded by 12 bytes, three 32 bit values,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Each slot of root parameters is preceded by 12 bytes, three 32 bit values,
Each slot of root parameters is preceded by 12 bytes (three 32 bit values)

representing the parameter type, a flag encoding the pipeline stages where
the data is visible, and an offset calculated from the start of RTS0 section.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this saying that each root parameter starts with this header, and the parameters are laid out one after the other, or are the headers contiguous and then index into a single blob of data for all of the parameters?

The description here sounds like the former, but I suspect the format actually works like the latter, otherwise having the offset field here wouldn't make much sense.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checking DXC source code, I am not 100% sure how this is layout, because the logic used to calculate the Offset is confusing, but my understanding is headers are contiguous and then index into a single blob of data for all the parameters. At least that is how the data appears to be read in DXC.

I will update the text to reflect this.


.. code-block:: c

struct RootParameterHeader {
uint32_t ParameterType;
uint32_t ShaderVisibility;
uint32_t ParameterOffset;
};

The following sections will describe each of the root parameters types and their encodings.

Root Constants
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you deem worthwhile, we could add the parameter type enum value. Something like:

Suggested change
Root Constants
Root Constants: ParameterType = 0u

''''''''''''''

Root constants are values passed directly to shaders without needing a constant
buffer. It is a 12 bytes long structure, two 32 bit values encoding the register
and space the constant is assigned to, and one 32 bit value encoding the constant value.

.. code-block:: c

struct RootConstants {
uint32_t Register;
uint32_t Space;
uint32_t Value;
};

Root Descriptor
'''''''''''''''

Root descriptors provide direct GPU memory addresses to resources. Version 1.1 of
root descriptor is a 12 byte long, the first two 32 bit values encode the register
and space being assigned to the descriptor, and the last 32 bit value is an access flag flag.

Version 1.0 doesn't contain the flags available in version 1.1.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that I see how this reads I think describing these additively might be better after all. Maybe something like:

Root descriptors provide direct GPU memory addresses to resources.

In version 1.0, the root descriptor is 8 bytes. It encodes the register and
space as 2 32-bit values.

In version 1.1, the root descriptor is 12 bytes. It matches the 1.0 descriptor
but adds a 32-bit access flag.

If this makes sense to you, similar handling in the root descriptor table section should work too.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove - this sentence is redundant with the above at this point

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like you didn't have a chance to address this one yet.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, thought this was gone in the latest pr, address it in the most recent changes


.. code-block:: c

struct RootDescriptor_V1_0 {
uint32_t ShaderRegister;
uint32_t RegisterSpace;
};

struct RootDescriptor_V1_1 {
uint32_t ShaderRegister;
uint32_t RegisterSpace;
uint32_t Flags;
};

Root Descriptor Table
'''''''''''''''''''''
Descriptor tables let shaders access multiple resources through a single pointer to a descriptor heap.

The tables are made of a collection of descriptor ranges. Version 1.1 ranges are 24 bytes long, containing
five 32 bit values: The type of register, the number of registers in the range, the starting register number,
the register space, an offset in number of descriptors from the start of the table and finally an access flag.

Version 1.0 ranges are the 20 bytes long, following the same structure without the flags.

.. code-block:: c

struct DescriptorRange_V1_0 {
uint_32t RangeType;
uint32_t NumDescriptors;
uint32_t BaseShaderRegister;
uint32_t RegisterSpace;
uint32_t OffsetInDescriptorsFromTableStart;
};

struct DescriptorRange_V1_1 {
dxbc::DescriptorRangeType RangeType;
uint32_t NumDescriptors;
uint32_t BaseShaderRegister;
uint32_t RegisterSpace;
uint32_t OffsetInDescriptorsFromTableStart;
// Bitfield of flags from the Flags enum
uint32_t Flags;
};

Static Samplers
~~~~~~~~~~~~~~~

Static samplers are predefined filtering settings built into the root signature, avoiding descriptor heap lookups.

This section also has a variable size. The size is 68 bytes long, containing the following fields: 32 bits for a
filter mode, three 32 bit fields for texture address mode, 64 bits for the bias value of minmap level calculation,
32 bits for maximum anisotropy level, 32 bits for the comparison function type, 32 bits for the static border colour,
two 64 bit fields for the min and max level of detail, two 32 bit fields for the register number and space and finally
32 bits for the shader visibility flag.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't look quite right:

  1. You say the section has a variable size, but then describe a fixed layout. Which is it?
  2. The description doesn't match the code block - MipLODBias, MinLOD, and MaxLOD are all floats below but listed as 64 bit fields here.

I also think describing each field in a paragraph like this gets a bit muddled. It might be better to simply say that the structure consists of 13 32-byte fields (as it appears to, assuming the 64-bit mentions in the text above are mistakes) of various enum, float, and integer values and let the names of the fields in the code block speak for themselves.


.. code-block:: c

struct StaticSamplerDesc {
FilterMode Filter;
TextureAddressMode AddressU;
TextureAddressMode AddressV;
TextureAddressMode AddressW;
float MipLODBias;
uint32_t MaxAnisotropy;
ComparisonFunc ComparisonFunc;
StaticBorderColor BorderColor;
float MinLOD;
float MaxLOD;
uint32_t ShaderRegister;
uint32_t RegisterSpace;
ShaderVisibility ShaderVisibility;
};