spirv

SPIR-V Specification (Provisional)

John Kessenich, LunarG and Boaz Ouriel, Intel

Version 0.99, Revision 30

April 2, 2015

SPIR-V Specification (Provisional) ii

Copyright 2014-2015 The Khronos Group Inc. All Rights Reserved.

This specification is protected by copyright laws and contains material proprietary to the Khronos Group, Inc. It or any compo-nents may not be reproduced, republished, distributed, transmitted, displayed, broadcast, or otherwise exploited in any mannerwithout the express prior written permission of Khronos Group. You may use this specification for implementing the functionalitytherein, without altering or removing any trademark, copyright or other notice from the specification, but the receipt or possessionof this specification does not convey any rights to reproduce, disclose, or distribute its contents, or to manufacture, use, or sellanything that it may describe, in whole or in part.

Khronos Group grants express permission to any current Promoter, Contributor or Adopter member of Khronos to copy andredistribute UNMODIFIED versions of this specification in any fashion, provided that NO CHARGE is made for the specificationand the latest available update of the specification for any version of the API is used whenever possible. Such distributedspecification may be reformatted AS LONG AS the contents of the specification are not changed in any way. The specificationmay be incorporated into a product that is sold as long as such product includes significant independent work developed by theseller. A link to the current version of this specification on the Khronos Group website should be included whenever possiblewith specification distributions.

Khronos Group makes no, and expressly disclaims any, representations or warranties, express or implied, regarding this spec-ification, including, without limitation, any implied warranties of merchantability or fitness for a particular purpose or non-infringement of any intellectual property. Khronos Group makes no, and expressly disclaims any, warranties, express or implied,regarding the correctness, accuracy, completeness, timeliness, and reliability of the specification. Under no circumstances willthe Khronos Group, or any of its Promoters, Contributors or Members or their respective partners, officers, directors, employees,agents, or representatives be liable for any damages, whether direct, indirect, special or consequential damages for lost revenues,lost profits, or otherwise, arising from or in connection with these materials.

Khronos, SYCL, SPIR, WebGL, EGL, COLLADA, StreamInput, OpenVX, OpenKCam, glTF, OpenKODE, OpenVG, OpenWF,OpenSL ES, OpenMAX, OpenMAX AL, OpenMAX IL and OpenMAX DL are trademarks and WebCL is a certification markof the Khronos Group Inc. OpenCL is a trademark of Apple Inc. and OpenGL and OpenML are registered trademarks and theOpenGL ES and OpenGL SC logos are trademarks of Silicon Graphics International used under license by Khronos. All otherproduct names, trademarks, and/or company names are used solely for identification and belong to their respective owners.

SPIR-V Specification (Provisional) iii

REVISION HISTORY

NUMBER DATE DESCRIPTION NAME

1 Aug 2014 Created jk

29 Mar 2015 Provisional Release jk

30 2-Apr-2015 Provisional Release jk

SPIR-V Specification (Provisional) iv

Contents

1 Introduction 2

