SPIR-V Tools

NEWS 2023-01-11: Development occurs on the main branch.

Overview

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][spirv-registry] for the SPIR-V specification, headers, and XML registry.

Downloads

The official releases for SPIRV-Tools can be found on LunarG's SDK download page.

For convenience, here are also links to the latest builds (HEAD). Those are untested automated builds. Those are not official releases, nor are guaranteed to work. Official releases builds are in the Vulkan SDK.

More downloads

Versioning SPIRV-Tools

See CHANGES for a high level summary of recent changes, by version.

SPIRV-Tools project version numbers are of the form vyear.index and with an optional -dev suffix to indicate work in progress. For example, the following versions are ordered from oldest to newest:

• v2016.0
• v2016.1-dev
• v2016.1
• v2016.2-dev
• v2016.2

Use the --version option on each command line tool to see the software version. An API call reports the software version as a C-style string.

Releases

The official releases for SPIRV-Tools can be found on LunarG's SDK download page.

You can find either the prebuilt, and QA tested binaries, or download the SDK Config, which lists the commits to use to build the release from scratch.

GitHub releases are deprecated, and we will not publish new releases until further notice.

Supported features

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 OpConstant, OpSpecConstant, and OpSwitch.
• Where tools expect binary input, a hex stream may be provided instead. See spirv-dis --help.

See docs/syntax.md for the assembly language syntax.

Validator

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.

The validator is incomplete. See the CHANGES file for reports on completed work, and the Validator sub-project for planned and in-progress work.

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. The validator has been parameterized to allow larger values, for use when targeting a more-than-minimally-capable SPIR-V consumer.

See tools/val/val.cpp or run spirv-val --help for the command-line help.

Optimizer

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: * Simplification * Strip debug info * Strip reflection info * Specialization Constants * Set spec constant default value * Freeze spec constant to default value * Fold OpSpecConstantOp and OpSpecConstantComposite * 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. * Normalization * Compact IDs * Canonicalize IDs * CFG cleanup * Flatten decorations * Merge returns * Convert AMD-specific instructions to KHR instructions * Code improvement * Conditional constant propagation * If-conversion * Loop fission * Loop fusion * Loop-invariant code motion * Loop unroll * Other * 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 (spirv-opt -Os)
• Optimization for performance (spirv-opt -O)

For the latest list with detailed documentation, please refer to include/spirv-tools/optimizer.hpp.

For suggestions on using the code reduction options, please refer to this white paper.

Linker

Note: The linker is still under development.

Current features: * Combine multiple SPIR-V binary modules together. * Combine into a library (exports are retained) or an executable (no symbols are exported).

See the CHANGES file for reports on completed work, and the General sub-project for planned and in-progress work.

Reducer

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.

Fuzzer

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.

Diff

Note: The diff tool is still under development.

The diff tool takes two SPIR-V files, either in binary or text format and produces a diff-style comparison between the two. The instructions between the src and dst modules are matched as best as the tool can, and output is produced (in src id-space) that shows which instructions are removed in src, added in dst or modified between them. The order of instructions are not retained.

Matching instructions between two SPIR-V modules is not trivial, and thus a number of heuristics are applied in this tool. In particular, without debug information, match functions is nontrivial as they can be reordered. As such, this tool is primarily useful to produce the diff of two SPIR-V modules derived from the same source, for example before and after a modification to the shader, before and after a transformation, or SPIR-V produced from different tools.

Extras

• Utility filters
• Build target spirv-tools-vimsyntax generates file spvasm.vim. Copy that file into your $HOME/.vim/syntax directory to get SPIR-V assembly syntax highlighting in Vim. This build target is not built by default.

Contributing

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 public_spirv_tools_dev@khronos.org 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][spirv-tools-projects].

(To provide feedback on the SPIR-V specification, file an issue on the [SPIRV-Headers][spirv-headers] GitHub repository.)

See docs/projects.md to see how we use the GitHub Project feature to organize planned and in-progress work.

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][spirv-tools-cla] (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][cpp-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.0 for SPIRV-Tools. Settings are defined by the included .clang-format file.

We intend to maintain a linear history on the GitHub main branch.

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
git clone https://github.com/abseil/abseil-cpp.git          spirv-tools/external/abseil_cpp
git clone https://github.com/microsoft/mimalloc.git         spirv-tools/external/mimalloc

Dependency on Effcee

Some tests depend on the [Effcee][effcee] library for stateful matching. Effcee itself depends on [RE2][re2], and RE2 depends on [Abseil][abseil-cpp].

• 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/effcee, RE2 sources to appear in external/re2, and Abseil sources to appear in external/abseil_cpp.

Dependency on mimalloc

SPIRV-Tools may be configured to use the [mimalloc][mimalloc] library to improve memory allocation performance.

In the CMake build, usage of mimalloc is controlled by the SPIRV_TOOLS_USE_MIMALLOC option. This variable defaults on ON when building for Windows and `OF