[DirectX] Documenting Root Signature Binary representation #131011

joaosaffran · 2025-03-12T18:49:13Z

Closes: #131009, #129796, #129749, #129561

llvmbot · 2025-03-12T18:49:49Z

@llvm/pr-subscribers-backend-directx

Author: None (joaosaffran)

Changes

Closes: #131009

Full diff: https://github.com/llvm/llvm-project/pull/131011.diff

1 Files Affected:

(modified) llvm/docs/DirectX/DXContainer.rst (+45)

diff --git a/llvm/docs/DirectX/DXContainer.rst b/llvm/docs/DirectX/DXContainer.rst
index 40c088462a452..8d32ad02d5e6a 100644
--- a/llvm/docs/DirectX/DXContainer.rst
+++ b/llvm/docs/DirectX/DXContainer.rst
@@ -612,3 +612,48 @@ RootDescriptorTable provides basic table structure:
 #. **NumDescriptorRanges**: Number of descriptor ranges
 #. **DescriptorRangesOffset**: Offset to descriptor range array
 
+Static Samplers
+~~~~~~~~~~~~~~~
+
+Static samplers provide a way to define fixed sampler states within the root signature itself.
+
+.. code-block:: cpp
+
+   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;
+   };
+
+
+The StaticSamplerDesc structure defines all properties of a static sampler:
+
+#. Filter: The filtering mode (e.g., point, linear, anisotropic) used for texture sampling. 
+   For details, check `Direct X documentation <https://learn.microsoft.com/en-us/windows/win32/api/d3d12/ne-d3d12-d3d12_filter#syntax>`_. 
+#. AddressU: The addressing mode for the U texture coordinate.
+   For details, check `Direct X documentation <https://learn.microsoft.com/en-us/windows/win32/api/d3d12/ne-d3d12-d3d12_texture_address_mode>`_. 
+#. AddressV: The addressing mode for the V texture coordinate.
+#. AddressW: The addressing mode for the W texture coordinate.
+#. MipLODBias: Bias value applied to mipmap level of detail calculations.
+#. MaxAnisotropy: Maximum anisotropy level when using anisotropic filtering.
+#. ComparisonFunc: Comparison function used for comparison samplers.
+   For details, check `Direct X documentation <https://learn.microsoft.com/en-us/windows/win32/api/d3d12/ne-d3d12-d3d12_comparison_func>`_. 
+#. BorderColor: Predefined border color used when address mode is set to border.
+   For details, check `Direct X documentation <https://learn.microsoft.com/en-us/windows/win32/api/d3d12/ne-d3d12-d3d12_static_border_color>`_. 
+#. MinLOD: Minimum level of detail to use for sampling.
+#. MaxLOD: Maximum level of detail to use for sampling.
+#. ShaderRegister: The shader sampler register (s#) where this sampler is bound.
+#. RegisterSpace: The register space used for the binding.
+#. ShaderVisibility: Specifies which shader stages can access this sampler.
+   For details, check `Direct X documentation <https://learn.microsoft.com/en-us/windows/win32/api/d3d12/ne-d3d12-d3d12_shader_visibility>`_. 
+

github-actions · 2025-03-12T18:50:54Z

⚠️ We detected that you are using a GitHub private e-mail address to contribute to the repo.
Please turn off Keep my email addresses private setting in your account.
See LLVM Discourse for more information.

alsepkow · 2025-03-12T23:23:04Z

llvm/docs/DirectX/DXContainer.rst

+   };
+
+
+The StaticSamplerDesc structure defines all properties of a static sampler:


Do you think it would make sense to remove all of these lines and instead just link to the top of the https://learn.microsoft.com/en-us/windows/win32/api/d3d12/ns-d3d12-d3d12_static_sampler_desc page?

Although, that link could break one day.

The intention here is to document the binary representation of root signatures inside dxcontainer, one of such parts is static samplers. Although, DX12 representation and the compiler representation are the same, that might not be the case in the future. For example, if we decide to change this representation or if DX12 decide to change theirs representation. Therefore, I think this duplication might be okay IMHO.

Does that mean that this struct will be defined in .../BinaryFormat/DXContainer.h ?

Yes. DXC has similar structs as well

This references a lot of types that aren't defined in this document. As a description of a binary format it really needs to discuss the sizes and layout of things more so than what the things are for.

…ic-samplers

inbelic