1.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 About this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Extendability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Debuggability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.5 Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.6 Static Single Assignment (SSA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.7 Built-In Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.8 Specialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.9 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Specification 6

2.1 Language Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.2 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.3 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.4 Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Physical Layout of a SPIR-V Module and Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4 Logical Layout of a Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5 Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5.1 SSA Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.6 Entry Point and Execution Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.7 Execution Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.8 Types and Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.9 Function Calling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.10 Extended Instruction Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.11 Structured Control Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.12 Specialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.13 Linkage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.14 ES Precision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.15 Debug Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.15.1 Function-Name Mangling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.16 Validation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.16.1 Universal Validation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.16.2 Validation Rules for Graphical Shader Entry Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.16.3 OpenCL Validation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

SPIR-V Specification (Provisional) v

2.17 Universal Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.18 Memory Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.18.1 Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.19 Execution Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.19.1 Code Motion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 Binary Form 21

3.1 Magic Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Source Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3 Execution Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4 Addressing Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.5 Memory Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.6 Execution Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.7 Storage Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.8 Dim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.9 Sampler Addressing Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.10 Sampler Filter Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.11 FP Fast Math Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.12 FP Rounding Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.13 Linkage Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.14 Access Qualifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.15 Function Parameter Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.16 Decoration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.17 BuiltIn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.18 Selection Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.19 Loop Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.20 Function Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.21 Memory Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.22 Memory Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.23 Execution Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.24 Group Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.25 Kernel Enqueue Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.26 Kernel Profiling Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.27 Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.27.1 Miscellaneous Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.27.2 Debug (Removable) Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.27.3 Annotation Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.27.4 Extension Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.27.5 Mode-Setting Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

SPIR-V Specification (Provisional) vi

3.27.6 Type-Declaration Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.27.7 Constant-Creation Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.27.8 Memory Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.27.9 Function Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.27.10 Texture Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.27.11 Conversion Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.27.12 Composite Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

3.27.13 Arithmetic Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3.27.14 Relational and Logical Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3.27.15 Derivative Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

3.27.16 Flow-Control Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

3.27.17 Atomic Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

3.27.18 Primitive Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

3.27.19 Barrier Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

3.27.20 Group Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

3.27.21 Device-Side Enqueue Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

3.27.22 Pipe Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

4 Changes from Revision 29 110

5 TBD 111

SPIR-V Specification (Provisional) 1 / 111

A Simple Binary Intermediate Language for Graphical Shaders and OpenCL Compute Kernels

Contributors and Acknowledgements

Connor Abbott, Intel

Dan Baker, Oxide Games

Pat Brown, NVIDIA

Patrick Doane, Blizzard Entertainment

Tim Foley, Intel

Ben Gaster, Qualcomm

Kerch Holt, NVIDIA

Neil Henning, Codeplay

Ashwin Kolhe, NVIDIA

Graeme Leese, Broadcom

Yuan Lin, NVIDIA

Timothy Lottes, Epic Games

Daniel Koch, NVIDIA

John McDonald, Valve

Andrew Richards, Codeplay

Ian Romanick, Intel

Graham Sellers, AMD

Robert Simpson, QUALCOMM

NoteThis specification can be printed with some or all language capabilities present. See Language Capabilities for details. Thisprinting includes the following capabilities:

Basic Shaders, which includes Matrices and vertex, fragment, and compute shaders.

Geometry Shaders.

Tessellation Shaders.

Physical Addressing.

Linking.

Kernels for OpenCL.


1 Introduction

Abstract

Abstract. This document fully defines SPIR-V, a new binary intermediate language for representing graphical-shader stagesand compute kernels for multiple Khronos APIs. Each function in a SPIR-V module contains a control-flow graph (CFG) ofbasic blocks, with additional instructions and constraints to retain source-code structured flow control. Load/store instructionsare used to access declared variables, which includes all input/output (IO). Intermediate results bypassing load/store use staticsingle-assignment (SSA) representation. Data objects are represented logically, with hierarchical type information: There is noflattening of aggregates or assignment to physical register banks, etc. Selectable addressing models establish whether generalpointers may be used, or if memory access is purely logical.

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 short, transparent, self-contained specification (sections Specification and Binary Form).

Map easily to other IRs, including LLVM IR.

Be the form passed by an API into a driver to set shaders/kernels.

Can be targeted by new front ends for novel high-level languages.

Allow the first parts of the source compilation and reflection process 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.

Allow separation of core specification from source language-specific sets of built-in functions.

Reduce compile time during application run time. (Eliminating most of the compile time during application run time is not agoal of this IL. Target-specific register allocation and scheduling are expected to still take significant time.)

Allow some optimizations to be done offline.

1.2 About this document

This document aims to:

Include everything needed to fully understand, create, and consume SPIR-V.

Imported sets of instructions (which implement source-specific built-in functions) will need their own specification.

Separate expository and specification language. The specification-proper is in Specification and Binary Form.


1.3 Extendability

SPIR-V can be extended by multiple vendors/parties simultaneously:

Using the OpExtension instruction to require new semantics that must be supported. Such new semantics would come from anextension document.

Reserving (registering) ranges of the enumerants, as described further below.

Aided by instruction skipping, also further described below.

Enumerants. It is easy to extend all the types, storage classes, opcodes, decorations, etc. by adding to the enumeration tokens.

Registration. Ranges of token values in the Binary Form section can be pre-allocated to numerous vendors/parties. This allowscombining multiple independent extensions without conflict.

Extended Instructions. Sets of extended instructions can be provided and specified in separate specifications. These helppersonalize SPIR-V for different source languages or execution environments. Multiple sets of extended instructions can beimported 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 triviallyenabled by the word count in an instruction, which makes it easier to add new instructions without breaking existing tools.

1.4 Debuggability

SPIR-V can decorate, with a text string, virtually anything created in the shader: types, variables, functions, etc. This is re-quired for externally visible symbols, and also allowed for naming the result of any instruction. This can be used to aid inunderstandability when disassembling or debugging lowered versions of SPIR-V.

Line numbers and file names can also be decorations for any type, variable, instruction result, etc.

1.5 Design Principles

Regularity. All instructions start with a word count. This allows walking a SPIR-V module without decoding each opcode. Allinstructions have an opcode that dictates for all operands what kind of operand they are. For instructions with a variable numberof operands, the number of variable operands is known by subtracting the number of non-variable words from the instructionsword count. Instructions with a string operand always take the string operand as the last operand.

Non Combinatorial. There is no combinatorial type explosion or need for large encode/decode tables for types. Rather, typesare parameterized. Sampler types declare their dimensionality, arrayness, etc. all orthogonally, which greatly simplify code. Thisis 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., OpenGL stage) is specified, internal operation is essentially mode-less: Generallyit will follow the rule: "same spelling, same semantics", and does not have mode bits (like version #) that modify semantics. If achange to SPIR-V modifies semantics, it should use a different spelling. This makes downstream code much more robust. Thereare execution modes declared, but these are generally to affect the way the module interacts with the environment around it, notthe internal semantics.

Declarative. SPIR-V declares externally-visible modes like "writes depth", rather than having rules that require deduction fromfull shader inspection. It also explicitly declares what addressing modes, execution model, extended instruction sets, etc. will beused. See Language Capabilities for more information.

SSA. All results of intermediate operations are strictly SSA. However, declared variables use load/store for access and variablescan be stored to multiple times.

IO. Some storage classes are for input/output (IO) and, fundamentally, IO will be done through load/store of variables declaredin these storage classes.


1.6 Static Single Assignment (SSA)

SPIR-V includes a phi-instruction to allow the merging together of intermediate results from split flow control. This allowscomputation without load/store to variables. SPIR-V is flexible in the degree to which load/store is used; it is possible to use flowcontrol with no phi-instructions, while still staying in SSA form. (The store instruction does not have a result that participates inthe SSA name space.)

Some storage classes are for IO and, fundamentally, IO will be done through load/store, and initial load and final store cannever be eliminated. Other storage classes are shader local and can have their load/store eliminated. It can be considered anoptimization to largely eliminate such load/stores by moving them into intermediate results in SSA form.

1.7 Built-In Variables

SPIR-V identifies built-in variables from a high-level language with an enumerant decoration. This assigns any unusual semanticsto the variable. Built-in variables must otherwise be declared and treated the same as any other variable.

1.8 Specialization

Specialization enables creating a portable SPIR-V module outside the target execution environment, based on constant valuesthat wont be known until inside the execution environment. For example, to size a fixed array with a constant not known duringcreation 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.9 Example

The SPIR-V form is binary, not human readable, and fully described in Binary Form. This is an example direct disassembly togive a basic idea of what SPIR-V looks like.

GLSL fragment shader:

#version 450

in vec4 color1;noperspective in vec4 color2;out vec4 color;

uniform vec4 multiplier;uniform bool cond;

struct S {bool b;vec4 v[5];int i;

};uniform S s;

void main(){

vec4 scale = vec4(1.0, 1.0, 2.0, 1.0);

if (cond)color = color1 + s.v[2];

elsecolor = sqrt(color2) * scale;

for (int i = 0; i < 4; ++i)color *= multiplier;

}


Corresponding SPIR-V:

Result-Id Type-Id Opcode Operands...

Source GLSL 4501: ExtInstImport "GLSL.std.450"

MemoryModel Logical GLSL450EntryPoint Fragment 4Name 4 "main"Name 10 "scale"Name 16 "cond"Name 21 "color"Name 23 "color1"Name 29 "S"MemberName 29(S) 0 "b"MemberName 29(S) 1 "v"MemberName 29(S) 2 "i"Name 31 "s"Name 39 "color2"Name 45 "i"Name 53 "multiplier"Decorate 23(color1) SmoothDecorate 39(color2) Noperspective

2: TypeVoid3: TypeFunction 27: TypeFloat 328: TypeVector 7(float) 49: TypePointer Function 8(fvec4)

11: 7(float) Constant 106535321612: 7(float) Constant 107374182413: 8(fvec4) ConstantComposite 11 11 12 1114: TypeBool15: TypePointer UniformConstant 14(bool)

16(cond): 15(ptr) Variable UniformConstant20: TypePointer Output 8(fvec4)

21(color): 20(ptr) Variable Output22: TypePointer Input 8(fvec4)

23(color1): 22(ptr) Variable Input25: TypeInt 32 026: 25(int) Constant 527: TypeArray 8(fvec4) 2628: TypeInt 32 1

29(S): TypeStruct 14(bool) 27 28(int)30: TypePointer UniformConstant 29(S)

31(s): 30(ptr) Variable UniformConstant32: 28(int) Constant 133: 28(int) Constant 234: TypePointer UniformConstant 8(fvec4)

39(color2): 22(ptr) Variable Input44: TypePointer Function 28(int)46: 28(int) Constant 050: 28(int) Constant 4

53(multiplier): 34(ptr) Variable UniformConstant4(main): 2 Function None 3

5: Label10(scale): 9(ptr) Variable Function

45(i): 44(ptr) Variable FunctionStore 10(scale) 13

17: 14(bool) Load 16(cond)SelectionMerge 19 NoneBranchConditional 17 18 38

18: Label


24: 8(fvec4) Load 23(color1)35: 34(ptr) AccessChain 31(s) 32 3336: 8(fvec4) Load 3537: 8(fvec4) FAdd 24 36

Store 21(color) 37Branch 19

38: Label40: 8(fvec4) Load 39(color2)41: 8(fvec4) ExtInst 1(GLSL.std.450) 28(sqrt) 4042: 8(fvec4) Load 10(scale)43: 8(fvec4) FMul 41 42

Store 21(color) 43Branch 19

19: LabelStore 45(i) 46Branch 47

47: Label49: 28(int) Load 45(i)51: 14(bool) SLessThan 49 50

LoopMerge 48 NoneBranchConditional 51 52 48

52: Label54: 8(fvec4) Load 53(multiplier)55: 8(fvec4) Load 21(color)56: 8(fvec4) FMul 55 54

Store 21(color) 5657: 28(int) Load 45(i)58: 28(int) IAdd 57 32

Store 45(i) 58Branch 47

48: LabelBranch 6

6: LabelReturnFunctionEnd

2 Specification

2.1 Language Capabilities

Capability requirements for a module are declared early in a module.

A validator can validate that the module uses only declared capabilities.

An implementation may reject modules requesting capabilities it does not support.

Capabilities include:

CapabilityAbbrevi-

ation

Capability Declared Through DependsOn

Matrix Native matrices. OpTypeMatrixShader Shaders for vertex, fragment, and

compute stages.OpEntryPoint Matrix

Geom Geometry shaders OpEntryPoint ShaderTess Tessellation shaders. OpEntryPoint ShaderAddr Physical addressing, to allow

non-logical addressing modes.OpMemoryModel


CapabilityAbbrevi-

ation

Capability Declared Through DependsOn

Link Ability to have partially linked modulesand libraries.

Linkage AttributesDecoration

Kernel Kernels for OpenCL. OpEntryPoint

To obtain portable SPIR-V, a particular release of an API consuming SPIR-V must specify:

Which capabilities above are required to be supported.

Required limits, if they are beyond the Universal Limits.

2.2 Terms

2.2.1 Instructions

Word: 32-bits.

: A numerical name; the name used to refer to an object, a type, a function, a label, etc. An always consumes oneword. The s defined by a module obey SSA.

Literal String: A nul-terminated stream of characters consuming an integral number of words. The character set is Unicode inthe 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 strings nul-termination character (0),and all contents past the end of the string in the final word are padded with 0.

Literal Number: A numeric value consuming one or more words. When a numeric value is larger than one word, low-orderwords appear first.

Literal: A Literal String or a Literal Number.

Operand: A one-word argument to an instruction. E.g., it could be an , or a (part of a) literal. Which form it holds is alwaysexplicitly known from the opcode.

Immediate: Operand(s) directly holding a literal value rather than an . Immediates larger than one word will consumemultiple operands, one per word. That is, operand counting is always done per word, not per immediate.

Result : Most instructions produce a result, named by an explicitly provided in the instruction.

WordCount: The number of words taken by an instruction, including the instructions opcode and optional operands. That is, thetotal 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 , an optional of the instructions type, and a variable list of operands. All instruction opcodes andsemantics are listed in Instructions.

Decoration: Auxiliary information such as built-in variable, stream numbers, invariance, interpolation type, precision qualifiers,etc., added to s or structure members through decorations. Decorations are enumerated in Decoration in the Binary Formsection.

Annotation instruction: E.g., OpName, OpMemberName, OpLine, OpDecorate, OpMemberDecorate, OpGroupDecorate, Op-GroupMemberDecorate, and OpDecorationGroup. These add information to an created by some other instruction.

Object: An instantiation of a non-void type, either as the result of an operation, or created through OpVariable.

Memory Object: An object created through OpVariable. Such an object can die on function exit, if it was a function variable, orexist for the duration of an entry point.

Intermediate Object or Intermediate Value or Intermediate Result: An object created by an operation (not memory allocated byOpVariable) and dying on its last consumption.

Constant Instruction: Either a specialization-constant instruction or a fixed constant instruction: Instructions that start "OpCon-stant" or "OpSpec".


2.2.2 Types

Boolean type: The type returned by OpTypeBool.

Integer type: Any width signed or unsigned type from OpTypeInt.

Floating-point type: Any width type from OpTypeFloat.

Numerical type: An integer type or floating-point type.

Scalar: A single instance of a numerical type.

Vector: An ordered homogeneous collection of scalars. When scalars are part of a vector, they will also be called components.Vector sizes are quite restrictive and dependent on the execution model.

Matrix: An ordered homogeneous collection of vectors. When vectors are part of a matrix, they will also be called columns.Matrix sizes are quite restrictive and dependent on the execution model.

Array: An ordered homogeneous collection of any non-void-type objects. When an object is part of an array, it will also be calledan element. Array sizes are generally not restricted.

Structure: An ordered heterogeneous collection of any non-void types. When an object is part of a structure, it will also be calleda member.

Aggregate: A structure or an array.

Composite: An aggregate, a matrix, or a vector.

2.2.3 Module

Module: A single compilation unit of SPIR-V. Corresponds to one full stage of the graphical pipeline. Corresponds to a fully orpartially linked OpenCL kernel module with one or more entry points.

Execution Model: An OpenGL stage or OpenCL kernel. These are enumerated in Execution Model in the Binary Form section.

Entry Point: The function where a particular execution model will begin execution.

Execution Mode: Modes of operation relating to the interface or execution environment of the module. These are enumerated inExecution Mode in the Binary Form section.

Vertex Processor: Any stage or execution model that processes vertices: Vertex, tessellation control, tessellation evaluation, andgeometry. Explicitly excludes fragment and compute.

2.2.4 Flow Control

Structured Loop: A loop that retains nested flow-control structure using the OpLoopMerge instruction. See Structured ControlFlow.

Structured Switch: An OpSwitch that retains nested flow-control structure using the OpSelectionMerge instruction. See Struc-tured Control Flow.

Loop Break: An instruction within a Structured Loop that branches to the loops merge block.

Switch Break: An instruction within a Structured Switch that branches to the switchs merge block.

Loop Continue: An instruction within a Structured Loop that branches to the loops header block.

Break Block: A block containing a loop break or switch break instruction.

Continue Block: A block containing a loop continue instruction.

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:


WordNumber

Contents

0 Magic Number.1 Version number. The first public version will be 100 (use 99 for

pre-release).2 Generators magic number. It is associated with the tool that

generated the module. Its value does not affect any semantics, andis allowed to be 0. Using a non-0 value is encouraged, and can beregistered with Khronos.

3 Bound; where all s in this module are guaranteed to satisfy

0 < id < Bound

Bound should be small, smaller is better, with all in a modulebeing 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 WordNumber

Contents

0 Opcode: The 16 high-order bits are the WordCount of theinstruction. The 16 low-order bits are the opcode enumerant.

1 Optional instruction type (presence determined byopcode).

. Optional instruction result (presence determined byopcode).

. Operand 1 (if needed)

. Operand 2 (if needed). . . . . .

WordCount - 1 Operand N (N is determined by WordCount minus the 1 to 3words used for the opcode, instruction type , andinstruction result ).

Instructions are variable length due both to having optional instruction type and result words as well as a variablenumber 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:

1. Optional OpSource instruction stating the source language and version number.

2. Optional OpSourceExtension instructions (extensions used within the source language).

3. Optional OpCompileFlag instructions.

4. Optional OpExtension instructions (extensions to SPIR-V).

5. Optional OpExtInstImport instructions.

6. The single required OpMemoryModel instruction.

7. All entry point declarations, using OpEntryPoint.


8. All execution mode declarations, using OpExecutionMode.

9. All debug and annotation instructions, which must be in the following order:

a. all OpString

b. all OpName and all OpMemberName

c. all OpLine

d. all decoration instructions (OpDecorate, OpMemberDecorate, OpGroupDecorate, OpGroupMemberDecorate, andOpDecorationGroup).

10. All type declarations (OpTypeXXX instructions), all constant instructions, and all global variable declarations (all Op-Variable instructions whose Storage Class is not Function). All operands in all these instructions must be declared beforebeing used. Otherwise, they can be in any order.

11. All function declarations (functions without a body). A function declaration is as follows.

a. Function declaration, using OpFunction.

b. Function parameter declarations, using OpFunctionParameter.

c. Function end, using OpFunctionEnd.

12. All function definitions (functions with a body). A function definition is as follows.

a. Function definition, using OpFunction.

b. Function parameter declarations, using OpFunctionParameter.

c. Block

d. Block

e. . . .

f. Function end, using OpFunctionEnd.

Within a function definition:

A block always starts with an OpLabel instruction.

A block always ends with a branch instruction.

All variables declared in a function must have a Storage Class of Function.

All variable declarations in a function must be the first instructions in the first block in the function.

NoteForward references (an operand that appears before the result defining it) are allowed for function and annotation-instruction operands. This allows for recursion, early declaration of entry points, and ability to fully know a type or variable onceit is declared. Labels will also be forward referenced. Loops might also have forward references to a phi function. In all cases,there is enough type information to enable a single simple pass through a module to transform it. Function calls have all thetype information in the call, phi-functions dont change type, and labels dont have type.

The Validation Rules section lists additional rules that must be satisfied.


2.5 Instructions

Most instructions create a result , as provided in the result field of the instruction. These result s are then referredto by other instructions through their operands. All instruction operands are specified in the Binary Form section.

Instructions are explicit about whether they require immediates, rather than an referring to some other result. This is strictlyknown just from the opcode.

An immediate 32-bit (or smaller) integer is always one operand directly holding a 32-bit twos-complement value.

An immediate 32-bit float is always one operand, directly holding a 32-bit IEEE 754 floating-point representation.

An immediate 64-bit float is always two operands, directly holding a 64-bit IEEE 754 representation. The low-order 32-bitsappear in the first operand.

2.5.1 SSA Form

A module is always in single-static-assignment (SSA) form. That is, there is always exactly one instruction resulting in anyparticular result . Storing into variables declared in memory is not subject to this; such stores do not create result s.Accessing declared variables is done through

OpVariable to allocate an object in memory and create a result 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 that can then be used as an operand in other instructions.

OpStore through a pointer, to write a value. There is no result for an OpStore.

OpLoad and OpStore instructions can often be eliminated, using intermediate results instead. When this happens in multiplecontrol-flow paths, these values need to be merged again at the paths merge point. Use OpPhi to merge such values together.

2.6 Entry Point and Execution Model

The OpEntryPoint instruction identifies two things: an execution model and a function definition. Execution models includeVertex, GLCompute, etc. (one for each graphical stage), as well as Kernel for OpenCL kernels. For the complete list, seeExecution Model in the Binary Form section.

2.7 Execution Modes

Information like the following are declared with OpExecutionMode instructions. For example,

number of invocations (ExecutionInvocations)

vertex-order CCW (InputVertexOrderCcw)

triangle strip generation (OutputTriangleStrip)

number of output vertices (OutputVertices)

etc.

For a complete list, see Execution Mode in the Binary Form section.


2.8 Types and Variables

Types are built up hierarchically, using OpTypeXXX instructions. The result of an OpTypeXXX instruction becomes a type for future use where type s are needed. There is no type of an OpTypeXXX instruction.

The "leaves" to start building with are OpTypeFloat, OpTypeInt, and OpTypeBool. Other types are built up from the result 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, OpTypeSampler, OpTypeArray, Op-TypeRuntimeArray, OpTypeStruct, and OpTypePointer. These are parameterized by number of components, array size, memberlists, etc. The sampler types are parameterized by the return type, dimensionality, image, depth-comparison, etc. To do texturefiltering operations, a sampler must contain both a filter (sampling state) and a texture. Such a combined sampler can be setdirectly by the API, or made by combining a filter and sampler containing just a texture, which themselves were set by the API.

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 can be provided using the decoration instructions (OpDecorate, OpMem-berDecorate, OpGroupDecorate, OpGroupMemberDecorate, and OpDecorationGroup). These can add, for example, Invariantto an created by another instruction. See the full list of decorations in the Binary Form section.

Types are not allowed to be aliased: Two different type s must be for two different types. Non-structure types cannot bedecorated (OpDecorate). Hence, two non-structure types cannot and will not differ due to decoration differences. (If such deco-rations are desired, they can be applied to the object declared.) Structure type members can be decorated (OpMemberDecorate)and structure types can be decorated (OpDecorate). To support types that differ only in decoration, two different structure typescan be made that have the same member-type operands. Types are different even if the only difference is a decoration.

Variables are declared to be of an already built type, and placed in a storage class. Storage classes include UniformConstant,Input, WorkgroupLocal, etc. and are fully specified in Storage Class. Variables declared with the Function storage class canhave their lifetimes specified within their function using the OpLifetimeStart and OpLifetimeStop instructions.

Intermediate results are typed by the instructions type , which must validate with respect to the operation being done.

Built-in variables needing special driver handling (having unique semantics) are declared using OpDecorate or OpMemberDec-orate with the decoration BuiltIn, followed by a BuiltIn enumerant. This decoration is applied to a variable or structure member.

2.9 Function Calling

To call a function defined in the current module or a function declared to be imported from another module, use OpFunctionCallwith an operand that is the of the OpFunction to call, and the s of the arguments to pass. All arguments are passed byvalue 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 will 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 operationsinclude:

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. They can be referenced (but not specified) in this specifica-tion. The separate extended instruction set specification will specify instruction enumerants, semantics, and instruction names.

For example, the GLSL built-in functions are specified in the GLSL Built-In Functions.

To use an extended instruction set, first import it by name using OpExtInstImport and giving it a result :

OpExtInstImport "name-of-extended-instruction-set"

The "name-of-extended-instruction-set" is a literal string. The standard convention for this string is

".."

For example "GLSL.std.450" could be the name of the core built-in functions for GLSL versions 450 and earlier.

NoteThere is nothing precluding having two "mirror" sets of instructions with different names but the same enumerants, which could,for example, let modifying just the import statement to change a performance/accuracy tradeoff.

Then, to call a specific extended instruction, use OpExtInst:

OpExtInst instruction-number operand0, operand1, ...

Extended instruction-set specifications will provide semantics for each "instruction-number". One specification could choose thatthe granularity of the entry-point-numbers is per overloaded name, while another could choose to provide entry-point-numbersand mangled names for all the possible overloadings. The specification must be clear on its semantics, and producers/consumersof 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 thatinstruction name strings are provided or mangled.

NoteProducing and consuming extended instructions can be done entirely through numbers (no string parsing). An extendedinstruction set specification provides enumerants for the instructions, and these will be produced by the front end and consumedby the back end.

2.11 Structured Control Flow

Selection and looping in the CFG have the choice to explicitly represent structured form (nested control flow). Selection includesif-then-else using OpBranchConditional and switch using OpSwitch. Each such loop or selection construct will include:

the set of blocks forming its body,

one header block, and

one merge block. Merge blocks cannot be shared; each construct must have its own.

The constructs header and merge blocks are identified by a merge instruction: An OpLoopMerge instruction for loops and anOpSelectionMerge instruction for selections. The block containing this merge instruction is the header block, and the blockselected by the merge instructions Label operand is the merge block. The merge instruction is the second-to-last instruction inthe header block.

These blocks define the control-flow construct by satisfying these rules:


the header-block dominates all blocks in the construct, including the merge block

the merge-block post dominates all blocks in the construct, including the header block

with the exception of break blocks and continue blocks: Break and continue blocks, and the blocks they post dominate, are notpost dominated by the merge blocks of the nested constructs containing them.

That is, conceptually speaking, there is no branching from outside a structured control-flow construct to inside it, or from insideit to outside it, except for breaks and continues.

Note that a switch "default statement" that does nothing can be represented by the OpSwitchs Default operand being the labelof a structured switchs merge block.

2.12 Specialization

Specialization is provided as part of the Shader capability.

A module may be written to consume an externally provided specialization, which is a set of specialization constants. Applyinga specialization results in a modified module.

NoteNo optimizing transforms are required to make a specialized module functionally correct. The specializing transform is straight-forward and explicitly defined below.

NoteAd hoc specializing should not be done through constants (OpConstant or OpConstantComposite) that get overwritten: ASPIR-V SPIR-V transform might want to do something irreversible with the value of such a constant, unconstrained from thepossibility that its value could be later changed.

Within a module, a Specialization Constant is declared with one of these instructions:

OpSpecConstantTrue

OpSpecConstantFalse

OpSpecConstant

OpSpecConstantComposite

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 make anexternal specialization optional. However, such a default constant is used only if the external specialization does not include aspecialization for it and a fully specialized module must be created.

An external specialization is logically provided as a list of pairs. Each pair is an of a scalar specialization instructionalong with its specialization constant. The numeric values are exactly what the operands would be to an OpConstant instruction.Boolean values are true if non-zero and false if 0.

Specializing a module is straightforward. The following specialization instructions can be updated with specialization constants,and replaced in place, leaving everything else in the module exactly the same:

OpSpecConstantTrue -> OpConstantTrue or OpConstantFalseOpSpecConstantFalse -> OpConstantTrue or OpConstantFalse

OpSpecConstant -> OpConstantOpSpecConstantComposite -> OpConstantComposite


The external specialization must indicate whether it is a partial specialization or a full specialization. If it indicates a partial spe-cialization, then only those specialization constants provided by the external specialization can be modified. A full specializationallows all specialization instructions to be modified.

TBD. Add these instructions to Section 3 to use in constructing derived specialization constants:

OpSpecIAdd

OpSpecISub

OpSpecIMul

OpSpecUDiv (invalid to divide by 0)

OpSpecUMod

OpSpecLogicalAnd

OpSpecLogicalOr

OpSpecLogicalXor

2.13 Linkage

The ability to have partially linked modules and libraries is provided as part of the Link capability.

By default, functions and global variables are private to a module and cannot be accessed by other modules. However, a modulemay be written to export or import functions and global (module scope) variables. Imported functions and global variabledefinitions 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 assignsthe following linkage attributes to decorated values:

A Linkage Type.

A name, which is a Literal String, and is used to uniquely identify exported values.

NoteWhen resolving imported functions, the Function Control and all Function Parameter Attributes are taken from the functiondefinition, and not from the function declaration.

2.14 ES Precision

ES precision qualifiers are handled with OpDecorate and OpMemberDecorate instructions (or if more efficient, the OpGroupDec-orate, OpGroupMemberDecorate). The precision decorations are:

PrecisionLow

PrecisionMedium

PrecisionHigh

The precision decoration can be applied to

The of a variable, where the variables type is numerical (including vectors, arrays, etc. of numerical types, but not astructure).

The result of an instruction, meaning the instruction is to operate at and result in the decorated precision.


A structure member (through OpMemberDecorate).

There is no complex SPIR-V propagation algorithm to decide at what precision to operate. Any complex ES precision propagationalgorithms execute in the front-end that generates the module, not below. The rules for consuming SPIR-V are simply these:

If an instructions result has been decorated with a precision, implementation may use its definition of that precision.

If an instructions result has not been decorated with a precision, implementation must use full (nominal, non-qualified)precision for that instruction.

2.15 Debug Information

Debug information is supplied with the annotations OpName, OpMemberName, and OpLine. A module will not lose anysemantics 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 anyneed for name "unmangling". (Valid modules can be created without inclusion of mangled names.)

By convention, for debugging purposes, modules with OpSource of OpenCL use the Itanium name-mangling standard.

2.16 Validation Rules

2.16.1 Universal Validation Rules

All modules must obey the following, or it is an invalid module:

The stream of instructions must be ordered as described in the Logical Layout section.

Non-structure types (scalars, vectors, arrays, etc.) with the same operand parameterization cannot be type aliases. For non-structures, two type s match iff the types match.

If the Logical addressing model is selected:

OpVariable cannot allocate an object whose type is a pointer type A pointer can only be consumed by the following instructions

* OpLoad

* OpStore

A pointer can only be created by the following instructions:

* OpVariable

* OpAccessChain

* OpInBoundsAccessChain

SSA

Each must appear exactly once as the result of an instruction. The definition of an SSA should dominate all uses of it, with the following exceptions:

* Function calls may call functions not yet defined. However, note that the functions argument and return types will alreadybe known at the call site.

* Uses in a phi-function in a loop may consume definitions in the loop that dont dominate the use.

Entry point and execution model


There is at least one OpEntryPoint instruction, unless the Link capability is being used. No function can be targeted by both an OpEntryPoint instruction and an OpFunctionCall instruction.

Functions

A function declaration (an OpFunction with no basic blocks), must have a Linkage Attributes Decoration with the ImportLinkage Type.

A function definition (an OpFunction with basic blocks) cannot be decorated with the Import Linkage Type.

Global (Module Scope) Variables

It is illegal to initialize an imported variable. This means that a module-scope OpVariable with initialization value cannot bemarked 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 dominates all other blocks in the function. The order of blocks in a function must satisfy the partial ordering imposed by the functions dominator tree (dominators

must appear before 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.

All OpPhi instructions within a block must appear before all non OpPhi instructions in the block. Each block ends in one branch instruction. These are

* OpBranch

* OpBranchConditional

* OpSwitch

* OpKill

* OpReturn

* OpReturnValue

* OpUnreachable

The branch instructions can only appear as the last instruction in a block. OpLabel instructions can only appear within a function. All branches within a function must be to labels in that function. Structured Loops (those having an OpLoopMerge instruction).

* The header dominates the merge block.

* The merge block post-dominates the header, except for breaks and continues, see Structured Control Flow for more detail.

* The OpLoopMerge instruction must be the 2nd to last instruction in the header block.

Structured Selection (those have an OpSelectionMerge instruction)

* The header dominates the merge block.

* The merge block post-dominates the header, except for breaks and continues, see Structured Control Flow for more detail.

* The OpSelectionMerge instruction must be the 2nd to last instruction in the header block

* For a particular nesting level of OpSwitch, branches in that switchs Target operand must be to one of labels within that same Target (not inside another Target), or to the label of another Target at the same level of switch nesting, or to the switchs merge block.

All OpFunctionCall Function operands are an of an OpFunction in the same module.


Data rules

Vector types can only be parameterized with numerical types or the OpTypeBool type. Matrix types can only be parameterized with floating-point types. OpVariableArray can only be used for the Function storage class. Specialization constants (see Specialization) are limited to integers, Booleans, floating-point numbers, and vectors of these.

Decoration rules

The Aliased decoration can only be applied to intermediate objects that are pointers to non-void types. The Linkage Attributes decoration cannot be applied to Entry Point functions (functions targeted by an OpEntryPoint

instruction).

OpLoad and OpStore can only consume objects whose type is a pointer.

All OpLoad, OpStore, and OpPhi instructions must be within a function definition.

A result resulting from an instruction within a function can only be used in that function.

A function call must have the same number of arguments as the function definition has parameters.

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 either be formed by a variable declaration or an OpImagePointerinstruction.

The only instructions that can operate on a pointer to the storage class AtomicCounter are

* OpAtomicLoad

* OpAtomicIIncrement

* OpAtomicIDecrement

All pointers used in atomic operation instructions must be pointers to one of the following:

* 32-bit scalar integer

* 64-bit scalar integer

2.16.2 Validation Rules for Graphical Shader Entry Points

Can only have one OpEntryPoint.

Must select the Logical addressing model.

CFG:

Loops must be structured, having an OpLoopMerge instruction in their header. Selections must be structured, having an OpSelectionMerge instruction in their header.

Scalar integer types can be parameterized only as:

32-bit signed 32-bit unsigned

Scalar floating-point types can be parameterized only as:

32 bit 64 bit


Data rules:

Vector types for can only be parameterized as having 2, 3, or 4 components. Matrix types can only be parameterized as having only 2, 3, or 4 columns.

Texturing rules:

All OpSampler instructions must appear in the first basic block of the entry point.

2.16.3 OpenCL Validation Rules

The following rules are applicable to modules that use OpenCL1.2 and OpenCL2.0 Memory Model. Modules that adhere tothese rules can be consumed by an OpenCL runtime.

OpenCL supports Addr, Link, Kernel. The use of any other capability is disallowed.

Can only have Physical32 or Physical64 addressing model.

OpTypeInt validation rules

The bit width operand can only be parameterized as 8, 16, 32 and 64 bit. The sign operand must always be 0.

OpTypeFloat bit width operand can only be parameterized as 16, 32 and 64 bit.

OpTypeVector can only be parameterized as having 2, 3, 4, 8, or 16 components.

Variables used in atomic operations can only be 32-bit or 64-bit floating-point numbers, or a 32-bit or 64-bit signed integers.

2.17 Universal Limits

These quantities are minimum limits for all implementations and validators. Implementations are allowed to support largerquantities. Specific APIs may impose larger minimums. See Language Capabilities.

Validators must either

inform when these limits are crossed, or

be explicitly parameterized with larger limits.

Limited Entity Minimum LimitDecimal HexadecimalCharacters in a literal name 1024 400Characters in a literal string 65,536 10000

Instruction word count264 108

(256 operand words plus 8more words)

Result bound

See Physical Layout for the shader-specific bound.4,194,304 400,000

Control-flow nesting depth

Measured per function, in program order, counting themaximum number of OpBranch, OpBranchConditional,or OpSwitch that are seen without yet seeing theircorresponding merge points, as declared byOpSelectionMerge or OpLoopMerge.

1024 400


Global variables (Storage Class other than Function) 65,536 10000Local variables (Function Storage Class) 524,288 80,000

Decorations per target Number of entries in theDecoration table.Execution modes per entry point 256 100Indexes for OpAccessChain, OpInBoundsAccessChain,OpCompositeExtract, and OpCompositeInsert 256 100

Number of function parameters, per functiondeclaration 256 100

OpFunctionCall actual arguments 256 100OpExtInst actual arguments 256 100OpSwitch (literal, label) pairs 16,384 4000OpTypeStruct members 16,384 4000Structure nesting depth 256 100

2.18 Memory Model

A memory model is chosen using a single OpMemoryModel instruction near the beginning of the module. This selects both anaddressing model and a memory model.

The Logical addressing model means pointers have no physical size or numeric value. In this mode, pointers can only be createdfrom existing objects, and they cannot be stored into an object.

The non-Logical addressing models allow physical pointers to be formed. OpVariable can be used to create objects that holdpointers. These are declared for a specific Storage Class. Pointers for one storage class cannot be used to access objects inanother storage class. However, they can be converted with conversion opcodes. Any particular addressing model must describethe bitwidth of pointers for each of the storage classes.

TBD: A more detailed memory model is being worked out. It will reflect realities of modern system architecture, and largelyunify multiple past memory models through paramaterized use of Memory Semantics and Execution Scopes. E.g., use of ac-quire/release semantics within an execution scope largely gives the control needed for current and past memory models. Thisincludes replacing most purposes of the traditional volatile keyword in high-level languages.

2.18.1 Aliasing

Here, aliasing means one of:

Two or more pointers that point into overlapping parts of the same underlying object. That is, two intermediates, both of whichare typed pointers, that can be dereferenced (in bounds) such that both dereferences access the same memory.

Images, textures, buffers, or other externally allocated objects where a function might access the same underlying memory viaaccesses to two different objects.

How aliasing is managed depends on the Memory Model:

The simple and GLSL memory models can assume that aliasing is generally not present. Specifically, the compiler is free tocompile as if aliasing is not present, unless a pointer is explicitly indicated to be an alias. This is indicated by applying theAliased Decoration to an intermediate objects . Applying Restrict is allowed, but has no effect.

The OpenCL memory models must assume that aliasing is generally present. Specifically, the compiler must compile as ifaliasing is present, unless a pointer is explicitly indicated to not alias. This is done by applying the Restrict Decoration to anintermediate objects . Applying Aliased is allowed, but has no effect.

It is invalid to apply both Restrict and Aliased to the same .


2.19 Execution Model

TBD. Executions models will be expanded to include details of various precision requirements for different environments andreleases of a different APIs and high-level languages. This will include IEEE floating point rules, allowed optimizations, andhow NaN, infinities, and denormalized numbers are handled.

2.19.1 Code Motion

Texturing instructions in the Fragment Execution Model that rely on an implicit derivative cannot be moved within flow controlthat is not known to be uniform flow control.

TBD. Give a strict definition of uniform flow control.

3 Binary Form

This section contains the exact form for all instructions, starting with the numerical values for all fields. See Physical Layout forthe order words appear in.

3.1 Magic Number

Magic number for a SPIR-V module.

TipEndianness: A module is defined as a stream of words, not a stream of bytes. However, if stored as a stream of bytes (e.g., ina file), the magic number can be used to deduce what endianness to apply to convert the byte stream back to a word stream.

Magic Number0x07230203

3.2 Source Language

The source language is an annotation, with no semantics that affect the meaning of other parts of the module. Used by OpSource.

Source Language0 Unknown1 ESSL2 GLSL3 OpenCL

3.3 Execution Model

Used by OpEntryPoint.

Execution Model RequiredCapability

0 VertexVertex shading stage.

Shader

1 TessellationControlTessellation control (or hull) shading stage.

Tess


Execution Model RequiredCapability

2 TessellationEvaluationTessellation evaluation (or domain) shading stage.

Tess

3 GeometryGeometry shading stage.

Geom

4 FragmentFragment shading stage.

Shader

5 GLComputeGraphical compute shading stage.

Shader

6 KernelCompute kernel.

Kernel

3.4 Addressing Model

Used by OpMemoryModel.

Addressing Model RequiredCapability

0 Logical1 Physical32

Indicates a 32-bit module, where the address width isequal to 32 bits.

Addr

2 Physical64Indicates a 64-bit module, where the address width isequal to 64 bits.

Addr

3.5 Memory Model

Used by OpMemoryModel.

Memory Model RequiredCapability

0 SimpleNo shared memory consistency issues.

Shader

1 GLSL450Memory model needed by later versions of GLSL andESSL. Works across multiple versions.

Shader

2 OpenCL1.2OpenCL 1.2 memory model.

Kernel


Kernel


Kernel

3.6 Execution Mode

Declare the modes this modules stage will execute in. Used by OpExecutionMode.


Execution Mode RequiredCapability

Extra Operands

0 InvocationsNumber of times to invoke the geometry stage foreach input primitive received. The default is to runonce for each input primitive. If greater than thetarget-dependent maximum, it will fail to compile.Only valid with the Geometry Execution Model.

Geom Literal NumberNumber of invocations

1 SpacingEqualRequests the tessellation primitive generator to divideedges into a collection of equal-sized segments. Onlyvalid with one of the tessellation Execution Models.

Tess

2 SpacingFractionalEvenRequests the tessellation primitive generator to divideedges into an even number of equal-length segmentsplus two additional shorter fractional segments. Onlyvalid with one of the tessellation Execution Models.

Tess

3 SpacingFractionalOddRequests the tessellation primitive generator to divideedges into an odd number of equal-length segmentsplus two additional shorter fractional segments. Onlyvalid with one of the tessellation Execution Models.

Tess

4 VertexOrderCwRequests the tessellation primitive generator togenerate triangles in clockwise order. Only valid withone of the tessellation Execution Models.

Tess

5 VertexOrderCcwRequests the tessellation primitive generator togenerate triangles in counter-clockwise order. Onlyvalid with one of the tessellation Execution Models.

Tess

6 PixelCenterIntegerPixels appear centered on whole-number pixeloffsets. E.g., the coordinate (0.5, 0.5) appears tomove to (0.0, 0.0). Only valid with the FragmentExecution Model.

Shader

7 OriginUpperLeftPixel coordinates appear to originate in the upper left,and increase toward the right and downward. Onlyvalid with the Fragment Execution Model.

Shader

8 EarlyFragmentTestsFragment tests are to be performed before fragmentshader execution. Only valid with the FragmentExecution Model.

Shader

9 PointModeRequests the tessellation primitive generator togenerate a point for each distinct vertex in thesubdivided primitive, rather than to generate lines ortriangles. Only valid with one of the tessellationExecution Models.

Tess

10 XfbThis stage will run in transform feedback-capturingmode and this module is responsible for describingthe transform-feedback setup. See the XfbBuffer,Offset, and Stride Decorations.

Shader



Extra Operands

11 DepthReplacingThis mode must be declared if this modulepotentially changes the fragments depth. Only validwith the Fragment Execution Model.

Shader

12 DepthAnyTBD: this should probably be removed. Depthtesting will always be performed after the shader hasexecuted. Only valid with the Fragment ExecutionModel.

Shader

13 DepthGreaterExternal optimizations may assume depthmodifications will leave the fragments depth asgreater than or equal to the fragments interpolateddepth value (given by the z component of theFragCoord BuiltIn decorated variable). Only validwith the Fragment Execution Model.

Shader

14 DepthLessExternal optimizations may assume depthmodifications leave the fragments depth less than thefragments interpolated depth value, (given by the zcomponent of the FragCoord BuiltIn decoratedvariable). Only valid with the Fragment ExecutionModel.

Shader

15 DepthUnchangedExternal optimizations may assume this stage did notmodify the fragments depth. However,DepthReplacing mode must accurately representdepth modification. Only valid with the FragmentExecution Model.

Shader

16 LocalSizeIndicates the work-group size in the x, y, and zdimensions. Only valid with the GLCompute orKernel Execution Models.

LiteralNumberx size

LiteralNumbery size

LiteralNumberz size

17 LocalSizeHintA hint to the compiler, which indicates the mostlikely to be used work-group size in the x, y, and zdimensions. Only valid with the Kernel ExecutionModel.

Kernel LiteralNumberx size

LiteralNumbery size

LiteralNumberz size

18 InputPointsStage input primitive is points. Only valid with theGeometry Execution Model.

Geom

19 InputLinesStage input primitive is lines. Only valid with theGeometry Execution Model.

Geom

20 InputLinesAdjacencyStage input primitive is lines adjacency. Only validwith the Geometry Execution Model.

Geom

21 InputTrianglesFor a geometry stage, input primitive is triangles. Fora tessellation stage, requests the tessellation primitivegenerator to generate triangles. Only valid with theGeometry or one of the tessellation ExecutionModels.

GeomTess



Extra Operands

22 InputTrianglesAdjacencyGeometry stage input primitive is trianglesadjacency. Only valid with the Geometry ExecutionModel.

Geom

23 InputQuadsRequests the tessellation primitive generator togenerate quads. Only valid with one of thetessellation Execution Models.

Tess

24 InputIsolinesRequests the tessellation primitive generator togenerate isolines. Only valid with one of thetessellation Execution Models.

Tess

25 OutputVerticesFor a geometry stage, the maximum number ofvertices the shader will ever emit in a singleinvocation. For a tessellation-control stage, thenumber of vertices in the output patch produced bythe tessellation control shader, which also specifiesthe number of times the tessellation control shader isinvoked. Only valid with the Geometry or one of thetessellation Execution Models.

GeomTess

Literal NumberVertex count

26 OutputPointsStage output primitive is points. Only valid with theGeometry Execution Model.

Geom

27 OutputLineStripStage output primitive is line strip. Only valid withthe Geometry Execution Model.

Geom

28 OutputTriangleStripStage output primitive is triangle strip. Only validwith the Geometry Execution Model.

Geom

29 VecTypeHintA hint to the compiler, which indicates that mostoperations used in the entry point are explicitlyvectorized using a particular vector type. Only validwith the Kernel Execution Model.

Kernel Vector type

30 ContractionOffIndicates that floating-point-expressions contractionis disallowed. Only valid with the Kernel ExecutionModel.

Kernel

3.7 Storage Class

Class of storage for declared variables (does not include intermediate values). Used by:

OpTypePointer

OpVariable

OpVariableArray

OpGenericCastToPtrExplicit


Storage Class RequiredCapability

0 UniformConstantShared externally, read-only memory, visible across allinstantiations or work groups. Graphics uniform memory.OpenCL Constant memory.

1 InputInput from pipeline. Read only.

Shader

2 UniformShared externally, visible across all instantiations or workgroups.

Shader

3 OutputOutput to pipeline.

Shader

4 WorkgroupLocalShared across all work items within a work group.OpenGL "shared". OpenCL local memory.

5 WorkgroupGlobalVisible across all work items of all work groups. OpenCLglobal memory.

6 PrivateGlobalAccessible across functions within a module, non-IO (notvisible outside the module).

Shader

7 FunctionA variable local to a function.

Shader

8 GenericA generic pointer, which overloads StoragePrivate,StorageLocal, StorageGlobal. not a real storage class.

Kernel

9 PrivatePrivate to a work-item and is not visible to anotherwork-item. OpenCL private memory.

Kernel

10 AtomicCounterFor holding atomic counters.

Shader

3.8 Dim

Dimensionality of a texture. Used by OpTypeSampler.

Dim RequiredCapability

0 1D1 2D2 3D3 Cube Shader4 Rect Shader5 Buffer

3.9 Sampler Addressing Mode

Define the addressing mode of read image extended instructions.


Sampler Addressing Mode RequiredCapability

0 NoneThe image coordinates used to sample elements of theimage refer to a location inside the image, otherwise theresults are undefined.

Kernel

1 ClampToEdgeOut-of-range image coordinates are clamped to the extent.

Kernel

2 ClampOut-of-range image coordinates will return a border color.

Kernel

3 RepeatOut-of-range image coordinates are wrapped to the validrange. Can only be used with normalized coordinates.

Kernel

4 RepeatMirroredFlip the image coordinate at every integer junction. Canonly be used with normalized coordinates.

Kernel

3.10 Sampler Filter Mode

Define the filter mode of read image extended instructions.

Sampler Filter Mode RequiredCapability

0 NearestUse filter nearset mode when performing a read imageoperation.

Kernel

1 LinearUse filter linear mode when performing a read imageoperation.

Kernel

3.11 FP Fast Math Mode

Enables fast math operations which are otherwise unsafe.

Only valid on OpFAdd, OpFSub, OpFMul, OpFDiv, OpFRem, and OpFMod instructions.

This value is a mask; it can be formed by combining the bits from multiple rows in the table below.

FP Fast Math Mode RequiredCapability

0x0 None0x1 NotNaN

Assume parameters and result are not NaN.Kernel

0x2 NotInfAssume parameters and result are not +/- Inf.

Kernel

0x4 NSZTreat the sign of a zero parameter or result asinsignificant.

Kernel

0x8 AllowRecipAllow the usage of reciprocal rather than perform adivision.

Kernel

0x10 FastAllow algebraic transformations according to real-numberassociative and distibutive algebra. This flag implies allthe others.

Kernel


3.12 FP Rounding Mode

Associate a rounding mode to a floating-point conversion instruction.

By default

Conversions from floating-point to integer types use the round-toward-zero rounding mode.

Conversions to floating-point types use the round-to-nearest-even rounding mode.

FP Rounding Mode RequiredCapability

0 RTERound to nearest even.

Kernel

1 RTZRound towards zero.

Kernel

2 RTPRound towards positive infinity.

Kernel

3 RTNRound towards negative infinity.

Kernel

3.13 Linkage Type

Associate a linkage type to functions or global variables. See linkage.

Linkage Type RequiredCapability

0 ExportAccessible by other modules as well.

Link

1 ImportA declaration of a global variable or a function that existsin another module.

Link

3.14 Access Qualifier

Defines the access permissions of OpTypeSampler and OpTypePipe object.

Used by OpTypePipe.

Access Qualifier RequiredCapability

0 ReadOnlyA read-only object.

Kernel

1 WriteOnlyA write-only object.

Kernel

2 ReadWriteA readable and writable object.

Kernel

3.15 Function Parameter Attribute

Adds additional information to the return type and to each parameter of a function.


Function Parameter Attribute RequiredCapability

0 ZextValue should be zero extended if needed.

Kernel

1 SextValue should be sign extended if needed.

Kernel

2 ByValThis indicates that the pointer parameter should really bepassed by value to the function. Only valid for pointerparameters (not for ret value).

Kernel

3 SretIndicates that the pointer parameter specifies the addressof a structure that is the return value of the function in thesource program. Only applicable to the first parameterwhich must be a pointer parameters.

Kernel

4 NoAliasIndicates that the memory pointed by a pointer parameteris not accessed via pointer values which are not derivedfrom this pointer parameter. Only valid for pointerparameters. Not valid on return values.

Kernel

5 NoCaptureThe callee does not make a copy of the pointer parameterinto a location that is accessible after returning from thecallee. Only valid for pointer parameters. Not valid onreturn values.

Kernel

6 SVMCL TBD

Kernel

7 NoWriteCan only read the memory pointed by a pointerparameter. Only valid for pointer parameters. Not validon return values.

Kernel

8 NoReadWriteCannot dereference the memory pointed by a pointerparameter. Only valid for pointer parameters. Not validon return values.

Kernel

3.16 Decoration

Used by OpDecorate and OpMemberDecorate.

Decoration RequiredCapability

Extra Operands

0 PrecisionLowApply as described in the ES Precision section.

Shader

1 PrecisionMediumApply as described in the ES Precision section.

Shader

2 PrecisionHighApply as described in the ES Precision section.

Shader

3 BlockApply to a structure type to establish it is anon-SSBO-like shader-interface block.

TBD can this be removed? Probably doesnt addanything over a nonwritable structure in theUniformConstant or Uniform storage class. with aBinding and DescriptorSet decoration.

Shader



Extra Operands

4 BufferBlockApply to a structure type to establish it is anSSBO-like shader-interface block.

TBD can this be removed? Probably doesnt addanything over a structure in the UniformConstant orUniform storage class. with a Binding andDescriptorSet decoration.

Shader

5 RowMajorApply to a variable or a member of a structure. Mustdecorate an entity whose type is a matrix. Indicatesthat components within a row are contiguous inmemory.

Matrix

6 ColMajorApply to a variable or a member of a structure. Mustdecorate an entity whose type is a matrix. Indicatesthat components within a column are contiguous inmemory.

Matrix

7 GLSLSharedApply to a structure type to get GLSL sharedmemory layout.

Shader

8 GLSLStd140Apply to a structure type to get GLSL std140memory layout.

Shader

9 GLSLStd430Apply to a structure type to get GLSL std430memory layout.

Shader

10 GLSLPackedApply to a structure type to get GLSL packedmemory layout.

Shader

11 SmoothApply to a variable or a member of a structure.Indicates that perspective-correct interpolation mustbe used. Only valid for the Input and OutputStorage Classes.

Shader

12 NoperspectiveApply to a variable or a member of a structure.Indicates that linear, non-perspective correct,interpolation must be used. Only valid for the Inputand Output Storage Classes.

Shader

13 FlatApply to a variable or a member of a structure.Indicates no interpolation will be done. Thenon-interpolated value will come from a vertex, asdescribed in the API specification. Only valid for theInput and Output Storage Classes.

Shader

14 PatchApply to a variable or a member of a structure.Indicates a tessellation patch. Only valid for theInput and Output Storage Classes.

Tess



Extra Operands

15 CentroidApply to a variable or a member of a structure. Whenused with multi-sampling rasterization, allows asingle interpolation location for an entire pixel. Theinterpolation location must lie in both the pixel and inthe primitive being rasterized. Only valid for theInput and Output Storage Classes.

Shader

16 SampleApply to a variable or a member of a structure. Whenused with multi-sampling rasterization, requiresper-sample interpolation. The interpolation locationsmust be the locations of the samples lying in both thepixel and in the primitive being rasterized. Only validfor the Input and Output Storage Classes.

Shader

17 InvariantApply to a variable, to indicate expressionscomputing its value be done invariant with respect toother modules computing the same expressions.

Shader

18 RestrictApply to a variable, to indicate the compiler maycompile as if there is no aliasing. See the Aliasingsection for more detail.

19 AliasedApply to a variable, to indicate the compiler is togenerate accesses to the variable that work correctlyin the presence of aliasing. See the Aliasing sectionfor more detail.

20 VolatileApply to a variable, to indicate the memory holdingthe variable is volatile. See the Memory Modelsection for more detail.

21 ConstantIndicates that a global variable is constant and willnever be modified. Only allowed on global variables.

Kernel

22 CoherentApply to a variable, to indicate the memory holdingthe variable is coherent. See the Memory Modelsection for more detail.

23 NonwritableApply to a variable, to indicate the memory holdingthe variable is not writable, and that this module doesnot write to it.

24 NonreadableApply to a variable, to indicate the memory holdingthe variable is not readable, and that this module doesnot read from it.

25 UniformApply to a variable or a member of a structure.Asserts that the value backing the decorated isdynamically uniform across all instantiations thatmight run in parallel.

Shader



Extra Operands

26 NoStaticUseApply to a variable to indicate that it is known thatthis module does not read or write it. Useful forestablishing interface.

TBD consider removing this?27 CPacked

Marks a structure type as "packed", indicating thatthe alignment of the structure is one and that there isno padding between structure members.

Kernel

28 SaturatedConversionIndicates that a conversion to an integer type which isoutside the representable range of Result Type will beclamped to the nearest representable value of ResultType. NaN will be converted to 0.

This decoration can only be applied to conversioninstructions to integer types, not including theOpSatConvertUToS and OpSatConvertSToUinstructions.

Kernel

29 StreamApply to a variable or a member of a structure.Indicates the stream number to put an output on.Only valid for the Output Storage Class and theGeometry Execution Model.

Geom Literal NumberStream number

30 LocationApply to a variable or a structure member. Forms themain linkage for Storage Class Input and Outputvariables:- between the API and vertex-stage inputs,- between consecutive programmable stages, or- between fragment-stage outputs and the API.Only valid for the Input and Output StorageClasses.

Shader Literal NumberLocation

31 ComponentApply to a variable or a member of a structure.Indicates which component within a Location willbe taken by the decorated entity. Only valid for theInput and Output Storage Classes.

Shader Literal NumberComponent within a vector

32 IndexApply to a variable to identify a blend equation inputindex, used as described in the API specification.Only valid for the Output Storage Class and theFragment Execution Model.

Shader Literal NumberIndex

33 BindingApply to a variable. Part of the main linkage betweenthe API and SPIR-V modules for memory buffers,textures, etc. See the API specification for moreinformation.

Shader Literal NumberBinding point

34 DescriptorSetApply to a variable. Part of the main linkage betweenthe API and SPIR-V modules for memory buffers,textures, etc. See the API specification for moreinformation.

Shader Literal NumberDescriptor set



Extra Operands

35 OffsetApply to a structure member. This gives the byteoffset of the me

spirv

Documents

khronos group website

adopter member of khronos

express permission

openmax al

openmax il

registered trademarks

current version

theopengl es