DirectX Adopting SPIR-V as the Interchange Format of the Future

Today the Direct3D and HLSL teams are excited to share some insight into the next big step for GPU programmability. Once Shader Model 7 is released, DirectX 12 will accept shaders compiled to SPIR-V™. The HLSL team is committed to open development processes and collaborating with The Khronos® Group and LLVM Project. We’re sharing this information at the beginning of our multi-year development process so that we can be transparent about this transition from the start. We are working with the Khronos SPIR™ and Vulkan® working groups to ensure that this transition benefits the whole development ecosystem.

Embracing Open Technologies and Standards​

It is our mission that HLSL be the best language for compiling graphics and compute shaders for any device or GPU runtime API. To support that goal, the HLSL team is actively embracing open technologies and collaborating with industry standards. We will continue to adopt and support the best open-source tools available while contributing our own innovations to make Direct3D and other Microsoft technologies best in class.


Adapted from “Corgis working as a team”. (n.d.).

In the 8 years since Shader Model 6.0 was first introduced, Direct3D and HLSL have grown considerably in both features and adoption. Releasing DXC on GitHub and the tremendous contributions from open-source collaborators and partners played a significant role in expanding HLSL’s user base to include Vulkan and Metal developers. As a result of this expansion, the team is focusing on developing HLSL support in Clang to enable us to keep up with industry demand for openness and new features. As we look end to end at the best way to support the full spectrum of our users, we are working hard to support HLSL for both DXIL and SPIR-V with Clang and LLVM.

To better enable HLSL’s Vulkan support, the HLSL team is now participating in The Khronos Group’s SPIR and Vulkan working groups. This direct participation will allow smoother collaboration and more rapid adoption of Vulkan features. We believe this will ensure that HLSL is the best language for writing shaders for every GPU runtime environment.

HLSL is a key shading language used widely across the industry, and Khronos warmly welcomes Microsoft’s participation and embrace of the SPIR-V open standard, which will benefit HLSL, Direct3D, and the entire graphics ecosystem. Khronos will work to ensure that SPIR-V continues to evolve and remains responsive to the needs of all its client APIs and languages, now including DX12 and HLSL. — Neil Trevett, Khronos Group President.

Click to expand...

One example of our commitment to supporting the industry is our strong partnership with Google to develop core HLSL language features, like operator overloading, as well as features to expose Vulkan functionality, like inline SPIR-V. We greatly value this ongoing partnership and will continue to work with Google and other partners in the future.

Since 2017 our collaboration on a SPIR-V backend for DXC has yielded an industrial strength shader compiler benefiting graphics developers everywhere. We are excited to see Microsoft adopt SPIR-V as the shader intermediate language for Direct3D. We look forward to delivering future language and hardware features to developers at greater velocity and with less fuss. — David Neto, Chrome team at Google

Click to expand...

The Road to Replacing DXIL​

Adapted from, “Where we’re going we don’t need roads,” Robert Zemeckis, “Back to the Future”, 1985

Shader Model 6 and its successors have dramatically extended the capabilities of Direct3D. Features like ray tracing and work graphs would not have been possible without the capabilities brought to Shader Model 6 by adopting an LLVM-based IR and compiler. If you want to understand more about interchange formats please read through to the Appendix.

As we look to the future, maintaining a proprietary IR format (even one based on an open-source project) is counter to our commitments to open technologies, so Shader Model 7.0 will adopt SPIR-V as its interchange format. Over the next few years, we will be working to define a SPIR-V environment for Direct3D, and a set of SPIR-V extensions to support all of Direct3D’s current and future shader programming features through SPIR-V. This will allow developers to take better advantage of existing tools and unify the ecosystem around investing in one IR.

In addition to providing a compiler for HLSL to Direct3D’s SPIR-V, we will also be building and providing translation tools to translate SPIR-V to DXIL and DXIL to SPIR-V. Those tools will allow and driver developers to gradually transition and gracefully adapt tooling and drivers.

