Skip to content

[DirectX] Adding root constant documentation #129569

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

Closed
Closed
Changes from 1 commit
Commits
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
72 changes: 72 additions & 0 deletions llvm/docs/DirectX/DXContainer.rst
Original file line number Diff line number Diff line change
Expand Up @@ -400,3 +400,75 @@ 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>`_.

Copy link
Contributor

Choose a reason for hiding this comment

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

nit: the two lines used here and elsewhere creates a different formatting from the rest of the document


Root Signature (RST0) Part
---------
.. _RST0:

The Root Signature defines the interface between the shader and the pipeline, specifying which resources are bound to the shader and how they are accessed. This structure serves as a contract between the application and the GPU, establishing a layout for resource binding that both the shader compiler and the runtime can understand.

The Root Signature consists of a header followed by a collection of root parameters and static samplers. The structure uses a versioned design with offset-based references to allow for flexible serialization and deserialization.
Copy link
Contributor

Choose a reason for hiding this comment

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

We usually wrap the text in .rst files so that they're easier to read when not rendered, as we do elsewhere in this file where it's wrapped at column 80.


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

.. code-block:: c

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


The `RootSignatureHeader` structure contains the top-level information about a root signature:

- **Version**: Specifies the version of the root signature format. This allows for backward compatibility as the format evolves.
- **NumParameters**: The number of root parameters contained in this root signature.
- **ParametersOffset**: Byte offset from the beginning to the array of root parameters header.
Copy link
Contributor

Choose a reason for hiding this comment

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

Byte offset from the beginning to the array of root parameters header.

If all the offsets are from the beginning (I think they're all offset from the beginning of the RST0 part rather than the beginning of the container?) then maybe we can get away with just mentioning this once?

- **NumStaticSamplers**: The number of static samplers defined in the root signature.
- **StaticSamplerOffset**: Byte offset from the beginning to the array of static samplers.
- **Flags**: Bit flags that define global behaviors for the root signature, such as whether to deny vertex shader access to certain resources.

This header allows readers to navigate the binary representation of the root signature by providing counts and offsets to locate each component within the serialized data.

Root Parameter Header
~~~~~~~~~~~~~~~~~~~~~~~

.. code-block:: c

struct RootParameterHeader {
dxbc::RootParameterType ParameterType;
dxbc::ShaderVisibility ShaderVisibility;
uint32_t ParameterOffset;
};


Each root parameter in the signature is preceded by a `RootParameterHeader` that describes the parameter's basic attributes:

- **ParameterType**: Enumeration indicating what type of parameter this is (e.g., descriptor table, constants, CBV, SRV, UAV).
- **ShaderVisibility**: Specifies which shader stages can access this parameter (e.g., all stages, vertex shader only, pixel shader only).
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 an enum as well, or is it a flags object?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Shader visibility is an enum, here is the spec link proving more details.

- **ParameterOffset**: Byte offset from the beginning to the specific parameter data structure for this entry.

The header uses a parameter type field rather than encoding the version of the parameter through size, allowing for a more explicit representation of the parameter's nature.

Root Parameters
~~~~~~~~~~~~~~~~~~~~~~~

.. code-block:: c

union RootParameter {
RootConstants Constants;
};

The `RootParameter` union represents the various types of parameters that can be specified in a root signature. Such includes:
Copy link
Collaborator

Choose a reason for hiding this comment

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

This can't be a union. They're different sized and the size of each parameter varies.


- **Constants**: Represents inline root constants that are directly embedded in the root signature and passed to the shader without requiring a constant buffer resource.

Each specific parameter type will have its own structure with fields relevant to that parameter type. For example, `RootConstants` would include information about the register binding, count of 32-bit values, and other properties specific to constant parameters.

When processing root parameters, readers should first check the `ParameterType` field in the corresponding header to determine which member of the union to access.
Loading