One general minor nit is that the motivation of each structure is not consistent in being at the start or end of the description. Personally I would place them at the start, but I would also be critical on if we need them. Some don't seem to be relevant to the binary data layout

llvm/docs/DirectX/DXContainer.rst

inbelic

LGTM, you have addressed my comments. None of my remaining issues are blockers to merge, but I would want another explicit approval first

llvm/docs/DirectX/DXContainer.rst

inbelic · 2025-03-13T23:27:21Z

llvm/docs/DirectX/DXContainer.rst

+shader visibility and its offset, and a data section. The parameters don't need to follow 
+any specific order. Root parameters define the interface elements that shaders can access. 


Imo saying "the order doesn't matter" is equivalent to "swapping the order of root parameters will describe the same root signature". Which I don't think is true (the default offset being append).

Maybe we can note this implication of ordering?

Happy to be wrong. I might not be looking at it from the right lens of copying over the data from offline chat. To me it does feel like this behaviour should be noted tho

Some description about what, if anything, the ordering of the root paramters implies (and an explicit mention of the "append" offset) seems like it would be useful.

bogner

Various editorial notes. From a high level I think it would be helpful to describe what's in the various parts of the format before showing example C structs to describe those parts, and I think we need to be more explicit about what's laid out where in the format rather than going into a lot of detail about what the fields are used for.

bogner · 2025-03-17T05:14:11Z

llvm/docs/DirectX/DXContainer.rst

+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.


These two sentences feel very redundant with one another, and neither really has a lot of content. The first says this defines an interface and the second literally defines what an interface is. Something like "The root signature part describes how resources are bound to the shader pipeline" is both more direct and clearer.

bogner · 2025-03-17T05:30:58Z

llvm/docs/DirectX/DXContainer.rst

+The Root Signature consists of a header followed by an array of root parameters 
+and an array of static samplers. The structure uses a versioned design with 
+offset-based references to allow for flexible serialization and deserialization. 
+One consequence of using an offset-based reference is that root parameters and 
+static samplers don't need to follow any specific ordering logic.


Calling the root parameters and static samplers "arrays" implies that they have fixed sizes, but at the very least root parameters do not. I also find the discussion of the versioning scheme and order independence here a bit random at this point in the document.

I think it might be clearer to say that the root signature part consists of three sections - a header that provides version information and offsets to the other parts, a parameters part that describes root parameters, and a samplers part that describes static samplers.

bogner · 2025-03-17T05:41:30Z

llvm/docs/DirectX/DXContainer.rst

+.. 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 of RST0 section to the array of root 
+   parameters header.
+#. **NumStaticSamplers**: The number of static samplers defined in the root signature.
+#. **StaticSamplerOffset**: Byte offset 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.


It's probably fine, but I wonder if showing an example C structure followed by the list of fields is overly verbose here. What do you think of simply describing the header in a sentence and then illustrating with a C struct, like

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
...

bogner · 2025-03-17T05:42:09Z

llvm/docs/DirectX/DXContainer.rst

+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.


This is just defining a header - I don't think it's necessary

bogner · 2025-03-17T05:44:45Z

llvm/docs/DirectX/DXContainer.rst

+shader visibility and its offset, and a data section. The parameters don't need to follow 
+any specific order. Root parameters define the interface elements that shaders can access. 


Some description about what, if anything, the ordering of the root paramters implies (and an explicit mention of the "append" offset) seems like it would be useful.

bogner · 2025-03-17T05:49:09Z

llvm/docs/DirectX/DXContainer.rst

+     dxbc::RootParameterType ParameterType;
+     dxbc::ShaderVisibility ShaderVisibility;


We're describing a binary format, not C. An enum in C does not necessarily map to 32 bits, so we should really be explicit about the size of the data here. This is a 32-bit value describing the parameter type (from a binary format point of view), not an enum of type RootParameterType.

Also, as above, I think having a description of what the values in a root paramter header are before we bother showing the example C struct would make this easier to follow.

bogner · 2025-03-17T05:51:44Z

llvm/docs/DirectX/DXContainer.rst

+#. **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).


I think it would be helpful to explain the full set of parameter types and possible visibilities in the top level description of root parameters. Then this can simply refer back to that and say we describe the parameter type and visibility and we don't need the "e.g." for each of these.

bogner · 2025-03-17T05:52:26Z

llvm/docs/DirectX/DXContainer.rst

