The SPIR-V Tools project provides an API and commands for processing SPIR-V modules.
The project includes an assembler, binary module parser, disassembler, validator, and optimizer for SPIR-V. Except for the optimizer, all are based on a common static library. The library contains all of the implementation details, and is used in the standalone tools whilst also enabling integration into other code bases directly. The optimizer implementation resides in its own library, which depends on the core library.
The interfaces have stabilized: We don't anticipate making a breaking change for existing features.
SPIR-V is defined by the Khronos Group Inc. See the SPIR-V Registry for the SPIR-V specification, headers, and XML registry.
CHANGES for a high level summary of recent changes, by version.
SPIRV-Tools project version numbers are of the form
.index and with an optional
-dev suffix to indicate work in progress. For example, the following versions are ordered from oldest to newest:
--version option on each command line tool to see the software version. An API call reports the software version as a C-style string.
Some versions of SPIRV-Tools are tagged as stable releases (see tags on github). These versions undergo extra testing. Releases are not directly related to releases (or versions) of SPIRV-Headers. Releases of SPIRV-Tools are tested against the version of SPIRV-Headers listed in the DEPS file. The release generally uses the most recent compatible version of SPIRV-Headers available at the time of release. No version of SPIRV-Headers other than the one listed in the DEPS file is guaranteed to work with the SPIRV-Tools release.
Assembler, binary parser, and disassembler
- Support for SPIR-V 1.0, through 1.5
- Based on SPIR-V syntax described by JSON grammar files in the SPIRV-Headers repository.
- Usually, support for a new version of SPIR-V is ready within days after publication.
- Support for extended instruction sets:
- GLSL std450 version 1.0 Rev 3
- OpenCL version 1.0 Rev 2
- Assembler only does basic syntax checking. No cross validation of IDs or types is performed, except to check literal arguments to
docs/syntax.md for the assembly language syntax.
The validator checks validation rules described by the SPIR-V specification.
Khronos recommends that tools that create or transform SPIR-V modules use the validator to ensure their outputs are valid, and that tools that consume SPIR-V modules optionally use the validator to protect themselves from bad inputs. This is especially encouraged for debug and development scenarios.
The validator has one-sided error: it will only return an error when it has implemented a rule check and the module violates that rule.
Note: The validator checks some Universal Limits, from section 2.17 of the SPIR-V spec. The validator will fail on a module that exceeds those minimum upper bound limits. It is future work to parameterize the validator to allow larger limits accepted by a more than minimally capable SPIR-V consumer.
The optimizer is a collection of code transforms, or "passes". Transforms are written for a diverse set of reasons:
- To restructure, simplify, or normalize the code for further processing.
- To eliminate undesirable code.
- To improve code quality in some metric such as size or performance. Note: These transforms are not guaranteed to actually improve any given metric. Users should always measure results for their own situation.
As of this writing, there are 67 transforms including examples such as:
- Strip debug info
- Strip reflection info
- Specialization Constants
- Set spec constant default value
- Freeze spec constant to default value
- Unify constants
- Eliminate dead constant
- Code Reduction
- Inline all function calls exhaustively
- Convert local access chains to inserts/extracts
- Eliminate local load/store in single block
- Eliminate local load/store with single store
- Eliminate local load/store with multiple stores
- Eliminate local extract from insert
- Eliminate dead instructions (aggressive)
- Eliminate dead branches
- Merge single successor / single predecessor block pairs
- Eliminate common uniform loads
- Remove duplicates: Capabilities, extended instruction imports, types, and decorations.
- Compact IDs
- CFG cleanup
- Flatten decorations
- Merge returns
- Convert AMD-specific instructions to KHR instructions
- Code improvement
- Conditional constant propagation
- Loop fission
- Loop fusion
- Loop-invariant code motion
- Loop unroll
- Graphics robust access
- Upgrade memory model to VulkanKHR
Additionally, certain sets of transformations have been packaged into higher-level recipes. These include:
- Optimization for size (
- Optimization for performance (
For the latest list with detailed documentation, please refer to
For suggestions on using the code reduction options, please refer to this white paper.
Note: The linker is still under development.
- Combine multiple SPIR-V binary modules together.
- Combine into a library (exports are retained) or an executable (no symbols are exported).
Note: The reducer is still under development.
The reducer simplifies and shrinks a SPIR-V module with respect to a user-supplied interestingness function. For example, given a large SPIR-V module that cause some SPIR-V compiler to fail with a given fatal error message, the reducer could be used to look for a smaller version of the module that causes the compiler to fail with the same fatal error message.
To suggest an additional capability for the reducer, file an issue with "Reducer:" as the start of its title.
Note: The fuzzer is still under development.
The fuzzer applies semantics-preserving transformations to a SPIR-V binary module, to produce an equivalent module. The original and transformed modules should produce essentially identical results when executed on identical inputs: their results should differ only due to floating-point round-off, if at all. Significant differences in results can pinpoint bugs in tools that process SPIR-V binaries, such as miscompilations. This metamorphic testing approach is similar to the method used by the GraphicsFuzz project for fuzzing of GLSL shaders.
To suggest an additional capability for the fuzzer, file an issue with "Fuzzer:" as the start of its title.
- Utility filters
- Build target
spvasm.vim. Copy that file into your
$HOME/.vim/syntaxdirectory to get SPIR-V assembly syntax highlighting in Vim. This build target is not built by default.
The SPIR-V Tools project is maintained by members of the The Khronos Group Inc., and is hosted at https://github.com/KhronosGroup/SPIRV-Tools.
Consider joining the
[email protected] mailing list, via https://www.khronos.org/spir/spirv-tools-mailing-list/. The mailing list is used to discuss development plans for the SPIRV-Tools as an open source project. Once discussion is resolved, specific work is tracked via issues and sometimes in one of the projects.
(To provide feedback on the SPIR-V specification, file an issue on the SPIRV-Headers GitHub repository.)
Contributions via merge request are welcome. Changes should:
- Be provided under the Apache 2.0.
- You'll be prompted with a one-time "click-through" Khronos Open Source Contributor License Agreement (CLA) dialog as part of submitting your pull request or other contribution to GitHub.
- Include tests to cover updated functionality.
- C++ code should follow the Google C++ Style Guide.
- Code should be formatted with
clang-format. kokoro/check-format/build.sh shows how to download it. Note that we currently use
clang-format version 5.0.0for SPIRV-Tools. Settings are defined by the included .clang-format file.
We intend to maintain a linear history on the GitHub
Getting the source
Example of getting sources, assuming SPIRV-Tools is configured as a standalone project:
git clone https://github.com/KhronosGroup/SPIRV-Tools.git spirv-tools cd spirv-tools # Check out sources for dependencies, at versions known to work together, # as listed in the DEPS file. python3 utils/git-sync-deps
For some kinds of development, you may need the latest sources from the third-party projects:
git clone https://github.com/KhronosGroup/SPIRV-Headers.git spirv-tools/external/spirv-headers git clone https://github.com/google/googletest.git spirv-tools/external/googletest git clone https://github.com/google/effcee.git spirv-tools/external/effcee git clone https://github.com/google/re2.git spirv-tools/external/re2
Dependency on Effcee
- If SPIRV-Tools is configured as part of a larger project that already uses Effcee, then that project should include Effcee before SPIRV-Tools.
- Otherwise, SPIRV-Tools expects Effcee sources to appear in
external/effceeand RE2 sources to appear in
Source code organization
example: demo code of using SPIRV-Tools APIs
external/googletest: Intended location for the googletest sources, not provided
external/effcee: Location of Effcee sources, if the
effceelibrary is not already configured by an enclosing project.
external/re2: Location of RE2 sources, if the
re2library is not already configured by an enclosing project. (The Effcee project already requires RE2.)
include/: API clients should add this directory to the include search path
external/spirv-headers: Intended location for SPIR-V headers, not provided
include/spirv-tools/libspirv.h: C API public interface
source/: API implementation
test/: Tests, using the googletest framework
tools/: Command line executables
The project contains a number of tests, used to drive development and ensure correctness. The tests are written using the googletest framework. The
googletest source is not provided with this project. There are two ways to enable tests:
- If SPIR-V Tools is configured as part of an enclosing project, then the enclosing project should configure
googletestbefore configuring SPIR-V Tools.
- If SPIR-V Tools is configured as a standalone project, then download the
googletestsource into the
Note: Prebuilt binaries are available from the downloads page.
First get the sources. Then build using CMake, Bazel, Android ndk-build, or the Emscripten SDK.
Build using CMake
You can build the project using CMake:
cd <spirv-dir> mkdir build && cd build cmake [-G <platform-generator>] <spirv-dir>
Once the build files have been generated, build using the appropriate build command (e.g.
msbuild, etc.; this depends on the platform generator used above), or use your IDE, or use CMake to run the appropriate build command for you:
cmake --build . [--config Debug] # runs `make` or `ninja` or `msbuild` etc.
Note about the fuzzer
The SPIR-V fuzzer,
spirv-fuzz, can only be built via CMake, and is disabled by default. To build it, clone protobuf and use the
SPIRV_BUILD_FUZZER CMake option, like so:
(the SPIRV-Tools repo root):git clone --depth=1 --branch v188.8.131.52 https://github.com/protocolbuffers/protobuf external/protobuf # In your build directory: cmake [-G <platform-generator>] <spirv-dir> -DSPIRV_BUILD_FUZZER=ON cmake --build . --config Debug
You can also add
-DSPIRV_ENABLE_LONG_FUZZER_TESTS=ON to build additional fuzzer tests.
Build using Bazel
You can also use Bazel to build the project.
cd <spirv-dir> bazel build :all
Build a node.js package using Emscripten
The SPIRV-Tools core library can be built to a WebAssembly node.js module. The resulting
SpirvTools WebAssembly module only exports methods to assemble and disassemble SPIR-V modules.
First, make sure you have the Emscripten SDK. Then:
cd <spirv-dir> ./source/wasm/build.sh
Note: This builds the package locally. It does not publish it to npm.
To test the result:
Tools you'll need
For building and testing SPIRV-Tools, the following tools should be installed regardless of your OS:
- CMake: if using CMake for generating compilation targets, you need to install CMake Version 2.8.12 or later.
- Python 3: for utility scripts and running the test suite.
- Bazel (optional): if building the source with Bazel, you need to install Bazel Version 0.29.1 on your machine. Other versions may also work, but are not verified.
- Emscripten SDK (optional): if building the WebAssembly module.
SPIRV-Tools is regularly tested with the following compilers:
- GCC version 9.3
- Clang version 10.0
- AppleClang 11.0
- Visual Studio 2015
- Visual Studio 2017
Other compilers or later versions may work, but they are not tested.
The following CMake options are supported:
OFF- Build the spirv-fuzz tool.
ON- Enables color console output.
OFF- Build only the library and the command line tools. This will prevent the tests from being built.
OFF- Build only the library, not the command line tools and tests.
SPIRV_USE_SANITIZER=, default is no sanitizing - On UNIX platforms with an appropriate version of
clangthis option enables the use of the sanitizers documented here. This should only be used with a debug build.
OFF- On UNIX platforms enable more strict warnings. The code might not compile with this option enabled. For Clang, enables
-Weverything. For GCC, enables
ON- Forces a compilation error on any warnings encountered by enabling the compiler-specific compiler front-end option. No compiler front-end options are enabled when this option is OFF.
Additionally, you can pass additional C preprocessor definitions to SPIRV-Tools via setting
SPIRV_TOOLS_EXTRA_DEFINITIONS. For example, by setting it to
/D_ITERATOR_DEBUG_LEVEL=0 on Windows, you can disable checked iterators and iterator debugging.
SPIR-V Tools supports building static libraries
libSPIRV-Tools-opt.a for Android:
export ANDROID_NDK=/path/to/your/ndk mkdir build && cd build mkdir libs mkdir app $ANDROID_NDK/ndk-build -C ../android_test \ NDK_PROJECT_PATH=. \ NDK_LIBS_OUT=`pwd`/libs \ NDK_APP_OUT=`pwd`/app
Occasionally the entries in DEPS will need to be updated. This is done on demand when there is a request to do this, often due to downstream breakages. To update
utils/roll_deps.sh and confirm that tests pass. The script requires Chromium's
The internals of the library use C++11 features, and are exposed via both a C and C++ API.
In order to use the library from an application, the include path should point to
SPIRV-ToolsCMake target: Creates the static library:
SPIRV-Tools-optCMake target: Creates the static library:
The interfaces are still under development, and are expected to change.
There are five main entry points into the library in the C interface:
spvTextToBinary: An assembler, translating text to a binary SPIR-V module.
spvBinaryToText: A disassembler, translating a binary SPIR-V module to text.
spvBinaryParse: The entry point to a binary parser API. It issues callbacks for the header and each parsed instruction. The disassembler is implemented as a client of
spvValidateimplements the validator functionality. Incomplete
spvValidateBinaryimplements the validator functionality. Incomplete
The C++ interface is comprised of three classes,
Linker, all in the
Optimizerprovides methods for registering and running optimization passes.
Linkerprovides methods for combining together multiple binaries.
Command line tools
Command line tools, which wrap the above library functions, are provided to assemble or disassemble shader files. It's a convention to name SPIR-V assembly and binary files with suffix
The assembler reads the assembly language text, and emits the binary form.
The standalone assembler is the executable called
spirv-as, and is located in
spvTextToBinary library function.
spirv-as- the standalone assembler
-h to print help.
The disassembler reads the binary form, and emits assembly language text.
The standalone disassembler is the executable called
spirv-dis, and is located in
spvBinaryToText library function.
spirv-dis- the standalone disassembler
-h to print help.
The output includes syntax colouring when printing to the standard output stream, on Linux, Windows, and OS X.
The linker combines multiple SPIR-V binary modules together, resulting in a single binary module as output.
This is a work in progress. The linker does not support OpenCL program linking options related to math flags. (See section 184.108.40.206 in OpenCL 1.2)
spirv-link- the standalone linker
The optimizer processes a SPIR-V binary module, applying transformations in the specified order.
This is a work in progress, with initially only few available transformations.
spirv-opt- the standalone optimizer
Warning: This functionality is under development, and is incomplete.
The standalone validator is the executable called
spirv-val, and is located in
spvValidate library function.
The validator operates on the binary form.
spirv-val- the standalone validator
The reducer shrinks a SPIR-V binary module, guided by a user-supplied interestingness test.
This is a work in progress, with initially only shrinks a module in a few ways.
spirv-reduce- the standalone reducer
spirv-reduce --help to see how to specify interestingness.
The fuzzer transforms a SPIR-V binary module into a semantically-equivalent SPIR-V binary module by applying transformations in a randomized fashion.
This is a work in progress, with initially only a few semantics-preserving transformations.
spirv-fuzz- the standalone fuzzer
spirv-fuzz --help for a detailed list of options.
Control flow dumper tool
The control flow dumper prints the control flow graph for a SPIR-V module as a GraphViz graph.
This is experimental.
spirv-cfg- the control flow graph dumper
spirv-lesspipe.sh- Automatically disassembles
.spvbinary files for the
lessprogram, on compatible systems. For example, set the
LESSOPENenvironment variable as follows, assuming both
spirv-disare on your executable search path:
export LESSOPEN='| spirv-lesspipe.sh "%s"'
Then you page through a disassembled module as follows:
spirv-lesspipe.shscript will pass through any extra arguments to
spirv-dis. So, for example, you can turn off colours and friendly ID naming as follows:
export LESSOPEN='| spirv-lesspipe.sh "%s" --no-color --raw-id'
vim-spirv - A vim plugin which supports automatic disassembly of
.spvfiles using the
:editcommand and assembly using the
:writecommand. The plugin also provides additional features which include; syntax highlighting; highlighting of all ID's matching the ID under the cursor; and highlighting errors where the
OpExtInstis used without an appropriate
50spirv-tools.el- Automatically disassembles '.spv' binary files when loaded into the emacs text editor, and re-assembles them when saved, provided any modifications to the file are valid. This functionality must be explicitly requested by defining the symbol SPIRV_TOOLS_INSTALL_EMACS_HELPERS as follows:
cmake -DSPIRV_TOOLS_INSTALL_EMACS_HELPERS=true ...
In addition, this helper is only installed if the directory /etc/emacs/site-start.d exists, which is typically true if emacs is installed on the system.
Note that symbol IDs are not currently preserved through a load/edit/save operation. This may change if the ability is added to spirv-as.
Tests are only built when googletest is found.
Running test with CMake
to run all the tests. To run tests using all threads:
To run a single test target, use
. For example, you can run all
opt tests with:
ctest -R 'spirv-tools-test_opt'
Running test with Bazel
bazel test :all to run all tests. This will run tests in parallel by default.
To run a single test target, specify
:my_test_target instead of
:all. Test target names get printed when you run
bazel test :all. For example, you can run
bazel test :opt_def_use_test
See the projects pages for more information.
Assembler and disassembler
- The disassembler could emit helpful annotations in comments. For example:
- Use variable name information from debug instructions to annotate key operations on variables.
- Show control flow information by annotating
OpLabelinstructions with that basic block's predecessors.
- Error messages could be improved.
This is a work in progress.
- The linker could accept math transformations such as allowing MADs, or other math flags passed at linking-time in OpenCL.
- Linkage attributes can not be applied through a group.
- Check decorations of linked functions attributes.
- Remove dead instructions, such as OpName targeting imported symbols.
Full license terms are in LICENSE
Copyright (c) 2015-2016 The Khronos Group Inc. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.