Workflows for developers building Direct3D applications with the AgilitySDK will remain largely unchanged. We do expect some changes for developers who maintain tooling that manipulates or edits compiled shaders, however we believe that the robust tooling available for working with SPIR-V binaries will provide benefits outweighing the cost of transition.

SPIR-V’s core design enables extensibility, which will enable more rapid innovation of GPU API features. Using a common format for representing compiled shaders will enable faster adoption of features across multiple APIs. We feel this is a huge step forward for enabling developer productivity across the industry.

This transition will take several years, and we hope that by being open with our plans early we can enable developers and partners to plan appropriately with as much notice as possible.

Unlocking Innovation in Direct3D​

Our plans for Shader Model 7 represent the beginning of a new chapter of innovation for Direct3D. By aligning with open standards and embracing the best open-source technologies we will accelerate development of new features and enable rapidly surfacing cutting-edge hardware capabilities.

Utilizing an industry standard interchange format will allow Microsoft and hardware vendors to focus their engineering efforts on differentiating features that will power the next generation of applications instead of duplicating common functionality.

With these upcoming changes and our continued investment in Direct3D, the future of DirectX has never been brighter.

Appendix: A Brief History of GPU Interchange Formats​

Unlike CPUs, GPUs have not adopted common long-lived architectures. That means that, while the CPU code for an application compiled once 10+ years ago may run on a brand new device, the GPU code would not have the same portability if it were compiled to the GPU’s native Instruction Set Architecture (ISA).

To solve this problem, GPU programming models often defer generating native ISA to runtime when the GPU driver can optimize for the GPU’s specific hardware capabilities. Graphics programming APIs support either shipping shader programs in source code form, or in a Virtual ISA that abstracts common hardware features at a higher level. Both forms allow the GPU driver to lower and optimize the program more efficiently, but the use of a virtual ISA reduces the time it takes the driver to generate native code. As such, virtual ISAs have become the preferred method for shipping shader programs for high-performance applications.

Direct3D has supported a virtual ISA for shader programs since shader programmability was introduced in Direct3D 8. The original virtual ISA, DirectX Bytecode (DXBC), evolved and eventually was replaced by the LLVM-based DirectX Intermediate Language (DXIL).


Adapted from, “Andy doesn’t know,” Michael Schur, “Parks and Recreation,” 2009-2015

LLVM’s Intermediate Representation (IR) brought some major advantages to GPU programmability. LLVM’s IR can be treated as a virtual ISA, but it is inherently a Static Single-Assignment (SSA) IR. Most well-known and widely used optimizing compilers use SSA IRs because they provide significant advantages due to a simplified program representation that makes it easier to write optimizing transformations.

Using an SSA IR as the interchange format for GPU programs simplified the transformation from the interchange representation to the GPU driver compiler’s internal representation required for optimizing and lowering to the native ISA.

LLVM has a long history of being used as a GPU interchange format. The original Standard Portable Intermediate Representation (SPIR) was LLVM 3.2’s IR serialized to LLVM’s bitcode format.

LLVM’s bitcode format had some significant drawbacks. Notably it is not version stable. New versions of LLVM support a lossy upgrading of older LLVM IR modules, but new LLVM cannot write IR modules that can be read by older versions of LLVM. Additionally, LLVM bitcode is a bit-packed file format which has two big drawbacks (1) it compresses poorly, and (2) it is hard to read or write from tools that aren’t LLVM.

To solve these problems The Khronos Group developed SPIR-V as a successor to SPIR. SPIR-V is ideologically aligned with LLVM’s IR, but it supports a stable and simple binary serialization. This makes SPIR-V easy to read and write by simpler tools than LLVM IR. SPIR-V is the interchange format used for a wide array of GPU programming technologies developed by the Khronos Group including Vulkan, OpenCL, and SYCL.