Copyright 2014-2023 The Khronos Group Inc.
This Specification is protected by copyright laws and contains material proprietary to Khronos. Except as described by these terms, 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.
This Specification has been created under the Khronos Intellectual Property Rights Policy, which is Attachment A of the Khronos Group Membership Agreement available at www.khronos.org/files/member_agreement.pdf.
Khronos grants a conditional copyright license to use and reproduce the unmodified Specification for any purpose, without fee or royalty, EXCEPT no licenses to any patent, trademark or other intellectual property rights are granted under these terms. Parties desiring to implement the Specification and make use of Khronos trademarks in relation to that implementation, and receive reciprocal patent license protection under the Khronos Intellectual Property Rights Policy must become Adopters and confirm the implementation as conformant under the process defined by Khronos for this Specification; see https://www.khronos.org/adopters.
Khronos makes no, and expressly disclaims any, representations or warranties, express or implied, regarding this Specification, including, without limitation: merchantability, fitness for a particular purpose, non-infringement of any intellectual property, correctness, accuracy, completeness, timeliness, and reliability. Under no circumstances will Khronos, 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.
This Specification contains substantially unmodified functionality from, and is a successor to, Khronos specifications including all versions of "The SPIR Specification", "The OpenGL Shading Language", "The OpenGL ES Shading Language", as well as all Khronos OpenCL API and OpenCL programming language specifications.
The Khronos Intellectual Property Rights Policy defines the terms Scope, Compliant Portion, and Necessary Patent Claims.
Some parts of this Specification are purely informative and so are EXCLUDED from the Scope of this Specification. Section 1.3 "About This Document" defines how these parts of the Specification are identified.
Where this Specification uses technical terminology, defined in the Glossary or otherwise, that refer to enabling technologies that are not expressly set forth in this Specification, those enabling technologies are EXCLUDED from the Scope of this Specification. For clarity, enabling technologies not disclosed with particularity in this Specification (e.g. semiconductor manufacturing technology, hardware architecture, processor architecture or microarchitecture, memory architecture, compiler technology, object oriented technology, basic operating system technology, compression technology, algorithms, and so on) are NOT to be considered expressly set forth; only those application program interfaces and data structures disclosed with particularity are included in the Scope of this Specification.
For purposes of the Khronos Intellectual Property Rights Policy as it relates to the definition of Necessary Patent Claims, all recommended or optional features, behaviors and functionality set forth in this Specification, if implemented, are considered to be included as Compliant Portions.
Khronos® and Vulkan® are registered trademarks, and ANARI™, WebGL™, glTF™, NNEF™, OpenVX™, SPIR™, SPIR-V™, SYCL™, OpenVG™, Vulkan SC™, 3D Commerce™ and Kamaros™ are trademarks of The Khronos Group Inc. OpenXR™ is a trademark owned by The Khronos Group Inc. and is registered as a trademark in China, the European Union, Japan and the United Kingdom. OpenCL™ is a trademark of Apple Inc. used under license by Khronos. OpenGL® is a registered trademark and the OpenGL ES™ and OpenGL SC™ logos are trademarks of Hewlett Packard Enterprise used under license by Khronos. ASTC is a trademark of ARM Holdings PLC. 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
-
Jeff Bolz, NVIDIA
-
Stuart Brady, Arm
-
Gordon Brown, Codeplay
-
Pat Brown, NVIDIA
-
Nate Cesario, LunarG
-
Diana Po-Yu Chen, MediaTek
-
Stephen Clarke, Imagination
-
Joshua Davis, Unity
-
Hugo Devillers, University of Saarland
-
Patrick Doane, Blizzard Entertainment
-
Alastair Donaldson, Google
-
Yuehai Du, Qualcomm
-
Stefanus Du Toit, Google
-
Faith Ekstrand, Collabora
-
Gregory Fischer, LunarG
-
Theresa Foley, Intel
-
Spencer Fricke, Samsung
-
Ben Gaster, Qualcomm
-
Alexander Galazin, ARM
-
Christopher Gautier, ARM
-
Arcady Goldmints, LunarG
-
Jeremy Hayes, LunarG
-
Tobias Hector, AMD
-
Nicolai Hahnle, AMD
-
Neil Henning, AMD
-
Kerch Holt, NVIDIA
-
Lee Howes, Qualcomm
-
Samuel Huang, Mediatek
-
Marty Johnson, Khronos
-
Roy Ju, MediaTek
-
Baldur Karlsson, Valve
-
Ronan Keryell, Xilinx
-
John Kessenich, Google
-
Wooyoung Kim, Qualcomm
-
Vasileios Klimis, Imperial College London
-
Daniel Koch, NVIDIA
-
Ashwin Kolhe, NVIDIA
-
Tim Kong, Samsung
-
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
-
Kevin Petit, Arm
-
Robert Quill, Imagination Technologies
-
Christophe Riccio, Unity
-
Andrew Richards, Codeplay
-
Ian Romanick, Intel
-
Graham Sellers, AMD
-
Simon Waters, Samsung
-
Robert Simpson, Qualcomm
-
Pradyuman Singh, NVIDIA
-
Bartosz Sochacki, Intel
-
Nikos Stavropoulos, Think Silicon
-
Brian Sumner, AMD
-
John Wickerson, Imperial College London
-
Andrew Woloszyn, Google
-
Robin Voetter, StreamHPC
-
Ruihao Zhang, Qualcomm
-
Weifeng Zhang, Qualcomm
1. Introduction
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/) |
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. All string comparisons are case sensitive. 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.
Constant Instruction: Either a specialization-constant instruction or a non-specialization constant instruction: Instructions that start "OpConstant" or "OpSpec".
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 block termination instruction. A block has no additional label or block termination instructions.
Branch Instruction: One of the following, used as a block termination instruction:
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.
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.
Selection Header: A header block whose merge instruction is an OpSelectionMerge and whose termination instruction is an OpBranchConditional.
Switch Header: A header block whose merge instruction is an OpSelectionMerge and whose termination instruction is an OpSwitch.
Merge Block: A block declared by the Merge Block operand of a merge instruction.
Branch Edge: There is a branch edge from block A to block B if the terminator of A is a branch instruction and B is one of the target blocks for the branch instruction.
Merge Edge: There is a merge edge from block A to block B if A contains a merge instruction and B is the merge block of this merge instruction.
Continue Edge: There is a continue edge from block A to block B if A is a loop header and B is the Continue Target of the loop header’s OpLoopMerge instruction.
Structured Control-Flow Edge: There is a structured control-flow edge from block A to block B if there is a branch edge, merge edge, or continue edge from A to B.
Back Edge: A branch edge that
branches to one of its ancestors in a depth-first search over
structured control-flow edges starting
at the function’s entry block.
Note: When all loops are structured, each back edge corresponds to exactly
one loop header, and vice versa, making this set of back edges invariant with
respect to which depth-first search found them.
This implies that the CFG defined by the function’s structured control-flow edges is reducible.
Back-Edge Block: If there is a back edge from block A to block B then A is a back-edge block.
Path: A sequence of blocks B0, B1, …, Bn where for each 0 <= i < n there is a branch edge from Bi to Bi+1. This forms a path from B0 to Bn.
Structured Control-Flow Path: A sequence of blocks B0, B1, …, Bn where for each 0 <= i < n there is a structured control-flow edge from Bi to Bi+1. This forms a structured control-flow path from B0 to Bn
Structurally Reachable: A block B is structurally reachable if there exists a structured control-flow path from the entry block of the function containing B to B.
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 block to block B includes block A. A strictly dominates B if A dominates B and A and B are different blocks.
Structurally Dominate: A block A structurally dominates a block B, where A and B are in the same function, if every structured control-flow path from the function’s entry block to block B includes block A. A strictly structurally dominates B if A structurally dominates B and A and B are different blocks.
Structurally Post Dominate: A block B structurally post dominates a block A, where A and B are in the same function, if every structured control-flow path from A to a function termination instruction includes block B.
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.
Group (Invocations): The set of invocations that participate in a tangled instruction. The specific set is determined by the instruction.
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. It has a size of exactly 4 invocations.
Quad index: The index of an invocation in a quad.
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. A subgroup’s size is defined by the maximum of the current values of the SubgroupSize and SubgroupMaxSize built-in variables.
Cluster: A partition of invocations in a subgroup. Invocations are partitioned into clusters based on their subgroup local invocation ID and the per-instruction cluster size ClusterSize, with ClusterSize invocations per cluster. The first ClusterSize invocations with the smallest subgroup local invocation IDs are assigned to the first cluster, then the next ClusterSize remaining invocations with the smallest local invocation IDs are assigned to the next cluster, and so on. Invocations in a cluster may be active or inactive. If the current value of the SubgroupSize built-in variable is not evenly divisible by the cluster size then the additional invocations in the last cluster are considered inactive.
Workgroup: The set of invocations partitioned in some execution models (e.g. GLCompute, Kernel) as a workgroup. Its size is defined statically by either the WorkgroupSize built-in or the LocalSize or LocalSizeId Execution Modes, or can be queried via the WorkgroupSize built-in. These values can be defined in multiple dimensions, and its total size is the product of the size in each specified dimension.
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:
-
Non-semantic instructions with OpExtInst.
-
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 block 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. (Control flow may partially or fully reconverge before reaching the merge block so long as it converges by the time the merge block is reached.) These blocks delimit constructs that must nest, and must be entered and exited in structured ways, as per the following.
2.11.1. Rules for Structured Control-flow Declarations
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 structurally dominate its merge block
-
all 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 merge block, OpLoopMerge Continue Target, and corresponding back-edge block:
-
the Continue Target and merge block must be different blocks
-
the loop header must structurally dominate the Continue Target
-
the Continue Target must structurally dominate the back-edge block
-
the back-edge block must structurally post dominate the Continue Target
-
2.11.2. Structured Control-flow Constructs
A structured control-flow construct is defined as one of:
-
a selection construct: the blocks structurally dominated by a selection header, excluding blocks structurally dominated by the selection header’s merge block
-
a continue construct: the blocks that are both structurally dominated by an OpLoopMerge Continue Target and structurally post dominated by the corresponding loop’s back-edge block
-
a loop construct: the blocks structurally dominated by a loop header, excluding both the loop header’s continue construct and the blocks structurally dominated by the loop header’s merge block
-
a switch construct: the blocks structurally dominated by a switch header, excluding blocks structurally dominated by the switch header’s merge block
-
a case construct: the blocks structurally dominated by an OpSwitch Target or Default block, excluding the blocks structurally dominated by the OpSwitch construct’s corresponding merge block (note that as a consequence of this definition, an OpSwitch Target or Default block that is equal to the OpSwitch’s corresponding merge block does not give rise to a case construct)
2.11.3. Rules for Structured Control-flow Constructs
Below, we will use the following terminology:
-
A branch edge from block A to block B exits a structured control-flow construct S if and only if A is contained in S and B is not contained in S
-
A single-block loop is a loop construct where the loop’s header block, continue target and back-edge block are all the same.
-
The header block of a continue construct is the continue target of the associated loop.
-
The header block of a case construct is the OpSwitch Target or Default block that defines the case construct.
If the header block of a structured control-flow construct is structurally reachable then that structured control-flow construct must satisfy the following rules:
-
if a branch edge from block A to block B exits the structured control-flow construct S, then the exit must correspond to one of the following:
-
Breaking from a selection construct: S is a selection construct, S is the innermost structured control-flow construct containing A, and B is the merge block for S
-
Breaking from the innermost loop: S is the innermost loop construct containing A, and B is the merge block for S
-
Entering the innermost loop’s continue construct: S is the innermost loop construct containing A, and B is the continue target for S
-
Next loop iteration: the branch edge from A to B is a back edge (so that S is the continue construct of the associated loop)
-
Branching from back-edge block to loop merge: A is the back-edge block for a loop construct (so that S is the continue construct of the associated loop), and B is the merge block for the loop construct
-
Branching from one case construct to another: S is a case construct associated with an OpSwitch instruction, and B is a target block or default block associated with the OpSwitch instruction
-
Breaking from the innermost switch construct without breaking from a loop: S is the innermost switch construct containing A, B is the merge block for S, and the branch from A to B does not exit a loop construct
-
-
a branch edge that exits a continue construct must branch to the header block or merge block of the associated loop
-
for a loop construct that is not a single block loop, if there is a branch edge from a block B to the loop’s continue target that is not a back edge, then B must belong to the loop construct
-
if a structured control-flow construct S contains the header block for a selection, loop or switch construct different from S, then S must also contain that construct’s merge block
-
all branches into a selection, loop or switch construct from structurally-reachable blocks outside the construct must be to the construct’s header block
-
for a switch construct S with associated OpSwitch instruction:
-
the header block for S must structurally dominate every case construct associated with S
-
each case construct associated with S must not branch to more than one other case construct associated with S
-
each case construct associated with S must not be branched to by more than one other case construct associated with S
-
if T1 and T2 appear as labels of targets in the OpSwitch instruction and the case construct defined by T1 branches to the case construct defined by T2 then the last target with label T1 must immediately precede the first target with label T2 in the list of OpSwitch Target operands
-
if T1 and T2 appear as labels of targets in the OpSwitch instruction and the case construct defined by T1 branches to the Default case construct of the OpSwitch which in turn branches to the case construct defined by T2, then either:
-
the block that defines the Default case construct must appear as a target label in the OpSwitch instruction, or
-
the last target with label T1 must immediately precede the first target with label T2 in the list of OpSwitch Target operands
-
-
for any label T, all targets with label T must appear consecutively in the list of 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 must only be applied to:
-
The <id> of an OpVariable, where it refers to the value of the variable.
-
The <id> of an OpFunctionParameter, where it refers to the value of the parameter.
-
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, where it refers to the value returned by the function.
-
A structure-type member (through OpMemberDecorate).
-
The Result <id> of an OpFunctionCall, where it refers to the result of the function call.
-
The Result <id> of other instructions that operate on numerical types, meaning the instruction is to operate at relaxed precision. The instruction’s operands may also be truncated to the relaxed precision.
In all cases, the types of the values that the RelaxedPrecision Decoration refers to must be:
-
a scalar, vector, or matrix, or array of scalars, vectors, or matrices, and all the components in the types must be a 32-bit numerical type,
-
a pointer to such a type, where it refers to the value pointed to.
The values that the RelaxedPrecision Decoration refers to can be truncated to relaxed precision.
When applied to a variable, function parameter, 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 additionally allowed for logical pointer types, while other prohibitions remain:
-
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
-
A pointer can be 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, whether or not operands point into the same buffer, 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 contains a pointer) in the PhysicalStorageBuffer storage class, the OpVariable must be decorated with exactly one of AliasedPointer or RestrictPointer.
-
If an OpFunctionParameter is a pointer (or contains a pointer) 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 contains a pointer) 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 type of OpConstantNull must not be a pointer type with storage class PhysicalStorageBuffer.
-
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 declared.
-
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.
-
Each OpEntryPoint must contain at most one of LocalSize, LocalSizeId, LocalSizeHint, or LocalSizeHintId Execution Modes.
-
-
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 block termination instruction.
-
Each block 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.
-
Image, sampler, and sampled image objects must not appear as operands to OpPhi instructions, or OpSelect instructions, or any instructions other than the image or sampler instructions specified to operate on them.
-
All OpSampledImage instructions, or instructions that load an image or sampler reference, must be in the same block in which their Result <id> are consumed.
-
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.
-
If the workgroup size is statically specified (using the LocalSize, LocalSizeId execution modes, or the WorkgroupSize BuiltIn), the product of all workgroup size dimensions must not be zero.
2.16.2. Validation Rules for Shader Capabilities
-
CFG:
-
Loops must be structured. That is, the target basic block of a back edge must contain an OpLoopMerge instruction.
-
Selections must be structured. That is, an OpSelectionMerge instruction is required to precede:
-
an OpSwitch instruction
-
an OpBranchConditional instruction that has different True Label and False Label operands where neither are declared merge blocks or Continue Targets.
-
-
-
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 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 during their intersecting dynamic lifetimes. 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.
The memory locations associated with an OpFunctionParameter memory object declaration are dependent on the dynamic execution of the associated function. A dynamic instance of an OpFunctionParameter memory object declaration can be traced to either an OpVariable or an entry point OpFunctionParameter. During the execution of an entry point, behavior is undefined if operations on two distinct memory object declarations dynamically access the same memory locations during an intersection of the lifetimes of those two objects, with at least one of them performing a write, and at least one of the memory object declarations does not have the Aliased decoration (or is assumed to alias via the memory model).
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 | Enabling Capabilities | |
---|---|---|
0 |
Unknown |
|
1 |
ESSL |
|
2 |
GLSL |
|
3 |
OpenCL_C |
|
4 |
OpenCL_CPP |
|
5 |
HLSL |
|
6 |
CPP_for_OpenCL |
|
7 |
SYCL |
|
8 |
HERO_C |
|
9 |
NZSL |
|
10 |
WGSL |
|
11 |
Slang |
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 |
5364 |
TaskEXT |
MeshShadingEXT |
5365 |
MeshEXT |
MeshShadingEXT |
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. All Extra Operands that are <id>s must be the <id>s of constant instructions unless otherwise stated.
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, MeshShadingEXT |
||
27 |
OutputPoints |
Geometry, MeshShadingNV, MeshShadingEXT |
|||
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> |
<id> |
<id> |
Kernel |
4169 |
NonCoherentColorAttachmentReadEXT |
TileImageColorReadAccessEXT |
|||
4170 |
NonCoherentDepthAttachmentReadEXT |
TileImageDepthReadAccessEXT |
|||
4171 |
NonCoherentStencilAttachmentReadEXT |
TileImageStencilReadAccessEXT |
|||
4421 |
SubgroupUniformControlFlowKHR |
Shader |
|||
4446 |
PostDepthCoverage |
SampleMaskPostDepthCoverage |
|||
4459 |
DenormPreserve |
Literal |
DenormPreserve |
||
4460 |
DenormFlushToZero |
Literal |
DenormFlushToZero |
||
4461 |
SignedZeroInfNanPreserve |
Literal |
SignedZeroInfNanPreserve |
||
4462 |
RoundingModeRTE |
Literal |
RoundingModeRTE |
||
4463 |
RoundingModeRTZ |
Literal |
RoundingModeRTZ |
||
5017 |
EarlyAndLateFragmentTestsAMD |
Shader |
|||
5027 |
StencilRefReplacingEXT |
StencilExportEXT |
|||
5069 |
CoalescingAMDX |
ShaderEnqueueAMDX |
|||
5071 |
MaxNodeRecursionAMDX |
<id> |
ShaderEnqueueAMDX |
||
5072 |
StaticNumWorkgroupsAMDX |
<id> |
<id> |
<id> |
ShaderEnqueueAMDX |
5073 |
ShaderIndexAMDX |
<id> |
ShaderEnqueueAMDX |
||
5077 |
MaxNumWorkgroupsAMDX |
<id> |
<id> |
<id> |
ShaderEnqueueAMDX |
5079 |
StencilRefUnchangedFrontAMD |
StencilExportEXT |
|||
5080 |
StencilRefGreaterFrontAMD |
StencilExportEXT |
|||
5081 |
StencilRefLessFrontAMD |
StencilExportEXT |
|||
5082 |
StencilRefUnchangedBackAMD |
StencilExportEXT |
|||
5083 |
StencilRefGreaterBackAMD |
StencilExportEXT |
|||
5084 |
StencilRefLessBackAMD |
StencilExportEXT |
|||
5269 |
OutputLinesNV |
MeshShadingNV, MeshShadingEXT |
|||
5269 |
OutputLinesEXT |
MeshShadingNV, MeshShadingEXT |
|||
5270 |
OutputPrimitivesNV |
Literal |
MeshShadingNV, MeshShadingEXT |
||
5270 |
OutputPrimitivesEXT |
Literal |
MeshShadingNV, MeshShadingEXT |
||
5289 |
DerivativeGroupQuadsNV |
ComputeDerivativeGroupQuadsNV |
|||
5290 |
DerivativeGroupLinearNV |
ComputeDerivativeGroupLinearNV |
|||
5298 |
OutputTrianglesNV |
MeshShadingNV, MeshShadingEXT |
|||
5298 |
OutputTrianglesEXT |
MeshShadingNV, MeshShadingEXT |
|||
5366 |
PixelInterlockOrderedEXT |
FragmentShaderPixelInterlockEXT |
|||
5367 |
PixelInterlockUnorderedEXT |
FragmentShaderPixelInterlockEXT |
|||
5368 |
SampleInterlockOrderedEXT |
FragmentShaderSampleInterlockEXT |
|||
5369 |
SampleInterlockUnorderedEXT |
FragmentShaderSampleInterlockEXT |
|||
5370 |
ShadingRateInterlockOrderedEXT |
FragmentShaderShadingRateInterlockEXT |
|||
5371 |
ShadingRateInterlockUnorderedEXT |
FragmentShaderShadingRateInterlockEXT |
|||
5618 |
SharedLocalMemorySizeINTEL |
Literal |
VectorComputeINTEL |
||
5620 |
RoundingModeRTPINTEL |
Literal |
RoundToInfinityINTEL |
||
5621 |
RoundingModeRTNINTEL |
Literal |
RoundToInfinityINTEL |
||
5622 |
FloatingPointModeALTINTEL |
Literal |
RoundToInfinityINTEL |
||
5623 |
FloatingPointModeIEEEINTEL |
Literal |
RoundToInfinityINTEL |
||
5893 |
MaxWorkgroupSizeINTEL |
Literal |
Literal |
Literal |
KernelAttributesINTEL |
5894 |
MaxWorkDimINTEL |
Literal |
KernelAttributesINTEL |
||
5895 |
NoGlobalOffsetINTEL |
KernelAttributesINTEL |
|||
5896 |
NumSIMDWorkitemsINTEL |
Literal |
FPGAKernelAttributesINTEL |
||
5903 |
SchedulerTargetFmaxMhzINTEL |
Literal |
FPGAKernelAttributesINTEL |
||
6154 |
StreamingInterfaceINTEL |
Literal |
FPGAKernelAttributesINTEL |
||
6160 |
RegisterMapInterfaceINTEL |
Literal |
FPGAKernelAttributesv2INTEL |
||
6417 |
NamedBarrierCountINTEL |
Literal |
VectorComputeINTEL |
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, VectorComputeINTEL |
7 |
Function |
|
8 |
Generic |
GenericPointer |
9 |
PushConstant |
Shader |
10 |
AtomicCounter |
AtomicStorage |
11 |
Image |
|
12 |
StorageBuffer |
Shader |
4172 |
TileImageEXT |
TileImageColorReadAccessEXT |
5068 |
NodePayloadAMDX |
ShaderEnqueueAMDX |
5076 |
NodeOutputPayloadAMDX |
ShaderEnqueueAMDX |
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 |
5385 |
HitObjectAttributeNV |
ShaderInvocationReorderNV |
5402 |
TaskPayloadWorkgroupEXT |
MeshShadingEXT |
5605 |
CodeSectionINTEL |
FunctionPointersINTEL |
5936 |
DeviceOnlyINTEL |
USMStorageClassesINTEL |
5937 |
HostOnlyINTEL |
USMStorageClassesINTEL |
3.8. Dim
Dimensionality of an image. Some uses require capabilities beyond the enabling capabilities, for example where the type’s Sampled operand is 2, or Arrayed operand is 1. See the capabilities section for more detail.
Used by OpTypeImage.
Dim | Enabling Capabilities | |
---|---|---|
0 |
1D |
Sampled1D |
1 |
2D |
|
2 |
3D |
|
3 |
Cube |
Shader |
4 |
Rect |
SampledRect |
5 |
Buffer |
SampledBuffer |
6 |
SubpassData |
InputAttachment |
4173 |
TileImageDataEXT |
TileImageColorReadAccessEXT |
3.9. Sampler Addressing Mode
Addressing mode for creating constant samplers.
Used by OpConstantSampler.
Sampler Addressing Mode | Enabling Capabilities | |
---|---|---|
0 |
None |
|
1 |
ClampToEdge |
|
2 |
Clamp |
|
3 |
Repeat |
|
4 |
RepeatMirrored |
3.10. Sampler Filter Mode
Filter mode for creating constant samplers.
Used by OpConstantSampler.
Sampler Filter Mode | Enabling Capabilities | |
---|---|---|
0 |
Nearest |
|
1 |
Linear |
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 |
19 |
UnsignedIntRaw10EXT |
Kernel |
20 |
UnsignedIntRaw12EXT |
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. |
0x4000 |
Nontemporal |
Missing before version 1.6. |
0x10000 |
Offsets |
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.
Only valid on
-
OpFAdd, OpFSub, OpFMul, OpFDiv, OpFRem, and OpFMod instructions
-
Missing before version 1.6:
-
the OpFNegate instruction
-
the OpOrdered, OpUnordered, OpFOrdEqual, OpFUnordEqual, OpFOrdNotEqual, OpFUnordNotEqual, OpFOrdLessThan, OpFUnordLessThan, OpFOrdGreaterThan, OpFUnordGreaterThan, OpFOrdLessThanEqual, OpFUnordLessThanEqual, OpFOrdGreaterThanEqual, and OpFUnordGreaterThanEqual instructions
-
OpExtInst extended instructions, where expressly permitted by the extended instruction set in use.
-
FP Fast Math Mode | Enabling Capabilities | |
---|---|---|
0x0 |
None |
|
0x1 |
NotNaN |
|
0x2 |
NotInf |
|
0x4 |
NSZ |
|
0x8 |
AllowRecip |
|
0x10 |
Fast |
|
0x10000 |
AllowContractFastINTEL |
FPFastMathModeINTEL |
0x20000 |
AllowReassocINTEL |
FPFastMathModeINTEL |
3.16. FP Rounding Mode
Associate a rounding mode to a floating-point conversion instruction.
FP Rounding Mode | Enabling Capabilities | |
---|---|---|
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 |
2 |
LinkOnceODR |
Linkage |
3.18. Access Qualifier
Defines the access permissions.
Used by OpTypeImage, OpTypePipe, and OpTypeBufferSurfaceINTEL.
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.
Only one of Zext and Sext can be used to decorate the same <id>, and no attribute may be used multiple times on the same <id>. Otherwise, multiple function parameter attributes can be applied to the same <id>.
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 |
5940 |
RuntimeAlignedINTEL |
RuntimeAlignedAttributeINTEL |
3.20. Decoration
Decorations add additional information to an <id> or member of a structure.
It is invalid to decorate any given <id> or structure member more than one time with the same decoration, unless explicitly allowed below for a specific 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, UniformDecoration |
|||
27 |
UniformId |
Scope <id> |
Shader, UniformDecoration |
||
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.
|
|||
4487 |
WeightTextureQCOM |
Reserved. |
|||
4488 |
BlockMatchTextureQCOM |
Reserved. |
|||
4999 |
ExplicitInterpAMD |
Reserved. |
|||
5019 |
NodeSharesPayloadLimitsWithAMDX |
<id> |
ShaderEnqueueAMDX |
||
5020 |
NodeMaxPayloadsAMDX |
<id> |
ShaderEnqueueAMDX |
||
5078 |
TrackFinishWritingAMDX |
ShaderEnqueueAMDX |
|||
5091 |
PayloadNodeNameAMDX |
Literal |
ShaderEnqueueAMDX |
||
5248 |
OverrideCoverageNV |
SampleMaskOverrideCoverageNV |
|||
5250 |
PassthroughNV |
GeometryShaderPassthroughNV |
|||
5252 |
ViewportRelativeNV |
ShaderViewportMaskNV |
|||
5256 |
SecondaryViewportRelativeNV |
Literal |
ShaderStereoViewNV |
||
5271 |
PerPrimitiveNV |
MeshShadingNV, MeshShadingEXT |
|||
5271 |
PerPrimitiveEXT |
MeshShadingNV, MeshShadingEXT |
|||
5272 |
PerViewNV |
MeshShadingNV |
|||
5273 |
PerTaskNV |
MeshShadingNV, MeshShadingEXT |
|||
5285 |
PerVertexKHR |
FragmentBarycentricNV, FragmentBarycentricKHR |
|||
5285 |
PerVertexNV |
FragmentBarycentricNV, FragmentBarycentricKHR |
|||
5300 |
NonUniform |
ShaderNonUniform |
|||
5300 |
NonUniformEXT |
ShaderNonUniform |
|||
5355 |
RestrictPointer |
PhysicalStorageBufferAddresses |
|||
5355 |
RestrictPointerEXT |
PhysicalStorageBufferAddresses |
|||
5356 |
AliasedPointer |
PhysicalStorageBufferAddresses |
|||
5356 |
AliasedPointerEXT |
PhysicalStorageBufferAddresses |
|||
5386 |
HitObjectShaderRecordBufferNV |
ShaderInvocationReorderNV |
|||
5398 |
BindlessSamplerNV |
BindlessTextureNV |
|||
5399 |
BindlessImageNV |
BindlessTextureNV |
|||
5400 |
BoundSamplerNV |
BindlessTextureNV |
|||
5401 |
BoundImageNV |
BindlessTextureNV |
|||
5599 |
SIMTCallINTEL |
Literal |
VectorComputeINTEL |
||
5602 |
ReferencedIndirectlyINTEL |
IndirectReferencesINTEL |
|||
5607 |
ClobberINTEL |
Literal |
AsmINTEL |
||
5608 |
SideEffectsINTEL |
AsmINTEL |
|||
5624 |
VectorComputeVariableINTEL |
VectorComputeINTEL |
|||
5625 |
FuncParamIOKindINTEL |
Literal |
VectorComputeINTEL |
||
5626 |
VectorComputeFunctionINTEL |
VectorComputeINTEL |
|||
5627 |
StackCallINTEL |
VectorComputeINTEL |
|||
5628 |
GlobalVariableOffsetINTEL |
Literal |
VectorComputeINTEL |
||
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. |
||
5822 |
FunctionRoundingModeINTEL |
Literal |
FP Rounding Mode |
FunctionFloatControlINTEL |
|
5823 |
FunctionDenormModeINTEL |
Literal |
FP Denorm Mode |
FunctionFloatControlINTEL |
|
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 |
||
5883 |
StridesizeINTEL |
Literal |
FPGAMemoryAttributesINTEL |
||
5884 |
WordsizeINTEL |
Literal |
FPGAMemoryAttributesINTEL |
||
5885 |
TrueDualPortINTEL |
FPGAMemoryAttributesINTEL |
|||
5899 |
BurstCoalesceINTEL |
FPGAMemoryAccessesINTEL |
|||
5900 |
CacheSizeINTEL |
Literal |
FPGAMemoryAccessesINTEL |
||
5901 |
DontStaticallyCoalesceINTEL |
FPGAMemoryAccessesINTEL |
|||
5902 |
PrefetchINTEL |
Literal |
FPGAMemoryAccessesINTEL |
||
5905 |
StallEnableINTEL |
FPGAClusterAttributesINTEL |
|||
5907 |
FuseLoopsInFunctionINTEL |
LoopFuseINTEL |
|||
5909 |
MathOpDSPModeINTEL |
Literal |
Literal |
FPGADSPControlINTEL |
|
5914 |
AliasScopeINTEL |
<id> |
MemoryAccessAliasingINTEL |
||
5915 |
NoAliasINTEL |
<id> |
MemoryAccessAliasingINTEL |
||
5917 |
InitiationIntervalINTEL |
Literal |
FPGAInvocationPipeliningAttributesINTEL |
||
5918 |
MaxConcurrencyINTEL |
Literal |
FPGAInvocationPipeliningAttributesINTEL |
||
5919 |
PipelineEnableINTEL |
Literal |
FPGAInvocationPipeliningAttributesINTEL |
||
5921 |
BufferLocationINTEL |
Literal |
FPGABufferLocationINTEL |
||
5944 |
IOPipeStorageINTEL |
Literal |
IOPipesINTEL |
||
6080 |
FunctionFloatingPointModeINTEL |
Literal |
FP Operation Mode |
FunctionFloatControlINTEL |
|
6085 |
SingleElementVectorINTEL |
VectorComputeINTEL |
|||
6087 |
VectorComputeCallableFunctionINTEL |
VectorComputeINTEL |
|||
6140 |
MediaBlockIOINTEL |
VectorComputeINTEL |
|||
6147 |
InitModeINTEL |
Initialization Mode Qualifier |
GlobalVariableFPGADecorationsINTEL |
||
6148 |
ImplementInRegisterMapINTEL |
Literal |
GlobalVariableFPGADecorationsINTEL |
||
6168 |
HostAccessINTEL |
Host Access Qualifier |
Literal |
GlobalVariableHostAccessINTEL |
|
6170 |
FPMaxErrorDecorationINTEL |
Literal |
FPMaxErrorINTEL |
||
6172 |
LatencyControlLabelINTEL |
Literal |
FPGALatencyControlINTEL |
||
6173 |
LatencyControlConstraintINTEL |
Literal |
Literal |
Literal |
FPGALatencyControlINTEL |
6175 |
ConduitKernelArgumentINTEL |
FPGAArgumentInterfacesINTEL |
|||
6176 |
RegisterMapKernelArgumentINTEL |
FPGAArgumentInterfacesINTEL |
|||
6177 |
MMHostInterfaceAddressWidthINTEL |
Literal |
FPGAArgumentInterfacesINTEL |
||
6178 |
MMHostInterfaceDataWidthINTEL |
Literal |
FPGAArgumentInterfacesINTEL |
||
6179 |
MMHostInterfaceLatencyINTEL |
Literal |
FPGAArgumentInterfacesINTEL |
||
6180 |
MMHostInterfaceReadWriteModeINTEL |
Access Qualifier |
FPGAArgumentInterfacesINTEL |
||
6181 |
MMHostInterfaceMaxBurstINTEL |
Literal |
FPGAArgumentInterfacesINTEL |
||
6182 |
MMHostInterfaceWaitRequestINTEL |
Literal |
FPGAArgumentInterfacesINTEL |
||
6183 |
StableKernelArgumentINTEL |
FPGAArgumentInterfacesINTEL |
|||
6442 |
CacheControlLoadINTEL |
Literal |
Load Cache Control |
CacheControlsINTEL |
|
6443 |
CacheControlStoreINTEL |
Literal |
Store Cache Control |
CacheControlsINTEL |
3.21. BuiltIn
Used when Decoration is BuiltIn. Apply to:
-
The result <id> of the OpVariable declaration of the built-in variable,
-
A structure-type member, if the built-in is a member of a structure, or
-
Deprecated: a constant instruction, when 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.
Application to a constant instruction has previously been used to define the workgroup size with specialization constants in some client APIs. As of version 1.6, all client APIs should instead use the LocalSizeId execution mode.
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, MeshShadingEXT |
8 |
InvocationId |
Geometry, Tessellation |
9 |
Layer |
Geometry, ShaderLayer, ShaderViewportIndexLayerEXT, MeshShadingNV, MeshShadingEXT |
10 |
ViewportIndex |
MultiViewport, ShaderViewportIndex, ShaderViewportIndexLayerEXT, MeshShadingNV, MeshShadingEXT |
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 |
4160 |
CoreIDARM |
CoreBuiltinsARM |
4161 |
CoreCountARM |
CoreBuiltinsARM |
4162 |
CoreMaxIDARM |
CoreBuiltinsARM |
4163 |
WarpIDARM |
CoreBuiltinsARM |
4164 |
WarpMaxIDARM |
CoreBuiltinsARM |
4416 |
SubgroupEqMask |
SubgroupBallotKHR, GroupNonUniformBallot |
4416 |
SubgroupEqMaskKHR |
SubgroupBallotKHR, GroupNonUniformBallot |
4417 |
SubgroupGeMask |
SubgroupBallotKHR, GroupNonUniformBallot |
4417 |
SubgroupGeMaskKHR |
SubgroupBallotKHR, GroupNonUniformBallot |
4418 |
SubgroupGtMask |
SubgroupBallotKHR, GroupNonUniformBallot |
4418 |
SubgroupGtMaskKHR |
SubgroupBallotKHR, GroupNonUniformBallot |
4419 |
SubgroupLeMask |
SubgroupBallotKHR, GroupNonUniformBallot |
4419 |
SubgroupLeMaskKHR |
SubgroupBallotKHR, GroupNonUniformBallot |
4420 |
SubgroupLtMask |
SubgroupBallotKHR, GroupNonUniformBallot |
4420 |
SubgroupLtMaskKHR |
SubgroupBallotKHR, GroupNonUniformBallot |
4424 |
BaseVertex |
DrawParameters |
4425 |
BaseInstance |
DrawParameters |
4426 |
DrawIndex |
DrawParameters, MeshShadingNV, MeshShadingEXT |
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 |
5021 |
CoalescedInputCountAMDX |
ShaderEnqueueAMDX |
5073 |
ShaderIndexAMDX |
ShaderEnqueueAMDX |
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 |
BaryCoordKHR |
FragmentBarycentricNV, FragmentBarycentricKHR |
5286 |
BaryCoordNV |
FragmentBarycentricNV, FragmentBarycentricKHR |
5287 |
BaryCoordNoPerspKHR |
FragmentBarycentricNV, FragmentBarycentricKHR |
5287 |
BaryCoordNoPerspNV |
FragmentBarycentricNV, FragmentBarycentricKHR |
5292 |
FragSizeEXT |
FragmentDensityEXT, ShadingRateNV |
5292 |
FragmentSizeNV |
ShadingRateNV, FragmentDensityEXT |
5293 |
FragInvocationCountEXT |
FragmentDensityEXT, ShadingRateNV |
5293 |
InvocationsPerPixelNV |
ShadingRateNV, FragmentDensityEXT |
5294 |
PrimitivePointIndicesEXT |
MeshShadingEXT |
5295 |
PrimitiveLineIndicesEXT |
MeshShadingEXT |
5296 |
PrimitiveTriangleIndicesEXT |
MeshShadingEXT |
5299 |
CullPrimitiveEXT |
MeshShadingEXT |
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 |
5334 |
CurrentRayTimeNV |
RayTracingMotionBlurNV |
5335 |
HitTriangleVertexPositionsKHR |
RayTracingPositionFetchKHR |
5337 |
HitMicroTriangleVertexPositionsNV |
RayTracingDisplacementMicromapNV |
5344 |
HitMicroTriangleVertexBarycentricsNV |
RayTracingDisplacementMicromapNV |
5351 |
IncomingRayFlagsNV |
RayTracingNV, RayTracingKHR |
5351 |
IncomingRayFlagsKHR |
RayTracingNV, RayTracingKHR |
5352 |
RayGeometryIndexKHR |
RayTracingKHR |
5374 |
WarpsPerSMNV |
ShaderSMBuiltinsNV |
5375 |
SMCountNV |
ShaderSMBuiltinsNV |
5376 |
WarpIDNV |
ShaderSMBuiltinsNV |
5377 |
SMIDNV |
ShaderSMBuiltinsNV |
5405 |
HitKindFrontFacingMicroTriangleNV |
RayTracingDisplacementMicromapNV |
5406 |
HitKindBackFacingMicroTriangleNV |
RayTracingDisplacementMicromapNV |
6021 |
CullMaskKHR |
RayCullMaskKHR |
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 | Enabling Capabilities | |
---|---|---|
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 |
0x800000 |
NoFusionINTEL |
FPGALoopControlsINTEL |
0x1000000 |
LoopCountINTEL |
FPGALoopControlsINTEL |
0x2000000 |
MaxReinvocationDelayINTEL |
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 | Enabling Capabilities | |
---|---|---|
0x0 |
None |
|
0x1 |
Inline |
|
0x2 |
DontInline |
|
0x4 |
Pure |
|
0x8 |
Const |
|
0x10000 |
OptNoneINTEL |
OptNoneINTEL |
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 |
0x10000 |
AliasScopeINTELMask |
MemoryAccessAliasingINTEL |
0x20000 |
NoAliasINTELMask |
MemoryAccessAliasingINTEL |
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 group 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 |
Also see extension: SPV_AMD_shader_ballot |
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. |
71 |
UniformDecoration |
Missing before version 1.6. |
4165 |
CoreBuiltinsARM |
Reserved. |
4166 |
TileImageColorReadAccessEXT |
Reserved. |
4167 |
TileImageDepthReadAccessEXT |
Reserved. |
4168 |
TileImageStencilReadAccessEXT |
Reserved. |
4422 |
FragmentShadingRateKHR |
Shader |
4423 |
SubgroupBallotKHR |
Reserved. |
4427 |
DrawParameters |
Shader |
4428 |
WorkgroupMemoryExplicitLayoutKHR |
Shader |
4429 |
WorkgroupMemoryExplicitLayout8BitAccessKHR |
WorkgroupMemoryExplicitLayoutKHR |
4430 |
WorkgroupMemoryExplicitLayout16BitAccessKHR |
WorkgroupMemoryExplicitLayoutKHR |
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 |
4484 |
TextureSampleWeightedQCOM |
Reserved. |
4485 |
TextureBoxFilterQCOM |
Reserved. |
4486 |
TextureBlockMatchQCOM |
Reserved. |
5008 |
Float16ImageAMD |
Shader |
5009 |
ImageGatherBiasLodAMD |
Shader |
5010 |
FragmentMaskAMD |
Shader |
5013 |
StencilExportEXT |
Shader |
5015 |
ImageReadWriteLodAMD |
Shader |
5016 |
Int64ImageEXT |
Shader |
5055 |
ShaderClockKHR |
Reserved. |
5067 |
ShaderEnqueueAMDX |
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. |
5283 |
MeshShadingEXT |
Shader |
5284 |
FragmentBarycentricKHR |
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 |
5336 |
RayTracingPositionFetchKHR |
Shader |
5340 |
RayTracingNV |
Shader |
5341 |
RayTracingMotionBlurNV |
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 |
DemoteToHelperInvocation |
Shader |
5379 |
DemoteToHelperInvocationEXT |
Shader |
5380 |
DisplacementMicromapNV |
Shader |
5381 |
RayTracingOpacityMicromapEXT |
RayQueryKHR, RayTracingKHR |
5383 |
ShaderInvocationReorderNV |
RayTracingKHR |
5390 |
BindlessTextureNV |
Reserved. |
5391 |
RayQueryPositionFetchKHR |
Shader |
5409 |
RayTracingDisplacementMicromapNV |
RayTracingKHR |
5568 |
SubgroupShuffleINTEL |
Reserved. |
5569 |
SubgroupBufferBlockIOINTEL |
Reserved. |
5570 |
SubgroupImageBlockIOINTEL |
Reserved. |
5579 |
SubgroupImageMediaBlockIOINTEL |
Reserved. |
5582 |
RoundToInfinityINTEL |
Reserved. |
5583 |
FloatingPointModeINTEL |
Reserved. |
5584 |
IntegerFunctions2INTEL |
Shader |
5603 |
FunctionPointersINTEL |
Reserved. |
5604 |
IndirectReferencesINTEL |
Reserved. |
5606 |
AsmINTEL |
Reserved. |
5612 |
AtomicFloat32MinMaxEXT |
Reserved. |
5613 |
AtomicFloat64MinMaxEXT |
Reserved. |
5616 |
AtomicFloat16MinMaxEXT |
Reserved. |
5617 |
VectorComputeINTEL |
VectorAnyINTEL |
5619 |
VectorAnyINTEL |
Reserved. |
5629 |
ExpectAssumeKHR |
Reserved. |
5696 |
SubgroupAvcMotionEstimationINTEL |
Reserved. |
5697 |
SubgroupAvcMotionEstimationIntraINTEL |
Reserved. |
5698 |
SubgroupAvcMotionEstimationChromaINTEL |
Reserved. |
5817 |
VariableLengthArrayINTEL |
Reserved. |
5821 |
FunctionFloatControlINTEL |
Reserved. |
5824 |
FPGAMemoryAttributesINTEL |
Reserved. |
5837 |
FPFastMathModeINTEL |
Kernel |
5844 |
ArbitraryPrecisionIntegersINTEL |
Reserved. |
5845 |
ArbitraryPrecisionFloatingPointINTEL |
Reserved. |
5886 |
UnstructuredLoopControlsINTEL |
Reserved. |
5888 |
FPGALoopControlsINTEL |
Reserved. |
5892 |
KernelAttributesINTEL |
Reserved. |
5897 |
FPGAKernelAttributesINTEL |
Reserved. |
5898 |
FPGAMemoryAccessesINTEL |
Reserved. |
5904 |
FPGAClusterAttributesINTEL |
Reserved. |
5906 |
LoopFuseINTEL |
Reserved. |
5908 |
FPGADSPControlINTEL |
Reserved. |
5910 |
MemoryAccessAliasingINTEL |
Reserved. |
5916 |
FPGAInvocationPipeliningAttributesINTEL |
Reserved. |
5920 |
FPGABufferLocationINTEL |
Reserved. |
5922 |
ArbitraryPrecisionFixedPointINTEL |
Reserved. |
5935 |
USMStorageClassesINTEL |
Reserved. |
5939 |
RuntimeAlignedAttributeINTEL |
Reserved. |
5943 |
IOPipesINTEL |
Reserved. |
5945 |
BlockingPipesINTEL |
Reserved. |
5948 |
FPGARegINTEL |
Reserved. |
6016 |
DotProductInputAll |
Missing before version 1.6. |
6016 |
DotProductInputAllKHR |
Missing before version 1.6.
|
6017 |
DotProductInput4x8Bit |
Int8 |
6017 |
DotProductInput4x8BitKHR |
Int8 |
6018 |
DotProductInput4x8BitPacked |
Missing before version 1.6. |
6018 |
DotProductInput4x8BitPackedKHR |
Missing before version 1.6.
|
6019 |
DotProduct |
Missing before version 1.6. |
6019 |
DotProductKHR |
Missing before version 1.6.
|
6020 |
RayCullMaskKHR |
Reserved. |
6022 |
CooperativeMatrixKHR |
Reserved. |
6025 |
BitInstructions |
Reserved. |
6026 |
GroupNonUniformRotateKHR |
GroupNonUniform |
6033 |
AtomicFloat32AddEXT |
Reserved. |
6034 |
AtomicFloat64AddEXT |
Reserved. |
6089 |
LongConstantCompositeINTEL |
Reserved. |
6094 |
OptNoneINTEL |
Reserved. |
6095 |
AtomicFloat16AddEXT |
Reserved. |
6114 |
DebugInfoModuleINTEL |
Reserved. |
6115 |
BFloat16ConversionINTEL |
Reserved. |
6141 |
SplitBarrierINTEL |
Reserved. |
6146 |
GlobalVariableFPGADecorationsINTEL |
Reserved. |
6161 |
FPGAKernelAttributesv2INTEL |
FPGAKernelAttributesINTEL |
6167 |
GlobalVariableHostAccessINTEL |
Reserved. |
6169 |
FPMaxErrorINTEL |
Reserved. |
6171 |
FPGALatencyControlINTEL |
Reserved. |
6174 |
FPGAArgumentInterfacesINTEL |
Reserved. |
6400 |
GroupUniformArithmeticKHR |
Reserved. |
6441 |
CacheControlsINTEL |
Reserved. |
3.32. Ray Flags
This is a literal mask; it can be formed by combining the bits from multiple rows in the table below.
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 |
0x400 |
ForceOpacityMicromap2StateEXT |
RayTracingOpacityMicromapEXT |
3.33. Ray Query Intersection
Ray Query Intersection | Enabling Capabilities | |
---|---|---|
0 |
RayQueryCandidateIntersectionKHR |
RayQueryKHR |
1 |
RayQueryCommittedIntersectionKHR |
RayQueryKHR |
3.34. Ray Query Committed Type
Ray Query Committed Type | Enabling Capabilities | |
---|---|---|
0 |
RayQueryCommittedIntersectionNoneKHR |
RayQueryKHR |
1 |
RayQueryCommittedIntersectionTriangleKHR |
RayQueryKHR |
2 |
RayQueryCommittedIntersectionGeneratedKHR |
RayQueryKHR |
3.35. Ray Query Candidate Type
Ray Query Candidate Type | Enabling Capabilities | |
---|---|---|
0 |
RayQueryCandidateIntersectionTriangleKHR |
RayQueryKHR |
1 |
RayQueryCandidateIntersectionAABBKHR |
RayQueryKHR |
3.36. Fragment Shading Rate
This is a literal mask; it can be formed by combining the bits from multiple rows in the table below.
Fragment Shading Rate | Enabling Capabilities | |
---|---|---|
0x0 |
None |
|
0x1 |
Vertical2Pixels |
FragmentShadingRateKHR |
0x2 |
Vertical4Pixels |
FragmentShadingRateKHR |
0x4 |
Horizontal2Pixels |
FragmentShadingRateKHR |
0x8 |
Horizontal4Pixels |
FragmentShadingRateKHR |
3.37. FP Denorm Mode
Floating point denormalized handling mode.
FP Denorm Mode | Enabling Capabilities | |
---|---|---|
0 |
Preserve |
FunctionFloatControlINTEL |
1 |
FlushToZero |
FunctionFloatControlINTEL |
3.38. FP Operation Mode
Floating point operation mode.
FP Operation Mode | Enabling Capabilities | |
---|---|---|
0 |
IEEE |
FunctionFloatControlINTEL |
1 |
ALT |
FunctionFloatControlINTEL |
3.39. Quantization Mode
Quantization Mode | Enabling Capabilities | |
---|---|---|
0 |
TRN |
ArbitraryPrecisionFixedPointINTEL |
1 |
TRN_ZERO |
ArbitraryPrecisionFixedPointINTEL |
2 |
RND |
ArbitraryPrecisionFixedPointINTEL |
3 |
RND_ZERO |
ArbitraryPrecisionFixedPointINTEL |
4 |
RND_INF |
ArbitraryPrecisionFixedPointINTEL |
5 |
RND_MIN_INF |
ArbitraryPrecisionFixedPointINTEL |
6 |
RND_CONV |
ArbitraryPrecisionFixedPointINTEL |
7 |
RND_CONV_ODD |
ArbitraryPrecisionFixedPointINTEL |
3.40. Overflow Mode
Overflow Mode | Enabling Capabilities | |
---|---|---|
0 |
WRAP |
ArbitraryPrecisionFixedPointINTEL |
1 |
SAT |
ArbitraryPrecisionFixedPointINTEL |
2 |
SAT_ZERO |
ArbitraryPrecisionFixedPointINTEL |
3 |
SAT_SYM |
ArbitraryPrecisionFixedPointINTEL |
3.41. Packed Vector Format
Used by:
Packed Vector Format | Enabling Capabilities | |
---|---|---|
0 |
PackedVectorFormat4x8Bit |
Missing before version 1.6. |
0 |
PackedVectorFormat4x8BitKHR |
Missing before version 1.6.
|
3.42. Cooperative Matrix Operands
This is a literal mask; it can be formed by combining the bits from multiple rows in the table below.
Used by OpCooperativeMatrixMulAddKHR.
Cooperative Matrix Operands | Enabling Capabilities | |
---|---|---|
0x0 |
None |
|
0x1 |
MatrixASignedComponentsKHR |
|
0x2 |
MatrixBSignedComponentsKHR |
|
0x4 |
MatrixCSignedComponentsKHR |
|
0x8 |
MatrixResultSignedComponentsKHR |
|
0x10 |
SaturatingAccumulationKHR |
3.43. Cooperative Matrix Layout
Cooperative Matrix Layout | Enabling Capabilities | |
---|---|---|
0 |
RowMajorKHR |
|
1 |
ColumnMajorKHR |
3.44. Cooperative Matrix Use
Cooperative Matrix Use | Enabling Capabilities | |
---|---|---|
0 |
MatrixAKHR |
|
1 |
MatrixBKHR |
|
2 |
MatrixAccumulatorKHR |
3.45. Initialization Mode Qualifier
Initialization Mode Qualifier | Enabling Capabilities | |
---|---|---|
0 |
InitOnDeviceReprogramINTEL |
GlobalVariableFPGADecorationsINTEL |
1 |
InitOnDeviceResetINTEL |
GlobalVariableFPGADecorationsINTEL |
3.46. Host Access Qualifier
Host Access Qualifier | Enabling Capabilities | |
---|---|---|
0 |
NoneINTEL |
GlobalVariableHostAccessINTEL |
1 |
ReadINTEL |
GlobalVariableHostAccessINTEL |
2 |
WriteINTEL |
GlobalVariableHostAccessINTEL |
3 |
ReadWriteINTEL |
GlobalVariableHostAccessINTEL |
3.47. Load Cache Control
Load Cache Control | Enabling Capabilities | |
---|---|---|
0 |
UncachedINTEL |
CacheControlsINTEL |
1 |
CachedINTEL |
CacheControlsINTEL |
2 |
StreamingINTEL |
CacheControlsINTEL |
3 |
InvalidateAfterReadINTEL |
CacheControlsINTEL |
4 |
ConstCachedINTEL |
CacheControlsINTEL |
3.48. Store Cache Control
Store Cache Control | Enabling Capabilities | |
---|---|---|
0 |
UncachedINTEL |
CacheControlsINTEL |
1 |
WriteThroughINTEL |
CacheControlsINTEL |
2 |
WriteBackINTEL |
CacheControlsINTEL |
3 |
StreamingINTEL |
CacheControlsINTEL |
3.49. Instructions
Form for each instruction:
Opcode Name (name-alias, name-alias, …) |
Capability Enabling Capabilities |
||
Opcode |
Results |
Operands |
3.49.1. Miscellaneous Instructions
OpNop |
|
1 |
0 |
OpUndef |
|||
3 |
1 |
<id> |
OpSizeOf |
Capability: |
|||
4 |
321 |
<id> |
<id> |
Capability: |
||||
4 |
4460 |
<id> |
<id> |
Capability: |
||
2 |
5630 |
<id> |
Capability: |
|||||
5 |
5631 |
<id> |
<id> |
<id> |
3.49.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.49.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.49.4. Extension Instructions
OpExtension |
||
2 + variable |
10 |
Literal |
OpExtInstImport |
|||
3 + variable |
11 |
Literal |
OpExtInst |
||||||
5 + variable |
12 |
<id> |
<id> |
Literal |
<id>, <id>, … |
3.49.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.49.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 |
Capability: |
|||||||
7 |
4456 |
<id> |
Scope <id> |
<id> |
<id> |
<id> |
Capability: |
|||
3 |
6086 |
Access Qualifier |
Capability: |
||
1 + variable |
6090 |
<id>, <id>, … |
3.49.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>, … |
Capability: |
||
1 + variable |
6091 |
<id>, <id>, … |
Capability: |
||
1 + variable |
6092 |
<id>, <id>, … |
3.49.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> |
Capability: |
|||||||
5 + variable |
4457 |
<id> |
<id> |
<id> |
Optional |
Optional |
Capability: |
||||||
4 + variable |
4458 |
<id> |
<id> |
<id> |
Optional |
Optional |
3.49.9. Function Instructions
OpFunction |
|||||
5 |
54 |
<id> |
<id> |
OpFunctionParameter |
|||
3 |
55 |
<id> |
1 |
56 |
OpFunctionCall |
|||||
4 + variable |
57 |
<id> |
<id> |
<id>, <id>, … |
3.49.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: |
|||||
4 + variable |
4160 |
<id> |
<id> |
Optional |
Capability: |
||||
3 + variable |
4161 |
<id> |
Optional |
Capability: |
||||
3 + variable |
4162 |
<id> |
Optional |
Capability: |
||||||
6 |
4480 |
<id> |
<id> |
<id> |
<id> |
Capability: |
||||||
6 |
4481 |
<id> |
<id> |
<id> |
<id> |
Capability: |
||||||||
8 |
4482 |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
Capability: |
||||||||
8 |
4483 |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
Capability: |
|||||||||
7 + variable |
5283 |
<id> |
<id> |
<id> |
<id> |
<id> |
Optional |
Optional |
3.49.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> |
Capability: |
||||
4 |
6116 |
<id> |
<id> |
Capability: |
||||
4 |
6117 |
<id> |
<id> |
3.49.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.49.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> |
OpSDot (OpSDotKHR) |
Capability: |
|||||
5 + variable |
4450 |
<id> |
<id> |
<id> |
Optional |
OpUDot (OpUDotKHR) |
Capability: |
|||||
5 + variable |
4451 |
<id> |
<id> |
<id> |
Optional |
OpSUDot (OpSUDotKHR) |
Capability: |
|||||
5 + variable |
4452 |
<id> |
<id> |
<id> |
Optional |
OpSDotAccSat (OpSDotAccSatKHR) |
Capability: |
||||||
6 + variable |
4453 |
<id> |
<id> |
<id> |
<id> |
Optional |
OpUDotAccSat (OpUDotAccSatKHR) |
Capability: |
||||||
6 + variable |
4454 |
<id> |
<id> |
<id> |
<id> |
Optional |
OpSUDotAccSat (OpSUDotAccSatKHR) |
Capability: |
||||||
6 + variable |
4455 |
<id> |
<id> |
<id> |
<id> |
Optional |
Capability: |
|||||||
6 + variable |
4459 |
<id> |
<id> |
<id> |
<id> |
Optional |
3.49.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.49.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.49.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> |
OpDPdxCoarse |
Capability: |
|||
4 |
213 |
<id> |
<id> |
OpDPdyCoarse |
Capability: |
|||
4 |
214 |
<id> |
<id> |
OpFwidthCoarse |
Capability: |
|||
4 |
215 |
<id> |
<id> |
3.49.17. Control-Flow Instructions
OpPhi |
||||
3 + variable |
245 |
<id> |
<id>, <id>, … |
OpLoopMerge |
|||||
4 + variable |
246 |
<id> |
<id> |
Literal, Literal, … |
OpSelectionMerge |
|||
3 |
247 |
<id> |
OpLabel |
||
2 |
248 |
OpBranch |
||
2 |
249 |
<id> |
OpBranchConditional |
|||||
4 + variable |
250 |
<id> |
<id> |
<id> |
Literal, Literal, … |
OpSwitch |
||||
3 + variable |
251 |
<id> |
<id> |
literal, label <id>, |
OpKill |
Capability: |
1 |
252 |
OpReturn |
|
1 |
253 |
OpReturnValue |
||
2 |
254 |
<id> |
OpUnreachable |
|
1 |
255 |
OpLifetimeStart |
Capability: |
||
3 |
256 |
<id> |
Literal |
OpLifetimeStop |
Capability: |
||
3 |
257 |
<id> |
Literal |
OpTerminateInvocation |
Capability: |
1 |
4416 |
OpDemoteToHelperInvocation (OpDemoteToHelperInvocationEXT) |
Capability: |
1 |
5380 |
3.49.18. Atomic Instructions
OpAtomicLoad |
||||||
6 |
227 |
<id> |
<id> |
Scope <id> |
Memory Semantics <id> |
OpAtomicStore |
|||||
5 |
228 |
<id> |
Scope <id> |
Memory Semantics <id> |
<id> |
OpAtomicExchange |
|||||||
7 |
229 |
<id> |
<id> |
Scope <id> |
Memory Semantics <id> |
<id> |
OpAtomicCompareExchange |
|||||||||
9 |
230 |
<id> |
<id> |
Scope <id> |
Memory Semantics <id> |
Memory Semantics <id> |
<id> |
<id> |
OpAtomicCompareExchangeWeak |
Capability: |
||||||||
9 |
231 |
<id> |
<id> |
Scope <id> |
Memory Semantics <id> |
Memory Semantics <id> |
<id> |
<id> |
OpAtomicIIncrement |
||||||
6 |
232 |
<id> |
<id> |
Scope <id> |
Memory Semantics <id> |
OpAtomicIDecrement |
||||||
6 |
233 |
<id> |
<id> |
Scope <id> |
Memory Semantics <id> |
OpAtomicIAdd |
|||||||
7 |
234 |
<id> |
<id> |
Scope <id> |
Memory Semantics <id> |
<id> |
OpAtomicISub |
|||||||
7 |
235 |
<id> |
<id> |
Scope <id> |
Memory Semantics <id> |
<id> |
OpAtomicSMin |
|||||||
7 |
236 |
<id> |
<id> |
Scope <id> |
Memory Semantics <id> |
<id> |
OpAtomicUMin |
|||||||
7 |
237 |
<id> |
<id> |
Scope <id> |
Memory Semantics <id> |
<id> |
OpAtomicSMax |
|||||||
7 |
238 |
<id> |
<id> |
Scope <id> |
Memory Semantics <id> |
<id> |
OpAtomicUMax |
|||||||
7 |
239 |
<id> |
<id> |
Scope <id> |
Memory Semantics <id> |
<id> |
OpAtomicAnd |
|||||||
7 |
240 |
<id> |
<id> |
Scope <id> |
Memory Semantics <id> |
<id> |
OpAtomicOr |
|||||||
7 |
241 |
<id> |
<id> |
Scope <id> |
Memory Semantics <id> |
<id> |
OpAtomicXor |
|||||||
7 |
242 |
<id> |
<id> |
Scope <id> |
Memory Semantics <id> |
<id> |
OpAtomicFlagTestAndSet |
Capability: |
|||||
6 |
318 |
<id> |
<id> |
Scope <id> |
Memory Semantics <id> |
OpAtomicFlagClear |
Capability: |
|||
4 |
319 |
<id> |
Scope <id> |
Memory Semantics <id> |
Capability: |
|||||||
7 |
5614 |
<id> |
<id> |
Scope <id> |
Memory Semantics <id> |
<id> |
Capability: |
|||||||
7 |
5615 |
<id> |
<id> |
Scope <id> |
Memory Semantics <id> |
<id> |
Capability: |
|||||||
7 |
6035 |
<id> |
<id> |
Scope <id> |
Memory Semantics <id> |
<id> |
3.49.19. Primitive Instructions
OpEmitVertex |
Capability: |
1 |
218 |
OpEndPrimitive |
Capability: |
1 |
219 |
OpEmitStreamVertex |
Capability: |
|
2 |
220 |
<id> |
OpEndStreamPrimitive |
Capability: |
|
2 |
221 |
<id> |
3.49.20. Barrier Instructions
OpControlBarrier |
||||
4 |
224 |
Scope <id> |
Scope <id> |
Memory Semantics <id> |
OpMemoryBarrier |
|||
3 |
225 |
Scope <id> |
Memory Semantics <id> |
OpNamedBarrierInitialize |
Capability: |
|||
4 |
328 |
<id> |
<id> |
OpMemoryNamedBarrier |
Capability: |
|||
4 |
329 |
<id> |
Scope <id> |
Memory Semantics <id> |
Capability: |
||||
4 |
6142 |
Scope <id> |
Scope <id> |
Memory Semantics <id> |
Capability: |
||||
4 |
6143 |
Scope <id> |
Scope <id> |
Memory Semantics <id> |
3.49.21. Group and Subgroup Instructions
OpGroupAsyncCopy |
Capability: |
||||||||
9 |
259 |
<id> |
Scope <id> |
<id> |
<id> |
<id> |
<id> |
<id> |
OpGroupWaitEvents |
Capability: |
|||
4 |
260 |
Scope <id> |
<id> |
<id> |
OpGroupAll |
Capability: |
||||
5 |
261 |
<id> |
Scope <id> |
<id> |
OpGroupAny |
Capability: |
||||
5 |
262 |
<id> |
Scope <id> |
<id> |
OpGroupBroadcast |
Capability: |
|||||
6 |
263 |
<id> |
Scope <id> |
<id> |
<id> |
OpGroupIAdd |
Capability: |
|||||
6 |
264 |
<id> |
Scope <id> |
Group Operation |
<id> |
OpGroupFAdd |
Capability: |
|||||
6 |
265 |
<id> |
Scope <id> |
Group Operation |
<id> |
OpGroupFMin |
Capability: |
|||||
6 |
266 |
<id> |
Scope <id> |
Group Operation |
<id> |
OpGroupUMin |
Capability: |
|||||
6 |
267 |
<id> |
Scope <id> |
Group Operation |
<id> |
OpGroupSMin |
Capability: |
|||||
6 |
268 |
<id> |
Scope <id> |
Group Operation |
<id> |
OpGroupFMax |
Capability: |
|||||
6 |
269 |
<id> |
Scope <id> |
Group Operation |
<id> |
OpGroupUMax |
Capability: |
|||||
6 |
270 |
<id> |
Scope <id> |
Group Operation |
<id> |
OpGroupSMax |
Capability: |
|||||
6 |
271 |
<id> |
Scope <id> |
Group Operation |
<id> |
Capability: |
||||
4 |
4421 |
<id> |
<id> |
OpSubgroupFirstInvocationKHR |
Capability: |
|||
4 |
4422 |
<id> |
<id> |
Capability: |
||||
4 |
4428 |
<id> |
<id> |
Capability: |
||||
4 |
4429 |
<id> |
<id> |
Capability: |
||||
4 |
4430 |
<id> |
<id> |
Capability: |
|||||||
6 + variable |
4431 |
<id> |
Scope <id> |
<id> |
<id> |
Optional |
OpSubgroupReadInvocationKHR |
Capability: |
||||
5 |
4432 |
<id> |
<id> |
<id> |
Capability: |
||||||
6 |
5000 |
<id> |
Scope <id> |
Group Operation |
<id> |
Capability: |
||||||
6 |
5001 |
<id> |
Scope <id> |
Group Operation |
<id> |
Capability: |
||||||
6 |
5002 |
<id> |
Scope <id> |
Group Operation |
<id> |
Capability: |
||||||
6 |
5003 |
<id> |
Scope <id> |
Group Operation |
<id> |
Capability: |
||||||
6 |
5004 |
<id> |
Scope <id> |
Group Operation |
<id> |
Capability: |
||||||
6 |
5005 |
<id> |
Scope <id> |
Group Operation |
<id> |
Capability: |
||||||
6 |
5006 |
<id> |
Scope <id> |
Group Operation |
<id> |
Capability: |
||||||
6 |
5007 |
<id> |
Scope <id> |
Group Operation |
<id> |
Capability: |
|||||
5 |
5571 |
<id> |
<id> |
<id> |
Capability: |
||||||
6 |
5572 |
<id> |
<id> |
<id> |
<id> |
Capability: |
||||||
6 |
5573 |
<id> |
<id> |
<id> |
<id> |
Capability: |
|||||
5 |
5574 |
<id> |
<id> |
<id> |
Capability: |
||||
4 |
5575 |
<id> |
<id> |
Capability: |
|||
3 |
5576 |
<id> |
<id> |
Capability: |
|||||
5 |
5577 |
<id> |
<id> |
<id> |
Capability: |
||||
4 |
5578 |
<id> |
<id> |
<id> |
Capability: |
|||||||
7 |
5580 |
<id> |
<id> |
<id> |
<id> |
<id> |
Capability: |
||||||
6 |
5581 |
<id> |
<id> |
<id> |
<id> |
<id> |
Capability: |
||||||
6 |
6401 |
<id> |
Scope <id> |
Group Operation |
<id> |
Capability: |
||||||
6 |
6402 |
<id> |
Scope <id> |
Group Operation |
<id> |
Capability: |
||||||
6 |
6403 |
<id> |
Scope <id> |
Group Operation |
<id> |
Capability: |
||||||
6 |
6404 |
<id> |
Scope <id> |
Group Operation |
<id> |
Capability: |
||||||
6 |
6405 |
<id> |
Scope <id> |
Group Operation |
<id> |
Capability: |
||||||
6 |
6406 |
<id> |
Scope <id> |
Group Operation |
<id> |
Capability: |
||||||
6 |
6407 |
<id> |
Scope <id> |
Group Operation |
<id> |
Capability: |
||||||
6 |
6408 |
<id> |
Scope <id> |
Group Operation |
<id> |
3.49.22. Device-Side Enqueue Instructions
OpEnqueueMarker |
Capability: |
||||||
7 |
291 |
<id> |
<id> |
<id> |
<id> |
<id> |
OpEnqueueKernel |
Capability: |
|||||||||||||
13 + variable |
292 |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id>, <id>, … |
OpGetKernelNDrangeSubGroupCount |
Capability: |
|||||||
8 |
293 |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
OpGetKernelNDrangeMaxSubGroupSize |
Capability: |
|||||||
8 |
294 |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
OpGetKernelWorkGroupSize |
Capability: |
||||||
7 |
295 |
<id> |
<id> |
<id> |
<id> |
<id> |
OpGetKernelPreferredWorkGroupSizeMultiple |
Capability: |
||||||
7 |
296 |
<id> |
<id> |
<id> |
<id> |
<id> |
OpRetainEvent |
Capability: |
|
2 |
297 |
<id> |
OpReleaseEvent |
Capability: |
|
2 |
298 |
<id> |
OpCreateUserEvent |
Capability: |
||
3 |
299 |
<id> |
OpIsValidEvent |
Capability: |
|||
4 |
300 |
<id> |
<id> |
OpSetUserEventStatus |
Capability: |
||
3 |
301 |
<id> |
<id> |
OpCaptureEventProfilingInfo |
Capability: |
|||
4 |
302 |
<id> |
<id> |
<id> |
OpGetDefaultQueue |
Capability: |
||
3 |
303 |
<id> |
OpBuildNDRange |
Capability: |
|||||
6 |
304 |
<id> |
<id> |
<id> |
<id> |
OpGetKernelLocalSizeForSubgroupCount |
Capability: |
|||||||
8 |
325 |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
OpGetKernelMaxNumSubgroups |
Capability: |
||||||
7 |
326 |
<id> |
<id> |
<id> |
<id> |
<id> |
3.49.23. Pipe Instructions
OpReadPipe |
Capability: |
||||||
7 |
274 |
<id> |
<id> |
<id> |
<id> |
<id> |
OpWritePipe |
Capability: |
||||||
7 |
275 |
<id> |
<id> |
<id> |
<id> |
<id> |
OpReservedReadPipe |
Capability: |
||||||||
9 |
276 |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
OpReservedWritePipe |
Capability: |
||||||||
9 |
277 |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
OpReserveReadPipePackets |
Capability: |
||||||
7 |
278 |
<id> |
<id> |
<id> |
<id> |
<id> |
OpReserveWritePipePackets |
Capability: |
||||||
7 |
279 |
<id> |
<id> |
<id> |
<id> |
<id> |
OpCommitReadPipe |
Capability: |
||||
5 |
280 |
<id> |
<id> |
<id> |
<id> |
OpCommitWritePipe |
Capability: |
||||
5 |
281 |
<id> |
<id> |
<id> |
<id> |
OpIsValidReserveId |
Capability: |
|||
4 |
282 |
<id> |
<id> |
OpGetNumPipePackets |
Capability: |
|||||
6 |
283 |
<id> |
<id> |
<id> |
<id> |
OpGetMaxPipePackets |
Capability: |
|||||
6 |
284 |
<id> |
<id> |
<id> |
<id> |
OpGroupReserveReadPipePackets |
Capability: |
|||||||
8 |
285 |
<id> |
Scope <id> |
<id> |
<id> |
<id> |
<id> |
OpGroupReserveWritePipePackets |
Capability: |
|||||||
8 |
286 |
<id> |
Scope <id> |
<id> |
<id> |
<id> |
<id> |
OpGroupCommitReadPipe |
Capability: |
|||||
6 |
287 |
Scope <id> |
<id> |
<id> |
<id> |
<id> |
OpGroupCommitWritePipe |
Capability: |
|||||
6 |
288 |
Scope <id> |
<id> |
<id> |
<id> |
<id> |
OpConstantPipeStorage |
Capability: |
|||||
6 |
323 |
<id> |
Literal |
Literal |
Literal |
OpCreatePipeFromPipeStorage |
Capability: |
|||
4 |
324 |
<id> |
<id> |
Capability: |
|||||
5 |
5946 |
<id> |
<id> |
<id> |
Capability: |
|||||
5 |
5947 |
<id> |
<id> |
<id> |
3.49.24. Non-Uniform Instructions
OpGroupNonUniformElect |
Capability: |
|||
4 |
333 |
<id> |
Scope <id> |
OpGroupNonUniformAll |
Capability: |
||||
5 |
334 |
<id> |
Scope <id> |
<id> |
OpGroupNonUniformAny |
Capability: |
||||
5 |
335 |
<id> |
Scope <id> |
<id> |
OpGroupNonUniformAllEqual |
Capability: |
||||
5 |
336 |
<id> |
Scope <id> |
<id> |
OpGroupNonUniformBroadcast |
Capability: |
|||||
6 |
337 |
<id> |
Scope <id> |
<id> |
<id> |
OpGroupNonUniformBroadcastFirst |
Capability: |
||||
5 |
338 |
<id> |
Scope <id> |
<id> |
OpGroupNonUniformBallot |
Capability: |
||||
5 |
339 |
<id> |
Scope <id> |
<id> |
OpGroupNonUniformInverseBallot |
Capability: |
||||
5 |
340 |
<id> |
Scope <id> |
<id> |
OpGroupNonUniformBallotBitExtract |
Capability: |
|||||
6 |
341 |
<id> |
Scope <id> |
<id> |
<id> |
OpGroupNonUniformBallotBitCount |
Capability: |
|||||
6 |
342 |
<id> |
Scope <id> |
Group Operation |
<id> |
OpGroupNonUniformBallotFindLSB |
Capability: |
||||
5 |
343 |
<id> |
Scope <id> |
<id> |
OpGroupNonUniformBallotFindMSB |
Capability: |
||||
5 |
344 |
<id> |
Scope <id> |
<id> |
OpGroupNonUniformShuffle |
Capability: |
|||||
6 |
345 |
<id> |
Scope <id> |
<id> |
<id> |
OpGroupNonUniformShuffleXor |
Capability: |
|||||
6 |
346 |
<id> |
Scope <id> |
<id> |
<id> |
OpGroupNonUniformShuffleUp |
Capability: |
|||||
6 |
347 |
<id> |
Scope <id> |
<id> |
<id> |
OpGroupNonUniformShuffleDown |
Capability: |
|||||
6 |
348 |
<id> |
Scope <id> |
<id> |
<id> |
OpGroupNonUniformIAdd |
Capability: |
||||||
6 + variable |
349 |
<id> |
Scope <id> |
Group Operation |
<id> |
Optional |
OpGroupNonUniformFAdd |
Capability: |
||||||
6 + variable |
350 |
<id> |
Scope <id> |
Group Operation |
<id> |
Optional |
OpGroupNonUniformIMul |
Capability: |
||||||
6 + variable |
351 |
<id> |
Scope <id> |
Group Operation |
<id> |
Optional |
OpGroupNonUniformFMul |
Capability: |
||||||
6 + variable |
352 |
<id> |
Scope <id> |
Group Operation |
<id> |
Optional |
OpGroupNonUniformSMin |
Capability: |
||||||
6 + variable |
353 |
<id> |
Scope <id> |
Group Operation |
<id> |
Optional |
OpGroupNonUniformUMin |
Capability: |
||||||
6 + variable |
354 |
<id> |
Scope <id> |
Group Operation |
<id> |
Optional |
OpGroupNonUniformFMin |
Capability: |
||||||
6 + variable |
355 |
<id> |
Scope <id> |
Group Operation |
<id> |
Optional |
OpGroupNonUniformSMax |
Capability: |
||||||
6 + variable |
356 |
<id> |
Scope <id> |
Group Operation |
<id> |
Optional |
OpGroupNonUniformUMax |
Capability: |
||||||
6 + variable |
357 |
<id> |
Scope <id> |
Group Operation |
<id> |
Optional |
OpGroupNonUniformFMax |
Capability: |
||||||
6 + variable |
358 |
<id> |
Scope <id> |
Group Operation |
<id> |
Optional |
OpGroupNonUniformBitwiseAnd |
Capability: |
||||||
6 + variable |
359 |
<id> |
Scope <id> |
Group Operation |
<id> |
Optional |
OpGroupNonUniformBitwiseOr |
Capability: |
||||||
6 + variable |
360 |
<id> |
Scope <id> |
Group Operation |
<id> |
Optional |
OpGroupNonUniformBitwiseXor |
Capability: |
||||||
6 + variable |
361 |
<id> |
Scope <id> |
Group Operation |
<id> |
Optional |
OpGroupNonUniformLogicalAnd |
Capability: |
||||||
6 + variable |
362 |
<id> |
Scope <id> |
Group Operation |
<id> |
Optional |
OpGroupNonUniformLogicalOr |
Capability: |
||||||
6 + variable |
363 |
<id> |
Scope <id> |
Group Operation |
<id> |
Optional |
OpGroupNonUniformLogicalXor |
Capability: |
||||||
6 + variable |
364 |
<id> |
Scope <id> |
Group Operation |
<id> |
Optional |
OpGroupNonUniformQuadBroadcast |
Capability: |
|||||
6 |
365 |
<id> |
Scope <id> |
<id> |
<id> |
OpGroupNonUniformQuadSwap |
Capability: |
|||||
6 |
366 |
<id> |
Scope <id> |
<id> |
<id> |
Capability: |
||||
4 |
5296 |
<id> |
<id> |
3.49.25. Reserved Instructions
Capability: |
||||||||||||
12 |
4445 |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
Capability: |
|||
3 |
4446 |
<id> |
<id> |
Capability: |
||||
4 |
4447 |
<id> |
<id> |
Capability: |
|
1 |
4448 |
Capability: |
|
1 |
4449 |
Capability: |
||
2 |
4472 |
Capability: |
|||||||||
9 |
4473 |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
Capability: |
||
2 |
4474 |
<id> |
Capability: |
|||
3 |
4475 |
<id> |
<id> |
Capability: |
||
2 |
4476 |
<id> |
Capability: |
||||
4 |
4477 |
<id> |
<id> |
Capability: |
|||||
5 |
4479 |
<id> |
<id> |
<id> |
Capability: |
|||||
5 |
5011 |
<id> |
<id> |
<id> |
Capability: |
||||||
6 |
5012 |
<id> |
<id> |
<id> |
<id> |
Capability: |
||||
4 |
5056 |
<id> |
Scope <id> |
Capability: |
||
2 |
5075 |
<id> |
Capability: |
||||
4 |
5078 |
<id> |
<id> |
Capability: |
|||||
5 |
5090 |
<id> |
Scope <id> |
<id> |
<id> |
Capability: |
|||||||||||||||
15 |
5249 |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
Capability: |
||||||||||||||
14 |
5250 |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
Capability: |
||||||||
8 |
5251 |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
Capability: |
||||
4 |
5252 |
<id> |
<id> |
Capability: |
||||
4 |
5253 |
<id> |
<id> |
Capability: |
||||
4 |
5254 |
<id> |
<id> |
Capability: |
||||
4 |
5255 |
<id> |
<id> |
Capability: |
||||||||||||||
14 |
5256 |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
Capability: |
||||
4 |
5257 |
<id> |
<id> |
Capability: |
||||
4 |
5258 |
<id> |
<id> |
Capability: |
||
2 |
5259 |
<id> |
Capability: |
|||||||||||||
13 |
5260 |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
Capability: |
||||||||||||||
14 |
5261 |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
Capability: |
|||||||||||||
13 |
5262 |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
Capability: |
|||||||
7 |
5263 |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
Capability: |
|||
3 |
5264 |
<id> |
<id> |
Capability: |
||||
4 |
5265 |
<id> |
<id> |
Capability: |
|||
3 |
5266 |
<id> |
<id> |
Capability: |
||||
4 |
5267 |
<id> |
<id> |
Capability: |
||||
4 |
5268 |
<id> |
<id> |
Capability: |
||||
4 |
5269 |
<id> |
<id> |
Capability: |
||||
4 |
5270 |
<id> |
<id> |
Capability: |
||||
4 |
5271 |
<id> |
<id> |
Capability: |
||||
4 |
5272 |
<id> |
<id> |
Capability: |
||||
4 |
5273 |
<id> |
<id> |
Capability: |
||||
4 |
5274 |
<id> |
<id> |
Capability: |
||||
4 |
5275 |
<id> |
<id> |
Capability: |
||||
4 |
5276 |
<id> |
<id> |
Capability: |
||||
4 |
5277 |
<id> |
<id> |
Capability: |
||||
4 |
5278 |
<id> |
<id> |
Capability: |
||||
2 + variable |
5279 |
<id> |
Optional |
Optional |
Capability: |
|||
3 |
5280 |
<id> |
<id> |
Capability: |
||
2 |
5281 |
Capability: |
|||||
4 + variable |
5294 |
<id> |
<id> |
<id> |
Optional |
Capability: |
|||
3 |
5295 |
<id> |
<id> |
Capability: |
|||
3 |
5299 |
<id> |
<id> |
Capability: |
||||||||
8 |
5300 |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
Capability: |
||||||||
8 |
5301 |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
Capability: |
|||||
5 |
5334 |
<id> |
<id> |
<id> |
Capability: |
|
1 |
5335 |
Capability: |
|
1 |
5336 |
Capability: |
||||||||||||
12 |
5337 |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
Capability: |
|||||||||||||
13 |
5338 |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
Capability: |
|||||||||||||
13 |
5339 |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
<id> |
OpRayQueryGetIntersectionTriangleVertexPositionsKHR |
Capability: |
||||
5 |
5340 |
<id> |
<id> |
<id> |
OpTypeAccelerationStructureNV (OpTypeAccelerationStructureKHR) |
Capability: |
|
2 |
5341 |
Capability: |
|||
3 |
5344 |
<id> |
<id> |
Capability: |
||||||
6 |
5358 |
<id> |
Scope <id> |
<id> |
<id> |
Capability: |
|||||||
6 + variable |
5359 |
<id> |
<id> |
<id> |
<id> |
Optional |
Capability: |
||||||
5 + variable |
5360 |
<id> |
<id> |
<id> |
<id> |
Optional |
Capability: |
||||||
6 |
5361 |
<id> |
<id> |
<id> |
<id> |
Capability: |
||||
4 |
5362 |
<id> |
<id> |
Capability: |
|
1 |
5364 |
Capability: |
|
1 |
5365 |
Capability: |
|||
3 |
5381 |
<id> |
Capability: |
||||
4 |
5391 |
<id> |
<id> |
Capability: |
||||
4 |
5392 |
<id> |
<id> |
Capability: |
||||
4 |
5393 |
<id> |
<id> |
Capability: |
||||
4 |
5394 |
<id> |
<id> |
Capability: |
||||
4 |
5395 |
<id> |
<id> |
Capability: |
||||
4 |
5396 |
<id> |
<id> |
Capability: |
||
2 |
5397 |
Literal |
Capability: |
||||
4 |
5585 |
<id> |
<id> |
Capability: |
||||
4 |
5586 |
<id> |
<id> |
Capability: |
|||||
5 |
5587 |
<id> |
<id> |
<id> |
Capability: |
|||||
5 |
5588 |
<id> |
<id> |
<id> |
Capability: |
|||||
5 |
5589 |
<id> |
<id> |
<id> |
Capability: |
|||||
5 |
5590 |
<id> |
<id> |
<id> |
Capability: |
|||||
5 |
5591 |
<id> |
<id> |
<id> |
Capability: |
|||||
5 |
5592 |
<id> |
<id> |
<id> |
Capability: |
|||||
5 |
5593 |
<id> |
<id> |
<id> |
Capability: |
|||||
5 |
5594 |
<id> |
<id> |
<id> |
Capability: |
|||||
5 |
5595 |
<id> |
<id> |
<id> |
Capability: |
|||||
5 |
5596 |
<id> |
<id> |
<id> |
Capability: |
|||||
5 |
5597 |
<id> |
<id> |
<id> |
Capability: |
|||||
5 |
5598 |
<id> |
<id> |
<id> |
Capability: |
||
1 + variable |
5887 |
Literal, Literal, … |
Capability: |
|||||
5 |
5949 |
<id> |
<id> |
<id> |
Capability: |
||||
4 |
6016 |
<id> |
<id> |
Capability: |
||||
4 |
6017 |
<id> |
<id> |
Capability: |
|||||
5 |
6018 |
<id> |
<id> |
<id> |
Capability: |
|||||
5 |
6019 |
<id> |
<id> |
<id> |
Capability: |
|||||
5 |
6020 |
<id> |
<id> |
<id> |
OpRayQueryGetIntersectionInstanceShaderBindingTableRecordOffsetKHR |
Capability: |
||||
5 |
6021 |
<id> |
<id> |
<id> |
Capability: |
|||||
5 |
6022 |
<id> |
<id> |
<id> |
Capability: |
|||||
5 |
6023 |
<id> |
<id> |
<id> |
Capability: |
|||||
5 |
6024 |
<id> |
<id> |
<id> |
Capability: |
|||||
5 |
6025 |
<id> |
<id> |
<id> |
Capability: |
||||
4 |
6026 |
<id> |
<id> |
Capability: |
|||||
5 |
6027 |
<id> |
<id> |
<id> |
Capability: |
|||||
5 |
6028 |
<id> |
<id> |
<id> |
Capability: |
||||
4 |
6029 |
<id> |
<id> |
Capability: |
||||
4 |
6030 |
<id> |
<id> |
Capability: |
|||||
5 |
6031 |
<id> |
<id> |
<id> |
Capability: |
|||||
5 |
6032 |
<id> |
<id> |
<id> |
4. Appendix A: Changes
4.1. Changes from Version 0.99, Revision 31
-
Added the PushConstant Storage Class.
-
Added OpIAddCarry, OpISubBorrow, OpUMulExtended, and OpSMulExtended.
-
Added OpInBoundsPtrAccessChain.
-
Added the Decoration NoContraction to prevent combining multiple operations into a single operation (bug 14396).
-
Added sparse texturing (14486):
-
Added OpImageSparse… for accessing images that might not be resident.
-
Added MinLod functionality for accessing images with a minimum level of detail.
-
-
Added back the Alignment Decoration, for the Kernel capability (14505).
-
Added a Nontemporal Memory Operand (14566).
-
Structured control flow changes:
-
Changed structured loops to have a structured continue Continue Target in OpLoopMerge (14422).
-
Added rules for how "fall through" works with OpSwitch (13579).
-
Added definitions for what is "inside" a structured control-flow construct (14422).
-
-
Added SubpassData Dim to support input targets written by a previous subpass as an output target (14304). This is also a Decoration and a Capability, and can be used by some image ops to read the input target.
-
Added OpTypeForwardPointer to establish the Storage Class of a forward reference to a pointer type (13822).
-
Improved Debuggability
-
Changed OpLine to not have a target <id>, but instead be placed immediately preceding the instruction(s) it is annotating (13905).
-
Added OpNoLine to terminate the affect of OpLine (13905).
-
Changed OpSource to include the source code:
-
Allow multiple occurrences.
-
Be mixed in with the OpString instructions.
-
Optionally consume an OpString result to say which file it is annotating.
-
Optionally include the source text corresponding to that OpString.
-
Included adding OpSourceContinued for source text that is too long for a single instruction.
-
-
-
Added a large number of Capabilities for subsetting functionality (14520, 14453), including 8-bit integer support for OpenCL kernels.
-
Added VertexIndex and InstanceIndex BuiltIn Decorations (14255).
-
Added GenericPointer capability that allows the ability to use the Generic Storage Class (14287).
-
Added IndependentForwardProgress Execution Mode (14271).
-
Added OpAtomicFlagClear and OpAtomicFlagTestAndSet instructions (14315).
-
Changed OpEntryPoint to take a list of Input and Output <id> for declaring the entry point’s interface.
-
Fixed internal bugs
-
14411 Added missing documentation for mad_sat OpenCL extended instructions (enums existed, just the documentation was missing)
-
14241 Removed shader capability requirement from OpImageQueryLevels and OpImageQuerySamples.
-
14241 Removed unneeded OpImageQueryDim instruction.
-
14241 Filled in TBD section for OpAtomicCompareExchangeWeek
-
14366 All OpSampledImage must appear before uses of sampled images (and still in the first block of the entry point).
-
14450 DeviceEnqueue capability is required for OpTypeQueue and OpTypeDeviceEvent
-
14363 OpTypePipe is opaque - moved packet size and alignment to opcodes
-
14367 Float16Buffer capability clarified
-
14241 Clarified how OpSampledImage can be used
-
14402 Clarified OpTypeImage encodings for OpenCL extended instructions
-
14569 Removed mention of non-existent OpFunctionDecl
-
14372 Clarified usage of OpGenericPtrMemSemantics
-
13801 Clarified the SpecId Decoration is just for constants
-
14447 Changed literal values of Memory Semantic enums to match OpenCL/C++11 atomics, and made the Memory Semantic None and Relaxed be aliases
-
14637 Removed subgroup scope from OpGroupAsyncCopy and OpGroupWaitEvents
-
4.2. Changes from Version 0.99, Revision 32
-
Added UnormInt101010_2 to the Image Channel Data Type table.
-
Added place holder for C++11 atomic Consume Memory Semantics along with an explicit AcquireRelease memory semantic.
-
Fixed internal bugs:
-
14690 OpSwitch literal width (and hence number of operands) is determined by the type of Selector, and be rigorous about how sub-32-bit literals are stored.
-
14485 The client API owns the semantics of built-ins that only have "pass through" semantics WRT SPIR-V.
-
14862 Removed the IndependentForwardProgress Execution Mode.
-
-
Fixed public bugs:
-
1387 Don’t describe result type of OpImageWrite.
-
4.3. Changes from Version 1.00, Revision 1
-
Adjusted Capabilities:
-
Split geometry-stream functionality into its own GeometryStreams capability (14873).
-
Have InputAttachmentIndex to depend on InputAttachment instead of Shader (14797).
-
Merge AdvancedFormats and StorageImageExtendedFormats into just StorageImageExtendedFormats (14824).
-
Require StorageImageReadWithoutFormat and StorageImageWriteWithoutFormat to read and write storage images with an Unknown Image Format.
-
Removed the ImageSRGBWrite capability.
-
-
Clarifications
-
RelaxedPrecision Decoration can be applied to OpFunction (14662).
-
-
Fixed internal bugs:
-
14797 The literal argument was missing for the InputAttachmentIndex Decoration.
-
14547 Remove the FragColor BuiltIn, so that no implicit broadcast is implied.
-
13292 Make statements about "Volatile" be more consistent with the memory model specification (non-functional change).
-
14948 Remove image-"Query" overloading on image/sampled-image type and "fetch" on non-sampled images, by adding the OpImage instruction to get the image from a sampled image.
-
14949 Make consistent placement between OpSource and OpSourceExtension in the logical layout of a module.
-
14865 Merge WorkgroupLinearId with LocalInvocationId BuiltIn Decorations.
-
14806 Include 3D images for OpImageQuerySize.
-
14325 Removed the Smooth Decoration.
-
12771 Make the version word formatted as: "0 | Major Number | Minor Number | 0" in the physical layout.
-
15035 Allow OpTypeImage to use a Depth operand of 2 for not indicating a depth or non-depth image.
-
15009 Split the OpenCL Source Language into two: OpenCL_C and OpenCL_CPP.
-
14683 OpSampledImage instructions can only be the consuming block, for scalars, and directly consumed by an image lookup or query instruction.
-
14325 mutual exclusion validation rules of Execution Modes and Decorations
-
15112 add definitions for invocation, dynamically uniform, and uniform control flow.
-
-
Renames
-
InputTargetIndex Decoration → InputAttachmentIndex
-
InputTarget Capability → InputAttachment
-
InputTarget Dim → SubpassData
-
WorkgroupLocal Storage Class → Workgroup
-
WorkgroupGlobal Storage Class → CrossWorkgroup
-
PrivateGlobal Storage Class → Private
-
OpAsyncGroupCopy → OpGroupAsyncCopy
-
OpWaitGroupEvents → OpGroupWaitEvents
-
InputTriangles Execution Mode → Triangles
-
InputQuads Execution Mode → Quads
-
InputIsolines Execution Mode → Isolines
-
4.4. Changes from Version 1.00, Revision 2
-
Updated example at the end of Section 1 to conform to the KHR_vulkan_glsl extension and treat OpTypeBool as an abstract type.
-
Adjusted Capabilities:
-
MatrixStride depends on Matrix (15234).
-
Sample, SampleId, SamplePosition, and SampleMask depend on SampleRateShading (15234).
-
ClipDistance and CullDistance BuiltIns depend on, respectively, ClipDistance and CullDistance (1407, 15234).
-
ViewportIndex depends on MultiViewport (15234).
-
AtomicCounterMemory should be the AtomicStorage (15234).
-
Float16 has no dependencies (15234).
-
Offset Decoration should only be for Shader (15268).
-
Generic Storage Class is supposed to need the GenericPointer Capability (14287).
-
Remove capability restriction on the BuiltIn Decoration (15248).
-
-
Fixed internal bugs:
-
15203 Updated description of SampleMask BuiltIn to include "Input or output…", not just "Input…"
-
15225 Include no re-association as a constraint required by the NoContraction Decoration.
-
15210 Clarify OpPhi semantics that operand values only come from parent blocks.
-
15239 Add OpImageSparseRead, which was missing (supposed to be 12 sparse-image instructions, but only 11 got incorporated, this adds the 12th).
-
15299 Move OpUndef back to the Miscellaneous section.
-
15321 OpTypeImage does not have a Depth restriction when used with SubpassData.
-
14948 Fix the Lod Image Operands to allow both integer and floating-point values.
-
15275 Clarify specific storage classes allowed for atomic operations under universal validation rules "Atomic access rules".
-
15501 Restrict Patch Decoration to one of the tessellation execution models.
-
15472 Reserved use of OpImageSparseSampleProjImplicitLod, OpImageSparseSampleProjExplicitLod, OpImageSparseSampleProjDrefImplicitLod, and OpImageSparseSampleProjDrefExplicitLod.
-
15459 Clarify what makes different aggregate types in "Types and Variables".
-
15426 Don’t require OpQuantizeToF16 to preserve NaN patterns.
-
15418 Don’t set both Acquire and Release bits in Memory Semantics.
-
15404 OpFunction Result <id> can only be used by OpFunctionCall, OpEntryPoint, and decoration instructions.
-
15437 Restrict element type for OpTypeRuntimeArray by adding a definition of concrete types.
-
15403 Clarify OpTypeFunction can only be consumed by OpFunction and functions can only return concrete and abstract types.
-
-
Improved accuracy of the opcode word count in each instruction regarding which operands are optional. For sampling operations with explicit LOD, this included not marking the required LOD operands as optional.
-
Clarified that when NonWritable, NonReadable, Volatile, and Coherent Decorations are applied to the Uniform storage class, the BufferBlock decoration must be present.
-
Fixed external bugs:
-
1413 (see internal 15275)
-
1417 Added definitions for block, dominate, post dominate, CFG, and back edge. Removed use of "dominator tree".
-
4.5. Changes from Version 1.00, Revision 3
-
Added definition of derivative group, and use it to say when derivatives are well defined.
4.6. Changes from Version 1.00, Revision 4
-
Expanded the list of instructions that may use or return a pointer in the Logical addressing model.
-
Added missing ABGR Image Channel Order
4.7. Changes from Version 1.00, Revision 5
-
Khronos SPIR-V issue #27: Removed Shader dependency from SampledBuffer and Sampled1D Capabilities.
-
Khronos SPIR-V issue #56: Clarify that the meaning of "read-only" in the Storage Classes includes not allowing initializers.
-
Khronos SPIR-V issue #57: Clarify "modulo" means "remainder" in OpFMod's description.
-
Khronos SPIR-V issue #60: OpControlBarrier synchronizes Output variables when used in tessellation-control shader.
-
Public SPIRV-Headers issue #1: Remove the Shader capability requirement from the Input Storage Class.
-
Public SPIRV-Headers issue #10: Don’t say the (u [, v] [, w], q) has four components, as it can be closed up when the optional ones are missing. Seen in the projective image instructions.
-
Public SPIRV-Headers issues #12 and #13 and Khronos SPIR-V issue #65: Allow OpVariable as an initializer for another OpVariable instruction or the Base of an OpSpecConstantOp with an AccessChain opcode.
-
Public SPIRV-Headers issues #14: add Max enumerants of 0x7FFFFFFF to each of the non-mask enums in the C-based header files.
4.8. Changes from Version 1.00, Revision 6
-
Khronos SPIR-V issue #63: Be clear that OpUndef can be used in sequence 9 (and is preferred to be) of the Logical Layout and can be part of partially-defined OpConstantComposite.
-
Khronos SPIR-V issue #70: Don’t explicitly require operand truncation for integer operations when operating at RelaxedPrecision.
-
Khronos SPIR-V issue #76: Include OpINotEqual in the list of allowed instructions for OpSpecConstantOp.
-
Khronos SPIR-V issue #79: Remove implication that OpImageQueryLod should have a component for the array index.
-
Public SPIRV-Headers issue #17: Decorations NoPerspective, Flat, Patch, Centroid, and Sample can apply to a top-level member that is itself a structure, so don’t disallow it through restrictions to numeric types.
4.9. Changes from Version 1.00, Revision 7
-
Khronos SPIR-V issue #69: OpImageSparseFetch editorial change in summary: include that it is sampled image.
-
Khronos SPIR-V issue #74: OpImageQueryLod requires a sampler.
-
Khronos SPIR-V issue #82: Clarification to the Float16Buffer Capability.
-
Khronos SPIR-V issue #89: Editorial improvements to OpMemberDecorate and OpDecorationGroup.
4.10. Changes from Version 1.00, Revision 8
-
Add SPV_KHR_subgroup_vote tokens.
-
Typo: Change "without a sampler" to "with a sampler" for the description of the SampledBuffer Capability.
-
Khronos SPIR-V issue #61: Clarification of packet size and alignment on all instructions that use the Pipes Capability.
-
Khronos SPIR-V issue #99: Use "invalid" language to replace any "compile-time error" language.
-
Khronos SPIR-V issue #55: Distinguish between branch instructions and termination instructions.
-
Khronos SPIR-V issue #94: Add missing OpSubgroupReadInvocationKHR enumerant.
-
Khronos SPIR-V issue #114: Header blocks strictly dominate their merge blocks.
-
Khronos SPIR-V issue #119: OpSpecConstantOp allows OpUndef where allowed by its opcode.
4.11. Changes from Version 1.00, Revision 9
-
Khronos Vulkan issue #652: Remove statements about matrix offsets and padding. These are described correctly in the Vulkan API specifications.
-
Khronos SPIR-V issue #113: Remove the "By Default" statements in FP Rounding Mode. These should be properly specified by the client API.
-
Add extension enumerants for
-
SPV_KHR_16bit_storage
-
SPV_KHR_device_group
-
SPV_KHR_multiview
-
SPV_NV_sample_mask_override_coverage
-
SPV_NV_geometry_shader_passthrough
-
SPV_NV_viewport_array2
-
SPV_NV_stereo_view_rendering
-
SPV_NVX_multiview_per_view_attributes
-
4.12. Changes from Version 1.00, Revision 10
-
Add HLSL source language.
-
Add StorageBuffer storage class.
-
Add StorageBuffer16BitAccess, UniformAndStorageBuffer16BitAccess, VariablePointersStorageBuffer, and VariablePointers capabilities.
-
Khronos SPIR-V issue #163: Be more clear that OpTypeStruct allows zero members. Also affects ArrayStride and Offset decoration validation rules.
-
Khronos SPIR-V issue #159: List allowed AtomicCounter instructions with the AtomicStorage capability rather than the validation rules.
-
Khronos SPIR-V issue #36: Describe more clearly the type of ND Range in OpGetKernelNDrangeSubGroupCount, OpGetKernelNDrangeMaxSubGroupSize, and OpEnqueueKernel.
-
Khronos SPIR-V issue #128: Be clear the OpDot operates only on vectors.
-
Khronos SPIR-V issue #80: Loop headers must dominate their continue target. See Structured Control Flow.
-
Khronos SPIR-V issue #150 allow UniformConstant storage-class variables to have initializers, depending on the client API.
4.13. Changes from Version 1.00, Revision 11
-
Public issue #2: Disallow the Cube dimension from use with the Offset, ConstOffset, and ConstOffset image operands.
-
Public issue #48: OpConvertPtrToU only returns a scalar, not a vector.
-
Khronos SPIR-V issue #130: Be more clear which masks are literal and which are not.
-
Khronos SPIR-V issue #154: Clarify only one of the listed Capabilities needs to be declared to use a feature that lists multiple capabilities. The non-declared capabilities need not be supported by the underlying implementation.
-
Khronos SPIR-V issue #174: OpImageDrefGather and OpImageSparseDrefGather return vectors, not scalars.
-
Khronos SPIR-V issue #182: The SampleMask built in does not depend on SampleRateShading, only Shader.
-
Khronos SPIR-V issue #183: OpQuantizeToF16 with too-small magnitude can result in either +0 or -0.
-
Khronos SPIR-V issue #203: OpImageTexelPointer has 3 components for cube arrays, not 4.
-
Khronos SPIR-V issue #217: Clearer language for OpArrayLength.
-
Khronos SPIR-V issue #213: Image Operand LoD is not used by query operations.
-
Khronos SPIR-V issue #223: OpPhi has exactly one parent operand per parent block.
-
Khronos SPIR-V issue #212: In the Validation Rules, make clear a pointer can be an operand in an extended instruction set.
-
Add extension enumerants for
-
SPV_AMD_shader_ballot
-
SPV_KHR_post_depth_coverage
-
SPV_AMD_shader_explicit_vertex_parameter
-
SPV_EXT_shader_stencil_export
-
SPV_INTEL_subgroups
-
4.14. Changes from Version 1.00
-
Moved version number to SPIR-V 1.1
-
New functionality:
-
Bug 14202 named barriers:
-
Added the NamedBarrier Capability.
-
Added the instructions: OpTypeNamedBarrier, OpNamedBarrierInitialize, and OpMemoryNamedBarrier.
-
-
Bug 14201 subgroup dispatch:
-
Added the SubgroupDispatch Capability.
-
Added the instructions: OpGetKernelLocalSizeForSubgroupCount and OpGetKernelMaxNumSubgroups.
-
Added SubgroupSize and SubgroupsPerWorkgroup Execution Modes.
-
-
Bug 14441 program-scope pipes:
-
Added the PipeStorage Capability.
-
Added Instructions: OpTypePipeStorage, OpConstantPipeStorage, and OpCreatePipeFromPipeStorage.
-
-
Bug 15434 Added the OpSizeOf instruction.
-
Bug 15024 support for OpenCL-C++ ivdep loop attribute:
-
Added DependencyInfinite and DependencyLength Loop Controls.
-
Updated OpLoopMerge to support these.
-
-
Bug 14022 Added Initializer and Finalizer and Execution Modes.
-
Bug 15539 Added the MaxByteOffset Decoration.
-
Bug 15073 Added the Kernel Capability to the SpecId Decoration.
-
Bug 14828 Added the OpModuleProcessed instruction.
-
-
Fixed internal bugs:
-
Bug 15481 Clarification on alignment and size operands for pipe operands
-
4.15. Changes from Version 1.1, Revision 1
-
Incorporated bug fixes from Revision 6 of Version 1.00 (see section 4.7. Changes from Version 1.00, Revision 5).
4.16. Changes from Version 1.1, Revision 2
-
Incorporated bug fixes from Revision 7 of Version 1.00 (see section 4.8. Changes from Version 1.00, Revision 6).
4.17. Changes from Version 1.1, Revision 3
-
Incorporated bug fixes from Revision 8 of Version 1.00 (see section 4.9. Changes from Version 1.00, Revision 7).
4.18. Changes from Version 1.1, Revision 4
-
Incorporated bug fixes from Revision 9 of Version 1.00 (see section 4.10. Changes from Version 1.00, Revision 8).
4.19. Changes from Version 1.1, Revision 5
-
Incorporated changes from Revision 10 of Version 1.00 (see section 4.11. Changes from Version 1.00, Revision 9).
4.20. Changes from Version 1.1, Revision 6
-
Incorporated changes from Revision 11 of Version 1.00 (see section 4.12. Changes from Version 1.00, Revision 10).
4.21. Changes from Version 1.1, Revision 7
-
Incorporated changes from Revision 12 of Version 1.00 (see section 4.13. Changes from Version 1.00, Revision 11).
-
State where all OpModuleProcessed belong, in the logical layout.
4.22. Changes from Version 1.1
-
Moved version number to SPIR-V 1.2
-
New functionality:
-
Added OpExecutionModeId to allow using an <id> to set the execution modes SubgroupsPerWorkgroupId, LocalSizeId, and LocalSizeHintId.
-
Added OpDecorateId to allow using an <id> to set the decorations AlignmentId and MaxByteOffsetId.
-
4.23. Changes from Version 1.2, Revision 1
-
Incorporated changes from Revision 12 of Version 1.00 (see section 4.13. Changes from Version 1.00, Revision 11).
-
Incorporated changes from Revision 8 of Version 1.1 (see section 4.21. Changes from Version 1.1, Revision 7).
4.24. Changes from Version 1.2, Revision 2
-
Combine the 1.0, 1.1, and 1.2 specifications, making a unified specification. The previous 1.0, 1.1, and 1.2 specifications are replaced with this one unified specification.
4.25. Changes from Version 1.2, Revision 3
Fixed Khronos-internal issues:
-
#249: Improve description of OpTranspose.
-
#251: Undefined values in OpUndef include abstract and opaque values.
-
#258: Deprecate OpAtomicCompareExchangeWeak in favor of OpAtomicCompareExchange.
-
#241: Use "invalid" instead of "compile-time" error for ConstOffsets.
-
#248: OpImageSparseRead is not for SubpassData.
-
#257: Allow OpImageSparseFetch and OpImageSparseRead with the Sample image operands.
-
#229: Some sensible constraints on branch hints for OpBranchConditional.
-
#236: OpVariable's storage class must match storage class of the pointer type.
-
#216: Can decorate pointer types with Coherent and Volatile.
-
#247: Don’t say Scope <id> is a mask; it is not.
-
#254: Remove validation rules about the types atomic instructions can operate on. These rules belong instead to the client API.
-
#265: OpGroupDecorate cannot target an OpDecorationGroup.
4.26. Changes from Version 1.2
-
Moved version number to SPIR-V 1.3
-
New functionality:
-
Added subgroup operations:
-
the OpGroupNonUniform instructions and capabilities.
-
Subgroup-mask built-in decorations.
-
-
Khronos SPIR-V issue #125, #138, #196: Removed capabilities from the rounding modes.
-
Khronos SPIR-V issue #110: Removed the execution-model restrictions from OpControlBarrier.
-
-
Incorporated the following extensions:
-
SPV_KHR_shader_draw_parameters
-
SPV_KHR_16bit_storage
-
SPV_KHR_device_group
-
SPV_KHR_multiview
-
SPV_KHR_storage_buffer_storage_class
-
SPV_KHR_variable_pointers
-
-
Reserved symbols for
-
SPV_GOOGLE_decorate_string
-
SPV_GOOGLE_hlsl_functionality1
-
SPV_AMD_gpu_shader_half_float_fetch
-
-
Added deprecation model.
4.27. Changes from Version 1.3, Revision 1
-
Fixed Issues:
-
Public SPIRV-Headers PR #73: Add missing fields for some NVIDIA-specific tokens.
-
Khronos SPIR-V Issue #202: Shader Validation: Be clear that arrays of blocks set by the client API cannot have an ArrayStride.
-
Khronos SPIR-V Issue #210: Clarify the Result Type of OpSampledImage.
-
Khronos SPIR-V Issue #211: State that Derivative instructions only work on 32-bit width components.
-
Khronos SPIR-V Issue #239: Clarify OpImageFetch is for an image whose Sampled operand is 1.
-
Khronos SPIR-V Issue #256: OpAtomicCompareExchange does not store if comparison fails.
-
Khronos SPIR-V Issue #269: Be more clear which bits are mutually exclusive for memory semantics.
-
Khronos SPIR-V Issue #278: Delete OpTypeRuntimeArray restriction on storage classes, as this is already covered by the client API.
-
Khronos SPIR-V Issue #279:
-
Add section expository section 2.8.1 "Unsigned Versus Signed Integers".
-
As expected, OpUConvert can have vector Result Type.
-
-
Khronos SPIR-V Issue #280: OpImageQuerySizeLod and OpImageQueryLevels can be limited by the client API.
-
Khronos SPIR-V Issue #285: Remove Kernel as a capability implicitly declared by Int8.
-
Khronos SPIR-V Issue #290: Clarify implicit declaration of capabilities, in part by changing the column heading to *Implicitly Declares".
-
Khronos SPIR-V Issues #295: Explicitly say blocks cannot be nested in blocks, in the validation section. (This was already indirectly required.)
-
Khronos SPIR-V Issue #299: Add the ImageGatherExtended capability to ConstOffsets in the image operands section.
-
Khronos SPIR-V Issues #303 and #304: OpGroupNonUniformBallotBitExtract documentation: add Result Type and fix Index parameter.
-
Khronos SPIR-V Issue #310: Remove instruction word count from the Limits table, as it is already intrinsically limited.
-
Khronos SPIR-V Issue #313: Move the FPRoundingMode-decoration validation rule to the shader validation section (not a universal rule). Also, include the StorageBuffer storage class in this rule.
-
4.28. Changes from Version 1.3, Revision 2
-
New enumarents:
-
For SPV_KHR_8bit_storage
-
-
Fixed Issues:
-
Add definition of Memory Object Declaration.
-
Khronos SPIR-V Issue #275: Clarify the meaning of Aliased and Restrict in the Aliasing section.
-
Khronos SPIR-V Issue #315: Be more specific about where many decorations are allowed, particularly for OpFunctionParameter. Includes being clear that the BuiltIn decoration does not apply to OpFunctionParamater.
-
Khronos SPIR-V Issue #348: Clarify remainder descriptions in OpFRem, OpFMod, OpSRem, and OpSMod.
-
Khronos SPIR-V Issue #342: State the DepthReplacing execution-mode behavior more specifically.
-
Khronos SPIR-V Issue #341: More specific wording for depth-hint execution modes DepthGreater, DepthLess, and DepthUnchanged.
-
Khronos SPIR-V Issues #276 and #311: Take more care with unreachable blocks in structured control flow and how to branch into a construct.
-
Khronos SPIR-V Issue #320: Include OpExecutionModeId in the logical layout.
-
Khronos SPIR-V Issue #238: Fix description of OpImageQuerySize to correct Sampled Type → Sampled and list the correct set of dimensions.
-
Khronos SPIR-V Issue #346: Remove ordered rule for structures in the memory layout: Vulkan allows out-of-order Offset layouts.
-
Khronos SPIR-V Issue #322: Allow OpImageQuerySize to query the size of a NonReadable image.
-
Khronos SPIR-V Issue #244: Be more clear about the connections between dimensionalities and capabilities, and in referring to them from OpImageRead and OpImageWrite.
-
Khronos SPIR-V Issue #333: Be clear about overflow behavior for OpIAdd, OpISub, and OpIMul.
-
4.29. Changes from Version 1.3, Revision 3
-
Add enumerants for
-
SPV_KHR_vulkan_memory_model
-
-
Fixed Issues:
-
Typo: say OpMatrixTimesVector is Matrix X Vector.
-
Update on Khronos SPIR-V issue #244: Added Shader and Kernel capabilities to the 2D dimensionality.
-
Khronos SPIR-V Issue #317: Clarify that the Uniform decoration should apply only to objects, and that the dynamic instance of the object is the same, rather than at the consumer usage.
-
Khronos SPIR-V Issue #335: Clarify and correct when it is valid for pointers to be operands to OpFunctionCall. Corrections are believed to be consistent with existing front-end and back-end support.
-
Khronos SPIR-V Issue #344: don’t include inactive invocations in what makes the result of OpGroupNonUniformBallotBitExtract undefined.
-
4.30. Changes from Version 1.3, Revision 4
-
Add enumerants for
-
SPV_NV_fragment_shader_barycentric
-
SPV_NV_compute_shader_derivatives
-
SPV_NV_shader_image_footprint
-
SPV_NV_shading_rate
-
SPV_NV_mesh_shader
-
SPV_NVX_Raytracing
-
-
Formatting: Removed Enabling Extensions column and instead list the extensions in the Enabling Capabilities column.
4.31. Changes from Version 1.3, Revision 5
-
Reserve Tokens for:
-
SPV_KHR_no_integer_wrap_decoration
-
SPV_KHR_float_controls
-
-
Fixed Issues:
-
Khronos SPIR-V Issue #352: Remove from OpFunction the statement limiting the use its result. This does not result in any change in intent; it only avoids any past and potential future contradictions.
-
Khronos SPIR-V Issue #308: Don’t allow runtime-sized arrays to be loaded or copied by OpLoad or OpCopyMemory.
-
Include back-edge blocks in the list of blocks that can branch outside their own construct in the structured control-flow rules.
-
Khronos OpenGL API issue #77: Clarify the OriginUpperLeft and OriginLowerLeft execution modes apply only to FragCoord.
-
State the XfbStride and Stream restrictions in the Universal Validation Rules.
-
Khronos SPIR-V Issue #357: The Memory Operands of OpCopyMemory and OpCopyMemorySized applies to both Source and Target.
-
Khronos SPIR-V Issue #385: Be more clear what type <id> must be the same in OpCopyMemory.
-
Khronos SPIR-V Issue #359: OpAccessChain and OpPtrAccessChain do indexing with signed indexes, and OpPtrAccessChain is allowed to compute addresses of elements one past the end of an array.
-
Khronos SPIR-V Issue #367: General validation rules allow the Function storage class for atomic access, while the shader-specific validation rules do not.
-
Khronos SPIR-V Issue #382: In OpTypeFunction, disallow parameter types from being OpTypeVoid.
-
Khronos SPIR-V Issue #374: Built-in decorations can also apply to a constant instruction.
-
-
Editorial:
-
Make it more clear in OpVariable what Storage Classes must be the same.
-
Remove references to specific APIs, and instead generally refer only to "client API"s. Note that the previous lists of APIs was nonnormative.
-
State the FPRoundingMode decoration rule more clearly in the section listing Validation Rules for Shader Capabilities.
-
Don’t say "value preserving" in the Conversion instructions. These now convert the "value numerically".
-
State variable-pointer validation rules more clearly.
-
4.32. Changes from Version 1.3, Revision 6
-
Reserve Tokens for:
-
SPV_INTEL_media_block_io
-
SPV_NV_cooperative_matrix
-
SPV_INTEL_device_side_avc_motion_estimation, partially. See the SPV_INTEL_device_side_avc_motion_estimation extension specification for a full listing of tokens.
-
-
Fixed Issues:
-
Khronos SPIR-V Issue #406: Scope values must come from the table of scope values.
-
Khronos SPIR-V Issue #419: Validation rules include AtomicCounter in the list of storage classes allowed for pointer operands to an OpFunctionCall.
-
Khronos SPIR-V Issue #325: OpPhi clarifications regarding parent dominance, in the instruction and the validation rules, and forward references in the Logical Layout section.
-
Khronos SPIR-V Issue #415: Remove the non-writable storage classes PushConstant and Input from the FPRoundingMode decoration shader validation rule.
-
Khronos SPIR-V Issue #404: Clarify when OpGroupNonUniformShuffleXor, OpGroupNonUniformShuffleUp, and OpGroupNonUniformShuffleDown are valid or result in undefined values.
-
Khronos SPIR-V Issue #393: Be more clear that OpConvertUToPtr and OpConvertPtrToU operate only on unsigned scalar integers.
-
Khronos SPIR-V Issue #416: Result are undefined for all Shift instructions for shifts amounts equal to the bit width of the operand.
-
Khronos SPIR-V Issue #399: Refine the definition of a variable pointer, particularly for function parameters receiving a variable pointer.
-
Khronos SPIR-V Issue #441: Clarify that atomic instruction’s Scope <id> must be a valid memory scope. More generally, all Scope <id> operands are now either Memory or Execution.
-
Khronos SPIR-V Issue #426: Be more direct about undefined behavior for non-uniform control flow in OpControlBarrier and the OpGroup… instructions that discuss this.
-
-
Deprecate
-
Khronos SPIR-V Issue #429: Deprecate OpDecorationGroup, OpGroupDecorate, and OpGroupMemberDecorate
-
-
Editorial
-
Add more clarity that the full client API describes the execution environment (there is not a separate specification from the client API specification).
-
4.33. Changes from Version 1.3, Revision 7
-
Fixed Issues:
-
Khronos SPIR-V Issue #371: Restrict intermediate object types to variable types allowed at global scope. See shader validation data rules.
-
Khronos SPIR-V Issue #408: (Re)allow the decorations Volatile, Coherent, NonWritable, and NonReadable on members of blocks. (Temporarily dropping this functionality was accidental/clerical; intent is that it has always been present.)
-
Khronos SPIR-V Issue #418: Add statements about undefinedness and how NaNs are mixed to OpGroupNonUniformFAdd, OpGroupNonUniformFMul, OpGroupNonUniformFMin, and OpGroupNonUniformFMax.
-
Khronos SPIR-V Issue #435: Expand the universal validation rule for variable pointers and matrices to also disallow pointing within a matrix.
-
Khronos SPIR-V Issue #447: Remove implication that OpPtrAccessChain obeys an ArrayStride decoration in storage classes laid out by the implementation.
-
Khronos SPIR-V Issue #450: Allow pointers to OpFunctionCall to be pointers to an element of an array of samplers or images. See the universal validation rules under the Logical addressing model without variable pointers.
-
Khronos SPIR-V Issue #452: OpGroupNonUniformAllEqual uses ordered compares for floating-point values.
-
Khronos SPIR-V Issue #454: Add OpExecutionModeId to the list of allowed forward references in the Logical Layout of a Module.
-
4.34. Changes from Version 1.3
-
New Functionality:
-
Public issue #35: OpEntryPoint must list all global variables in the interface. Additionally, duplication in the list is not allowed.
-
Khronos SPIR-V Issue #140: Generalize OpSelect to select between two objects.
-
Khronos SPIR-V Issue #156: Add OpUConvert to the list of required opcodes in OpSpecConstantOp.
-
Khronos SPIR-V Issue #345: Generalize the NonWritable decoration to include Private and Function storage classes. This helps identify lookup tables.
-
Khronos SPIR-V Issue #84: Add OpCopyLogical to copy similar but unequal types.
-
Khronos SPIR-V Issue #170: Add OpPtrEqual and OpPtrNotEqual to compare pointers.
-
Khronos SPIR-V Issue #362: Add OpPtrDiff to count the number of elements between two element pointers.
-
Khronos SPIR-V Issue #332: Add SignExtend and ZeroExtend image operands.
-
Khronos SPIR-V Issue #340: Add the UniformId decoration, which takes a Scope operand.
-
Khronos SPIR-V Issue #112: Add iteration-control loop controls.
-
Khronos SPIR-V Issue #366: Change Memory Access operands and the Memory Access section to now be Memory Operands and the Memory Operands section.
-
Khronos SPIR-V Issue #357: Allow OpCopyMemory and OpCopyMemorySized to have Memory Operands for both their Source and Target.
-
-
New Extensions Incorporated into SPIR-V 1.4:
-
SPV_KHR_no_integer_wrap_decoration. See NoSignedWrap and NoUnsignedWrap decorations and universal validation decoration rules.
-
SPV_GOOGLE_decorate_string. See OpDecorateString and OpMemberDecorateString.
-
SPV_GOOGLE_hlsl_functionality1. See CounterBuffer and UserSemantic decorations.
-
SPV_KHR_float_controls. See DenormPreserve, DenormFlushToZero, SignedZeroInfNanPreserve, RoundingModeRTE, and RoundingModeRTZ execution modes and capabilities.
-
-
Removed:
-
Khronos SPIR-V Issue #437: Removed OpAtomicCompareExchangeWeak, and the BufferBlock decoration.
-
4.35. Changes from Version 1.4, Revision 1
-
GitHub SPIRV-Registry Issue #25: Remove validation rule for simultaneous use of RowMajor and ColMajor, instead stating this in the decoration cells themselves.
-
Khronos Issue #319: Bring in fixes to the SPV_KHR_16bit_storage extension. See the StorageBuffer16BitAccess and the related 16-bit capabilities.
-
Khronos Issue #363: OpTypeBool can be used in the Input and Output storage classes, but the client APIs still only allow built-in Boolean variables (e.g. FrontFacing), not user variables.
-
Khronos Issue #432: Remove the untrue expository statement "OpFunction is the only valid use of OpTypeFunction."
-
Khronos Issue #465: Distinguish between the Groups capability and the Group and Subgroup instructions.
-
Khronos Issue #484: Have OpTypeArray and OpTypeStruct point to their definitions.
-
Khronos Issue #477: Include 0.0 in the range of required values for RelaxedPrecision and other minor clarifications in the relaxed-precision section regarding floating-point precision.
-
Khronos Issue #226: Be more clear about explicit level-of-detail being either Lod or Grad throughout the sampling instructions, and that ConstOffset, Offset, and ConstOffsets are mutually exclusive in the image operand’s descriptions.
-
Khronos Issue #390: The Volatile decoration does not guarantee each invocation performs the access.
-
Reserved New Tokens for:
-
SPV_EXT_fragment_shader_interlock
-
SPV_NV_shader_sm_builtins
-
SPV_INTEL_shader_integer_functions2
-
SPV_EXT_demote_to_helper_invocation
-
SPV_KHR_shader_clock
-
SPV_GOOGLE_user_type
-
Volatile, for SPV_KHR_vulkan_memory_model
-
4.36. Changes from Version 1.4
-
Extensions Incorporated into SPIR-V 1.5:
-
SPV_KHR_8bit_storage
-
SPV_EXT_descriptor_indexing
-
SPV_EXT_shader_viewport_index_layer, with changes: Replaced the single ShaderViewportIndexLayerEXT capability with the two new capabilities ShaderViewportIndex and ShaderLayer. Declaring both is equivalent to declaring ShaderViewportIndexLayerEXT.
-
SPV_EXT_physical_storage_buffer and SPV_KHR_physical_storage_buffer
-
SPV_KHR_vulkan_memory_model
-
-
Khronos Issue #402: Relax OpGroupNonUniformBroadcast Id from constant to dynamically uniform, starting with version 1.5.
-
Khronos Issue #493: Relax OpGroupNonUniformQuadBroadcast Id from constant to dynamically uniform, starting with version 1.5.
-
Khronos Issue #494: Update the Dynamically Uniform definition to say that the invocation group is the set of invocations, unless otherwise stated.
-
Khronos Issue #485: When RelaxedPrecision is applied to a numerical instruction, the operands may be truncated.
4.37. Changes from Version 1.5, Revision 1
-
Khronos Issue #511: Allow non-execution non-memory scopes in the introduction to the Scope <id> section .
-
Khronos MR !147: Fix OpFNegate so it handles 0.0f properly
-
Khronos Issue #502: OpAccessChain array indexes must be an in-bounds for logical pointer types.
-
Khronos Issue #518: Include both VariablePointers and VariablePointersStorageBuffer capabilities in the validation rules when discussing variable pointer rules.
-
Khronos Issue #496: Allow Invariant to decorate a block member.
-
Khronos Issue #469: Disallow OpConstantNull result and OpPtrEqual, OpPtrNotEqual, and OpPtrDiff operands from being pointers into the PhysicalStorageBuffer storage class. See the PhysicalStorageBuffer validation rules.
-
Khronos Issue #425: Clarify what variables can allocate pointers, in the validation rules, based on the declarations of the VariablePointers or VariablePointersStorageBuffer capabilities.
-
Khronos Issue #442: Add a note pointing out where signedness has some semantic meaning.
-
Khronos Issue #498: Relaxed the set of allowed types for some Group and Subgroup instructions.
-
Khronos Issue #500: Deprecate OpLessOrGreater in favor of OpFOrdNotEqual.
-
Khronos Issue #354: Rationalize literals throughout the specification. Remove "immediate" as a separate definition. Be more rigid about a single literal mapping to one or more operands, and that the instruction description defines the type of the literal.
-
Khronos Issue #479: Disallow intermediate aggregate types that could not be used to declare global variables, and disallow all types that can’t be used for declaring variables. See the shader validation "Type Rules". Also, more strongly state that intermediate values don’t form a storage class, in the introduction to storage classes.
-
Khronos Issue #78: Use a more correct definition of back edge.
-
Khronos Issue #492: Overflow with OpSDiv, OpSRem, and OpSMod results in undefined behavior.
4.38. Changes from Version 1.5, Revision 2
-
Reserve enumerants for SPV_KHR_ray_query and SPV_KHR_ray_tracing.
-
Khronos MR #164: Subtract all exits from what a construct contains, not just the construct’s merge block. See the Structured Control Flow section.
-
Khronos Issues #394 and #473: More clearly state that the <id> declared by an OpTypeForwardPointer can be consumed by any type-declaration instruction that can legally consume the type of <id>. Also consolidated the rules for this within the instruction itself.
-
Khronos Vulkan Issue #1951: Clarify that the SampledImageArrayDynamicIndexing capability applies to dynamic indexing of image, sampler and sampled image objects.
-
Khronos Issue #523: Label as memory Scope the additional operand for each of
-
MakeTexelAvailable and MakeTexelVisible image operands, and
-
MakePointerAvailable and MakePointerVisible memory operands.
-
-
Khronos Issue #529: Allow the scope of uniform control flow to be defined by the client API.
-
Khronos Issue #530: Allow the definition of derivative group to be set by the client API.
-
Khronos Issue #293: Editorial simplification and clarification of different types under Types and Variables.
-
Khronos Issue #506: Add to the definition of Pure under Function Control that assuming it computes the same results also requires the same global state.
-
Khronos Issue #539: Clarify out-of-bounds indexes for OpAccessChain.
-
Khronos Issue #550: Include OpUndef in the allowed constituents for OpSpecConstantComposite.
-
Khronos Issue #389: Be more clear which instructions can be updated with a specialization constant in the specialization section.
-
Khronos Issue #544: Be more concise with OpLabel language.
-
Khronos Issue #245: State that Dref operands must be 32-bit scalar floats in the image instructions.
-
Khronos Issue #457: Change rule for OpUnreachable to being that behavior is undefined if it is executed.
-
Khronos Issue #231: Explicitly state that the component numbers 0, 1, 2, and 3 are 32-bit scalar integers for OpImageGather and OpImageSparseGather.
-
Khronos Issue #534: State where OpNoLine can be in the logical layout and with OpPhi.
-
Khronos MR #168: Add definitions of quad and quad index, used by OpGroupNonUniformQuadBroadcast and OpGroupNonUniformQuadSwap.
4.39. Changes from Version 1.5, Revision 3
-
Reserve enumerants for the extensions
-
SPV_INTEL_fpga_loop_controls
-
SPV_INTEL_blocking_pipes
-
SPV_INTEL_unstructured_loop_controls
-
SPV_INTEL_fpga_reg
-
SPV_INTEL_fpga_memory_attributes
-
SPV_INTEL_kernel_attributes
-
SPV_INTEL_function_pointers
-
SPV_EXT_shader_image_int64
-
SPV_KHR_fragment_shading_rate
-
SPV_EXT_shader_atomic_float_add
-
-
Establish formal meanings for validity (being statically expressed) and behavior (regarding dynamic execution), in Validity and Defined Behavior. This also changed a number of uses of these terms throughout the specifications to be consistent with these definitions.
-
Main issue for this: Khronos issue #540.
-
Addresses Khronos issues #542, #540, #545, #546, #547, and #548.
-
Khronos issue #491: For OpConvertFToU and OpConvertFToS, behavior is undefined if Result Type is not wide enough to hold the converted value.
-
Khronos issue #591: Module validity does not depend on the default values of specialization constants.
-
-
Fix Khronos issues:
-
#214: LoD and gather Image Instructions need non-multisampled images (MS of 0), while others that provide a Sample Image Operand need a multisampled image (MS of 1).
-
#324: For several Capabilities, explicitly list the values OpTypeImage has for Sampled, instead of saying sampled or unsampled.
-
#361: Stop requiring OpTypeRuntimeArray to be concrete, in the description of OpTypeRuntimeArray. (This may still be restricted elsewhere though.)
-
#553: Add definition of a tangled instruction and update the definitions of dynamic instance and uniform control flow.
-
#517: Expand the About This Document section to also discuss versioning.
-
#564: Depth hint for the DepthLess execution mode means less-than-or-equal to.
-
#558: Explicitly say (rather than imply) that ImageMipmap and ImageReadWrite capabilities apply to kernels.
-
#563: Delete unnecessary statement about incomplete images in OpImageQueryLod.
-
#570: Update the definitions of the Acquire and Release memory semantics.
-
#560: It is not valid to make duplicate BuiltIn variables.
-
#566: The Client API specificies what happens with image coordinates outside the image for OpImageRead, OpImageWrite, and OpImageSparseRead.
-
#573: Clarify the type read/written is scalar or vector in OpImageRead, OpImageWrite, and OpImageSparseRead.
-
#595: Remove the parenthetical partial list of annotation instructions in the logical layout section.
-
#574: Constituents of OpConstantComposite must not be specialization constants.
-
#444: Use more restrictive "only" language for what decorations may apply to.
-
MR !182: See the client API for how SubpassData coordinates are applied in OpImageRead.
-
4.40. Changes from Version 1.5, Revision 4
-
Update to January 7, 2021 public headers.
4.41. Changes from Version 1.5, Revision 5
-
Ported the specification itself to use asciidoctor instead of asciidoc.
-
Reserve enumerants for the extensions:
-
SPV_INTEL_float_controls2
-
SPV_INTEL_vector_compute
-
SPV_INTEL_arbitrary_precision_floating_point
-
SPV_INTEL_usm_storage_classes
-
SPV_INTEL_unstructured_loop_controls
-
SPV_KHR_subgroup_uniform_control_flow
-
SPV_KHR_linkonce_odr
-
SPV_KHR_expect_assume
-
SPV_EXT_shader_atomic_float_min_max
-
SPV_KHR_integer_dot_product
-
SPV_KHR_bit_instructions
-
SPV_NV_ray_tracing_motion_blur
-
SPV_INTEL_optnone
-
SPV_NV_bindless_texture
-
-
Add CPP_for_OpenCL source language.
-
Clarify that OpFDiv has a defined result when the divisor is 0. (MR !195.)
-
Fix execution-mode table to show all 3 operands for LocalSizeHintId.
-
Fix GitHub SPIRV-Registry issues:
-
#79: Clarify the definitions of StorageImageMultisample and ImageMSArray capabilities.
-
-
Fix Khronos issues:
-
#351: OpUDiv and OpUMod have undefined behavior if the divisor is 0.
-
#621: Clarify the definition of the Sampled operand for OpTypeImage.
-
#611: Clarifying string literals are case sensitive for comparisons.
-
#615: Clarify Block and BufferBlock decorations.
-
#654: Clarify that the ZeroExtend image operand is not valid with signed types.
-
#623: Clarify OpAccessChain doesn’t create any extra restrictions.
-
#647: Clarify NoWrite and NoReadWrite function parameter attributes apply to the pointer, not to the underlying memory.
-
#585: Clarify that OpCopyObject cannot have result type OpTypeVoid.
-
#614: Clarify that OpUndef, OpPhi, and OpReturnValue cannot have result type OpTypeVoid.
-
#115: Clarify the Shader validation rules for when OpSelectionMerge and OpLoopMerge instructions are necessary.
-
#656: Clarify the <id>-based rules for operands apply only to operands that are <id>s, in the OpSpecConstantOp instruction.
-
#627: Clarify the places that the RelaxedPrecision decoration must apply to.
-
#549: Clarify the VariablePointers and VariablePointersStorageBuffer capabilities enable additional features for logical pointers, but keep other prohibitions. Also that the VariablePointers and VariablePointersStorageBuffer capabilities allow a pointer to be an operand to OpReturnValue.
-
#640: Add parenthetical note in structured control flow about reconverging before reaching a merge block.
-
#656: Clarify the <id>-based rules for OpSpecConstantOp operands apply only to operands that are <id>s.
-
#651: Add a validation rule that the workgroup size cannot have a dimension with the value zero statically.
-
#580: Clarify that SubpassInput is not valid as the Dim operand of OpTypeSampledImage, and that sampled images with a Dim of Buffer are not valid in image sampling instructions.
-
#619: Add a validation rule that LocalSize, LocalSizeId, LocalSizeHint, and LocalSizeHintId can’t be used at the same time.
-
#663: Restrict OpSwitch from being used to directly break or continue in a structured loop.
-
#678: Allow the AliasedPointer and RestrictPointer decorations to apply to memory object declarations.
-
#682: Clarify that the VariablePointersStorageBuffer capability is sufficient to compare pointers that point into different storage buffers using OpPtrEqual and OpPtrNotEqual.
-
-
Changes from public headers
-
PR #240: Remove the Kernel capability from fast-math flags.
-
PR #257: Remove the Shader implicit declaration from SPV_EXT_shader_atomic_float_add capabilities.
-
4.42. Changes from Version 1.5
-
New Functionality:
-
Khronos SPIR-V issue #515: The FPFastMathMode decoration may now be used with OpFNegate, with the binary floating-point comparison instructions (including OpOrdered and OpUnordered), and with OpExtInst where expressly permitted by the extended instruction set.
-
#661: Added a Nontemporal Image Operand.
-
-
Extensions Incorporated into SPIR-V 1.6:
-
SPV_KHR_non_semantic_info, see OpExtInstImport.
-
SPV_KHR_integer_dot_product
-
SPV_KHR_terminate_invocation
-
SPV_EXT_demote_to_helper_invocation, with changes: Only OpDemoteToHelperInvocationEXT was incorporated. Instead of using OpIsHelperInvocationEXT, modules should use Volatile loads of the HelperInvocation built-in variable.
-
-
Deprecations and Removals, from Khronos SPIR-V issues:
-
Removed OpLessOrGreater. Use OpFOrdNotEqual instead.
-
#620: The WorkgroupSize built-in is deprecated starting with version 1.6.
-
#645: The True Label and False Label of an OpBranchConditional must not be the same, starting with version 1.6.
-
#584: Disallow Dim Buffer in OpTypeSampledImage and OpSampledImage starting with version 1.6.
-
Deprecated OpKill, in favor of OpTerminateInvocation, or OpDemoteToHelperInvocation.
-
-
Reserve enumerants for the SPV_KHR_fragment_shader_barycentric extension.
4.43. Changes from Version 1.6, Revision 1
-
Reserve enumerants for:
-
SPV_KHR_ray_cull_mask
-
SPV_KHR_uniform_group_instructions
-
SPV_AMD_shader_early_and_late_fragment_tests
-
SPV_INTEL_vector_compute
-
SPV_INTEL_memory_access_aliasing
-
SPV_INTEL_split_barrier
-
SYCL source language
-
-
Fix Khronos issues:
-
#680, #685, #696: Refine, clarify, and fix structured control-flow definitions and rules:
-
Add the concept of a structured control-flow path to better express the rules for structured control flow, as defined by the following terms.
-
Terms: Define the terms branch edge, merge edge, continue edge, structured control-flow edge, path, structured control-flow path, structurally reachable, structurally dominate, and structurally post dominate. Remove "post dominate". Revise definition of back edge to refer to branch edge instead of branch. Pull out back-edge block into its own definition. Rename the term "termination instruction" to block termination instruction and introduce the term function termination instruction.
-
Rework and simplify structured control-flow rules using the terms above. Clarify that a loop’s continue target must be different from its merge block. Remove redundant condition that a loop’s continue construct must contain the loop’s back-edge block. Precisely define the rules for exiting structured control-flow constructs.
-
-
#672, #673, #674: Clarify branching rules for the OpSwitch instruction, for:
-
the order in which target operands appear in an OpSwitch instruction,
-
duplicated targets, and
-
branching between case constructs, to make it clear that branch edges do not have to start at a switch target, but can come from anywhere in a switch construct.
-
-
#695: For most cases, disallow multiple uses of the same decoration on the same <id> or structure member.
-
#696: Change validation rules for physical storage buffers to clarify they apply to pointers nested in other types (not just arrays).
-
#672, #704: Clarify branching rules under switch construct rules for the OpSwitch instruction, making it clear that the rules about target ordering only apply to targets that define case constructs, and resolving ambiguity about what is allowed when the default case construct appears in the list of targets.
-
-
Clarify the meaning of fast math flags when the asserted properties are not true.
4.44. Changes from Version 1.6, Revision 2
-
Reserve enumerants for:
-
SPV_KHR_ray_tracing_position_fetch
-
SPV_QCOM_image_processing
-
SPV_ARM_core_builtins
-
SPV_NV_shader_invocation_reorder
-
SPV_NV_displacement_micromap
-
SPV_AMDX_shader_enqueue
-
SPV_INTEL_fp_max_error
-
SPV_INTEL_kernel_attributes
-
SPV_INTEL_cache_controls
-
SPV_INTEL_global_variable_fpga_decorations
-
SPV_INTEL_global_variable_host_access
-
SPV_INTEL_bfloat16_conversion
-
SPV_INTEL_runtime_aligned
-
SPV_INTEL_fpga_argument_interfaces
-
SPV_INTEL_fpga_dsp_control
-
SPV_INTEL_fpga_invocation_pipelining_attributes
-
SPV_INTEL_fpga_latency_control
-
SPV_INTEL_fpga_loop_controls
-
SPV_INTEL_fpga_memory_attributes
-
SPV_EXT_image_raw10_raw12
-
SPV_EXT_shader_tile_image
-
SPV_EXT_mesh_shader
-
SPV_EXT_opacity_micromap
-
-
Other changes from public headers
-
Added source languages HERO_C, NZSL, WGSL, and Slang
-
Removed the Kernel enabling capability from the sampler addressing modes.
-
-
Fix SPIR-V Registry issues:
-
#72: Be consistent in OpTypeBool that SPIR-V can support Booleans in the UniformConstant storage class.
-
#197: Clarify that OpQuantizeToF16 must flush denormalized values to 0.
-
-
Fix Khronos SPIR-V issues:
-
#689: Clarify use of OpPhi on OpTypeImage in the universal validation rules.
-
#708: Remove unused definitions of Break Block, Continue Block and Return Block.
-
#707: Clarify that using a bad Direction in OpGroupNonUniformQuadSwap is invalid SPIR-V.
-
#712: Clarify multiple UserSemantic decorations can apply to a variable or structure member.
-
#731: Clarify that aliasing is based on dynamic execution.
-
#736: Clarify that OpArrayLength may have a logical pointer operand in the universal validation rules.
-
#737: Clarify validation rule restricting OpConstantNull from pointing into the PhysicalStorageBuffer storage class.
-
#738: Restrict OpImageQueryLevels and OpImageQueryLod images to have MS of 0.
-
#295: Clarify that the ZeroExtend and SignExtend image operands are not valid together.
-
#753: Clarify that GroupNonUniformQuad instructions are not affected by their execution scopes, and require the value to be subgroup.
-
#754: Modify ClusterSize operands to refer to the size of the group of invocations participating in the instruction instead of always talking about SubgroupSize.
-
#755: Clarify set of invocations affected by a group operation:
-
Add definition of group (invocations).
-
Add definition of workgroup.
-
Link to new definitions throughout the specification.
-
Modify description of Execution Scope to clarify that it identifies the group an instruction affects.
-
Remove restrictions on Execution Scope for most instructions, leaving it up to client APIs to restrict them.
-
Clarify that non-uniform instructions require the value of Execution Scope to be subgroup.
-
Clarify that GroupNonUniformQuad instructions are not affected by their execution scopes.
-
-
#757: Restrict the type of ballot bit sets to be 4-component vectors of 32-bit unsigned integers in Non-Uniform Instructions.
-
#758: Add the definition of a cluster.
-
#772: Clarify that OpPtrAccessChain does not dereference any pointer.
-
#750: Update validation rules to reflect support for image and sampler array non-uniform indexing.
-
-
Khronos SPIR-V MRs:
-
#261: Clarify that Sampled operand for OpImageSparseFetch is restricted to 1, bringing it in line with the constraint for OpImageFetch.
-
#280: Control barriers wait only for active invocations.
-
-
Deprecations:
-
Issue #756: Deprecated the use of BuiltIn to decorate a constant to set its value and removed the deprecation of the WorkgroupSize built-in. That is, WorkgroupSize is kept but no longer marked as deprecated (it is still required by OpenCL). The use of BuiltIn to decorate a constant to set its value was only for WorkgroupSize, which has been superseded by the LocalSizeId execution mode.
-
MR #277: Deprecated Simple memory model in favor of GLSL450.
-