© Copyright 2014-2020 The Khronos Group Inc. All Rights Reserved.
© Copyright 2014-2020 The Khronos Group Inc. All Rights Reserved.
This specification is protected by copyright laws and contains material proprietary to the Khronos Group, Inc. It or any components may not be reproduced, republished, distributed, transmitted, displayed, broadcast, or otherwise exploited in any manner without the express prior written permission of Khronos Group. You may use this specification for implementing the functionality therein, without altering or removing any trademark, copyright or other notice from the specification, but the receipt or possession of this specification does not convey any rights to reproduce, disclose, or distribute its contents, or to manufacture, use, or sell anything that it may describe, in whole or in part.
Khronos Group grants express permission to any current Promoter, Contributor or Adopter member of Khronos to copy and redistribute UNMODIFIED versions of this specification in any fashion, provided that NO CHARGE is made for the specification and the latest available update of the specification for any version of the API is used whenever possible. Such distributed specification may be reformatted AS LONG AS the contents of the specification are not changed in any way. The specification may be incorporated into a product that is sold as long as such product includes significant independent work developed by the seller. A link to the current version of this specification on the Khronos Group website should be included whenever possible with specification distributions.
Khronos Group makes no, and expressly disclaims any, representations or warranties, express or implied, regarding this specification, including, without limitation, any implied warranties of merchantability or fitness for a particular purpose or noninfringement of any intellectual property. Khronos Group makes no, and expressly disclaims any, warranties, express or implied, regarding the correctness, accuracy, completeness, timeliness, and reliability of the specification. Under no circumstances will the Khronos Group, or any of its Promoters, Contributors or Members or their respective partners, officers, directors, employees, agents, or representatives be liable for any damages, whether direct, indirect, special or consequential damages for lost revenues, lost profits, or otherwise, arising from or in connection with these materials.
Khronos, SYCL, SPIR, WebGL, EGL, COLLADA, StreamInput, OpenVX, OpenKCam, glTF, OpenKODE, OpenVG, OpenWF, OpenSL ES, OpenMAX, OpenMAX AL, OpenMAX IL and OpenMAX DL are trademarks and WebCL is a certification mark of the Khronos Group Inc. OpenCL is a trademark of Apple Inc. and OpenGL and OpenML are registered trademarks and the OpenGL ES and OpenGL SC logos are trademarks of Silicon Graphics International used under license by Khronos. All other product names, trademarks, and/or company names are used solely for identification and belong to their respective owners.
Contributors and Acknowledgments
Connor Abbott, Intel
Ben Ashbaugh, Intel
Alexey Bader, Intel
Alan Baker, Google
Dan Baker, Oxide Games
Kenneth Benzie, Codeplay
Gordon Brown, Codeplay
Pat Brown, NVIDIA
Diana Po-Yu Chen, MediaTek
Stephen Clarke, Imagination
Patrick Doane, Blizzard Entertainment
Stefanus Du Toit, Google
Tim Foley, Intel
Ben Gaster, Qualcomm
Alexander Galazin, ARM
Christopher Gautier, ARM
Neil Henning, AMD
Kerch Holt, NVIDIA
Lee Howes, Qualcomm
Roy Ju, MediaTek
Ronan Keryell, Xilinx
John Kessenich, Google
Daniel Koch, NVIDIA
Ashwin Kolhe, NVIDIA
Raun Krisch, Intel
Graeme Leese, Broadcom
Yuan Lin, NVIDIA
Yaxun Liu, AMD
Victor Lomuller, Codeplay
Timothy Lottes, Epic Games
John McDonald, Valve
Mariusz Merecki, Intel
David Neto, Google
Boaz Ouriel, Intel
Christophe Riccio, Unity
Andrew Richards, Codeplay
Ian Romanick, Intel
Graham Sellers, AMD
Robert Simpson, Qualcomm
Bartosz Sochacki, Intel
Nikos Stavropoulos, Think Silicon
Brian Sumner, AMD
Andrew Woloszyn, Google
Ruihao Zhang, Qualcomm
Weifeng Zhang, Qualcomm
Note
|
Up-to-date HTML and PDF versions of this specification may be found at the Khronos SPIR-V Registry. (https://www.khronos.org/registry/spir-v/) |
1. Introduction
Abstract
SPIR-V is a simple binary intermediate language for graphical shaders and compute kernels. A SPIR-V module contains multiple entry points with potentially shared functions in the entry point’s call trees. Each function contains a control-flow graph (CFG) of basic blocks, with optional instructions to express structured control flow. Load/store instructions are used to access declared variables, which includes all input/output (IO). Intermediate results bypassing load/store use static single-assignment (SSA) representation. Data objects are represented logically, with hierarchical type information: There is no flattening of aggregates or assignment to physical register banks, etc. Selectable addressing models establish whether general pointer operations may be used, or if memory access is purely logical.
This document fully defines SPIR-V, a Khronos-standard binary intermediate language for representing graphical-shader stages and compute kernels for multiple client APIs.
This is a unified specification, specifying all versions since and including version 1.0.
1.1. Goals
SPIR-V has the following goals:
-
Provide a simple binary intermediate language for all functionality appearing in Khronos shaders/kernels.
-
Have a concise, transparent, self-contained specification (sections Specification and Binary Form).
-
Map easily to other intermediate languages.
-
Be the form passed by a client API into a driver to set shaders/kernels.
-
Support multiple execution environments, specified by client APIs.
-
Can be targeted by new front ends for novel high-level languages.
-
Allow the first steps of compilation and reflection to be done offline.
-
Be low-level enough to require a reverse-engineering step to reconstruct source code.
-
Improve portability by enabling shared tools to generate or operate on it.
-
Reduce compile time during application run time. (Eliminating most of the compile time during application run time is not a goal of this intermediate language. Target-specific register allocation and scheduling are still expected to take significant time.)
-
Allow some optimizations to be done offline.
1.2. Execution Environment and Client API
SPIR-V is adaptable to multiple execution environments: A SPIR-V module is consumed by an execution environment, as specified by a client API. The full set of rules needed to consume SPIR-V in a particular environment comes from the combination of SPIR-V and that environment’s client API specification. The client API specifies its SPIR-V execution environment as well as extra rules, limitations, capabilities, etc. required by the form of SPIR-V it can validly consume.
1.3. About This Document
This document aims to:
-
Specify everything needed to create and consume non-extended SPIR-V, minus:
-
Extended instruction sets, which are imported and come with their own specifications.
-
Client API-specific rules, which are documented in client API specifications.
-
-
Separate expository and specification language. The specification-proper is in Specification and Binary Form.
1.3.1. Versioning
The specification covers multiple versions of SPIR-V, as described in the unified section. It has followed a Major.Minor.Revision versioning scheme, with the specification’s stated version being the most recent version of SPIR-V.
Major and Minor (but not Revision) are declared within a SPIR-V module.
Major is reserved for future use and has been fixed at 1. Minor changes have signified additions, deprecation, and removal of features. Revision changes have included clarifications, bug fixes, and deprecation (but not removal) of existing features.
1.4. Extendability
SPIR-V can be extended by multiple vendors or parties simultaneously:
-
Using the OpExtension instruction to add semantics, which are described in an extension specification.
-
Reserving (registering) ranges of the token values, as described further below.
-
Aided by instruction skipping, also further described below.
Enumeration Token Values. It is easy to extend all the types, storage classes, opcodes, decorations, etc. by adding to the token values.
Registration. Ranges of token values in the Binary Form section can be pre-allocated to numerous vendors/parties. This allows combining multiple independent extensions without conflict. To register ranges, use the https://github.com/KhronosGroup/SPIRV-Headers repository, and submit pull requests against the include/spirv/spir-v.xml file.
Extended Instructions. Sets of extended instructions can be provided and specified in separate specifications. Multiple sets of extended instructions can be imported without conflict, as the extended instructions are selected by {set id, instruction number} pairs.
Instruction Skipping. Tools are encouraged to skip opcodes for features they are not required to process. This is trivially enabled by the word count in an instruction, which makes it easier to add new instructions without breaking existing tools.
1.5. Debuggability
SPIR-V can decorate, with a text string, virtually anything created in the shader: types, variables, functions, etc. This is required for externally visible symbols, and also allowed for naming the result of any instruction. This can be used to aid in understandability when disassembling or debugging lowered versions of SPIR-V.
Location information (file names, lines, and columns) can be interleaved with the instruction stream to track the origin of each instruction.
1.6. Design Principles
Regularity. All instructions start with a word count. This allows walking a SPIR-V module without decoding each opcode. All instructions have an opcode that dictates for all operands what kind of operand they are. For instructions with a variable number of operands, the number of variable operands is known by subtracting the number of non-variable words from the instruction’s word count.
Non Combinatorial. There is no combinatorial type explosion or need for large encode/decode tables for types. Rather, types are parameterized. Image types declare their dimensionality, arrayness, etc. all orthogonally, which greatly simplify code. This is done similarly for other types. It also applies to opcodes. Operations are orthogonal to scalar/vector size, but not to integer vs. floating-point differences.
Modeless. After a given execution model (e.g., pipeline stage) is specified, internal operation is essentially modeless: Generally, it follows the rule: "same spelling, same semantics", and does not have mode bits that modify semantics. If a change to SPIR-V modifies semantics, it should use a different spelling. This makes consumers of SPIR-V much more robust. There are execution modes declared, but these generally affect the way the module interacts with its execution environment, not its internal semantics. Capabilities are also declared, but this is to declare the subset of functionality that is used, not to change any semantics of what is used.
Declarative. SPIR-V declares externally-visible modes like "writes depth", rather than having rules that require deduction from full shader inspection. It also explicitly declares what addressing modes, execution model, extended instruction sets, etc. will be used. See Language Capabilities for more information.
SSA. All results of intermediate operations are strictly SSA. However, declared variables reside in memory and use load/store for access, and such variables can be stored to multiple times.
IO. Some storage classes are for input/output (IO) and, fundamentally, IO is done through load/store of variables declared in these storage classes.
1.7. Static Single Assignment (SSA)
SPIR-V includes a phi instruction to allow the merging together of intermediate results from split control flow. This allows split control flow without load/store to memory. SPIR-V is flexible in the degree to which load/store is used; it is possible to use control flow with no phi-instructions, while still staying in SSA form, by using memory load/store.
Some storage classes are for IO and, fundamentally, IO is done through load/store, and initial load and final store won’t be eliminated. Other storage classes are shader local and can have their load/store eliminated. It can be considered an optimization to largely eliminate such loads/stores by moving them into intermediate results in SSA form.
1.8. Built-In Variables
SPIR-V identifies built-in variables from a high-level language with an enumerant decoration. This assigns any unusual semantics to the variable. Built-in variables are otherwise declared with their correct SPIR-V type and treated the same as any other variable.
1.9. Specialization
Specialization enables offline creation of a portable SPIR-V module based on constant values that won’t be known until a later point in time. For example, to size a fixed array with a constant not known during creation of a module, but known when the module will be lowered to the target architecture.
See Specialization in the next section for more details.
1.10. Example
The SPIR-V form is binary, not human readable, and fully described in Binary Form. This is an example disassembly to give a basic idea of what SPIR-V looks like:
GLSL fragment shader:
#version 450 in vec4 color1; in vec4 multiplier; noperspective in vec4 color2; out vec4 color; struct S { bool b; vec4 v[5]; int i; }; uniform blockName { S s; bool cond; }; void main() { vec4 scale = vec4(1.0, 1.0, 2.0, 1.0); if (cond) color = color1 + s.v[2]; else color = sqrt(color2) * scale; for (int i = 0; i < 4; ++i) color *= multiplier; }
Corresponding SPIR-V:
; Magic: 0x07230203 (SPIR-V) ; Version: 0x00010000 (Version: 1.0.0) ; Generator: 0x00080001 (Khronos Glslang Reference Front End; 1) ; Bound: 63 ; Schema: 0 OpCapability Shader %1 = OpExtInstImport "GLSL.std.450" OpMemoryModel Logical GLSL450 OpEntryPoint Fragment %4 "main" %31 %33 %42 %57 OpExecutionMode %4 OriginLowerLeft ; Debug information OpSource GLSL 450 OpName %4 "main" OpName %9 "scale" OpName %17 "S" OpMemberName %17 0 "b" OpMemberName %17 1 "v" OpMemberName %17 2 "i" OpName %18 "blockName" OpMemberName %18 0 "s" OpMemberName %18 1 "cond" OpName %20 "" OpName %31 "color" OpName %33 "color1" OpName %42 "color2" OpName %48 "i" OpName %57 "multiplier" ; Annotations (non-debug) OpDecorate %15 ArrayStride 16 OpMemberDecorate %17 0 Offset 0 OpMemberDecorate %17 1 Offset 16 OpMemberDecorate %17 2 Offset 96 OpMemberDecorate %18 0 Offset 0 OpMemberDecorate %18 1 Offset 112 OpDecorate %18 Block OpDecorate %20 DescriptorSet 0 OpDecorate %42 NoPerspective ; All types, variables, and constants %2 = OpTypeVoid %3 = OpTypeFunction %2 ; void () %6 = OpTypeFloat 32 ; 32-bit float %7 = OpTypeVector %6 4 ; vec4 %8 = OpTypePointer Function %7 ; function-local vec4* %10 = OpConstant %6 1 %11 = OpConstant %6 2 %12 = OpConstantComposite %7 %10 %10 %11 %10 ; vec4(1.0, 1.0, 2.0, 1.0) %13 = OpTypeInt 32 0 ; 32-bit int, sign-less %14 = OpConstant %13 5 %15 = OpTypeArray %7 %14 %16 = OpTypeInt 32 1 %17 = OpTypeStruct %13 %15 %16 %18 = OpTypeStruct %17 %13 %19 = OpTypePointer Uniform %18 %20 = OpVariable %19 Uniform %21 = OpConstant %16 1 %22 = OpTypePointer Uniform %13 %25 = OpTypeBool %26 = OpConstant %13 0 %30 = OpTypePointer Output %7 %31 = OpVariable %30 Output %32 = OpTypePointer Input %7 %33 = OpVariable %32 Input %35 = OpConstant %16 0 %36 = OpConstant %16 2 %37 = OpTypePointer Uniform %7 %42 = OpVariable %32 Input %47 = OpTypePointer Function %16 %55 = OpConstant %16 4 %57 = OpVariable %32 Input ; All functions %4 = OpFunction %2 None %3 ; main() %5 = OpLabel %9 = OpVariable %8 Function %48 = OpVariable %47 Function OpStore %9 %12 %23 = OpAccessChain %22 %20 %21 ; location of cond %24 = OpLoad %13 %23 ; load 32-bit int from cond %27 = OpINotEqual %25 %24 %26 ; convert to bool OpSelectionMerge %29 None ; structured if OpBranchConditional %27 %28 %41 ; if cond %28 = OpLabel ; then %34 = OpLoad %7 %33 %38 = OpAccessChain %37 %20 %35 %21 %36 ; s.v[2] %39 = OpLoad %7 %38 %40 = OpFAdd %7 %34 %39 OpStore %31 %40 OpBranch %29 %41 = OpLabel ; else %43 = OpLoad %7 %42 %44 = OpExtInst %7 %1 Sqrt %43 ; extended instruction sqrt %45 = OpLoad %7 %9 %46 = OpFMul %7 %44 %45 OpStore %31 %46 OpBranch %29 %29 = OpLabel ; endif OpStore %48 %35 OpBranch %49 %49 = OpLabel OpLoopMerge %51 %52 None ; structured loop OpBranch %53 %53 = OpLabel %54 = OpLoad %16 %48 %56 = OpSLessThan %25 %54 %55 ; i < 4 ? OpBranchConditional %56 %50 %51 ; body or break %50 = OpLabel ; body %58 = OpLoad %7 %57 %59 = OpLoad %7 %31 %60 = OpFMul %7 %59 %58 OpStore %31 %60 OpBranch %52 %52 = OpLabel ; continue target %61 = OpLoad %16 %48 %62 = OpIAdd %16 %61 %21 ; ++i OpStore %48 %62 OpBranch %49 ; loop back %51 = OpLabel ; loop merge point OpReturn OpFunctionEnd
2. Specification
2.1. Language Capabilities
A SPIR-V module is consumed by a client API that needs to support the features used by that SPIR-V module. Features are classified through capabilities. Capabilities used by a particular SPIR-V module are declared early in that module with the OpCapability instruction. Then:
-
A validator can validate that the module uses only its declared capabilities.
-
A client API is allowed to reject modules declaring capabilities it does not support.
All available capabilities and their dependencies form a capability hierarchy, fully listed in the capability section. Only top-level capabilities need to be explicitly declared; their dependencies are implicitly declared.
If an instruction, enumerant, or other feature specifies multiple enabling capabilities, only one such capability needs to be declared to use the feature. This declaration does not itself imply anything about the presence of the other enabling capabilities: The execution environment needs to support only the declared capability.
The SPIR-V specification provides universal capability-specific validation rules, in the validation section. Additionally, each client API includes the following:
-
Which capabilities in the capability section it supports or requires, and hence allows in a SPIR-V module.
-
Any additional validation rules it has beyond those specified by the SPIR-V specification.
-
Required limits, if they are beyond the Universal Limits.
2.2. Terms
2.2.1. Instructions
<id>: A numerical name; the name used to refer to an object, a type, a function, a label, etc. An <id> always consumes one word. The <id>s defined by a module obey SSA.
Result <id>: Most instructions define a result, named by an <id> explicitly provided in the instruction. The Result <id> is used as an operand in other instructions to refer to the instruction that defined it.
Literal: An immediate value, not an <id>. Literals larger than one word consume multiple operands, one per word. An instruction states what type the literal will be interpreted as. A string is interpreted as a nul-terminated stream of characters. The character set is Unicode in the UTF-8 encoding scheme. The UTF-8 octets (8-bit bytes) are packed four per word, following the little-endian convention (i.e., the first octet is in the lowest-order 8 bits of the word). The final word contains the string’s nul-termination character (0), and all contents past the end of the string in the final word are padded with 0. For a numeric literal, the lower-order words appear first. If a numeric type’s bit width is less than 32-bits, the value appears in the low-order bits of the word, and the high-order bits must be 0 for a floating-point type or integer type with Signedness of 0, or sign extended for an integer type with a Signedness of 1 (similarly for the remaining bits of widths larger than 32 bits but not a multiple of 32 bits).
Operand: A one-word argument to an instruction. E.g., it could be an <id>, or (or part of) a literal. Which form it holds is always explicitly known from the opcode.
WordCount: The complete number of words taken by an instruction, including the word holding the word count and opcode, and any optional operands. An instruction’s word count is the total space taken by the instruction.
Instruction: After a header, a module is simply a linear list of instructions. An instruction contains a word count, an opcode, an optional Result <id>, an optional <id> of the instruction’s type, and a variable list of operands. All instruction opcodes and semantics are listed in Instructions.
Decoration: Auxiliary information such as built-in variable, stream numbers, invariance, interpolation type, relaxed precision, etc., added to <id>s or structure-type members through Decorations. Decorations are enumerated in Decoration in the Binary Form section.
Object: An instantiation of a non-void type, either as the Result <id> of an operation, or created through OpVariable.
Memory Object: An object created through OpVariable. Such an object exists only for the duration of a function if it is a function variable, and otherwise exists for the duration of an invocation.
Memory Object Declaration: An OpVariable, or an OpFunctionParameter of pointer type, or the contents of an OpVariable that holds either a pointer to the PhysicalStorageBuffer storage class or an array of such pointers.
Intermediate Object or Intermediate Value or Intermediate Result: An object created by an operation (not memory allocated by OpVariable) and dying on its last consumption.
2.2.2. Types
Boolean type: The type declared by OpTypeBool.
Integer type: Any width signed or unsigned type from OpTypeInt. By convention, the lowest-order bit is referred to as bit-number 0, and the highest-order bit as bit-number Width - 1.
Floating-point type: Any width type from OpTypeFloat.
Numerical type: An integer type or a floating-point type.
Scalar: A single instance of a numerical type or Boolean type. Scalars are also called components when being discussed either by themselves or in the context of the contents of a vector.
Vector: An ordered homogeneous collection of two or more scalars. Vector sizes are quite restrictive and dependent on the execution model.
Matrix: An ordered homogeneous collection of vectors. The vectors forming a matrix are also called its columns. Matrix sizes are quite restrictive and dependent on the execution model.
Array: An ordered homogeneous aggregate of any non-void-type objects. The objects forming an array are also called its elements. Array sizes are generally not restricted.
Structure: An ordered heterogeneous aggregate of any non-void types. The objects forming a structure are also called its members.
Image: A traditional texture or image; SPIR-V has this single name for these. An image type is declared with OpTypeImage. An image does not include any information about how to access, filter, or sample it.
Sampler: Settings that describe how to access, filter, or sample an image. Comes either from literal declarations of settings or from an opaque reference to externally bound settings. A sampler does not include an image.
Sampled Image: An image combined with a sampler, enabling filtered accesses of the image’s contents.
Physical Pointer Type: An OpTypePointer whose Storage Class uses physical addressing according to the addressing model.
Logical Pointer Type: A pointer type that is not a physical pointer type.
Concrete Type: A numerical scalar, vector, or matrix type, or physical pointer type, or any aggregate containing only these types.
Abstract Type: An OpTypeVoid or OpTypeBool, or logical pointer type, or any aggregate type containing any of these.
Opaque Type: A type that is, or contains, or points to, or contains pointers to, any of the following types:
Variable pointer: A pointer of logical pointer type that results from one of the following instructions:
Additionally, any OpAccessChain, OpInBoundsAccessChain, or OpCopyObject that takes a variable pointer as an operand also produces a variable pointer. An OpFunctionParameter of pointer type is a variable pointer if any OpFunctionCall to the function statically passes a variable pointer as the value of the parameter.
2.2.3. Computation
2.2.4. Module
Module: A single unit of SPIR-V. It can contain multiple entry points, but only one set of capabilities.
Entry Point: A function in a module where execution begins. A single entry point is limited to a single execution model. An entry point is declared using OpEntryPoint.
Execution Model: A graphical-pipeline stage or OpenCL kernel. These are enumerated in Execution Model.
Execution Mode: Modes of operation relating to the interface or execution environment of the module. These are enumerated in Execution Mode. Generally, modes do not change the semantics of instructions within a SPIR-V module.
2.2.5. Control Flow
Block: A contiguous sequence of instructions starting with an OpLabel, ending with a termination instruction. A block has no additional label or termination instructions.
Branch Instruction: One of the following, used as a termination instruction:
Dominate: A block A dominates a block B, where A and B are in the same function, if every path from the function’s entry point to block B includes block A. A strictly dominates B only if A dominates B and A and B are different blocks.
Post Dominate: A block B post dominates a block A, where A and B are in the same function, if every path from A to a function-return instruction goes through block B.
Control-Flow Graph: The graph formed by a function’s blocks and branches. The blocks are the graph’s nodes, and the branches the graph’s edges.
CFG: Control-flow graph.
Back Edge: A branch is a back edge if there is a depth-first search starting at the entry block of the
CFG where the branch branches to one of its ancestors.
A back-edge block is a block containing such a branch instruction.
Note: For a given function, if all its loops are structured, then each back edge corresponds to exactly one loop
header, and vice versa.
So the set of back-edges in the function is unique, regardless of the depth-first search used to find them.
This is equivalent to the function’s CFG being reducible.
Merge Instruction: One of the following, used before a branch instruction to declare structured control flow:
Header Block: A block containing a merge instruction.
Loop Header: A header block whose merge instruction is an OpLoopMerge.
Merge Block: A block declared by the Merge Block operand of a merge instruction.
Break Block: A block containing a branch to the Merge Block of a loop header’s merge instruction.
Continue Block: A block containing a branch to an OpLoopMerge instruction’s Continue Target.
Return Block: A block containing an OpReturn or OpReturnValue branch.
Invocation: A single execution of an entry point in a SPIR-V module, operating only on the amount of data explicitly exposed by the semantics of the instructions. (Any implicit operation on additional instances of data would comprise additional invocations.) For example, in compute execution models, a single invocation operates only on a single work item, or, in a vertex execution model, a single invocation operates only on a single vertex.
Quad: The execution environment can partition invocations into quads, where invocations within a quad can synchronize and share data with each other efficiently. See the client API specification for more details.
Subgroup: Invocations are partitioned into subgroups, where invocations within a subgroup can synchronize and share data with each other efficiently. In compute models, the current workgroup is a superset of the subgroup.
Invocation Group: The complete set of invocations collectively processing a particular compute workgroup or graphical operation, where the scope of a "graphical operation" is implementation dependent, but at least as large as a single point, line, triangle, or patch, and at most as large as a single rendering command, as defined by the client API.
Derivative Group: Defined only for the Fragment Execution Model: The set of invocations collectively processing derivatives, which is at most as large as a single point, line, or triangle, including any helper invocations, as defined by the client API.
-
Image instructions that consume an implicit derivative
Tangled instructions communicate between invocations.
Dynamic Instance: Within a single invocation, a single static instruction can be executed multiple times, giving multiple dynamic instances of that instruction. This can happen if the instruction is executed in a loop, or in a function called from multiple call sites, or combinations of multiple of these. Different loop iterations and different dynamic function-call-site chains yield different dynamic instances of such an instruction.
Additionally, a single dynamic instance may be executed by multiple invocations. Only tangled instructions are required to execute the dynamic instance as if all invocations that communicate together and share the same dynamic instance execute simultaneously. Invocations that execute the same dynamic instance of an instruction will continue to execute the same dynamic instances as long as they follow the same control flow path. A dynamic instance of an instruction, tangled or not, is executed by one or more invocations.
Dynamically Uniform: An <id> is dynamically uniform for a dynamic instance consuming it if its value is the same for all invocations (in the invocation group, unless otherwise stated) that execute that dynamic instance.
Uniform Control Flow: Uniform control flow (or converged control flow) occurs if all invocations (in the invocation group, unless otherwise stated) execute the same dynamic instance of an instruction. Uniform control flow is the initial state at the entry point, and lasts until a conditional branch takes different control paths for different invocations (non-uniform or divergent control flow). Such divergence can reconverge, with all the invocations once again executing the same control-flow path, and this re-establishes the existence of uniform control flow. If control flow is uniform upon entry into a structured loop or selection, and all invocations leave that loop or selection via the header block’s declared merge block, then control flow reconverges to be uniform at that merge block.
2.2.6. Validity and Defined Behavior
Most SPIR-V rules are expressed statically. These statically expressed rules are based on what can be seen with a direct static examination of the module in the specific places the rule says to look. These are expressed using terms like must, must not, valid, not valid, and invalid. Such rules establish whether the module is classified as valid or not valid, which in turn provides terms that tools may use in labeling and describing modules they process. A module is valid only if it does not violate any of these statically expressed rules. Such rules might not be considered violated if a specialization constant is involved, as described in the specialization constant section.
Some SPIR-V rules say that behavior is not defined, that something results in undefined behavior, or that behavior is defined only under some circumstances. These all refer only to something that happens dynamically while an invocation of a shader or kernel executes.
An invocation having undefined behavior is independent of a module being valid. Tools containing smart transforms may be able to deduce from a static module that behavior will be undefined if some part were to be executed. However, this does not allow the tool to classify the module as invalid.
Sometimes, SPIR-V refers to the client API to specify what is statically valid or dynamically defined for a specific situation, in which case those rules come from the client API’s execution environment. Otherwise, a SPIR-V client API can define an execution environment that adds additional statically expressed rules, further constraining what SPIR-V itself said was valid. However, a client cannot remove any such statically expressed rules. A client will not remove any undefined behavior specified by SPIR-V.
2.3. Physical Layout of a SPIR-V Module and Instruction
A SPIR-V module is a single linear stream of words. The first words are shown in the following table:
Word Number | Contents |
---|---|
0 |
|
1 |
Version number. The bytes are, high-order to low-order: 0 | Major Number | Minor Number | 0 Hence, version 1.3 is the value 0x00010300. |
2 |
Generator’s magic number. It is associated with the tool that generated the module. Its value does not affect any semantics, and is allowed to be 0. Using a non-0 value is encouraged, and can be registered with Khronos at https://github.com/KhronosGroup/SPIRV-Headers. |
3 |
Bound; where all <id>s in this module are guaranteed to satisfy 0 < id < Bound Bound should be small, smaller is better, with all <id> in a module being densely packed and near 0. |
4 |
0 (Reserved for instruction schema, if needed.) |
5 |
First word of instruction stream, see below. |
All remaining words are a linear sequence of instructions.
Each instruction is a stream of words:
Instruction Word Number | Contents |
---|---|
0 |
Opcode: The 16 high-order bits are the WordCount of the instruction. The 16 low-order bits are the opcode enumerant. |
1 |
Optional instruction type <id> (presence determined by opcode). |
. |
Optional instruction Result <id> (presence determined by opcode). |
. |
Operand 1 (if needed) |
. |
Operand 2 (if needed) |
… |
… |
WordCount - 1 |
Operand N (N is determined by WordCount minus the 1 to 3 words used for the opcode, instruction type <id>, and instruction Result <id>). |
Instructions are variable length due both to having optional instruction type <id> and Result <id> words as well as a variable number of operands. The details for each specific instruction are given in the Binary Form section.
2.4. Logical Layout of a Module
The instructions of a SPIR-V module must be in the following order. For sections earlier than function definitions, it is invalid to use instructions other than those indicated.
-
All OpCapability instructions.
-
Optional OpExtension instructions (extensions to SPIR-V).
-
Optional OpExtInstImport instructions.
-
The single required OpMemoryModel instruction.
-
All entry point declarations, using OpEntryPoint.
-
All execution-mode declarations, using OpExecutionMode or OpExecutionModeId.
-
These debug instructions, which must be grouped in the following order:
-
All OpString, OpSourceExtension, OpSource, and OpSourceContinued, without forward references.
-
All OpName and all OpMemberName.
-
All OpModuleProcessed instructions.
-
-
All annotation instructions:
-
All decoration instructions.
-
-
All type declarations (OpTypeXXX instructions), all constant instructions, and all global variable declarations (all OpVariable instructions whose Storage Class is not Function). This is the preferred location for OpUndef instructions, though they can also appear in function bodies. All operands in all these instructions must be declared before being used. Otherwise, they can be in any order. This section is the first section to allow use of OpLine and OpNoLine debug information.
-
All function declarations ("declarations" are functions without a body; there is no forward declaration to a function with a body). A function declaration is as follows.
-
Function declaration, using OpFunction.
-
Function parameter declarations, using OpFunctionParameter.
-
Function end, using OpFunctionEnd.
-
-
All function definitions (functions with a body). A function definition is as follows.
-
Function definition, using OpFunction.
-
Function parameter declarations, using OpFunctionParameter.
-
Block.
-
Block.
-
…
-
Function end, using OpFunctionEnd.
-
Within a function definition:
-
A block always starts with an OpLabel instruction. This may be immediately preceded by an OpLine instruction, but the OpLabel is considered as the beginning of the block.
-
A block always ends with a termination instruction (see validation rules for more detail).
-
All OpVariable instructions in a function must have a Storage Class of Function.
-
All OpVariable instructions in a function must be in the first block in the function. These instructions, together with any intermixed OpLine and OpNoLine instructions, must be the first instructions in that block. (Note the validation rules prevent OpPhi instructions in the first block of a function.)
-
A function definition (starts with OpFunction) can be immediately preceded by an OpLine instruction.
Forward references (an operand <id> that appears before the Result <id> defining it) are allowed for:
-
Operands that are an OpFunction. This allows for recursion and early declaration of entry points.
-
Annotation-instruction operands. This is required to fully know everything about a type or variable once it is declared.
-
Labels.
-
OpPhi can contain forward references.
-
OpTypeForwardPointer:
-
An OpTypeForwardPointer Pointer Type is a forward reference to an OpTypePointer.
-
Subsequent consumption of an OpTypeForwardPointer Pointer Type can be a forward reference.
-
-
The list of <id> provided in the OpEntryPoint instruction.
In all cases, there is enough type information to enable a single simple pass through a module to transform it. For example, function calls have all the type information in the call, phi-functions don’t change type, and labels don’t have type. The pointer forward reference allows structures to contain pointers to themselves or to be mutually recursive (through pointers), without needing additional type information.
The Validation Rules section lists additional rules.
2.5. Instructions
Most instructions create a Result <id>, as provided in the Result <id> field of the instruction. These Result <id>s are then referred to by other instructions through their <id> operands. All instruction operands are specified in the Binary Form section.
Instructions are explicit about whether an operand is (or is part of) a self-contained literal or an <id> referring to another instruction’s result. While an <id> always takes one operand, one literal takes one or more operands. Some common examples of literals:
-
A literal 32-bit (or smaller) integer is always one operand directly holding a 32-bit two’s-complement value.
-
A literal 32-bit float is always one operand, directly holding a 32-bit IEEE 754 floating-point representation.
-
A literal 64-bit float is always two operands, directly holding a 64-bit IEEE 754 representation. The low-order 32 bits appear in the first operand.
2.5.1. SSA Form
A module is always in static single assignment (SSA) form. That is, there is always exactly one instruction resulting in any particular Result <id>. Storing into variables declared in memory is not subject to this; such stores do not create Result <id>s. Accessing declared variables is done through:
-
OpVariable to allocate an object in memory and create a Result <id> that is the name of a pointer to it.
-
OpAccessChain or OpInBoundsAccessChain to create a pointer to a subpart of a composite object in memory.
-
OpLoad through a pointer, giving the loaded object a Result <id> that can then be used as an operand in other instructions.
-
OpStore through a pointer, to write a value. There is no Result <id> for an OpStore.
OpLoad and OpStore instructions can often be eliminated, using intermediate results instead. If this happens in multiple control-flow paths, these values need to be merged again at the path’s merge point. Use OpPhi to merge such values together.
2.6. Entry Point and Execution Model
The OpEntryPoint instruction identifies an entry point with two key things: an execution model and a function definition. Execution models include Vertex, GLCompute, etc. (one for each graphical stage), as well as Kernel for OpenCL kernels. For the complete list, see Execution Model. An OpEntryPoint also supplies a name that can be used externally to identify the entry point, and a declaration of all the Input and Output variables that form its input/output interface.
The static function call graphs rooted at two entry points are allowed to overlap, so that function definitions and global variable definitions can be shared. The execution model and any execution modes associated with an entry point apply to the entire static function call graph rooted at that entry point. This rule implies that a function appearing in both call graphs of two distinct entry points may behave differently in each case. Similarly, variables whose semantics depend on properties of an entry point, e.g. those using the Input Storage Class, may behave differently if used in call graphs rooted in two different entry points.
2.7. Execution Modes
Information like the following is declared with OpExecutionMode instructions. For example,
-
number of invocations (Invocations)
-
vertex-order CCW (VertexOrderCcw)
-
triangle strip generation (OutputTriangleStrip)
-
number of output vertices (OutputVertices)
-
etc.
For a complete list, see Execution Mode.
2.8. Types and Variables
Types are built up hierarchically, using OpTypeXXX instructions. The Result <id> of an OpTypeXXX instruction becomes a type <id> for future use where type <id>s are needed (therefore, OpTypeXXX instructions do not have a type <id>, like most other instructions do).
The "leaves" to start building with are types like OpTypeFloat, OpTypeInt, OpTypeImage, OpTypeEvent, etc. Other types are built up from the Result <id> of these. The numerical types are parameterized to specify bit width and signed vs. unsigned.
Higher-level types are then constructed using opcodes like OpTypeVector, OpTypeMatrix, OpTypeImage, OpTypeArray, OpTypeRuntimeArray, OpTypeStruct, and OpTypePointer. These are parameterized by number of components, array size, member lists, etc. The image types are parameterized by their sampling result type, dimensionality, arrayness, etc. To do sampling or filtering operations, a type from OpTypeSampledImage is used that contains both an image and a sampler. Such a sampled image can be set directly by the client API or combined in a SPIR-V module from an independent image and an independent sampler.
Types are built bottom up: A parameterizing operand in a type must be defined before being used.
Some additional information about the type of an <id> can be provided using the decoration instructions (OpDecorate, OpMemberDecorate, OpGroupDecorate, OpGroupMemberDecorate, and OpDecorationGroup). These can add, for example, Invariant to an <id> created by another instruction. See the full list of Decorations in the Binary Form section.
Two different type <id>s form, by definition, two different types. It is invalid to declare multiple non-aggregate, non-pointer type <id>s having the same opcode and operands. It is valid to declare multiple aggregate type <id>s having the same opcode and operands. This is to allow multiple instances of aggregate types with the same structure to be decorated differently. (Different decorations are not required; two different aggregate type <id>s are allowed to have identical declarations and decorations, and will still be two different types.) Pointer types are also allowed to have multiple <id>s for the same opcode and operands, to allow for differing decorations (e.g., Volatile) or different decoration values (e.g., different Array Stride values for the ArrayStride). If new pointers are formed, their types must be decorated as needed, so the consumer knows how to generate an access through the pointer.
Variables are declared to be of an already built type, and placed in a Storage Class. Storage classes include UniformConstant, Input, Workgroup, etc. and are fully specified in Storage Class. Variables declared with the Function Storage Class can have their lifetime’s specified within their function using the OpLifetimeStart and OpLifetimeStop instructions.
Intermediate results are typed by the instruction’s type <id>, which is constrained by each instruction’s description.
Built-in variables have special semantics and are declared using OpDecorate or OpMemberDecorate with the BuiltIn Decoration, followed by a BuiltIn enumerant. See the BuiltIn section for details on what can be decorated as a built-in variable.
2.8.1. Unsigned Versus Signed Integers
The integer type, OpTypeInt, is parameterized not only with a size, but also with signedness. There are two different ways to think about signedness in SPIR-V, both are internally consistent and acceptable:
-
As if all integers are "signless", meaning they are neither signed nor unsigned: All OpTypeInt instructions select a signedness of 0 to conceptually mean "no sign" (rather than "unsigned"). This is useful if translating from a language that does not distinguish between signed and unsigned types. The type of operation (signed or unsigned) to perform is always selected by the choice of opcode.
-
As if some integers are signed, and some are unsigned: Some OpTypeInt instructions select signedness of 0 to mean "unsigned" and some select signedness of 1 to mean "signed". This is useful if signedness matters to external interface, or if targeting a higher-level language that cares about types being signed and unsigned. The type of operation (signed or unsigned) to perform is still always selected by the choice of opcode, but a small amount of validation can be done where it is non-sensible to use a signed type.
Note in both cases all signed and unsigned operations always work on unsigned types, and the semantics of operation come from the opcode. SPIR-V does not know which way is being used; it is set up to support both ways of thinking.
Note that while SPIR-V aims to not assign semantic meaning to the signedness bit in choosing how to operate on values, there are a few cases known to do this, all confined to modules declaring the Shader capability:
-
validation for consistency checking for front ends for directly contradictory usage, where explicitly indicated in this specification
-
interfaces that might require widening of an input value, and otherwise don’t know whether to sign extend or zero extend, including the following bullet
-
an image read that might require widening of an operand, in versions where the SignExtend and ZeroExtend image operands are not available (if available, these operands are the supported way to communicate this).
2.9. Function Calling
To call a function defined in the current module or a function declared to be imported from another module, use OpFunctionCall with an operand that is the <id> of the OpFunction to call, and the <id>s of the arguments to pass. All arguments are passed by value into the called function. This includes pointers, through which a callee object could be modified.
2.10. Extended Instruction Sets
Many operations and/or built-in function calls from high-level languages are represented through extended instruction sets. Extended instruction sets include things like
-
trigonometric functions: sin(), cos(), …
-
exponentiation functions: exp(), pow(), …
-
geometry functions: reflect(), smoothstep(), …
-
functions having rich performance/accuracy trade-offs
-
etc.
Non-extended instructions, those that are core SPIR-V instructions, are listed in the Binary Form section. Native operations include:
-
Basic arithmetic: +, -, *, min(), scalar * vector, etc.
-
Texturing, to help with back-end decoding and support special code-motion rules.
-
Derivatives, due to special code-motion rules.
Extended instruction sets are specified in independent specifications, not in this specification. The separate extended instruction set specification specifies instruction opcodes, semantics, and instruction names.
To use an extended instruction set, first import it by name string using OpExtInstImport and giving it a Result <id>:
<extinst-id> OpExtInstImport "name-of-extended-instruction-set"
Where "name-of-extended-instruction-set" is a literal string. The standard convention for this string is
"<source language name>.<package name>.<version>"
For example "GLSL.std.450" could be the name of the core built-in functions for GLSL versions 450 and earlier.
Note
|
There is nothing precluding having two "mirror" sets of instructions with different names but the same opcode values, which could, for example, let modifying just the import statement to change a performance/accuracy trade off. |
Then, to call a specific extended instruction, use OpExtInst:
OpExtInst <extinst-id> instruction-number operand0, operand1, ...
Extended instruction-set specifications provide semantics for each "instruction-number". It is up to the specific specification what the overloading rules are on operand type. The specification will be clear on its semantics, and producers/consumers of it must follow those semantics.
By convention, it is recommended that all external specifications include an enum {…} listing all the "instruction-numbers", and a mapping between these numbers and a string representing the instruction name. However, there are no requirements that instruction name strings are provided or mangled.
Note
|
Producing and consuming extended instructions can be done entirely through numbers (no string parsing). An extended instruction set specification provides opcode enumerant values for the instructions, and these are produced by the front end and consumed by the back end. |
2.11. Structured Control Flow
SPIR-V can explicitly declare structured control-flow constructs using merge instructions. These explicitly declare a header block before the control flow diverges and a merge block where control flow subsequently converges. These blocks delimit constructs that must nest, and must be entered and exited in structured ways, as per the following.
Structured control-flow declarations must satisfy the following rules:
-
the merge block declared by a header block must not be a merge block declared by any other header block
-
each header block must strictly dominate its merge block, unless the merge block is unreachable in the CFG
-
all CFG back edges must branch to a loop header, with each loop header having exactly one back edge branching to it
-
for a given loop header, its OpLoopMerge Continue Target, and corresponding back-edge block:
-
the loop header must dominate the Continue Target, unless the Continue Target is unreachable in the CFG
-
the Continue Target must dominate the back-edge block
-
the back-edge block must post dominate the Continue Target
-
A structured control-flow construct is then defined as one of:
-
a selection construct: includes the blocks dominated by a selection header, while excluding blocks dominated by the selection construct’s merge block
-
a continue construct: includes the blocks dominated by an OpLoopMerge Continue Target and post dominated by the corresponding loop’s back-edge block, while excluding blocks dominated by that loop’s merge block
-
a loop construct: includes the blocks dominated by a loop header, while excluding both that header’s continue construct and the blocks dominated by the loop’s merge block
-
a case construct: the blocks dominated by an OpSwitch Target or Default (this construct is only defined for those OpSwitch Target or Default that are not equal to the OpSwitch’s corresponding merge block)
Furthermore, these structured control-flow constructs are additionally defined to exclude all outer constructs' continue constructs and exclude all blocks dominated by all outer constructs' merge blocks.
The above structured control-flow constructs must satisfy the following rules:
-
if a construct contains another header block, it also contains that header’s corresponding merge block if that merge block is reachable in the CFG
-
a continue construct must include its loop’s back-edge block
-
a break block is valid only for the innermost loop it is nested inside of
-
a continue block is valid only for the innermost loop it is nested inside of
-
a branch to an outer OpSwitch merge block is
-
valid only for the innermost OpSwitch the branch is nested inside of
-
not valid if it is nested in a loop that is nested in that OpSwitch
-
-
a branch from one case construct to another must be for the same OpSwitch
-
all branches into a construct from reachable blocks outside the construct must be to the header block
-
additionally for switches:
-
an OpSwitch block dominates all its defined case constructs
-
each case construct has at most one branch to another case construct
-
each case construct is branched to by at most one other case construct
-
if Target T1 branches to Target T2, or if Target T1 branches to the Default and the Default branches to Target T2, then T1 must immediately precede T2 in the list of the OpSwitch Target operands
-
2.12. Specialization
Specialization is intended for constant objects that will not have known constant values until after initial generation of a SPIR-V module. Such objects are called specialization constants.
A SPIR-V module containing specialization constants can consume one or more externally provided specializations: A set of final constant values for some subset of the module’s specialization constants. Applying these final constant values yields a new module having fewer remaining specialization constants. A module also contains default values for any specialization constants that never get externally specialized.
Note
|
No optimizing transforms are required to make a specialized module functionally correct. The specializing transform is straightforward and explicitly defined below. |
Note
|
Ad hoc specializing should not be done through constants (OpConstant or OpConstantComposite) that get overwritten: A SPIR-V → SPIR-V transform might want to do something irreversible with the value of such a constant, unconstrained from the possibility that its value could be later changed. |
Within a module, a Specialization Constant is declared with one of these instructions:
The literal operands to OpSpecConstant are the default numerical specialization constants. Similarly, the "True" and "False" parts of OpSpecConstantTrue and OpSpecConstantFalse provide the default Boolean specialization constants. These default values make an external specialization optional. However, such a default constant is applied only after all external specializations are complete, and none contained a specialization for it.
An external specialization is provided as a logical list of pairs. Each pair is a SpecId Decoration of a scalar specialization instruction along with its specialization constant. The numeric values are exactly what the operands would be to a corresponding OpConstant instruction. Boolean values are true if non-zero and false if zero.
Specializing a module is straightforward. The following specialization-constant instructions can be updated with specialization constants. These can be replaced in place, leaving everything else in the module exactly the same:
OpSpecConstantTrue -> OpConstantTrue or OpConstantFalse OpSpecConstantFalse -> OpConstantTrue or OpConstantFalse OpSpecConstant -> OpConstant OpSpecConstantComposite -> OpConstantComposite
Note that the OpSpecConstantOp instruction is not one that can be updated with a specialization constant.
The OpSpecConstantOp instruction is specialized by executing the operation and replacing the instruction with the result. The result can be expressed in terms of a constant instruction that is not a specialization-constant instruction. (Note, however, this resulting instruction might not have the same size as the original instruction, so is not a "replaced in place" operation.)
When applying an external specialization, the following (and only the following) will be modified to be non-specialization-constant instructions:
-
specialization-constant instructions with values provided by the specialization
-
specialization-constant instructions that consume nothing but non-specialization constant instructions (including those that the partial specialization transformed from specialization-constant instructions; these are in order, so it is a single pass to do so)
A full specialization can also be done, when requested or required, in which all specialization-constant instructions will be modified to non-specialization-constant instructions, using the default values where required.
If a statically expressed rule would be broken due to the value of a constant, and that constant is a specialization constant, then that rule is not violated. (Consequently, specialization-constant default values are not relevant to the validity of the module.)
2.13. Linkage
The ability to have partially linked modules and libraries is provided as part of the Linkage capability.
By default, functions and global variables are private to a module and cannot be accessed by other modules. However, a module may be written to export or import functions and global (module scope) variables. Imported functions and global variable definitions are resolved at linkage time. A module is considered to be partially linked if it depends on imported values.
Within a module, imported or exported values are decorated using the Linkage Attributes Decoration. This decoration assigns the following linkage attributes to decorated values:
-
A Linkage Type.
-
A name, interpreted is a literal string, is used to uniquely identify exported values.
Note
|
When resolving imported functions, the Function Control and all Function Parameter Attributes are taken from the function definition, and not from the function declaration. |
2.14. Relaxed Precision
The RelaxedPrecision Decoration allows 32-bit integer and 32-bit floating-point operations to execute with a relaxed precision of somewhere between 16 and 32 bits.
For a floating-point operation, operating at relaxed precision means that the minimum requirements for range and precision are as follows:
-
the floating point range may be as small as (-214, 214)
-
the floating point magnitude range includes 0.0 and [2-14, 214)
-
the relative floating point precision may be as small as 2-10
The range notation here means the largest required magnitude is half of the relative precision less than the value given.
Relative floating-point precision is defined as the worst case (i.e. largest) ratio of the smallest step in relation to the value for all non-zero values in the required range:
Precisionrelative = (abs(v1 - v2)min / abs(v1))max for v1 ≠ 0, v2 ≠ 0, v1 ≠ v2
It is therefore twice the maximum rounding error when converting from a real number. Subnormal numbers may be supported and may have lower relative precision.
For integer operations, operating at relaxed precision means that the operation is evaluated by an operation in which, for some N, 16 ≤ N ≤ 32:
-
the operation is executed as though its type were N bits in size, and
-
the result is zero or sign extended to 32 bits as determined by the signedness of the result type of the operation.
The RelaxedPrecision Decoration can be applied to:
-
The <id> of a variable, where the variable’s type is a scalar, vector, or matrix, or an array of scalar, vector, or matrix. In all cases, the components in the type must be a 32-bit numerical type.
-
The Result <id> of an instruction that operates on numerical types, meaning the instruction is to operate at relaxed precision. The instruction’s operands may also be truncated to the relaxed precision.
-
The Result <id> of an instruction that reads or filters from an image. E.g. OpImageSampleExplicitLod, meaning the instruction is to operate at relaxed precision.
-
The Result <id> of an OpFunction meaning the function’s returned result is at relaxed precision. It must not be applied to OpTypeFunction or to an OpFunction whose return type is OpTypeVoid.
-
A structure-type member (through OpMemberDecorate).
When applied to a variable or structure member, all loads and stores from the decorated object may be treated as though they were decorated with RelaxedPrecision. Loads may also be decorated with RelaxedPrecision, in which case they are treated as operating at relaxed precision.
All loads and stores involving relaxed precision still read and write 32 bits of data, respectively. Floating-point data read or written in such a manner is written in full 32-bit floating-point format. However, a load or store might reduce the precision (as allowed by RelaxedPrecision) of the destination value.
For debugging portability of floating-point operations, OpQuantizeToF16 may be used to explicitly reduce the precision of a relaxed-precision result to 16-bit precision. (Integer-result precision can be reduced, for example, using left- and right-shift opcodes.)
For image-sampling operations, decorations can appear on both the sampling instruction and the image variable being sampled. If either is decorated, they both should be decorated, and if both are decorated their decorations must match. If only one is decorated, the sampling instruction can behave either as if both were decorated or neither were decorated.
2.15. Debug Information
Debug information is supplied with:
-
Source-code text through OpString, OpSource, and OpSourceContinued.
-
Object names through OpName and OpMemberName.
A module does not lose any semantics when all such instructions are removed.
2.15.1. Function-Name Mangling
There is no functional dependency on how functions are named. Signature-typing information is explicitly provided, without any need for name "unmangling".
By convention, for debugging purposes, modules with OpSource Source Language of OpenCL use the Itanium name-mangling standard.
2.16. Validation Rules
2.16.1. Universal Validation Rules
-
When using OpBitcast to convert pointers to/from vectors of integers, only vectors of 32-bit integers are allowed.
-
If neither the VariablePointers nor VariablePointersStorageBuffer capabilities are declared, the following rules apply to logical pointer types:
-
OpVariable must not allocate an object whose type is or contains a logical pointer type.
-
It is invalid for a pointer to be an operand to any instruction other than:
-
all OpAtomic instructions
-
extended instruction-set instructions that are explicitly identified as taking pointer operands
-
It is invalid for a pointer to be the Result <id> of any instruction other than:
-
All indexes in OpAccessChain and OpInBoundsAccessChain that are OpConstant with type of OpTypeInt with a signedness of 1 must not have their sign bit set.
-
Any pointer operand to an OpFunctionCall must point into one of the following storage classes:
-
UniformConstant
-
Function
-
Private
-
Workgroup
-
AtomicCounter
-
-
Any pointer operand to an OpFunctionCall must be
-
a pointer to an element in an array that is a memory object declaration, where the element type is OpTypeSampler or OpTypeImage.
-
The instructions OpPtrEqual and OpPtrNotEqual must not be used.
-
-
If the VariablePointers or VariablePointersStorageBuffer capability is declared, the following are allowed for logical pointer types:
-
If OpVariable allocates an object whose type is or contains a logical pointer type, the Storage Class operand of the OpVariable must be one of the following:
-
Function
-
Private
-
-
If a pointer is the Object operand of OpStore or result of OpLoad, the storage class the pointer is stored to or loaded from must be one of the following:
-
Function
-
Private
-
-
A pointer type can be the:
-
Result Type of OpFunction
-
Result Type of OpFunctionCall
-
Return Type of OpTypeFunction
-
-
A pointer can be a variable pointer or an operand to one of:
-
A variable pointer must point to one of the following storage classes:
-
StorageBuffer
-
Workgroup (if the VariablePointers capability is declared)
-
-
If the VariablePointers capability is not declared, a variable pointer must be selected from pointers pointing into the same structure or be OpConstantNull.
-
A pointer operand to OpFunctionCall can point into the storage class:
-
StorageBuffer
-
-
For pointer operands to OpFunctionCall, the memory object declaration-restriction is removed for the following storage classes:
-
StorageBuffer
-
Workgroup
-
-
The instructions OpPtrEqual and OpPtrNotEqual can be used only if the Storage Class of the operands' OpTypePointer declaration is
-
StorageBuffer if the VariablePointersStorageBuffer capability is explicitly or implicitly declared, or
-
Workgroup, which can be used only if the VariablePointers capability was declared.
-
-
-
A variable pointer must not:
-
be an operand to an OpArrayLength instruction
-
point to an object that is or contains an OpTypeMatrix
-
point to a column, or a component in a column, within an OpTypeMatrix
-
-
Memory model
-
If OpLoad, OpStore, OpCopyMemory, or OpCopyMemorySized use MakePointerAvailable or MakePointerVisible, the optional scope operand must be present.
-
If OpImageRead, OpImageSparseRead, or OpImageWrite use MakeTexelAvailable or MakeTexelVisible, the optional scope operand must be present.
-
Memory accesses that use NonPrivatePointer must use pointers in the Uniform, Workgroup, CrossWorkgroup, Generic, Image, or StorageBuffer storage classes.
-
If the Vulkan memory model is declared and any instruction uses Device scope, the VulkanMemoryModelDeviceScope capability must be declared.
-
-
Physical storage buffer
-
If the addressing model is not PhysicalStorageBuffer64, then the PhysicalStorageBuffer storage class must not be used.
-
OpVariable must not use the PhysicalStorageBuffer storage class.
-
If the type an OpVariable points to is a pointer (or array of pointers) in the PhysicalStorageBuffer storage class, the OpVariable must be decorated with exactly one of AliasedPointer or RestrictPointer.
-
If an OpFunctionParameter is a pointer (or array of pointers) in the PhysicalStorageBuffer storage class, the function parameter must be decorated with exactly one of Aliased or Restrict.
-
If an OpFunctionParameter is a pointer (or array of pointers) and the type it points to is a pointer in the PhysicalStorageBuffer storage class, the function parameter must be decorated with exactly one of AliasedPointer or RestrictPointer.
-
Any pointer value whose storage class is PhysicalStorageBuffer and that points to a matrix, an array of matrices, or a row or element of a matrix must be the result of an OpAccessChain or OpPtrAccessChain instruction whose Base operand is a structure type (or recursively must be the result of a sequence of only access chains from a structure to the final value). Such a pointer must only be used as the Pointer operand to OpLoad or OpStore.
-
The result of OpConstantNull must not be a pointer into the PhysicalStorageBuffer storage class.
-
Operands to OpPtrEqual, OpPtrNotEqual, and OpPtrDiff must not be pointers into the PhysicalStorageBuffer storage class.
-
-
SSA
-
Each <id> must appear exactly once as the Result <id> of an instruction.
-
The definition of an SSA <id> should dominate all uses of it, with the following exceptions:
-
Function calls may call functions not yet defined. However, note that the function’s operand and return types are already known at the call site.
-
An OpPhi can consume definitions that do not dominate it.
-
-
-
Entry Point
-
There is at least one OpEntryPoint instruction, unless the Linkage capability is being used.
-
It is invalid for any function to be targeted by both an OpEntryPoint instruction and an OpFunctionCall instruction.
-
Each OpEntryPoint must not set more than one of the DenormFlushToZero or DenormPreserve execution modes for any given Target Width.
-
Each OpEntryPoint must not set more than one of the RoundingModeRTE or RoundingModeRTZ execution modes for any given Target Width.
-
-
Functions
-
A function declaration (an OpFunction with no basic blocks), must have a Linkage Attributes Decoration with the Import Linkage Type.
-
A function definition (an OpFunction with basic blocks) must not be decorated with the Import Linkage Type.
-
A function must not have both a declaration and a definition (no forward declarations).
-
-
Global (Module Scope) Variables
-
A module-scope OpVariable with an Initializer operand must not be decorated with the Import Linkage Type.
-
-
Control-Flow Graph (CFG)
-
Blocks exist only within a function.
-
The first block in a function definition is the entry point of that function and must not be the target of any branch. (Note this means it has no OpPhi instructions.)
-
The order of blocks in a function must satisfy the rule that blocks appear before all blocks they dominate.
-
Each block starts with a label.
-
A label is made by OpLabel.
-
This includes the first block of a function (OpFunction is not a label).
-
Labels are used only to form blocks.
-
-
The last instruction of each block is a termination instruction.
-
Each Termination instruction must be the last instruction in a block.
-
Each OpLabel instruction must be within a function.
-
All branches within a function must be to labels in that function.
-
-
All OpFunctionCall Function operands are an <id> of an OpFunction in the same module.
-
Data rules
-
Scalar floating-point types must be parameterized only as 32 bit, plus any additional sizes enabled by capabilities.
-
Scalar integer types must be parameterized only as 32 bit, plus any additional sizes enabled by capabilities.
-
Vector types must be parameterized only with numerical types or the OpTypeBool type.
-
Vector types must be parameterized only with 2, 3, or 4 components, plus any additional sizes enabled by capabilities.
-
Matrix types must be parameterized only with floating-point types.
-
Matrix types must be parameterized only with 2, 3, or 4 columns.
-
Specialization constants (see Specialization) are limited to integers, Booleans, floating-point numbers, and vectors of these.
-
All OpSampledImage instructions must be in the same block in which their Result <id> are consumed. Result <id> from OpSampledImage instructions must not appear as operands to OpPhi instructions or OpSelect instructions, or any instructions other than the image lookup and query instructions specified to take an operand whose type is OpTypeSampledImage.
-
If instructions dereference a composite to get an image or a sampler, behavior is undefined unless all the dereferencing Indexes are dynamically-uniform. Such instructions must be in the same block in which their Result <id> are consumed. Such Result <id> must not appear as operands to OpPhi instructions or OpSelect instructions, or any instructions other than the image instructions specified to operate on them.
-
The capabilities StorageBuffer16BitAccess, UniformAndStorageBuffer16BitAccess, StoragePushConstant16, and StorageInputOutput16 do not generally add 16-bit operations. Rather, they add only the following specific abilities:
-
An OpTypePointer pointing to a 16-bit scalar, a 16-bit vector, or a composite containing a 16-bit member can be used as the result type of OpVariable, or OpAccessChain, or OpInBoundsAccessChain.
-
OpLoad can load 16-bit scalars, 16-bit vectors, and 16-bit matrices.
-
OpStore can store 16-bit scalars, 16-bit vectors, and 16-bit matrices.
-
OpCopyObject can be used for 16-bit scalars or composites containing 16-bit members.
-
16-bit scalars or 16-bit vectors can be used as operands to a width-only conversion instruction to another allowed type (OpFConvert, OpSConvert, or OpUConvert), and can be produced as results of a width-only conversion instruction from another allowed type.
-
A structure containing a 16-bit member can be an operand to OpArrayLength.
-
-
The capabilities StorageBuffer8BitAccess, UniformAndStorageBuffer8BitAccess, and StoragePushConstant8, do not generally add 8-bit operations. Rather, they add only the following specific abilities:
-
An OpTypePointer pointing to an 8-bit scalar, an 8-bit vector, or a composite containing an 8-bit member can be used as the result type of OpVariable, or OpAccessChain, or OpInBoundsAccessChain.
-
OpLoad can load 8-bit scalars and vectors.
-
OpStore can store 8-bit scalars and 8-bit vectors.
-
OpCopyObject can be used for 8-bit scalars or composites containing 8-bit members.
-
8-bit scalars and vectors can be used as operands to a width-only conversion instruction to another allowed type (OpSConvert, or OpUConvert), and can be produced as results of a width-only conversion instruction from another allowed type.
-
A structure containing an 8-bit member can be an operand to OpArrayLength.
-
-
-
Decoration rules
-
The Linkage Attributes Decoration must not be applied to functions targeted by an OpEntryPoint instruction.
-
A BuiltIn Decoration must be applied only as follows:
-
If applied to a structure-type member, all members of that structure type must also be decorated with BuiltIn. (No allowed mixing of built-in variables and non-built-in variables within a single structure.)
-
If applied to a structure-type member, that structure type must not be contained as a member of another structure type.
-
There must be no more than one object per Storage Class that contains a structure type containing members decorated with BuiltIn, consumed per entry-point.
-
-
-
OpLoad and OpStore must consume only objects whose type is a pointer.
-
A Result <id> resulting from an instruction within a function must be used only in that function.
-
A function call must have the same number of arguments as the function definition (or declaration) has parameters, and their respective types must match.
-
An instruction requiring a specific number of operands must have that many operands. The word count must agree.
-
Each opcode specifies its own requirements for number and type of operands, and these must be followed.
-
Atomic access rules
-
The pointers taken by atomic operation instructions must be a pointer into one of the following Storage Classes:
-
Uniform when used with the BufferBlock Decoration
-
StorageBuffer
-
PhysicalStorageBuffer
-
Workgroup
-
CrossWorkgroup
-
Generic
-
AtomicCounter
-
Image
-
Function
-
-
-
It is invalid to have a construct that uses the StorageBuffer Storage Class and a construct that uses the Uniform Storage Class with the BufferBlock Decoration in the same SPIR-V module.
-
All XfbStride Decorations must be the same for all objects decorated with the same XfbBuffer XFB Buffer Number.
-
All Stream Decorations must be the same for all objects decorated with the same XfbBuffer XFB Buffer Number.
2.16.2. Validation Rules for Shader Capabilities
-
CFG:
-
Loops must be structured, having an OpLoopMerge instruction in their header.
-
Selections must be structured, having an OpSelectionMerge instruction in their header.
-
-
Entry point and execution model
-
Each entry point in a module, along with its corresponding static call tree within that module, forms a complete pipeline stage.
-
Each OpEntryPoint with the Fragment Execution Model must have an OpExecutionMode for either the OriginLowerLeft or the OriginUpperLeft Execution Mode. (Exactly one of these is required.)
-
An OpEntryPoint with the Fragment Execution Model must not set more than one of the DepthGreater, DepthLess, or DepthUnchanged Execution Modes.
-
An OpEntryPoint with one of the Tessellation Execution Models must not set more than one of the SpacingEqual, SpacingFractionalEven, or SpacingFractionalOdd Execution Modes.
-
An OpEntryPoint with one of the Tessellation Execution Models must not set more than one of the Triangles, Quads, or Isolines Execution Modes.
-
An OpEntryPoint with one of the Tessellation Execution Models must not set more than one of the VertexOrderCw or VertexOrderCcw Execution Modes.
-
An OpEntryPoint with the Geometry Execution Model must set exactly one of the InputPoints, InputLines, InputLinesAdjacency, Triangles, or TrianglesAdjacency Execution Modes.
-
An OpEntryPoint with the Geometry Execution Model must set exactly one of the OutputPoints, OutputLineStrip, or OutputTriangleStrip Execution Modes.
-
-
Composite objects in the StorageBuffer, PhysicalStorageBuffer, Uniform, and PushConstant Storage Classes must be explicitly laid out. The following apply to all the aggregate and matrix types describing such an object, recursively through their nested types:
-
Each structure-type member must have an Offset decoration.
-
Each array type must have an ArrayStride decoration, unless it is an array that contains a structure decorated with Block or BufferBlock, in which case it must not have an ArrayStride decoration.
-
Each structure-type member that is a matrix or array-of-matrices must have be decorated with
-
a MatrixStride Decoration, and
-
one of the RowMajor or ColMajor decorations.
-
-
The ArrayStride, MatrixStride, and Offset decorations must be large enough to hold the size of the objects they affect (that is, specifying overlap is invalid). Each ArrayStride and MatrixStride must be greater than zero, and it is invalid for two members of a given structure to be assigned the same Offset.
-
Each OpPtrAccessChain must have a Base whose type is decorated with ArrayStride.
-
If an array-element pointer is derived from an array (e.g., using OpAccessChain), and the resulting element-pointer type is decorated with ArrayStride, its Array Stride must match the Array Stride of the array’s type. If the array’s type is not decorated with ArrayStride, the derived array-element pointer also must not be decorated with ArrayStride.
-
-
For structure objects in the Input and Output Storage Classes, the following apply:
-
If applied to structure-type members, the decorations Noperspective, Flat, Patch, Centroid, and Sample must be applied only to the top-level members of the structure type. (Nested objects' types must not be structures whose members are decorated with these decorations.)
-
-
Type Rules
-
All declared types are restricted to those types that are, or are contained within, valid types for an OpVariable Result Type or an OpTypeFunction Return Type.
-
Aggregate types for intermediate objects are restricted to those types that are a valid Type of an OpVariable Result Type in the global storage classes.
-
-
Decorations
-
It is invalid to apply more than one of Noperspective or Flat decorations to the same object or member.
-
It is invalid to apply more than one of Patch, Centroid, or Sample decorations to the same object or member.
-
It is invalid to apply more than one of Block and BufferBlock decorations to a structure type.
-
Block and BufferBlock decorations must not decorate a structure type that is nested at any level inside another structure type decorated with Block or BufferBlock.
-
The FPRoundingMode decoration must be applied only to a width-only conversion instruction whose only uses are Object operands of OpStore instructions storing through a pointer to a 16-bit floating-point object in the StorageBuffer, PhysicalStorageBuffer, Uniform, or Output Storage Classes.
-
-
All <id> used for Scope <id> and Memory Semantics <id> must be of an OpConstant.
-
Atomic access rules
-
The pointers taken by atomic operation instructions are further restricted to not point into the Function storage class.
-
2.16.3. Validation Rules for Kernel Capabilities
-
The Signedness in OpTypeInt must always be 0.
2.17. Universal Limits
These quantities are minimum limits for all implementations and validators. Implementations are allowed to support larger quantities. Client APIs may impose larger minimums. See Language Capabilities.
Validators inform when these limits (or explicitly parameterized limits) are crossed.
Limited Entity |
Minimum Limit |
|
Decimal |
Hexadecimal |
|
Characters in a literal string |
65,535 |
FFFF |
Result <id> bound |
4,194,303 |
3FFFFF |
Control-flow nesting depth |
1023 |
3FF |
Global variables (Storage Class other than Function) |
65,535 |
FFFF |
Local variables (Function Storage Class) |
524,287 |
7FFFF |
Decorations per target <id> |
Number of entries in the Decoration table. |
|
Execution modes per entry point |
255 |
FF |
Indexes for OpAccessChain, OpInBoundsAccessChain, OpPtrAccessChain, OpInBoundsPtrAccessChain, OpCompositeExtract, and OpCompositeInsert |
255 |
FF |
Number of function parameters, per function declaration |
255 |
FF |
OpFunctionCall actual arguments |
255 |
FF |
OpExtInst actual arguments |
255 |
FF |
OpSwitch (literal, label) pairs |
16,383 |
3FFF |
OpTypeStruct members |
16,383 |
3FFF |
Structure nesting depth |
255 |
FF |
2.18. Memory Model
A memory model is chosen using a single OpMemoryModel instruction near the beginning of the module. This selects both an addressing model and a memory model.
The Logical addressing model means pointers are abstract, having no physical size or numeric value. In this mode, pointers must be created only from existing objects, and they must not be stored into an object, unless additional capabilities, e.g., VariablePointers, are declared to add such functionality.
The non-Logical addressing models allow physical pointers to be formed. OpVariable can be used to create objects that hold pointers. These are declared for a specific Storage Class. Pointers for one Storage Class must not be used to access objects in another Storage Class. However, they can be converted with conversion opcodes. Any particular addressing model describes the bit width of pointers for each of the storage classes.
2.18.1. Memory Layout
Offset, MatrixStride, and ArrayStride Decorations partially define how a memory buffer is laid out. In addition, the following also define layout of a memory buffer, applied recursively as needed:
-
a vector consumes contiguous memory with lower-numbered components appearing in smaller offsets than higher-numbered components, and with component 0 starting at the vector’s Offset Decoration, if present
-
in an array, lower-numbered elements appear at smaller offsets than higher-numbered elements, with element 0 starting at the Offset Decoration for the array, if present
-
in a matrix, lower-numbered columns appear at smaller offsets than higher-numbered columns, and lower-numbered components within the matrix’s vectors appearing at smaller offsets than high-numbered components, with component 0 of column 0 starting at the Offset Decoration, if present (the RowMajor and ColMajor Decorations dictate what is contiguous)
2.18.2. Aliasing
Two memory object declarations are said to alias if they can be accessed (in bounds) such that both accesses address the same memory locations. If two memory operations access the same locations, and at least one of them performs a write, the memory consistency model specified by the client API defines the results based on the ordering of the accesses.
How aliasing is managed depends on the memory model:
-
The Simple, GLSL, and Vulkan memory models can assume that aliasing is generally not present between the memory object declarations. Specifically, the consumer is free to assume aliasing is not present between memory object declarations, unless the memory object declarations explicitly indicate they alias. Aliasing is indicated by applying the Aliased decoration to a memory object declaration’s <id>, for OpVariable and OpFunctionParameter. Applying Restrict is allowed, but has no effect. For variables holding PhysicalStorageBuffer pointers, applying the AliasedPointer decoration on the OpVariable indicates that the PhysicalStorageBuffer pointers are potentially aliased. Applying RestrictPointer is allowed, but has no effect. Variables holding PhysicalStorageBuffer pointers must be decorated as either AliasedPointer or RestrictPointer. Only those memory object declarations decorated with Aliased or AliasedPointer may alias each other.
-
The OpenCL memory model assumes that memory object declarations might alias each other. An implementation may assume that memory object declarations decorated with Restrict will not alias any other memory object declaration. Applying Aliased is allowed, but has no effect.
The Aliased decoration can be used to express that certain memory object declarations may alias. Referencing the following table, a memory object declaration P may alias another declared pointer Q if within a single row:
-
P is an instruction with opcode and storage class from the first pair of columns, and
-
Q is an instruction with opcode and storage class from the second pair of columns.
First Storage Class |
First Instruction(s) |
Second Instructions |
Second Storage Classes |
CrossWorkgroup |
OpFunctionParameter, OpVariable |
OpFunctionParameter, OpVariable |
CrossWorkgroup, Generic |
Function |
OpFunctionParameter |
OpFunctionParameter, OpVariable |
Function, Generic |
Function |
OpVariable |
OpFunctionParameter |
Function, Generic |
Generic |
OpFunctionParameter |
OpFunctionParameter, OpVariable |
CrossWorkgroup, Function, Generic, Workgroup |
Image |
OpFunctionParameter, OpVariable |
OpFunctionParameter, OpVariable |
Image, StorageBuffer, PhysicalStorageBuffer, Uniform, UniformConstant |
Output |
OpFunctionParameter |
OpFunctionParameter, OpVariable |
Output |
Private |
OpFunctionParameter |
OpFunctionParameter, OpVariable |
Private |
StorageBuffer |
OpFunctionParameter, OpVariable |
OpFunctionParameter, OpVariable |
Image, StorageBuffer, PhysicalStorageBuffer, Uniform, UniformConstant |
PhysicalStorageBuffer |
OpFunctionParameter, OpVariable |
OpFunctionParameter, OpVariable |
Image, StorageBuffer, PhysicalStorageBuffer, Uniform, UniformConstant |
Uniform |
OpFunctionParameter, OpVariable |
OpFunctionParameter, OpVariable |
Image, StorageBuffer, PhysicalStorageBuffer, Uniform, UniformConstant |
UniformConstant |
OpFunctionParameter, OpVariable |
OpFunctionParameter, OpVariable |
Image, StorageBuffer, PhysicalStorageBuffer, Uniform, UniformConstant |
Workgroup |
OpFunctionParameter |
OpFunctionParameter, OpVariable |
Workgroup, Generic |
Workgroup |
OpVariable |
OpFunctionParameter |
Workgroup, Generic |
In addition to the above table, memory object declarations in the CrossWorkgroup, Function, Input, Output, Private, or Workgroup storage classes must also have matching pointee types for aliasing to be present. In all other cases the decoration is ignored.
Because aliasing, as described above, only applies to memory object declarations, a consumer does not make any assumptions about whether or not memory regions of non memory object declarations overlap. As such, a consumer needs to perform dependency analysis on non memory object declarations if it wishes to reorder instructions affecting memory. Behavior is undefined if operations on two memory object declarations access the same memory location, with at least one of them performing a write, and at least one of the memory object declarations does not have the Aliased decoration.
For the PhysicalStorageBuffer storage class, OpVariable is understood to mean the PhysicalStorageBuffer pointer value(s) stored in the variable. An Aliased PhysicalStorageBuffer pointer stored in a Function variable can alias with other variables in the same function, global variables, or function parameters.
It is invalid to apply both Restrict and Aliased to the same <id>.
2.18.3. Null pointers
A "null pointer" can be formed from an OpConstantNull instruction with a pointer result type. The resulting pointer value is abstract, and will not equal the pointer value formed from any declared object or access chain into a declared object. Behavior is undefined if a load or store through OpConstantNull is executed.
2.19. Derivatives
Derivatives appear only in the Fragment Execution Model. They are either implicit or explicit. Some image instructions consume implicit derivatives, while the derivative instructions compute explicit derivatives. In all cases, derivatives are well defined when the derivative group has uniform control flow, otherwise see the client API specification for what behavior is allowed.
2.20. Code Motion
Texturing instructions in the Fragment Execution Model that rely on an implicit derivative won’t be moved into control flow that is not known to be uniform control flow within each derivative group.
2.21. Deprecation
A feature may be marked as deprecated by a version of the specification or extension to the specification. Features marked as deprecated in one version of the specification are still present in that version, but future versions may reduce their support or completely remove them. Deprecating before removing allows applications time to transition away from the deprecated feature. Once the feature is removed, all tokens used exclusively by that feature will be reserved and any use of those tokens will become invalid.
2.22. Unified Specification
This document specifies all versions of SPIR-V.
There are three kinds of entries in the tables of enumerated tokens:
-
Reservation: These say Reserved in the enabling capabilities. They often contain token names only, lacking a semantic description. They are invalid SPIR-V for any version, serving only to reserve the tokens. They may identify enabling capabilities and extensions, in which case any listed extensions might add the tokens. See the listed extensions for additional information.
-
Conditional: These say Missing before or Missing after in the enabling capabilities. They are invalid SPIR-V for the missing versions. They may identify enabling capabilities and extensions, in which case any listed extensions might add the tokens for some of the missing versions. See the listed extensions for additional information. For versions not identified as missing, the tokens are valid SPIR-V, subject to any listed enabling capabilities.
-
Universal: These have no mention of what version they are missing in, or of being reserved. They are valid in all versions of SPIR-V.
2.23. Uniformity
SPIR-V has multiple notions of uniformity of values. A Result <id> decorated as Uniform (for a particular scope) is a contract that all invocations within that scope compute the same value for that result, for a given dynamic instance of an instruction. This is useful to enable implementations to store results in a scalar register file (scalarization), for example. Results are assumed not to be uniform unless decorated as such.
An <id> is defined to be dynamically uniform for a dynamic instance of an instruction if all invocations (in an invocation group) that execute the dynamic instance have the same value for that <id>. This is not something that is explicitly decorated, it is just a property that arises. This property is assumed to hold for operands of certain instructions, such as the Image operand of image instructions, unless that operand is decorated as NonUniform. Some implementations require more complex instruction expansions to handle non-dynamically uniform values in certain instructions, and thus it is mandatory for certain operands to be decorated as NonUniform if they are not guaranteed to be dynamically uniform.
While the names may suggest otherwise, nothing forbids an <id> from being decorated as both Uniform and NonUniform. Because dynamically uniform is at a larger scope (invocation group) than the default Uniform scope (subgroup), it is even possible for the <id> to be uniform at the subgroup scope but not dynamically uniform.
3. Binary Form
This section contains the exact form for all instructions, starting with the numerical values for all fields. See Physical Layout for the order words appear in.
3.1. Magic Number
Magic number for a SPIR-V module.
Tip
|
Endianness: A module is defined as a stream of words, not a stream of bytes. However, if stored as a stream of bytes (e.g., in a file), the magic number can be used to deduce what endianness to apply to convert the byte stream back to a word stream. |
Magic Number |
---|
0x07230203 |
3.2. Source Language
The source language is for debug purposes only, with no semantics that affect the meaning of other parts of the module.
Used by OpSource.
Source Language | |
---|---|
0 |
Unknown |
1 |
ESSL |
2 |
GLSL |
3 |
OpenCL_C |
4 |
OpenCL_CPP |
5 |
HLSL |
3.3. Execution Model
Used by OpEntryPoint.
Execution Model | Enabling Capabilities | |
---|---|---|
0 |
Vertex |
Shader |
1 |
TessellationControl |
Tessellation |
2 |
TessellationEvaluation |
Tessellation |
3 |
Geometry |
Geometry |
4 |
Fragment |
Shader |
5 |
GLCompute |
Shader |
6 |
Kernel |
Kernel |
5267 |
TaskNV |
MeshShadingNV |
5268 |
MeshNV |
MeshShadingNV |
5313 |
RayGenerationNV |
RayTracingNV, RayTracingKHR |
5313 |
RayGenerationKHR |
RayTracingNV, RayTracingKHR |
5314 |
IntersectionNV |
RayTracingNV, RayTracingKHR |
5314 |
IntersectionKHR |
RayTracingNV, RayTracingKHR |
5315 |
AnyHitNV |
RayTracingNV, RayTracingKHR |
5315 |
AnyHitKHR |
RayTracingNV, RayTracingKHR |
5316 |
ClosestHitNV |
RayTracingNV, RayTracingKHR |
5316 |
ClosestHitKHR |
RayTracingNV, RayTracingKHR |
5317 |
MissNV |
RayTracingNV, RayTracingKHR |
5317 |
MissKHR |
RayTracingNV, RayTracingKHR |
5318 |
CallableNV |
RayTracingNV, RayTracingKHR |
5318 |
CallableKHR |
RayTracingNV, RayTracingKHR |
3.4. Addressing Model
Used by OpMemoryModel.
Addressing Model | Enabling Capabilities | |
---|---|---|
0 |
Logical |
|
1 |
Physical32 |
Addresses |
2 |
Physical64 |
Addresses |
5348 |
PhysicalStorageBuffer64 |
PhysicalStorageBufferAddresses |
5348 |
PhysicalStorageBuffer64EXT |
PhysicalStorageBufferAddresses |
3.5. Memory Model
Used by OpMemoryModel.
Memory Model | Enabling Capabilities | |
---|---|---|
0 |
Simple |
Shader |
1 |
GLSL450 |
Shader |
2 |
OpenCL |
Kernel |
3 |
Vulkan |
VulkanMemoryModel |
3 |
VulkanKHR |
VulkanMemoryModel |
3.6. Execution Mode
Declare the modes an entry point executes in.
Used by OpExecutionMode and OpExecutionModeId.
Execution Mode | Extra Operands | Enabling Capabilities | |||
---|---|---|---|---|---|
0 |
Invocations |
Literal |
Geometry |
||
1 |
SpacingEqual |
Tessellation |
|||
2 |
SpacingFractionalEven |
Tessellation |
|||
3 |
SpacingFractionalOdd |
Tessellation |
|||
4 |
VertexOrderCw |
Tessellation |
|||
5 |
VertexOrderCcw |
Tessellation |
|||
6 |
PixelCenterInteger |
Shader |
|||
7 |
OriginUpperLeft |
Shader |
|||
8 |
OriginLowerLeft |
Shader |
|||
9 |
EarlyFragmentTests |
Shader |
|||
10 |
PointMode |
Tessellation |
|||
11 |
Xfb |
TransformFeedback |
|||
12 |
DepthReplacing |
Shader |
|||
14 |
DepthGreater |
Shader |
|||
15 |
DepthLess |
Shader |
|||
16 |
DepthUnchanged |
Shader |
|||
17 |
LocalSize |
Literal |
Literal |
Literal |
|
18 |
LocalSizeHint |
Literal |
Literal |
Literal |
Kernel |
19 |
InputPoints |
Geometry |
|||
20 |
InputLines |
Geometry |
|||
21 |
InputLinesAdjacency |
Geometry |
|||
22 |
Triangles |
Geometry, Tessellation |
|||
23 |
InputTrianglesAdjacency |
Geometry |
|||
24 |
Quads |
Tessellation |
|||
25 |
Isolines |
Tessellation |
|||
26 |
OutputVertices |
Literal |
Geometry, Tessellation, MeshShadingNV |
||
27 |
OutputPoints |
Geometry, MeshShadingNV |
|||
28 |
OutputLineStrip |
Geometry |
|||
29 |
OutputTriangleStrip |
Geometry |
|||
30 |
VecTypeHint |
Literal |
Kernel |
||
31 |
ContractionOff |
Kernel |
|||
33 |
Initializer |
Kernel |
|||
34 |
Finalizer |
Kernel |
|||
35 |
SubgroupSize |
Literal |
SubgroupDispatch |
||
36 |
SubgroupsPerWorkgroup |
Literal |
SubgroupDispatch |
||
37 |
SubgroupsPerWorkgroupId |
<id> |
SubgroupDispatch |
||
38 |
LocalSizeId |
<id> |
<id> |
<id> |
Missing before version 1.2. |
39 |
LocalSizeHintId |
<id> |
Kernel |
||
4446 |
PostDepthCoverage |
SampleMaskPostDepthCoverage |
|||
4459 |
DenormPreserve |
Literal |
DenormPreserve |
||
4460 |
DenormFlushToZero |
Literal |
DenormFlushToZero |
||
4461 |
SignedZeroInfNanPreserve |
Literal |
SignedZeroInfNanPreserve |
||
4462 |
RoundingModeRTE |
Literal |
RoundingModeRTE |
||
4463 |
RoundingModeRTZ |
Literal |
RoundingModeRTZ |
||
5027 |
StencilRefReplacingEXT |
StencilExportEXT |
|||
5269 |
OutputLinesNV |
MeshShadingNV |
|||
5270 |
OutputPrimitivesNV |
Literal |
MeshShadingNV |
||
5289 |
DerivativeGroupQuadsNV |
ComputeDerivativeGroupQuadsNV |
|||
5290 |
DerivativeGroupLinearNV |
ComputeDerivativeGroupLinearNV |
|||
5298 |
OutputTrianglesNV |
MeshShadingNV |
|||
5366 |
PixelInterlockOrderedEXT |
FragmentShaderPixelInterlockEXT |
|||
5367 |
PixelInterlockUnorderedEXT |
FragmentShaderPixelInterlockEXT |
|||
5368 |
SampleInterlockOrderedEXT |
FragmentShaderSampleInterlockEXT |
|||
5369 |
SampleInterlockUnorderedEXT |
FragmentShaderSampleInterlockEXT |
|||
5370 |
ShadingRateInterlockOrderedEXT |
FragmentShaderShadingRateInterlockEXT |
|||
5371 |
ShadingRateInterlockUnorderedEXT |
FragmentShaderShadingRateInterlockEXT |
|||
5893 |
MaxWorkgroupSizeINTEL |
Literal |
Literal |
Literal |
KernelAttributesINTEL |
5894 |
MaxWorkDimINTEL |
Literal |
KernelAttributesINTEL |
||
5895 |
NoGlobalOffsetINTEL |
KernelAttributesINTEL |
|||
5896 |
NumSIMDWorkitemsINTEL |
Literal |
FPGAKernelAttributesINTEL |
3.7. Storage Class
Class of storage for declared variables. Intermediate values do not form a storage class, and unless stated otherwise, storage class-based restrictions are not restrictions on intermediate objects and their types.
Used by:
Storage Class | Enabling Capabilities | |
---|---|---|
0 |
UniformConstant |
|
1 |
Input |
|
2 |
Uniform |
Shader |
3 |
Output |
Shader |
4 |
Workgroup |
|
5 |
CrossWorkgroup |
|
6 |
Private |
Shader |
7 |
Function |
|
8 |
Generic |
GenericPointer |
9 |
PushConstant |
Shader |
10 |
AtomicCounter |
AtomicStorage |
11 |
Image |
|
12 |
StorageBuffer |
Shader |
5328 |
CallableDataNV |
RayTracingNV, RayTracingKHR |
5328 |
CallableDataKHR |
RayTracingNV, RayTracingKHR |
5329 |
IncomingCallableDataNV |
RayTracingNV, RayTracingKHR |
5329 |
IncomingCallableDataKHR |
RayTracingNV, RayTracingKHR |
5338 |
RayPayloadNV |
RayTracingNV, RayTracingKHR |
5338 |
RayPayloadKHR |
RayTracingNV, RayTracingKHR |
5339 |
HitAttributeNV |
RayTracingNV, RayTracingKHR |
5339 |
HitAttributeKHR |
RayTracingNV, RayTracingKHR |
5342 |
IncomingRayPayloadNV |
RayTracingNV, RayTracingKHR |
5342 |
IncomingRayPayloadKHR |
RayTracingNV, RayTracingKHR |
5343 |
ShaderRecordBufferNV |
RayTracingNV, RayTracingKHR |
5343 |
ShaderRecordBufferKHR |
RayTracingNV, RayTracingKHR |
5349 |
PhysicalStorageBuffer |
PhysicalStorageBufferAddresses |
5349 |
PhysicalStorageBufferEXT |
PhysicalStorageBufferAddresses |
5605 |
CodeSectionINTEL |
FunctionPointersINTEL |
3.8. Dim
Dimensionality of an image. The listed Array capabilities are required if the type’s Arrayed operand is 1. The listed Image capabilities are required if the type’s Sampled operand is 2.
Used by OpTypeImage.
Dim | Enabling Capabilities | |
---|---|---|
0 |
1D |
Sampled1D, Image1D |
1 |
2D |
Shader, Kernel, ImageMSArray |
2 |
3D |
|
3 |
Cube |
Shader, ImageCubeArray |
4 |
Rect |
SampledRect, ImageRect |
5 |
Buffer |
SampledBuffer, ImageBuffer |
6 |
SubpassData |
InputAttachment |
3.9. Sampler Addressing Mode
Addressing mode for creating constant samplers.
Used by OpConstantSampler.
Sampler Addressing Mode | Enabling Capabilities | |
---|---|---|
0 |
None |
Kernel |
1 |
ClampToEdge |
Kernel |
2 |
Clamp |
Kernel |
3 |
Repeat |
Kernel |
4 |
RepeatMirrored |
Kernel |
3.10. Sampler Filter Mode
Filter mode for creating constant samplers.
Used by OpConstantSampler.
Sampler Filter Mode | Enabling Capabilities | |
---|---|---|
0 |
Nearest |
Kernel |
1 |
Linear |
Kernel |
3.11. Image Format
Declarative image format.
Used by OpTypeImage.
Image Format | Enabling Capabilities | |
---|---|---|
0 |
Unknown |
|
1 |
Rgba32f |
Shader |
2 |
Rgba16f |
Shader |
3 |
R32f |
Shader |
4 |
Rgba8 |
Shader |
5 |
Rgba8Snorm |
Shader |
6 |
Rg32f |
StorageImageExtendedFormats |
7 |
Rg16f |
StorageImageExtendedFormats |
8 |
R11fG11fB10f |
StorageImageExtendedFormats |
9 |
R16f |
StorageImageExtendedFormats |
10 |
Rgba16 |
StorageImageExtendedFormats |
11 |
Rgb10A2 |
StorageImageExtendedFormats |
12 |
Rg16 |
StorageImageExtendedFormats |
13 |
Rg8 |
StorageImageExtendedFormats |
14 |
R16 |
StorageImageExtendedFormats |
15 |
R8 |
StorageImageExtendedFormats |
16 |
Rgba16Snorm |
StorageImageExtendedFormats |
17 |
Rg16Snorm |
StorageImageExtendedFormats |
18 |
Rg8Snorm |
StorageImageExtendedFormats |
19 |
R16Snorm |
StorageImageExtendedFormats |
20 |
R8Snorm |
StorageImageExtendedFormats |
21 |
Rgba32i |
Shader |
22 |
Rgba16i |
Shader |
23 |
Rgba8i |
Shader |
24 |
R32i |
Shader |
25 |
Rg32i |
StorageImageExtendedFormats |
26 |
Rg16i |
StorageImageExtendedFormats |
27 |
Rg8i |
StorageImageExtendedFormats |
28 |
R16i |
StorageImageExtendedFormats |
29 |
R8i |
StorageImageExtendedFormats |
30 |
Rgba32ui |
Shader |
31 |
Rgba16ui |
Shader |
32 |
Rgba8ui |
Shader |
33 |
R32ui |
Shader |
34 |
Rgb10a2ui |
StorageImageExtendedFormats |
35 |
Rg32ui |
StorageImageExtendedFormats |
36 |
Rg16ui |
StorageImageExtendedFormats |
37 |
Rg8ui |
StorageImageExtendedFormats |
38 |
R16ui |
StorageImageExtendedFormats |
39 |
R8ui |
StorageImageExtendedFormats |
40 |
R64ui |
Int64ImageEXT |
41 |
R64i |
Int64ImageEXT |
3.12. Image Channel Order
The image channel orders that result from OpImageQueryOrder.
Image Channel Order | Enabling Capabilities | |
---|---|---|
0 |
R |
Kernel |
1 |
A |
Kernel |
2 |
RG |
Kernel |
3 |
RA |
Kernel |
4 |
RGB |
Kernel |
5 |
RGBA |
Kernel |
6 |
BGRA |
Kernel |
7 |
ARGB |
Kernel |
8 |
Intensity |
Kernel |
9 |
Luminance |
Kernel |
10 |
Rx |
Kernel |
11 |
RGx |
Kernel |
12 |
RGBx |
Kernel |
13 |
Depth |
Kernel |
14 |
DepthStencil |
Kernel |
15 |
sRGB |
Kernel |
16 |
sRGBx |
Kernel |
17 |
sRGBA |
Kernel |
18 |
sBGRA |
Kernel |
19 |
ABGR |
Kernel |
3.13. Image Channel Data Type
Image channel data types that result from OpImageQueryFormat.
Image Channel Data Type | Enabling Capabilities | |
---|---|---|
0 |
SnormInt8 |
Kernel |
1 |
SnormInt16 |
Kernel |
2 |
UnormInt8 |
Kernel |
3 |
UnormInt16 |
Kernel |
4 |
UnormShort565 |
Kernel |
5 |
UnormShort555 |
Kernel |
6 |
UnormInt101010 |
Kernel |
7 |
SignedInt8 |
Kernel |
8 |
SignedInt16 |
Kernel |
9 |
SignedInt32 |
Kernel |
10 |
UnsignedInt8 |
Kernel |
11 |
UnsignedInt16 |
Kernel |
12 |
UnsignedInt32 |
Kernel |
13 |
HalfFloat |
Kernel |
14 |
Float |
Kernel |
15 |
UnormInt24 |
Kernel |
16 |
UnormInt101010_2 |
Kernel |
3.14. Image Operands
This is a literal mask; it can be formed by combining the bits from multiple rows in the table below.
Provides additional operands to sampling, or getting texels from, an image. Bits that are set indicate whether an additional operand follows, as described by the table. If there are multiple following operands indicated, they are ordered: Those indicated by smaller-numbered bits appear first. At least one bit must be set (None is invalid).
Used by:
Image Operands | Enabling Capabilities | |
---|---|---|
0x0 |
None |
|
0x1 |
Bias |
Shader |
0x2 |
Lod |
|
0x4 |
Grad |
|
0x8 |
ConstOffset |
|
0x10 |
Offset |
ImageGatherExtended |
0x20 |
ConstOffsets |
ImageGatherExtended |
0x40 |
Sample |
|
0x80 |
MinLod |
MinLod |
0x100 |
MakeTexelAvailable |
VulkanMemoryModel |
0x100 |
MakeTexelAvailableKHR |
VulkanMemoryModel |
0x200 |
MakeTexelVisible |
VulkanMemoryModel |
0x200 |
MakeTexelVisibleKHR |
VulkanMemoryModel |
0x400 |
NonPrivateTexel |
VulkanMemoryModel |
0x400 |
NonPrivateTexelKHR |
VulkanMemoryModel |
0x800 |
VolatileTexel |
VulkanMemoryModel |
0x800 |
VolatileTexelKHR |
VulkanMemoryModel |
0x1000 |
SignExtend |
Missing before version 1.4. |
0x2000 |
ZeroExtend |
Missing before version 1.4. |
3.15. FP Fast Math Mode
This is a literal mask; it can be formed by combining the bits from multiple rows in the table below.
Enables fast math operations which are otherwise unsafe.
FP Fast Math Mode | Enabling Capabilities | |
---|---|---|
0x0 |
None |
|
0x1 |
NotNaN |
Kernel |
0x2 |
NotInf |
Kernel |
0x4 |
NSZ |
Kernel |
0x8 |
AllowRecip |
Kernel |
0x10 |
Fast |
Kernel |
3.16. FP Rounding Mode
Associate a rounding mode to a floating-point conversion instruction.
FP Rounding Mode | |
---|---|
0 |
RTE |
1 |
RTZ |
2 |
RTP |
3 |
RTN |
3.17. Linkage Type
Associate a linkage type to functions or global variables. See linkage.
Linkage Type | Enabling Capabilities | |
---|---|---|
0 |
Export |
Linkage |
1 |
Import |
Linkage |
3.18. Access Qualifier
Defines the access permissions.
Used by OpTypeImage and OpTypePipe.
Access Qualifier | Enabling Capabilities | |
---|---|---|
0 |
ReadOnly |
Kernel |
1 |
WriteOnly |
Kernel |
2 |
ReadWrite |
Kernel |
3.19. Function Parameter Attribute
Adds additional information to the return type and to each parameter of a function.
Function Parameter Attribute | Enabling Capabilities | |
---|---|---|
0 |
Zext |
Kernel |
1 |
Sext |
Kernel |
2 |
ByVal |
Kernel |
3 |
Sret |
Kernel |
4 |
NoAlias |
Kernel |
5 |
NoCapture |
Kernel |
6 |
NoWrite |
Kernel |
7 |
NoReadWrite |
Kernel |
3.20. Decoration
Used by:
Decoration | Extra Operands | Enabling Capabilities | ||
---|---|---|---|---|
0 |
RelaxedPrecision |
Shader |
||
1 |
SpecId |
Literal |
Shader, Kernel |
|
2 |
Block |
Shader |
||
3 |
BufferBlock |
Shader |
||
4 |
RowMajor |
Matrix |
||
5 |
ColMajor |
Matrix |
||
6 |
ArrayStride |
Literal |
Shader |
|
7 |
MatrixStride |
Literal |
Matrix |
|
8 |
GLSLShared |
Shader |
||
9 |
GLSLPacked |
Shader |
||
10 |
CPacked |
Kernel |
||
11 |
BuiltIn |
|||
13 |
NoPerspective |
Shader |
||
14 |
Flat |
Shader |
||
15 |
Patch |
Tessellation |
||
16 |
Centroid |
Shader |
||
17 |
Sample |
SampleRateShading |
||
18 |
Invariant |
Shader |
||
19 |
Restrict |
|||
20 |
Aliased |
|||
21 |
Volatile |
|||
22 |
Constant |
Kernel |
||
23 |
Coherent |
|||
24 |
NonWritable |
|||
25 |
NonReadable |
|||
26 |
Uniform |
Shader |
||
27 |
UniformId |
Scope <id> |
Shader |
|
28 |
SaturatedConversion |
Kernel |
||
29 |
Stream |
Literal |
GeometryStreams |
|
30 |
Location |
Literal |
Shader |
|
31 |
Component |
Literal |
Shader |
|
32 |
Index |
Literal |
Shader |
|
33 |
Binding |
Literal |
Shader |
|
34 |
DescriptorSet |
Literal |
Shader |
|
35 |
Offset |
Literal |
Shader |
|
36 |
XfbBuffer |
Literal |
TransformFeedback |
|
37 |
XfbStride |
Literal |
TransformFeedback |
|
38 |
FuncParamAttr |
Function Parameter Attribute |
Kernel |
|
39 |
FPRoundingMode |
FP Rounding Mode |
||
40 |
FPFastMathMode |
FP Fast Math Mode |
Kernel |
|
41 |
LinkageAttributes |
Literal |
Linkage Type |
Linkage |
42 |
NoContraction |
Shader |
||
43 |
InputAttachmentIndex |
Literal |
InputAttachment |
|
44 |
Alignment |
Literal |
Kernel |
|
45 |
MaxByteOffset |
Literal |
Addresses |
|
46 |
AlignmentId |
<id> |
Kernel |
|
47 |
MaxByteOffsetId |
<id> |
Addresses |
|
4469 |
NoSignedWrap |
Missing before version 1.4.
|
||
4470 |
NoUnsignedWrap |
Missing before version 1.4.
|
||
4999 |
ExplicitInterpAMD |
Reserved. |
||
5248 |
OverrideCoverageNV |
SampleMaskOverrideCoverageNV |
||
5250 |
PassthroughNV |
GeometryShaderPassthroughNV |
||
5252 |
ViewportRelativeNV |
ShaderViewportMaskNV |
||
5256 |
SecondaryViewportRelativeNV |
Literal |
ShaderStereoViewNV |
|
5271 |
PerPrimitiveNV |
MeshShadingNV |
||
5272 |
PerViewNV |
MeshShadingNV |
||
5273 |
PerTaskNV |
MeshShadingNV |
||
5285 |
PerVertexNV |
FragmentBarycentricNV |
||
5300 |
NonUniform |
ShaderNonUniform |
||
5300 |
NonUniformEXT |
ShaderNonUniform |
||
5355 |
RestrictPointer |
PhysicalStorageBufferAddresses |
||
5355 |
RestrictPointerEXT |
PhysicalStorageBufferAddresses |
||
5356 |
AliasedPointer |
PhysicalStorageBufferAddresses |
||
5356 |
AliasedPointerEXT |
PhysicalStorageBufferAddresses |
||
5602 |
ReferencedIndirectlyINTEL |
IndirectReferencesINTEL |
||
5634 |
CounterBuffer |
<id> |
Missing before version 1.4. |
|
5634 |
HlslCounterBufferGOOGLE |
<id> |
Reserved. |
|
5635 |
UserSemantic |
Literal |
Missing before version 1.4. |
|
5635 |
HlslSemanticGOOGLE |
Literal |
Reserved. |
|
5636 |
UserTypeGOOGLE |
Literal |
Reserved. |
|
5825 |
RegisterINTEL |
FPGAMemoryAttributesINTEL |
||
5826 |
MemoryINTEL |
Literal |
FPGAMemoryAttributesINTEL |
|
5827 |
NumbanksINTEL |
Literal |
FPGAMemoryAttributesINTEL |
|
5828 |
BankwidthINTEL |
Literal |
FPGAMemoryAttributesINTEL |
|
5829 |
MaxPrivateCopiesINTEL |
Literal |
FPGAMemoryAttributesINTEL |
|
5830 |
SinglepumpINTEL |
FPGAMemoryAttributesINTEL |
||
5831 |
DoublepumpINTEL |
FPGAMemoryAttributesINTEL |
||
5832 |
MaxReplicatesINTEL |
Literal |
FPGAMemoryAttributesINTEL |
|
5833 |
SimpleDualPortINTEL |
FPGAMemoryAttributesINTEL |
||
5834 |
MergeINTEL |
Literal |
Literal |
FPGAMemoryAttributesINTEL |
5835 |
BankBitsINTEL |
Literal |
FPGAMemoryAttributesINTEL |
|
5836 |
ForcePow2DepthINTEL |
Literal |
FPGAMemoryAttributesINTEL |
3.21. BuiltIn
Used when Decoration is BuiltIn. Apply to:
-
the result <id> of the OpVariable declaration of the built-in variable, or
-
a structure-type member, if the built-in is a member of a structure, or
-
a constant instruction, if the built-in is a constant.
As stated per entry below, these have additional semantics and constraints specified by the client API.
For all the declarations of all the global variables and constants statically referenced by the entry-point’s call tree, within any specific storage class it is invalid to decorate with a specific BuiltIn more than once.
BuiltIn | Enabling Capabilities | |
---|---|---|
0 |
Position |
Shader |
1 |
PointSize |
Shader |
3 |
ClipDistance |
ClipDistance |
4 |
CullDistance |
CullDistance |
5 |
VertexId |
Shader |
6 |
InstanceId |
Shader |
7 |
PrimitiveId |
Geometry, Tessellation, RayTracingNV, RayTracingKHR, MeshShadingNV |
8 |
InvocationId |
Geometry, Tessellation |
9 |
Layer |
Geometry, ShaderLayer, ShaderViewportIndexLayerEXT, MeshShadingNV |
10 |
ViewportIndex |
MultiViewport, ShaderViewportIndex, ShaderViewportIndexLayerEXT, MeshShadingNV |
11 |
TessLevelOuter |
Tessellation |
12 |
TessLevelInner |
Tessellation |
13 |
TessCoord |
Tessellation |
14 |
PatchVertices |
Tessellation |
15 |
FragCoord |
Shader |
16 |
PointCoord |
Shader |
17 |
FrontFacing |
Shader |
18 |
SampleId |
SampleRateShading |
19 |
SamplePosition |
SampleRateShading |
20 |
SampleMask |
Shader |
22 |
FragDepth |
Shader |
23 |
HelperInvocation |
Shader |
24 |
NumWorkgroups |
|
25 |
WorkgroupSize |
|
26 |
WorkgroupId |
|
27 |
LocalInvocationId |
|
28 |
GlobalInvocationId |
|
29 |
LocalInvocationIndex |
|
30 |
WorkDim |
Kernel |
31 |
GlobalSize |
Kernel |
32 |
EnqueuedWorkgroupSize |
Kernel |
33 |
GlobalOffset |
Kernel |
34 |
GlobalLinearId |
Kernel |
36 |
SubgroupSize |
Kernel, GroupNonUniform, SubgroupBallotKHR |
37 |
SubgroupMaxSize |
Kernel |
38 |
NumSubgroups |
Kernel, GroupNonUniform |
39 |
NumEnqueuedSubgroups |
Kernel |
40 |
SubgroupId |
Kernel, GroupNonUniform |
41 |
SubgroupLocalInvocationId |
Kernel, GroupNonUniform, SubgroupBallotKHR |
42 |
VertexIndex |
Shader |
43 |
InstanceIndex |
Shader |
4416 |
SubgroupEqMask |
SubgroupBallotKHR, GroupNonUniformBallot |
4417 |
SubgroupGeMask |
SubgroupBallotKHR, GroupNonUniformBallot |
4418 |
SubgroupGtMask |
SubgroupBallotKHR, GroupNonUniformBallot |
4419 |
SubgroupLeMask |
SubgroupBallotKHR, GroupNonUniformBallot |
4420 |
SubgroupLtMask |
SubgroupBallotKHR, GroupNonUniformBallot |
4416 |
SubgroupEqMaskKHR |
SubgroupBallotKHR, GroupNonUniformBallot |
4417 |
SubgroupGeMaskKHR |
SubgroupBallotKHR, GroupNonUniformBallot |
4418 |
SubgroupGtMaskKHR |
SubgroupBallotKHR, GroupNonUniformBallot |
4419 |
SubgroupLeMaskKHR |
SubgroupBallotKHR, GroupNonUniformBallot |
4420 |
SubgroupLtMaskKHR |
SubgroupBallotKHR, GroupNonUniformBallot |
4424 |
BaseVertex |
DrawParameters |
4425 |
BaseInstance |
DrawParameters |
4426 |
DrawIndex |
DrawParameters, MeshShadingNV |
4432 |
PrimitiveShadingRateKHR |
FragmentShadingRateKHR |
4438 |
DeviceIndex |
DeviceGroup |
4440 |
ViewIndex |
MultiView |
4444 |
ShadingRateKHR |
FragmentShadingRateKHR |
4992 |
BaryCoordNoPerspAMD |
Reserved. |
4993 |
BaryCoordNoPerspCentroidAMD |
Reserved. |
4994 |
BaryCoordNoPerspSampleAMD |
Reserved. |
4995 |
BaryCoordSmoothAMD |
Reserved. |
4996 |
BaryCoordSmoothCentroidAMD |
Reserved. |
4997 |
BaryCoordSmoothSampleAMD |
Reserved. |
4998 |
BaryCoordPullModelAMD |
Reserved. |
5014 |
FragStencilRefEXT |
StencilExportEXT |
5253 |
ViewportMaskNV |
ShaderViewportMaskNV, MeshShadingNV |
5257 |
SecondaryPositionNV |
ShaderStereoViewNV |
5258 |
SecondaryViewportMaskNV |
ShaderStereoViewNV |
5261 |
PositionPerViewNV |
PerViewAttributesNV, MeshShadingNV |
5262 |
ViewportMaskPerViewNV |
PerViewAttributesNV, MeshShadingNV |
5264 |
FullyCoveredEXT |
FragmentFullyCoveredEXT |
5274 |
TaskCountNV |
MeshShadingNV |
5275 |
PrimitiveCountNV |
MeshShadingNV |
5276 |
PrimitiveIndicesNV |
MeshShadingNV |
5277 |
ClipDistancePerViewNV |
MeshShadingNV |
5278 |
CullDistancePerViewNV |
MeshShadingNV |
5279 |
LayerPerViewNV |
MeshShadingNV |
5280 |
MeshViewCountNV |
MeshShadingNV |
5281 |
MeshViewIndicesNV |
MeshShadingNV |
5286 |
BaryCoordNV |
FragmentBarycentricNV |
5287 |
BaryCoordNoPerspNV |
FragmentBarycentricNV |
5292 |
FragSizeEXT |
FragmentDensityEXT, ShadingRateNV |
5292 |
FragmentSizeNV |
ShadingRateNV, FragmentDensityEXT |
5293 |
FragInvocationCountEXT |
FragmentDensityEXT, ShadingRateNV |
5293 |
InvocationsPerPixelNV |
ShadingRateNV, FragmentDensityEXT |
5319 |
LaunchIdNV |
RayTracingNV, RayTracingKHR |
5319 |
LaunchIdKHR |
RayTracingNV, RayTracingKHR |
5320 |
LaunchSizeNV |
RayTracingNV, RayTracingKHR |
5320 |
LaunchSizeKHR |
RayTracingNV, RayTracingKHR |
5321 |
WorldRayOriginNV |
RayTracingNV, RayTracingKHR |
5321 |
WorldRayOriginKHR |
RayTracingNV, RayTracingKHR |
5322 |
WorldRayDirectionNV |
RayTracingNV, RayTracingKHR |
5322 |
WorldRayDirectionKHR |
RayTracingNV, RayTracingKHR |
5323 |
ObjectRayOriginNV |
RayTracingNV, RayTracingKHR |
5323 |
ObjectRayOriginKHR |
RayTracingNV, RayTracingKHR |
5324 |
ObjectRayDirectionNV |
RayTracingNV, RayTracingKHR |
5324 |
ObjectRayDirectionKHR |
RayTracingNV, RayTracingKHR |
5325 |
RayTminNV |
RayTracingNV, RayTracingKHR |
5325 |
RayTminKHR |
RayTracingNV, RayTracingKHR |
5326 |
RayTmaxNV |
RayTracingNV, RayTracingKHR |
5326 |
RayTmaxKHR |
RayTracingNV, RayTracingKHR |
5327 |
InstanceCustomIndexNV |
RayTracingNV, RayTracingKHR |
5327 |
InstanceCustomIndexKHR |
RayTracingNV, RayTracingKHR |
5330 |
ObjectToWorldNV |
RayTracingNV, RayTracingKHR |
5330 |
ObjectToWorldKHR |
RayTracingNV, RayTracingKHR |
5331 |
WorldToObjectNV |
RayTracingNV, RayTracingKHR |
5331 |
WorldToObjectKHR |
RayTracingNV, RayTracingKHR |
5332 |
HitTNV |
RayTracingNV |
5333 |
HitKindNV |
RayTracingNV, RayTracingKHR |
5333 |
HitKindKHR |
RayTracingNV, RayTracingKHR |
5351 |
IncomingRayFlagsNV |
RayTracingNV, RayTracingKHR |
5351 |
IncomingRayFlagsKHR |
RayTracingNV, RayTracingKHR |
5352 |
RayGeometryIndexKHR |
RayTracingKHR |
5374 |
WarpsPerSMNV |
ShaderSMBuiltinsNV |
5375 |
SMCountNV |
ShaderSMBuiltinsNV |
5376 |
WarpIDNV |
ShaderSMBuiltinsNV |
5377 |
SMIDNV |
ShaderSMBuiltinsNV |
3.22. Selection Control
This is a literal mask; it can be formed by combining the bits from multiple rows in the table below.
Used by OpSelectionMerge.
Selection Control | |
---|---|
0x0 |
None |
0x1 |
Flatten |
0x2 |
DontFlatten |
3.23. Loop Control
This is a literal mask; it can be formed by combining the bits from multiple rows in the table below.
Bits that are set indicate whether an additional operand follows, as described by the table. If there are multiple following operands indicated, they are ordered: Those indicated by smaller-numbered bits appear first.
Used by OpLoopMerge.
Loop Control | Enabling Capabilities | |
---|---|---|
0x0 |
None |
|
0x1 |
Unroll |
|
0x2 |
DontUnroll |
|
0x4 |
DependencyInfinite |
Missing before version 1.1. |
0x8 |
DependencyLength |
Missing before version 1.1. |
0x10 |
MinIterations |
Missing before version 1.4. |
0x20 |
MaxIterations |
Missing before version 1.4. |
0x40 |
IterationMultiple |
Missing before version 1.4. |
0x80 |
PeelCount |
Missing before version 1.4. |
0x100 |
PartialCount |
Missing before version 1.4. |
0x10000 |
InitiationIntervalINTEL |
FPGALoopControlsINTEL |
0x20000 |
MaxConcurrencyINTEL |
FPGALoopControlsINTEL |
0x40000 |
DependencyArrayINTEL |
FPGALoopControlsINTEL |
0x80000 |
PipelineEnableINTEL |
FPGALoopControlsINTEL |
0x100000 |
LoopCoalesceINTEL |
FPGALoopControlsINTEL |
0x200000 |
MaxInterleavingINTEL |
FPGALoopControlsINTEL |
0x400000 |
SpeculatedIterationsINTEL |
FPGALoopControlsINTEL |
3.24. Function Control
This is a literal mask; it can be formed by combining the bits from multiple rows in the table below.
Used by OpFunction.
Function Control | |
---|---|
0x0 |
None |
0x1 |
Inline |
0x2 |
DontInline |
0x4 |
Pure |
0x8 |
Const |
3.25. Memory Semantics <id>
The <id>'s value is a mask; it can be formed by combining the bits from multiple rows in the table below.
The value’s type must be a 32-bit integer scalar. This value is expected to be formed only from the bits in the table below, where at most one of these four bits can be set: Acquire, Release, AcquireRelease, or SequentiallyConsistent. If validation rules or the client API require a constant <id>, it is invalid for the value to not be formed this expected way. If non-constant <id> are allowed, behavior is undefined when the value is not formed this expected way.
Requesting both Acquire and Release semantics is done by setting the AcquireRelease bit, not by setting two bits.
Memory semantics define memory-order constraints, and on what storage classes those constraints apply to. The memory order constrains the allowed orders in which memory operations in this invocation are made visible to another invocation. The storage classes specify to which subsets of memory these constraints are to be applied. Storage classes not selected are not being constrained.
Used by:
Memory Semantics | Enabling Capabilities | |
---|---|---|
0x0 |
None (Relaxed) |
|
0x2 |
Acquire |
|
0x4 |
Release |
|
0x8 |
AcquireRelease |
|
0x10 |
SequentiallyConsistent |
|
0x40 |
UniformMemory |
Shader |
0x80 |
SubgroupMemory |
|
0x100 |
WorkgroupMemory |
|
0x200 |
CrossWorkgroupMemory |
|
0x400 |
AtomicCounterMemory |
AtomicStorage |
0x800 |
ImageMemory |
|
0x1000 |
OutputMemory |
VulkanMemoryModel |
0x1000 |
OutputMemoryKHR |
VulkanMemoryModel |
0x2000 |
MakeAvailable |
VulkanMemoryModel |
0x2000 |
MakeAvailableKHR |
VulkanMemoryModel |
0x4000 |
MakeVisible |
VulkanMemoryModel |
0x4000 |
MakeVisibleKHR |
VulkanMemoryModel |
0x8000 |
Volatile |
VulkanMemoryModel |
3.26. Memory Operands
This is a literal mask; it can be formed by combining the bits from multiple rows in the table below.
Provides additional operands to the listed memory instructions. Bits that are set indicate whether an additional operand follows, as described by the table. If there are multiple following operands indicated, they are ordered: Those indicated by smaller-numbered bits appear first. An instruction needing two masks must first provide the first mask followed by the first mask’s additional operands, and then provide the second mask followed by the second mask’s additional operands.
Used by:
Memory Operands | Enabling Capabilities | |
---|---|---|
0x0 |
None |
|
0x1 |
Volatile |
|
0x2 |
Aligned |
|
0x4 |
Nontemporal |
|
0x8 |
MakePointerAvailable |
VulkanMemoryModel |
0x8 |
MakePointerAvailableKHR |
VulkanMemoryModel |
0x10 |
MakePointerVisible |
VulkanMemoryModel |
0x10 |
MakePointerVisibleKHR |
VulkanMemoryModel |
0x20 |
NonPrivatePointer |
VulkanMemoryModel |
0x20 |
NonPrivatePointerKHR |
VulkanMemoryModel |
3.27. Scope <id>
Must be an <id> of a 32-bit integer scalar. Its value is expected to be one of the values in the table below. If validation rules or the client API require a constant <id>, it is invalid for it to not be one of these values. If non-constant <id> are allowed, behavior is undefined if <id> is not one of these values.
If labeled as a memory scope, it specifies the distance of synchronization from the current invocation. If labeled as an execution scope, it specifies the set of executing invocations taking part in the operation. Other usages (neither memory nor execution) of scope are possible, and each such usage defines what scope means in its context.
Used by:
Scope | Enabling Capabilities | |
---|---|---|
0 |
CrossDevice |
|
1 |
Device |
|
2 |
Workgroup |
|
3 |
Subgroup |
|
4 |
Invocation |
|
5 |
QueueFamily |
VulkanMemoryModel |
5 |
QueueFamilyKHR |
VulkanMemoryModel |
6 |
ShaderCallKHR |
RayTracingKHR |
3.28. Group Operation
Defines the class of workgroup or subgroup operation.
Used by:
Group Operation | Enabling Capabilities | |
---|---|---|
0 |
Reduce |
Kernel, GroupNonUniformArithmetic, GroupNonUniformBallot |
1 |
InclusiveScan |
Kernel, GroupNonUniformArithmetic, GroupNonUniformBallot |
2 |
ExclusiveScan |
Kernel, GroupNonUniformArithmetic, GroupNonUniformBallot |
3 |
ClusteredReduce |
GroupNonUniformClustered |
6 |
PartitionedReduceNV |
GroupNonUniformPartitionedNV |
7 |
PartitionedInclusiveScanNV |
GroupNonUniformPartitionedNV |
8 |
PartitionedExclusiveScanNV |
GroupNonUniformPartitionedNV |
3.29. Kernel Enqueue Flags
Specify when the child kernel begins execution.
Note: Implementations are not required to honor this flag. Implementations may not schedule kernel launch earlier than the point specified by this flag, however. Used by OpEnqueueKernel.
Kernel Enqueue Flags | Enabling Capabilities | |
---|---|---|
0 |
NoWait |
Kernel |
1 |
WaitKernel |
Kernel |
2 |
WaitWorkGroup |
Kernel |
3.30. Kernel Profiling Info
The <id>'s value is a mask; it can be formed by combining the bits from multiple rows in the table below.
Specifies the profiling information to be queried. Used by OpCaptureEventProfilingInfo.
Kernel Profiling Info | Enabling Capabilities | |
---|---|---|
0x0 |
None |
|
0x1 |
CmdExecTime |
Kernel |
3.31. Capability
Capabilities a module can declare it uses.
All used capabilities need to be declared, either explicitly with OpCapability or implicitly through the Implicitly Declares column: If a capability defined with statically expressed rules is used, it is invalid to not declare it. If a capability defined in terms of dynamic behavior is used, behavior is undefined unless the capability is declared. The Implicitly Declares column lists additional capabilities that are all implicitly declared when the Capability entry is explicitly or implicitly declared. It is not necessary, but allowed, to explicitly declare an implicitly declared capability.
See the capabilities section for more detail.
Used by OpCapability.
Capability | Implicitly Declares | |
---|---|---|
0 |
Matrix |
|
1 |
Shader |
Matrix |
2 |
Geometry |
Shader |
3 |
Tessellation |
Shader |
4 |
Addresses |
|
5 |
Linkage |
|
6 |
Kernel |
|
7 |
Vector16 |
Kernel |
8 |
Float16Buffer |
Kernel |
9 |
Float16 |
|
10 |
Float64 |
|
11 |
Int64 |
|
12 |
Int64Atomics |
Int64 |
13 |
ImageBasic |
Kernel |
14 |
ImageReadWrite |
ImageBasic |
15 |
ImageMipmap |
ImageBasic |
17 |
Pipes |
Kernel |
18 |
Groups |
|
19 |
DeviceEnqueue |
Kernel |
20 |
LiteralSampler |
Kernel |
21 |
AtomicStorage |
Shader |
22 |
Int16 |
|
23 |
TessellationPointSize |
Tessellation |
24 |
GeometryPointSize |
Geometry |
25 |
ImageGatherExtended |
Shader |
27 |
StorageImageMultisample |
Shader |
28 |
UniformBufferArrayDynamicIndexing |
Shader |
29 |
SampledImageArrayDynamicIndexing |
Shader |
30 |
StorageBufferArrayDynamicIndexing |
Shader |
31 |
StorageImageArrayDynamicIndexing |
Shader |
32 |
ClipDistance |
Shader |
33 |
CullDistance |
Shader |
34 |
ImageCubeArray |
SampledCubeArray |
35 |
SampleRateShading |
Shader |
36 |
ImageRect |
SampledRect |
37 |
SampledRect |
Shader |
38 |
GenericPointer |
Addresses |
39 |
Int8 |
|
40 |
InputAttachment |
Shader |
41 |
SparseResidency |
Shader |
42 |
MinLod |
Shader |
43 |
Sampled1D |
|
44 |
Image1D |
Sampled1D |
45 |
SampledCubeArray |
Shader |
46 |
SampledBuffer |
|
47 |
ImageBuffer |
SampledBuffer |
48 |
ImageMSArray |
Shader |
49 |
StorageImageExtendedFormats |
Shader |
50 |
ImageQuery |
Shader |
51 |
DerivativeControl |
Shader |
52 |
InterpolationFunction |
Shader |
53 |
TransformFeedback |
Shader |
54 |
GeometryStreams |
Geometry |
55 |
StorageImageReadWithoutFormat |
Shader |
56 |
StorageImageWriteWithoutFormat |
Shader |
57 |
MultiViewport |
Geometry |
58 |
SubgroupDispatch |
DeviceEnqueue |
59 |
NamedBarrier |
Kernel |
60 |
PipeStorage |
Pipes |
61 |
GroupNonUniform |
Missing before version 1.3. |
62 |
GroupNonUniformVote |
GroupNonUniform |
63 |
GroupNonUniformArithmetic |
GroupNonUniform |
64 |
GroupNonUniformBallot |
GroupNonUniform |
65 |
GroupNonUniformShuffle |
GroupNonUniform |
66 |
GroupNonUniformShuffleRelative |
GroupNonUniform |
67 |
GroupNonUniformClustered |
GroupNonUniform |
68 |
GroupNonUniformQuad |
GroupNonUniform |
69 |
ShaderLayer |
Missing before version 1.5. |
70 |
ShaderViewportIndex |
Missing before version 1.5. |
4422 |
FragmentShadingRateKHR |
Shader |
4423 |
SubgroupBallotKHR |
Reserved. |
4427 |
DrawParameters |
Shader |
4431 |
SubgroupVoteKHR |
Reserved. |
4433 |
StorageBuffer16BitAccess |
Missing before version 1.3.
|
4433 |
StorageUniformBufferBlock16 |
Missing before version 1.3.
|
4434 |
UniformAndStorageBuffer16BitAccess |
StorageBuffer16BitAccess, StorageUniformBufferBlock16 |
4434 |
StorageUniform16 |
StorageBuffer16BitAccess, StorageUniformBufferBlock16 |
4435 |
StoragePushConstant16 |
Missing before version 1.3.
|
4436 |
StorageInputOutput16 |
Missing before version 1.3.
|
4437 |
DeviceGroup |
Missing before version 1.3.
|
4439 |
MultiView |
Shader |
4441 |
VariablePointersStorageBuffer |
Shader |
4442 |
VariablePointers |
VariablePointersStorageBuffer |
4445 |
AtomicStorageOps |
Reserved. |
4447 |
SampleMaskPostDepthCoverage |
Reserved. |
4448 |
StorageBuffer8BitAccess |
Missing before version 1.5.
|
4449 |
UniformAndStorageBuffer8BitAccess |
StorageBuffer8BitAccess |
4450 |
StoragePushConstant8 |
Missing before version 1.5.
|
4464 |
DenormPreserve |
Missing before version 1.4.
|
4465 |
DenormFlushToZero |
Missing before version 1.4.
|
4466 |
SignedZeroInfNanPreserve |
Missing before version 1.4.
|
4467 |
RoundingModeRTE |
Missing before version 1.4.
|
4468 |
RoundingModeRTZ |
Missing before version 1.4.
|
4471 |
RayQueryProvisionalKHR |
Shader |
4472 |
RayQueryKHR |
Shader |
4478 |
RayTraversalPrimitiveCullingKHR |
RayQueryKHR, RayTracingKHR |
4479 |
RayTracingKHR |
Shader |
5008 |
Float16ImageAMD |
Shader |
5009 |
ImageGatherBiasLodAMD |
Shader |
5010 |
FragmentMaskAMD |
Shader |
5013 |
StencilExportEXT |
Shader |
5015 |
ImageReadWriteLodAMD |
Shader |
5016 |
Int64ImageEXT |
Shader |
5055 |
ShaderClockKHR |
Shader |
5249 |
SampleMaskOverrideCoverageNV |
SampleRateShading |
5251 |
GeometryShaderPassthroughNV |
Geometry |
5254 |
ShaderViewportIndexLayerEXT |
MultiViewport |
5254 |
ShaderViewportIndexLayerNV |
MultiViewport |
5255 |
ShaderViewportMaskNV |
ShaderViewportIndexLayerNV |
5259 |
ShaderStereoViewNV |
ShaderViewportMaskNV |
5260 |
PerViewAttributesNV |
MultiView |
5265 |
FragmentFullyCoveredEXT |
Shader |
5266 |
MeshShadingNV |
Shader |
5282 |
ImageFootprintNV |
Reserved. |
5284 |
FragmentBarycentricNV |
Reserved. |
5288 |
ComputeDerivativeGroupQuadsNV |
Reserved. |
5291 |
FragmentDensityEXT |
Shader |
5291 |
ShadingRateNV |
Shader |
5297 |
GroupNonUniformPartitionedNV |
Reserved. |
5301 |
ShaderNonUniform |
Shader |
5301 |
ShaderNonUniformEXT |
Shader |
5302 |
RuntimeDescriptorArray |
Shader |
5302 |
RuntimeDescriptorArrayEXT |
Shader |
5303 |
InputAttachmentArrayDynamicIndexing |
InputAttachment |
5303 |
InputAttachmentArrayDynamicIndexingEXT |
InputAttachment |
5304 |
UniformTexelBufferArrayDynamicIndexing |
SampledBuffer |
5304 |
UniformTexelBufferArrayDynamicIndexingEXT |
SampledBuffer |
5305 |
StorageTexelBufferArrayDynamicIndexing |
ImageBuffer |
5305 |
StorageTexelBufferArrayDynamicIndexingEXT |
ImageBuffer |
5306 |
UniformBufferArrayNonUniformIndexing |
ShaderNonUniform |
5306 |
UniformBufferArrayNonUniformIndexingEXT |
ShaderNonUniform |
5307 |
SampledImageArrayNonUniformIndexing |
ShaderNonUniform |
5307 |
SampledImageArrayNonUniformIndexingEXT |
ShaderNonUniform |
5308 |
StorageBufferArrayNonUniformIndexing |
ShaderNonUniform |
5308 |
StorageBufferArrayNonUniformIndexingEXT |
ShaderNonUniform |
5309 |
StorageImageArrayNonUniformIndexing |
ShaderNonUniform |
5309 |
StorageImageArrayNonUniformIndexingEXT |
ShaderNonUniform |
5310 |
InputAttachmentArrayNonUniformIndexing |
InputAttachment, ShaderNonUniform |
5310 |
InputAttachmentArrayNonUniformIndexingEXT |
InputAttachment, ShaderNonUniform |
5311 |
UniformTexelBufferArrayNonUniformIndexing |
SampledBuffer, ShaderNonUniform |
5311 |
UniformTexelBufferArrayNonUniformIndexingEXT |
SampledBuffer, ShaderNonUniform |
5312 |
StorageTexelBufferArrayNonUniformIndexing |
ImageBuffer, ShaderNonUniform |
5312 |
StorageTexelBufferArrayNonUniformIndexingEXT |
ImageBuffer, ShaderNonUniform |
5340 |
RayTracingNV |
Shader |
5345 |
VulkanMemoryModel |
Missing before version 1.5. |
5345 |
VulkanMemoryModelKHR |
Missing before version 1.5.
|
5346 |
VulkanMemoryModelDeviceScope |
Missing before version 1.5. |
5346 |
VulkanMemoryModelDeviceScopeKHR |
Missing before version 1.5.
|
5347 |
PhysicalStorageBufferAddresses |
Shader |
5347 |
PhysicalStorageBufferAddressesEXT |
Shader |
5350 |
ComputeDerivativeGroupLinearNV |
Reserved. |
5353 |
RayTracingProvisionalKHR |
Shader |
5357 |
CooperativeMatrixNV |
Shader |
5363 |
FragmentShaderSampleInterlockEXT |
Shader |
5372 |
FragmentShaderShadingRateInterlockEXT |
Shader |
5373 |
ShaderSMBuiltinsNV |
Shader |
5378 |
FragmentShaderPixelInterlockEXT |
Shader |
5379 |
DemoteToHelperInvocationEXT |
Shader |
5568 |
SubgroupShuffleINTEL |
Reserved. |
5569 |
SubgroupBufferBlockIOINTEL |
Reserved. |
5570 |
SubgroupImageBlockIOINTEL |
Reserved. |
5579 |
SubgroupImageMediaBlockIOINTEL |
Reserved. |
5584 |
IntegerFunctions2INTEL |
Shader |
5603 |
FunctionPointersINTEL |
Reserved. |
5604 |
IndirectReferencesINTEL |
Reserved. |
5696 |
SubgroupAvcMotionEstimationINTEL |
Reserved. |
5697 |
SubgroupAvcMotionEstimationIntraINTEL |
Reserved. |
5698 |
SubgroupAvcMotionEstimationChromaINTEL |
Reserved. |
5824 |
FPGAMemoryAttributesINTEL |
Reserved. |
5886 |
UnstructuredLoopControlsINTEL |
Reserved. |
5888 |
FPGALoopControlsINTEL |
Reserved. |
5892 |
KernelAttributesINTEL |
Reserved. |
5897 |
FPGAKernelAttributesINTEL |
Reserved. |
5945 |
BlockingPipesINTEL |
Reserved. |
5948 |
FPGARegINTEL |
Reserved. |
6033 |
AtomicFloat32AddEXT |
Shader |
6034 |
AtomicFloat64AddEXT |
Shader |
3.32. Reserved Ray Flags
This is a literal mask; it can be formed by combining the bits from multiple rows in the table below.
Reserved Ray Flags | Enabling Capabilities | |
---|---|---|
0x0 |
None |
|
0x1 |
OpaqueKHR |
RayQueryKHR, RayTracingKHR |
0x2 |
NoOpaqueKHR |
RayQueryKHR, RayTracingKHR |
0x4 |
TerminateOnFirstHitKHR |
RayQueryKHR, RayTracingKHR |
0x8 |
SkipClosestHitShaderKHR |
RayQueryKHR, RayTracingKHR |
0x10 |
CullBackFacingTrianglesKHR |
RayQueryKHR, RayTracingKHR |
0x20 |
CullFrontFacingTrianglesKHR |
RayQueryKHR, RayTracingKHR |
0x40 |
CullOpaqueKHR |
RayQueryKHR, RayTracingKHR |
0x80 |
CullNoOpaqueKHR |
RayQueryKHR, RayTracingKHR |
0x100 |
SkipTrianglesKHR |
RayTraversalPrimitiveCullingKHR |
0x200 |
SkipAABBsKHR |
RayTraversalPrimitiveCullingKHR |
3.33. Reserved Ray Query Intersection
Reserved Ray Query Intersection | Enabling Capabilities | |
---|---|---|
0 |
RayQueryCandidateIntersectionKHR |
RayQueryKHR |
1 |
RayQueryCommittedIntersectionKHR |
RayQueryKHR |
3.34. Reserved Ray Query Committed Type
Reserved Ray Query Committed Type | Enabling Capabilities | |
---|---|---|
0 |
RayQueryCommittedIntersectionNoneKHR |
RayQueryKHR |
1 |
RayQueryCommittedIntersectionTriangleKHR |
RayQueryKHR |
2 |
RayQueryCommittedIntersectionGeneratedKHR |
RayQueryKHR |
3.35. Reserved Ray Query Candidate Type
Reserved Ray Query Candidate Type | Enabling Capabilities | |
---|---|---|
0 |
RayQueryCandidateIntersectionTriangleKHR |
RayQueryKHR |
1 |
RayQueryCandidateIntersectionAABBKHR |
RayQueryKHR |
3.36. Reserved Fragment Shading Rate
This is a literal mask; it can be formed by combining the bits from multiple rows in the table below.
Reserved Fragment Shading Rate | Enabling Capabilities | |
---|---|---|
0x0 |
None |
|
0x1 |
Vertical2Pixels |
FragmentShadingRateKHR |
0x2 |
Vertical4Pixels |
FragmentShadingRateKHR |
0x4 |
Horizontal2Pixels |
FragmentShadingRateKHR |
0x8 |
Horizontal4Pixels |
FragmentShadingRateKHR |
3.37. Instructions
Form for each instruction:
Opcode Name (name-alias, name-alias, …) |
Capability Enabling Capabilities |
||
Opcode |
Results |
Operands |
3.37.1. Miscellaneous Instructions
OpNop |
|
1 |
0 |
OpUndef |
|||
3 |
1 |
<id> |
OpSizeOf |
Capability: |
|||
4 |
321 |
<id> |
<id> |
3.37.2. Debug Instructions
OpSourceContinued |
||
2 + variable |
2 |
Literal |
OpSource |
|||||
3 + variable |
3 |
Literal |
Optional |
Optional |
OpSourceExtension |
||
2 + variable |
4 |
Literal |
OpName |
|||
3 + variable |
5 |
<id> |
Literal |
OpMemberName |
||||
4 + variable |
6 |
<id> |
Literal |
Literal |
OpString |
|||
3 + variable |
7 |
Literal |
OpLine |
||||
4 |
8 |
<id> |
Literal |
Literal |
OpNoLine |
|
1 |
317 |
OpModuleProcessed |
Missing before version 1.1. |
|
2 + variable |
330 |
Literal |
3.37.3. Annotation Instructions
OpDecorate |
||||
3 + variable |
71 |
<id> |
Literal, Literal, … |
OpMemberDecorate |
|||||
4 + variable |
72 |
<id> |
Literal |
Literal, Literal, … |
OpDecorationGroup |
||
2 |
73 |
OpGroupDecorate |
|||
2 + variable |
74 |
<id> |
<id>, <id>, … |
OpGroupMemberDecorate |
|||
2 + variable |
75 |
<id> |
<id>, literal, |
OpDecorateId |
Missing before version 1.2. |
|||
3 + variable |
332 |
<id> |
<id>, <id>, … |
OpDecorateString (OpDecorateStringGOOGLE) |
Missing before version 1.4. |
||||
4 + variable |
5632 |
<id> |
Literal |
Optional Literals |
OpMemberDecorateString (OpMemberDecorateStringGOOGLE) |
Missing before version 1.4. |
|||||
5 + variable |
5633 |
<id> |
Literal |
Literal |
Optional Literals |
3.37.4. Extension Instructions
OpExtension |
||
2 + variable |
10 |
Literal |
OpExtInstImport |
|||
3 + variable |
11 |
Literal |
OpExtInst |
||||||
5 + variable |
12 |
<id> |
<id> |
Literal |
<id>, <id>, … |
3.37.5. Mode-Setting Instructions
OpMemoryModel |
|||
3 |
14 |
OpEntryPoint |
|||||
4 + variable |
15 |
<id> |
Literal |
<id>, <id>, … |
OpExecutionMode |
||||
3 + variable |
16 |
<id> |
Execution Mode |
Literal, Literal, … |
OpCapability |
||
2 |
17 |
Capability |
OpExecutionModeId |
Missing before version 1.2. |
|||
3 + variable |
331 |
<id> |
Execution Mode |
<id>, <id>, … |
3.37.6. Type-Declaration Instructions
2 |
19 |
OpTypeBool |
||
2 |
20 |
OpTypeInt |
||||
4 |
21 |
Literal |
Literal |
OpTypeFloat |
|||
3 |
22 |
Literal |
OpTypeVector |
||||
4 |
23 |
<id> |
Literal |
OpTypeMatrix |
Capability: |
|||
4 |
24 |
<id> |
Literal |
OpTypeImage |
||||||||||
9 + variable |
25 |
<id> |
Literal |
Literal |
Literal |
Literal |
Optional |
OpTypeSampler |
||
2 |
26 |
OpTypeSampledImage |
|||
3 |
27 |
<id> |
OpTypeArray |
||||
4 |
28 |
<id> |
<id> |
OpTypeRuntimeArray |
Capability: |
||
3 |
29 |
<id> |
OpTypeStruct |
|||
2 + variable |
30 |
<id>, <id>, … |
OpTypeOpaque |
Capability: |
||
3 + variable |
31 |
Literal |
OpTypePointer |
||||
4 |
32 |
<id> |
OpTypeFunction |
||||
3 + variable |
33 |
<id> |
<id>, <id>, … |
Capability: |
||
2 |
34 |
Capability: |
||
2 |
35 |
Capability: |
||
2 |
36 |
Capability: |
||
2 |
37 |
OpTypePipe |
Capability: |
||
3 |
38 |
Access Qualifier |
OpTypeForwardPointer |
Capability: |
||
3 |
39 |
<id> |
Capability: |
||
2 |
322 |
Capability: |
||
2 |
327 |
3.37.7. Constant-Creation Instructions
OpConstantTrue |
|||
3 |
41 |
<id> |
OpConstantFalse |
|||
3 |
42 |
<id> |
OpConstant |
||||
4 + variable |
43 |
<id> |
Literal |
OpConstantComposite |
||||
3 + variable |
44 |
<id> |
<id>, <id>, … |
OpConstantSampler |
Capability: |
|||||
6 |
45 |
<id> |
Literal |
OpConstantNull |
|||
3 |
46 |
<id> |
OpSpecConstantTrue |
|||
3 |
48 |
<id> |
OpSpecConstantFalse |
|||
3 |
49 |
<id> |
OpSpecConstant |
||||
4 + variable |
50 |
<id> |
Literal |
OpSpecConstantComposite |
||||
3 + variable |
51 |
<id> |
<id>, <id>, … |
OpSpecConstantOp |
|||||
4 + variable |
52 |
<id> |
Literal |
<id>, <id>, … |
3.37.8. Memory Instructions
OpVariable |
|||||
4 + variable |
59 |
<id> |
Optional |
OpImageTexelPointer |
||||||
6 |
60 |
<id> |
<id> |
<id> |
<id> |
OpLoad |
|||||
4 + variable |
61 |
<id> |
<id> |
Optional |
OpStore |
||||
3 + variable |
62 |
<id> |
<id> |
Optional |
OpCopyMemory |
|||||
3 + variable |
63 |
<id> |
<id> |
Optional |
Optional |
OpCopyMemorySized |
Capability: |
|||||
4 + variable |
64 |
<id> |
<id> |
<id> |
Optional |
Optional |
OpAccessChain |
|||||
4 + variable |
65 |
<id> |
<id> |
<id>, <id>, … |
OpInBoundsAccessChain |
|||||
4 + variable |
66 |
<id> |
<id> |
<id>, <id>, … |
OpPtrAccessChain |
Capability: |
|||||
5 + variable |
67 |
<id> |
<id> |
<id> |
<id>, <id>, … |
OpArrayLength |
Capability: |
||||
5 |
68 |
<id> |
<id> |
Literal |
OpGenericPtrMemSemantics |
Capability: |
|||
4 |
69 |
<id> |
<id> |
OpInBoundsPtrAccessChain |
Capability: |
|||||
5 + variable |
70 |
<id> |
<id> |
<id> |
<id>, <id>, … |
OpPtrEqual |
Missing before version 1.4. |
||||
5 |
401 |
<id> |
<id> |
<id> |
OpPtrNotEqual |
Missing before version 1.4. |
||||
5 |
402 |
<id> |
<id> |
<id> |
OpPtrDiff |
Capability: |
||||
5 |
403 |
<id> |
<id> |
<id> |
3.37.9. Function Instructions
OpFunction |
|||||
5 |
54 |
<id> |
<id> |
OpFunctionParameter |
|||
3 |
55 |
<id> |
1 |
56 |
OpFunctionCall |
|||||
4 + variable |
57 |
<id> |
<id> |
<id>, <id>, … |
3.37.10. Image Instructions
OpSampledImage |
|||||
5 |
86 |
<id> |
<id> |
<id> |
OpImageSampleImplicitLod |
Capability: |
||||||
5 + variable |
87 |
<id> |
<id> |
<id> |
Optional |
Optional |
OpImageSampleExplicitLod |
||||||||
7 + variable |
88 |
<id> |
<id> |
<id> |
<id> |
Optional |
OpImageSampleDrefImplicitLod |
Capability: |
|||||||
6 + variable |
89 |
<id> |
<id> |
<id> |
<id> |
Optional |
Optional |
OpImageSampleDrefExplicitLod |
Capability: |
||||||||
8 + variable |
90 |
<id> |
<id> |
<id> |
<id> |
<id> |
Optional |
OpImageSampleProjImplicitLod |
Capability: |
||||||
5 + variable |
91 |
<id> |
<id> |
<id> |
Optional |
Optional |
OpImageSampleProjExplicitLod |
Capability: |
|||||||
7 + variable |
92 |
<id> |
<id> |
<id> |
<id> |
Optional |
OpImageSampleProjDrefImplicitLod |
Capability: |
|||||||
6 + variable |
93 |
<id> |
<id> |
<id> |
<id> |
Optional |
Optional |
OpImageSampleProjDrefExplicitLod |
Capability: |
||||||||
8 + variable |
94 |
<id> |
<id> |
<id> |
<id> |
<id> |
Optional |
OpImageFetch |
|||||||
5 + variable |
95 |
<id> |
<id> |
<id> |
Optional |
Optional |
OpImageGather |
Capability: |
|||||||
6 + variable |
96 |
<id> |
<id> |
<id> |
<id> |
Optional |
Optional |
OpImageDrefGather |
Capability: |
|||||||
6 + variable |
97 |
<id> |
<id> |
<id> |
<id> |
Optional |
Optional |
OpImageRead |
|||||||
5 + variable |
98 |
<id> |
<id> |
<id> |
Optional |
Optional |
OpImageWrite |
||||||
4 + variable |
99 |
<id> |
<id> |
<id> |
Optional |
Optional |
OpImage |
||||
4 |
100 |
<id> |
<id> |
OpImageQueryFormat |
Capability: |
|||
4 |
101 |
<id> |
<id> |
OpImageQueryOrder |
Capability: |
|||
4 |
102 |
<id> |
<id> |
OpImageQuerySizeLod |
Capability: |
||||
5 |
103 |
<id> |
<id> |
<id> |
OpImageQuerySize |
Capability: |
|||
4 |
104 |
<id> |
<id> |
OpImageQueryLod |
Capability: |
||||
5 |
105 |
<id> |
<id> |
<id> |
OpImageQueryLevels |
Capability: |
|||
4 |
106 |
<id> |
<id> |
OpImageQuerySamples |
Capability: |
|||
4 |
107 |
<id> |
<id> |
OpImageSparseSampleImplicitLod |
Capability: |
||||||
5 + variable |
305 |
<id> |
<id> |
<id> |
Optional |
Optional |
OpImageSparseSampleExplicitLod |
Capability: |
|||||||
7 + variable |
306 |
<id> |
<id> |
<id> |
<id> |
Optional |
OpImageSparseSampleDrefImplicitLod |
Capability: |
|||||||
6 + variable |
307 |
<id> |
<id> |
<id> |
<id> |
Optional |
Optional |
OpImageSparseSampleDrefExplicitLod |
Capability: |
||||||||
8 + variable |
308 |
<id> |
<id> |
<id> |
<id> |
<id> |
Optional |
OpImageSparseSampleProjImplicitLod |
Capability: |
||||||
5 + variable |
309 |
<id> |
<id> |
<id> |
Optional |
Optional |
OpImageSparseSampleProjExplicitLod |
Capability: |
|||||||
7 + variable |
310 |
<id> |
<id> |
<id> |
<id> |
Optional |
OpImageSparseSampleProjDrefImplicitLod |
Capability: |
|||||||
6 + variable |
311 |
<id> |
<id> |
<id> |
<id> |
Optional |
Optional |
OpImageSparseSampleProjDrefExplicitLod |
Capability: |
||||||||
8 + variable |
312 |
<id> |
<id> |
<id> |
<id> |
<id> |
Optional |
OpImageSparseFetch |
Capability: |
||||||
5 + variable |
313 |
<id> |
<id> |
<id> |
Optional |
Optional |
OpImageSparseGather |
Capability: |
|||||||
6 + variable |
314 |
<id> |
<id> |
<id> |
<id> |
Optional |
Optional |
OpImageSparseDrefGather |
Capability: |
|||||||
6 + variable |
315 |
<id> |
<id> |
<id> |
<id> |
Optional |
Optional |
OpImageSparseTexelsResident |
Capability: |
|||
4 |
316 |
<id> |
<id> |
OpImageSparseRead |
Capability: |
||||||
5 + variable |
320 |
<id> |
<id> |
<id> |
Optional |
Optional |
Capability: |
|||||||||
7 + variable |
5283 |
<id> |
<id> |
<id> |
<id> |
<id> |
Optional |
Optional |
3.37.11. Conversion Instructions
OpConvertFToU |
||||
4 |
109 |
<id> |
<id> |
OpConvertFToS |
||||
4 |
110 |
<id> |
<id> |
OpConvertSToF |
||||
4 |
111 |
<id> |
<id> |
OpConvertUToF |
||||
4 |
112 |
<id> |
<id> |
OpUConvert |
||||
4 |
113 |
<id> |
<id> |
OpSConvert |
||||
4 |
114 |
<id> |
<id> |
OpFConvert |
||||
4 |
115 |
<id> |
<id> |
OpQuantizeToF16 |
Capability: |
|||
4 |
116 |
<id> |
<id> |
OpConvertPtrToU |
Capability: |
|||
4 |
117 |
<id> |
<id> |
OpSatConvertSToU |
Capability: |
|||
4 |
118 |
<id> |
<id> |
OpSatConvertUToS |
Capability: |
|||
4 |
119 |
<id> |
<id> |
OpConvertUToPtr |
Capability: |
|||
4 |
120 |
<id> |
<id> |
OpPtrCastToGeneric |
Capability: |
|||
4 |
121 |
<id> |
<id> |
OpGenericCastToPtr |
Capability: |
|||
4 |
122 |
<id> |
<id> |
OpGenericCastToPtrExplicit |
Capability: |
||||
5 |
123 |
<id> |
<id> |
Storage Class |
OpBitcast |
||||
4 |
124 |
<id> |
<id> |
3.37.12. Composite Instructions
OpVectorExtractDynamic |
|||||
5 |
77 |
<id> |
<id> |
<id> |
OpVectorInsertDynamic |
||||||
6 |
78 |
<id> |
<id> |
<id> |
<id> |
OpVectorShuffle |
||||||
5 + variable |
79 |
<id> |
<id> |
<id> |
Literal, Literal, … |
OpCompositeConstruct |
||||
3 + variable |
80 |
<id> |
<id>, <id>, … |
OpCompositeExtract |
|||||
4 + variable |
81 |
<id> |
<id> |
Literal, Literal, … |
OpCompositeInsert |
||||||
5 + variable |
82 |
<id> |
<id> |
<id> |
Literal, Literal, … |
OpCopyObject |
||||
4 |
83 |
<id> |
<id> |
OpTranspose |
Capability: |
|||
4 |
84 |
<id> |
<id> |
OpCopyLogical |
Missing before version 1.4. |
|||
4 |
400 |
<id> |
<id> |
3.37.13. Arithmetic Instructions
OpSNegate |
||||
4 |
126 |
<id> |
<id> |
OpFNegate |
||||
4 |
127 |
<id> |
<id> |
OpIAdd |
|||||
5 |
128 |
<id> |
<id> |
<id> |
OpFAdd |
|||||
5 |
129 |
<id> |
<id> |
<id> |
OpISub |
|||||
5 |
130 |
<id> |
<id> |
<id> |
OpFSub |
|||||
5 |
131 |
<id> |
<id> |
<id> |
OpIMul |
|||||
5 |
132 |
<id> |
<id> |
<id> |
OpFMul |
|||||
5 |
133 |
<id> |
<id> |
<id> |
OpUDiv |
|||||
5 |
134 |
<id> |
<id> |
<id> |
OpSDiv |
|||||
5 |
135 |
<id> |
<id> |
<id> |
OpFDiv |
|||||
5 |
136 |
<id> |
<id> |
<id> |
OpUMod |
|||||
5 |
137 |
<id> |
<id> |
<id> |
OpSRem |
|||||
5 |
138 |
<id> |
<id> |
<id> |
OpSMod |
|||||
5 |
139 |
<id> |
<id> |
<id> |
OpFRem |
|||||
5 |
140 |
<id> |
<id> |
<id> |
OpFMod |
|||||
5 |
141 |
<id> |
<id> |
<id> |
OpVectorTimesScalar |
|||||
5 |
142 |
<id> |
<id> |
<id> |
OpMatrixTimesScalar |
Capability: |
||||
5 |
143 |
<id> |
<id> |
<id> |
OpVectorTimesMatrix |
Capability: |
||||
5 |
144 |
<id> |
<id> |
<id> |
OpMatrixTimesVector |
Capability: |
||||
5 |
145 |
<id> |
<id> |
<id> |
OpMatrixTimesMatrix |
Capability: |
||||
5 |
146 |
<id> |
<id> |
<id> |
OpOuterProduct |
Capability: |
||||
5 |
147 |
<id> |
<id> |
<id> |
OpDot |
|||||
5 |
148 |
<id> |
<id> |
<id> |
OpIAddCarry |
|||||
5 |
149 |
<id> |
<id> |
<id> |
OpISubBorrow |
|||||
5 |
150 |
<id> |
<id> |
<id> |
OpUMulExtended |
|||||
5 |
151 |
<id> |
<id> |
<id> |
OpSMulExtended |
|||||
5 |
152 |
<id> |
<id> |
<id> |
3.37.14. Bit Instructions
OpShiftRightLogical |
|||||
5 |
194 |
<id> |
<id> |
<id> |
OpShiftRightArithmetic |
|||||
5 |
195 |
<id> |
<id> |
<id> |
OpShiftLeftLogical |
|||||
5 |
196 |
<id> |
<id> |
<id> |
OpBitwiseOr |
|||||
5 |
197 |
<id> |
<id> |
<id> |
OpBitwiseXor |
|||||
5 |
198 |
<id> |
<id> |
<id> |
OpBitwiseAnd |
|||||
5 |
199 |
<id> |
<id> |
<id> |
OpNot |
||||
4 |
200 |
<id> |
<id> |
OpBitFieldInsert |
Capability: |
||||||
7 |
201 |
<id> |
<id> |
<id> |
<id> |
<id> |
OpBitFieldSExtract |
Capability: |
|||||
6 |
202 |
<id> |
<id> |
<id> |
<id> |
OpBitFieldUExtract |
Capability: |
|||||
6 |
203 |
<id> |
<id> |
<id> |
<id> |
OpBitReverse |
Capability: |
|||
4 |
204 |
<id> |
<id> |
OpBitCount |
||||
4 |
205 |
<id> |
<id> |
3.37.15. Relational and Logical Instructions
OpAny |
||||
4 |
154 |
<id> |
<id> |
OpAll |
||||
4 |
155 |
<id> |
<id> |
OpIsNan |
||||
4 |
156 |
<id> |
<id> |
OpIsInf |
||||
4 |
157 |
<id> |
<id> |
OpIsFinite |
Capability: |
|||
4 |
158 |
<id> |
<id> |
OpIsNormal |
Capability: |
|||
4 |
159 |
<id> |
<id> |
OpSignBitSet |
Capability: |
|||
4 |
160 |
<id> |
<id> |
OpLessOrGreater |
Capability: |
||||
5 |
161 |
<id> |
<id> |
<id> |
OpOrdered |
Capability: |
||||
5 |
162 |
<id> |
<id> |
<id> |
OpUnordered |
Capability: |
||||
5 |
163 |
<id> |
<id> |
<id> |
OpLogicalEqual |
|||||
5 |
164 |
<id> |
<id> |
<id> |
OpLogicalNotEqual |
|||||
5 |
165 |
<id> |
<id> |
<id> |
OpLogicalOr |
|||||
5 |
166 |
<id> |
<id> |
<id> |
OpLogicalAnd |
|||||
5 |
167 |
<id> |
<id> |
<id> |
OpLogicalNot |
||||
4 |
168 |
<id> |
<id> |
OpSelect |
||||||
6 |
169 |
<id> |
<id> |
<id> |
<id> |
OpIEqual |
|||||
5 |
170 |
<id> |
<id> |
<id> |
OpINotEqual |
|||||
5 |
171 |
<id> |
<id> |
<id> |
OpUGreaterThan |
|||||
5 |
172 |
<id> |
<id> |
<id> |
OpSGreaterThan |
|||||
5 |
173 |
<id> |
<id> |
<id> |
OpUGreaterThanEqual |
|||||
5 |
174 |
<id> |
<id> |
<id> |
OpSGreaterThanEqual |
|||||
5 |
175 |
<id> |
<id> |
<id> |
OpULessThan |
|||||
5 |
176 |
<id> |
<id> |
<id> |
OpSLessThan |
|||||
5 |
177 |
<id> |
<id> |
<id> |
OpULessThanEqual |
|||||
5 |
178 |
<id> |
<id> |
<id> |
OpSLessThanEqual |
|||||
5 |
179 |
<id> |
<id> |
<id> |
OpFOrdEqual |
|||||
5 |
180 |
<id> |
<id> |
<id> |
OpFUnordEqual |
|||||
5 |
181 |
<id> |
<id> |
<id> |
OpFOrdNotEqual |
|||||
5 |
182 |
<id> |
<id> |
<id> |
OpFUnordNotEqual |
|||||
5 |
183 |
<id> |
<id> |
<id> |
OpFOrdLessThan |
|||||
5 |
184 |
<id> |
<id> |
<id> |
OpFUnordLessThan |
|||||
5 |
185 |
<id> |
<id> |
<id> |
OpFOrdGreaterThan |
|||||
5 |
186 |
<id> |
<id> |
<id> |
OpFUnordGreaterThan |
|||||
5 |
187 |
<id> |
<id> |
<id> |
OpFOrdLessThanEqual |
|||||
5 |
188 |
<id> |
<id> |
<id> |
OpFUnordLessThanEqual |
|||||
5 |
189 |
<id> |
<id> |
<id> |
OpFOrdGreaterThanEqual |
|||||
5 |
190 |
<id> |
<id> |
<id> |
OpFUnordGreaterThanEqual |
|||||
5 |
191 |
<id> |
<id> |
<id> |
3.37.16. Derivative Instructions
OpDPdx |
Capability: |
|||
4 |
207 |
<id> |
<id> |
OpDPdy |
Capability: |
|||
4 |
208 |
<id> |
<id> |
OpFwidth |
Capability: |
|||
4 |
209 |
<id> |
<id> |
OpDPdxFine |
Capability: |
|||
4 |
210 |
<id> |
<id> |
OpDPdyFine |
Capability: |
|||
4 |
211 |
<id> |
<id> |
OpFwidthFine |
Capability: |
|||
4 |
212 |
<id> |
<id> |