Skip to content

Commit 8a37a92

Browse files
bharadwajybharadwajy
authored
Update DXIL.rst (microsoft#6080)
Update table with supported shader model name, major and minor version number. Replace "verifier" with "validator"
1 parent ab4c4e5 commit 8a37a92

File tree

1 file changed

+38
-36
lines changed

1 file changed

+38
-36
lines changed

‎docs/DXIL.rst

Lines changed: 38 additions & 36 deletions
Original file line numberDiff line numberDiff line change
@@ -15,9 +15,9 @@ Prior to being converted into the low-level DXIL IR, a higher level IR is genera
1515

1616
LLVM is quickly becoming a de facto standard in modern compilation technology. The LLVM framework offers several distinct features, such as a vibrant ecosystem, complete compilation framework, modular design, and reasonable documentation. We can leverage these to achieve two important objectives.
1717

18-
First, unification of shader compilation tool chain. DXIL is a contract between IR producers, such as compilers for HLSL and other domain-specific languages, and IR consumers, such as IHV driver JIT compilers or offline XBOX shader compiler. In addition, the design provides for conversion the current HLSL IL, called DXBC IL in this document, to DXIL.
18+
First, unification of shader compilation tool chain. DXIL is a contract between IR producers, such as compilers for HLSL and other domain-specific languages, and IR consumers, such as IHV driver JIT compilers or offline XBOX shader compiler. In addition, the design provides for conversion of the legacy HLSL IL, called DXBC IL in this document, to DXIL.
1919

20-
Second, leveraging the LLVM ecosystem. Microsoft will publicly document DXIL to attract domain language implementers and spur innovation. Using LLVM-based IR offers reduced entry costs for small teams, simply because small teams are likely to use LLVM and Clang as their main compilation framework. We will provide DXIL verifier to check consistency of generated DXIL.
20+
Second, leveraging the LLVM ecosystem. Microsoft will publicly document DXIL to attract domain language implementers and spur innovation. Using LLVM-based IR offers reduced entry costs for small teams, simply because small teams are likely to use LLVM and Clang as their main compilation framework. We will provide DXIL validator to check consistency of generated DXIL.
2121

2222
The following diagram shows how some of these components tie together::
2323

@@ -44,9 +44,9 @@ The following diagram shows how some of these components tie together::
4444
+------------+----------------------+-----------+
4545
| |
4646
v v
47-
Driver Compiler Verifier
47+
Driver Compiler Validator
4848

49-
The *dxbc2dxil* element in the diagram is a component that converts existing DXBC shader byte code into DXIL. The *Optimizer* element is a component that consumes the high level IR, verifies it is valid, optimizes it, and produces a valid DXIL form. The *Verifier* element is a public component that verifies and signs DXIL. The *Linker* is a component that combines precompiled DXIL libraries with the entry function to produce a valid shader.
49+
The *dxbc2dxil* element in the diagram is a component that converts existing DXBC shader byte code into DXIL. The *Optimizer* element is a component that consumes the high level IR, verifies it is valid, optimizes it, and produces a valid DXIL form. The *Validator* element is a public component that verifies and signs DXIL. The *Linker* is a component that combines precompiled DXIL libraries with the entry function to produce a valid shader.
5050

5151
DXIL does not support the following HLSL features that were present in prior implementations.
5252

@@ -69,17 +69,21 @@ The following principles are used to ease reuse with LLVM components and aid ext
6969
* Additional information is conveyed via metadata, LLVM intrinsics or external functions.
7070
* Name prefixes: 'llvm.dx.', 'llvm.dxil.', 'dx.', and 'dxil.' are reserved.
7171

72-
LLVM IR has three equivalent forms: human-readable, binary (bitcode), and in-memory. DXIL is a binary format and is based on a subset of LLVM IR bitcode format. The document uses only human-readable form to describe DXIL.
73-
7472
Versioning
7573
==========
7674

7775
There are three versioning mechanisms in DXIL shaders: shader model, DXIL version, and LLVM bitcode version.
7876

79-
At a high-level, the shader model describes the target execution model and environment; DXIL provides a mechanism to express programs (including rules around expressing data types and operations); and LLVM bitcode provides a way to encode a DXIL program.
77+
At a high-level, the shader model describes the target execution model and environment.
8078

81-
Shader Model
82-
------------
79+
DXIL defines the rules for expressing Direct3D shader programs using a subset of standard LLVM IR. LLVM IR has three equivalent forms: human-readable, binary (bitcode), and in-memory. DXIL programs are encoded using a subset of LLVM IR bitcode format. This document uses only human-readable form to describe DXIL.
80+
81+
DXIL versioning allows for changes to the rules over time. The LLVM bitcode version is currently fixed at LLVM 3.7 for all DXIL versions.
82+
83+
A given DXIL version can support up to the latest shader model defined at the time that DXIL version was finalized. However, the DXIL version for a shader is typically set based on the shader model to ensure that any device supporting that particular shader model will be able to interpret the DXIL properly, without needing to know about any newer DXIL versions.
84+
85+
Shader Model (SM)
86+
-----------------
8387

8488
The shader model in DXIL is similar to DXBC shader model. A shader model specifies the execution model, the set of capabilities that shader instructions can use and the constraints that a shader program must adhere to.
8589

@@ -90,31 +94,29 @@ The shader model is specified as a named metadata in DXIL::
9094

9195
The following values of ``<shaderModelName>``, ``<major>``, ``<minor>`` are supported:
9296

93-
+-----------------------+---------------------------------------+-------------+
94-
| Target | Legacy Models | DXIL Models |
95-
+=======================+=======================================+=============+
96-
| Vertex shader (VS) | vs_4_0, vs_4_1, vs_5_0, vs_5_1 | vs_6_0 |
97-
+-----------------------+---------------------------------------+-------------+
98-
| Hull shader (HS) | hs_5_0, hs_5_1 | hs_6_0 |
99-
+-----------------------+---------------------------------------+-------------+
100-
| Domain shader (DS) | ds_5_0, ds_5_1 | ds_6_0 |
101-
+-----------------------+---------------------------------------+-------------+
102-
| Geometry shader (GS) | gs_4_0, gs_4_1, gs_5_0, gs_5_1 | gs_6_0 |
103-
+-----------------------+---------------------------------------+-------------+
104-
| Pixel shader (PS) | ps_4_0, ps_4_1, ps_5_0, ps_5_1 | ps_6_0 |
105-
+-----------------------+---------------------------------------+-------------+
106-
| Compute shader (CS) | cs_5_0 (cs_4_0 is mapped onto cs_5_0) | cs_6_0 |
107-
+-----------------------+---------------------------------------+-------------+
108-
| Shader library | no support | lib_6_1 |
109-
+-----------------------+---------------------------------------+-------------+
110-
| Mesh shader (MS) | no support | ms_6_5 |
111-
+-----------------------+---------------------------------------+-------------+
112-
| Amplification shader (AS) | no support | as_6_5 |
113-
+-----------------------+---------------------------------------+-------------+
114-
115-
The DXIL verifier ensures that DXIL conforms to the specified shader model.
116-
117-
For shader models prior to 6.0, only the rules applicable to the DXIL representation are valid. For example, the limits on maximum number of resources is honored, but the limits on registers aren't because DXIL does not have a representation for registers.
97+
+---------------------------+------------------------------+----------------------+
98+
| Shader Tyoe | shaderModelName | Minimum major, minor |
99+
+===========================+==============================+======================+
100+
| Vertex shader (VS) | vs | 6, 0 |
101+
+---------------------------+------------------------------+----------------------+
102+
| Hull shader (HS) | hs | 6, 0 |
103+
+---------------------------+------------------------------+----------------------+
104+
| Domain shader (DS) | ds | 6, 0 |
105+
+---------------------------+------------------------------+----------------------+
106+
| Geometry shader (GS) | gs | 6, 0 |
107+
+---------------------------+------------------------------+----------------------+
108+
| Pixel shader (PS) | ps | 6, 0 |
109+
+---------------------------+------------------------------+----------------------+
110+
| Compute shader (CS) | cs | 6, 0 |
111+
+---------------------------+------------------------------+----------------------+
112+
| Mesh shader (MS) | ms | 6, 5 |
113+
+---------------------------+------------------------------+----------------------+
114+
| Amplification shader (AS) | as | 6, 5 |
115+
+---------------------------+------------------------------+----------------------+
116+
| DXIL library | lib | 6, 3 |
117+
+---------------------------+------------------------------+----------------------+
118+
119+
The DXIL validator ensures that DXIL conforms to the specified shader model.
118120

119121
DXIL version
120122
------------
@@ -1240,7 +1242,7 @@ Both indices can be dynamic for SM6 and later to provide flexibility in usage of
12401242

12411243
Resources/samplers used in such a way must reside in descriptor tables (cannot be root descriptors); this will be validated during shader and root signature setup.
12421244

1243-
The DXIL verifier will ensure that all leaf-ranges (a and b above) of such a resource/sampler live-range have the same resource/sampler type and element type. If applicable, this constraint may be relaxed in the future. In particular, it is logical from HLSL programmer point of view to issue loads on compatible resource types, e.g., Texture2D, RWTexture2D, ROVTexture2D::
1245+
The DXIL validator will ensure that all leaf-ranges (a and b above) of such a resource/sampler live-range have the same resource/sampler type and element type. If applicable, this constraint may be relaxed in the future. In particular, it is logical from HLSL programmer point of view to issue loads on compatible resource types, e.g., Texture2D, RWTexture2D, ROVTexture2D::
12441246

12451247
Texture2D<float4> a[8];
12461248
RWTexture2D<float4> b[6];
@@ -1965,7 +1967,7 @@ TODO: enumerate all additional resource range properties, e.g., ROV, Texture2DMS
19651967

19661968
Operations
19671969
==========
1968-
DXIL operations are represented in two ways: using LLVM instructions and using LLVM external functions. The reference list of operations as well as their overloads can be found in the attached Excel spreadsheet "DXIL Operations".
1970+
DXIL operations are represented in two ways: using LLVM instructions and using LLVM external functions.
19691971

19701972
Operations via instructions
19711973
---------------------------

0 commit comments

Comments
 (0)