+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.


I have no idea what this sentence means.

bogner · 2025-03-17T05:54:08Z

llvm/docs/DirectX/DXContainer.rst

+Version 1.1 Root Descriptor
+"""""""""""""""""""""""""""
+The Version 1.1 RootDescriptor_V1_1 extends the base structure with the following additional fields:
+
+#. **Flags**: Provides additional metadata about the descriptor's usage pattern.


Given that version 1.1 only seems to have added a flags field, I think it might be clearer to describe the 1.1 format and then have a note about the flags that it wasn't present in 1.0

bogner · 2025-03-17T05:56:41Z

llvm/docs/DirectX/DXContainer.rst

+   };
+
+
+The StaticSamplerDesc structure defines all properties of a static sampler:


This references a lot of types that aren't defined in this document. As a description of a binary format it really needs to discuss the sizes and layout of things more so than what the things are for.

bogner

A couple of comments, and the line lengths seem a bit inconsistent, probably worth going through the change and reflowing to 80 columns.

bogner · 2025-03-19T16:41:09Z

llvm/docs/DirectX/DXContainer.rst

+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.


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.

bogner · 2025-03-19T17:10:38Z

llvm/docs/DirectX/DXContainer.rst

+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.


This doesn't look quite right:

You say the section has a variable size, but then describe a fixed layout. Which is it?

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.

bogner · 2025-03-19T17:16:59Z

llvm/docs/DirectX/DXContainer.rst

+#. `RTS0`_ - Stores compiled root signature.
 #. `SFI0`_ - Stores shader feature flags.


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.

bogner

Mostly good except I think the root parameter headers part is a bit misleading as currently worded.

It might also be helpful to describe the layout with a table. Do you think something like this would help?

Part	Size
Root Signature Header	24 bytes
Root Parameter Headers	12 bytes each
Root Parameters	8, 12, 20, or 24 bytes each
Static Sampler	52 bytes each

There might be a better way to show this, feel free to play around with it if you have better ideas.

bogner · 2025-03-19T18:39:59Z

llvm/docs/DirectX/DXContainer.rst

+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, 


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)

bogner · 2025-03-19T18:40:51Z

llvm/docs/DirectX/DXContainer.rst

+In version 1.1, the root descriptor is 12 bytes. It matches the 1.0 descriptor
+but adds a 32-bit access flag.
+
+Version 1.0 doesn't contain the flags available in version 1.1.


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

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

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

bogner · 2025-03-19T18:46:12Z

llvm/docs/DirectX/DXContainer.rst

+This section also has a variable size, since it can contain multiple static 
+samplers definitions. However, the definition is a fixed sized struct, 
+containing 13 32-byte fields of various enum, float, and integer values. 


Oh, I see what you were saying here now.

Suggested change

This section also has a variable size, since it can contain multiple static

samplers definitions. However, the definition is a fixed sized struct,

containing 13 32-byte fields of various enum, float, and integer values.

This section consists of a variable number of static sampler definitions as

described in the root signature header. Each definition is 52 bytes made up of

13 32-byte fields of various enum, float, and integer values.

bogner · 2025-03-19T18:55:41Z

llvm/docs/DirectX/DXContainer.rst

+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.


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.

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.

inbelic

Some misc nits and a couple questions

inbelic · 2025-03-19T21:28:40Z

llvm/docs/DirectX/DXContainer.rst

+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.


I am not sure if this is applicable here, but there are limits to the size of the root signatureI, specified here. Not sure if that implies that there are limits to the size of this binary format?

That can be a future validation, since this is a limitation dx12 runtime. But currently, this is not something DXC checks when serializing root signatures.

Does the validator (dxv) catch root signatures that are over the limit? In any case, we should make sure we have an issue to add validation that we're not allowing root signatures that go over this limit.

inbelic · 2025-03-19T21:33:11Z

llvm/docs/DirectX/DXContainer.rst

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


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

Suggested change

Root Constants

Root Constants: ParameterType = 0u

inbelic · 2025-03-19T21:36:07Z

llvm/docs/DirectX/DXContainer.rst

+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.


The definition of Value seems wrong to me. The RootConstants should be used to pass a contiguous block of memory consisting of num32BitConstants 32-bit values.

I would guess Value should actually denote how many elements there are.

Updated to follow the same definition as DX12

inbelic · 2025-03-19T21:37:13Z

llvm/docs/DirectX/DXContainer.rst

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


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

inbelic · 2025-03-19T21:37:35Z

llvm/docs/DirectX/DXContainer.rst

+Root Descriptor Table
+'''''''''''''''''''''
+Descriptor tables let shaders access multiple resources through a single pointer 


nit:

Suggested change

Root Descriptor Table

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

Descriptor tables let shaders access multiple resources through a single pointer

Root Descriptor Table

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

Descriptor tables let shaders access multiple resources through a single pointer

inbelic · 2025-03-19T21:38:46Z

llvm/docs/DirectX/DXContainer.rst

+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. In Version 1.0, the 


Suggested change

The tables are made of a collection of descriptor ranges. In Version 1.0, the

The tables are made of an array of descriptor ranges. In Version 1.0, the

nit: imo array is less vague and implies they are contiguous

I agree with @bogner, that using an array, imply that they have a fixed size, which is not the case for the binary representation.

inbelic · 2025-03-19T21:39:30Z

llvm/docs/DirectX/DXContainer.rst

+
+

Suggested change

bogner

A couple of typos / style edits, then this LGTM!

bogner · 2025-03-19T23:46:18Z

llvm/docs/DirectX/DXContainer.rst

+Root Parameter Headers   12                                          Many              
+Root Parameter           ================================ ===        Many
+                         Root Constants                   12                                      
+                         Root Descriptor Version 1.0      08                                      


Suggested change

Root Descriptor Version 1.0 08

Root Descriptor Version 1.0 8

bogner · 2025-03-19T23:47:00Z

llvm/docs/DirectX/DXContainer.rst

+in the following sections. All ``RootParameters`` will be serialized following 
+the order they were defined in the metadata representation.
+
+The table bellow sumarizes the data being serialized as well as it's size. The 


Suggested change

The table bellow sumarizes the data being serialized as well as it's size. The

The table below summarizes the data being serialized as well as it's size. The

bogner · 2025-03-19T23:49:12Z

llvm/docs/DirectX/DXContainer.rst

+In version 1.1, the root descriptor is 12 bytes. It matches the 1.0 descriptor
+but adds a 32-bit access flag.
+
+Version 1.0 doesn't contain the flags available in version 1.1.


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

llvm-ci · 2025-03-20T04:27:05Z

LLVM Buildbot has detected a new failure on builder openmp-s390x-linux running on systemz-1 while building llvm at step 6 "test-openmp".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/88/builds/9365

Here is the relevant piece of the build log for the reference

Step 6 (test-openmp) failure: test (failure)
******************** TEST 'libomp :: tasking/issue-94260-2.c' FAILED ********************
Exit Code: -11

Command Output (stdout):
--
# RUN: at line 1
/home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/./bin/clang -fopenmp   -I /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/runtimes/runtimes-bins/openmp/runtime/src -I /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.src/openmp/runtime/test -L /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/runtimes/runtimes-bins/openmp/runtime/src  -fno-omit-frame-pointer -mbackchain -I /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.src/openmp/runtime/test/ompt /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.src/openmp/runtime/test/tasking/issue-94260-2.c -o /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/runtimes/runtimes-bins/openmp/runtime/test/tasking/Output/issue-94260-2.c.tmp -lm -latomic && /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/runtimes/runtimes-bins/openmp/runtime/test/tasking/Output/issue-94260-2.c.tmp
# executed command: /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/./bin/clang -fopenmp -I /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/runtimes/runtimes-bins/openmp/runtime/src -I /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.src/openmp/runtime/test -L /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/runtimes/runtimes-bins/openmp/runtime/src -fno-omit-frame-pointer -mbackchain -I /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.src/openmp/runtime/test/ompt /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.src/openmp/runtime/test/tasking/issue-94260-2.c -o /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/runtimes/runtimes-bins/openmp/runtime/test/tasking/Output/issue-94260-2.c.tmp -lm -latomic
# executed command: /home/uweigand/sandbox/buildbot/openmp-s390x-linux/llvm.build/runtimes/runtimes-bins/openmp/runtime/test/tasking/Output/issue-94260-2.c.tmp
# note: command had no output on stdout or stderr
# error: command failed with exit status: -11

--

********************

joaosaffran added 17 commits March 3, 2025 10:21

Adding root constant documentation

e26ef18

Removing union, fix typos

4f3930a

Wrapping text

8fae269

Removing redundant byte offset reference

7ad5d2b

Try fix test

93116c0

Fix git error

e1d385a

Adding root descriptor subsection

b390cd2

Fix git error

46face1

Try fix test

6a260b3

Updating Root Descriptor documentation

82a7de3

Linking Direct X docs to details flags

b591fd8

Detail RootDescriptorFlags enum

583e29c

Update DXContainer.rst

16e3642

Addressing comments

3da10bd

Addressing comments

73c645d

Address PR Comments

fcabc0e

Adding Static Sampler Documentation

b13609d

joaosaffran requested review from bogner and inbelic March 12, 2025 18:49

llvmbot added the backend:DirectX label Mar 12, 2025

Update DXContainer.rst

4525033

alsepkow reviewed Mar 12, 2025

View reviewed changes

bogner mentioned this pull request Mar 13, 2025

[DirectX] Adding root constant documentation #129569

Closed

joaosaffran changed the base branch from users/joaosaffran/129797 to main March 13, 2025 16:33

joaosaffran added 2 commits March 13, 2025 16:36

Merge branch 'documentation/root-descriptors' into documentation/stat…

15babc8

…ic-samplers

make a single PR

5303de8

joaosaffran changed the title ~~[DirectX] Documenting Static Samplers binary representation~~ [DirectX] Documenting Root Signature Binary representation Mar 13, 2025

inbelic reviewed Mar 13, 2025

View reviewed changes

llvm/docs/DirectX/DXContainer.rst Outdated Show resolved Hide resolved

llvm/docs/DirectX/DXContainer.rst Outdated Show resolved Hide resolved

llvm/docs/DirectX/DXContainer.rst Outdated Show resolved Hide resolved

Update DXContainer.rst

8dc983a

joaosaffran requested review from inbelic and alsepkow March 13, 2025 21:52

inbelic reviewed Mar 13, 2025

View reviewed changes

Update DXContainer.rst

b013080

bogner reviewed Mar 17, 2025

View reviewed changes

Addressing comments

0bcfa6b

joaosaffran requested review from inbelic and bogner March 17, 2025 19:53

bogner reviewed Mar 19, 2025

View reviewed changes

Addressing comments

787c920

bogner reviewed Mar 19, 2025

View reviewed changes

inbelic reviewed Mar 19, 2025

View reviewed changes

joaosaffran added 2 commits March 19, 2025 16:19

Addressing some comments

351e6bb

Address PR Comments

32fd3de

joaosaffran requested review from inbelic and bogner March 19, 2025 23:33

bogner approved these changes Mar 19, 2025

View reviewed changes

joaosaffran added 2 commits March 19, 2025 16:55

Update DXContainer.rst

7dcad52

Update DXContainer.rst

a9260e5

joaosaffran merged commit d0d33d2 into llvm:main Mar 20, 2025
11 of 12 checks passed

joaosaffran deleted the documentation/static-samplers branch March 20, 2025 04:10

		};


		The StaticSamplerDesc structure defines all properties of a static sampler:

		shader visibility and its offset, and a data section. The parameters don't need to follow
		any specific order. Root parameters define the interface elements that shaders can access.

		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.

		dxbc::RootParameterType ParameterType;
		dxbc::ShaderVisibility ShaderVisibility;

		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.

		#. `RTS0`_ - Stores compiled root signature.
		#. `SFI0`_ - Stores shader feature flags.

	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)

	The tables are made of a collection of descriptor ranges. In Version 1.0, the
	The tables are made of an array of descriptor ranges. In Version 1.0, the

	The table bellow sumarizes the data being serialized as well as it's size. The
	The table below summarizes the data being serialized as well as it's size. The

[DirectX] Documenting Root Signature Binary representation #131011

[DirectX] Documenting Root Signature Binary representation #131011

Conversation

joaosaffran commented Mar 12, 2025 • edited Loading

llvmbot commented Mar 12, 2025

github-actions bot commented Mar 12, 2025

Choose a reason for hiding this comment

joaosaffran Mar 13, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

inbelic left a comment

Choose a reason for hiding this comment

inbelic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bogner left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bogner left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bogner left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

inbelic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bogner left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

llvm-ci commented Mar 20, 2025

joaosaffran commented Mar 12, 2025 •

edited

Loading

joaosaffran Mar 13, 2025 •

edited

Loading