DirectXShaderCompiler: HLSL to DXIL and SPIR-V with dxc

What DirectXShaderCompiler solves, and for whom

HLSL source is not what a GPU driver consumes. Something has to lower it to an intermediate representation the runtime and driver agree on, and for DirectX that representation is DXIL. The DirectX Shader Compiler is that something. The README describes the project as a fork of LLVM and Clang, modified to accept HLSL and emit a validated shader binary that can be consumed by GPU drivers, and it names two targets: DXIL for DirectX and SPIR-V for Vulkan.

The audience follows from that. Graphics, game and compute developers who need shader binaries for DirectX or Vulkan. The releases page and the Windows SDK both carry supported builds, so a studio that only needs to compile shaders never has to build the compiler itself. The project also states a goal beyond shipping a binary: letting the broader community of shader developers contribute to the language and representation of shader programs, while maintaining compatibility and supportability for the platform. That is a governance statement as much as a technical one, and it explains why the repository is a full LLVM tree rather than a small standalone tool.

Inside the fork: dxc, dxcompiler, dxil and dxv

The release artifacts map cleanly onto a pipeline. dxc.exe is the command-line tool that compiles HLSL for shader model 6.0 or higher. dxcompiler.[dll|so] is a componentized compiler, assembler, disassembler and validator exposed as a dynamic library. dxil.[dll|so] provides DXIL validation and hashing. dxv.exe validates DXIL IR, which is to say it checks an already-compiled program rather than compiling one. Alongside those, the project ships C++ headers for working with the dynamic libraries and HLSL headers that expose higher-level abstractions.

That split matters for tooling. If you are writing a build step, you can either shell out to dxc or link against dxcompiler and drive compilation in-process. If you are writing a content pipeline that must reject invalid shaders before they reach a driver, dxv and the dxil library give you a validation stage separate from compilation. The README does not document the API surface of those libraries; it points at the headers instead, so plan on reading them.

Development is described as running on two axes. Language evolution proceeds with no impact to the DXIL representation. Surfacing hardware capabilities does affect DXIL, and the README says it therefore requires coordination with GPU implementations. Practically, that means a new language feature can land in a release without breaking existing binaries, while a new hardware capability cannot.

Installing dxc and compiling your first shader

You do not need to build from source to get started. The README lists four supported channels for pre-built binaries: the repository's Releases page, the NuGet package Microsoft.Direct3D.DXC, the Windows SDK, and the Vulkan SDK. Note the parenthetical on the Windows SDK entry: that build is DXIL-only. If you want SPIR-V output, take the Releases page or the NuGet package instead.

Once dxc is on your PATH, compilation is a single invocation. The README gives dxc.exe as a command-line tool that can compile HLSL programs for shader model 6.0 or higher, and the user guide for it lives at tools/clang/docs/UsingDxc.rst. That file is where the flag set is documented; the README itself does not list the individual options, so read the guide before wiring a build step around it.

To get SPIR-V for Vulkan from the same HLSL sources, you target the SPIR-V path instead. The README points at docs/SPIR-V.rst for how HLSL features map to SPIR-V, and at the SPIR-V CodeGen wiki page for how to build, use and contribute to that path. Both are the places to look for the flags that path accepts.

If you build DXC from source and Apple's Metal Shader Converter is present at build and configuration time, the README states that DXC can generate Metal shader libraries directly using the -metal flag. It adds a constraint worth reading twice: DXC cannot currently disassemble Metal shaders, so the -Fc flag cannot be used in conjunction with the -Fo flag. Building from source is documented separately in docs/BuildingAndTestingDXC.rst.

Compiling is only half the story. Running DXIL shaders needs operating system and driver support. The README names Windows 10 Creators Update as the first version to support DXIL shaders, and the wiki covers experimental support and the software adapter for cases where hardware support is missing.

Driver support is part of your build matrix

This is the limitation people hit after the compiler works. A shader that compiles cleanly can still fail to run because the driver does not implement the shader model you targeted. The README's hardware section is explicit about the vendors and the modes.

NVIDIA's r396 drivers, r397.64 and later, provide release mode support for DXIL 1.1 and Shader Model 6.1 on Win10 1709 and later, with experimental mode support for DXIL 1.2 and Shader Model 6.2 on Win10 1803 and later, plus DXR in experimental mode. AMD's Radeon Software Adrenalin Edition 18.4.1 or later provides release mode support for DXIL 1.1 and Shader Model 6.1. Intel's 15.60 drivers, 15.60.0.4849 and later, support release mode for DXIL 1.0 and Shader Model 6.0, and release mode for DXIL 1.1 and Shader Model 6.1 with View Instancing support only.

Read those entries as a compatibility table, not as a footnote. Targeting Shader Model 6.2 means asking your users for experimental-mode drivers. Targeting DXIL 1.1 on Intel means accepting View Instancing as the only 6.1 feature you can rely on. The compiler will happily emit a binary your audience cannot run, so the shader model you compile for is a product decision as much as a build flag.

When DXC is the wrong tool

The wrong-tool cases fall into three groups.

First, non-DirectX, non-Vulkan, non-Metal targets. The README frames the project around DXIL for DirectX and SPIR-V for Vulkan, with Metal available only when built from source with Apple's converter. If your renderer is OpenGL-only, or you are writing shaders for a console toolchain with its own compiler, DXC is not in that path.

Second, old shader models. dxc compiles for shader model 6.0 or higher. A codebase still on shader model 5.x and its legacy assembly is outside the tool's stated range, and the Windows SDK build will not help because it is DXIL-only.

Third, anyone who wants to compile HLSL on a machine without the runtime pieces. The README's running-shaders section is unambiguous that DXIL execution needs OS and driver support, and that Windows 10 Creators Update is the floor. The wiki mentions experimental support and a software adapter, which tells you the fallback exists but is not the default experience. There is also a documentation gap: the README does not document rollback, so if you need to pin an older compiler and revert, the repository's release history is the only thing to go on.

Alternatives and how they differ

The most direct alternative for the SPIR-V path is glslang, the Khronos reference compiler. The difference is the source language and the direction of travel. glslang takes GLSL and HLSL and produces SPIR-V, and it is the front end the Vulkan ecosystem treats as canonical. DXC starts from an HLSL front end built on Clang and an LLVM back end, and its SPIR-V CodeGen is described in the README as an example of community contribution, documented in docs/SPIR-V.rst. If your project is Vulkan-first and your shaders are GLSL, glslang is the natural fit. If your shaders are HLSL and you also ship DirectX, DXC gives you one source language and two outputs.

For the DirectX path, the practical comparison is not another open source compiler but the Windows SDK build of this same project. It is a supported version of the compiler and validator, and it is DXIL-only. Choosing it means giving up the SPIR-V and Metal outputs and tracking whatever version the SDK ships, in exchange for a component Microsoft supports as part of the platform. That is a real trade, and it is the one most Windows-only teams should evaluate first.

A third option is to build the compiler yourself from this repository. That buys you the Metal path and full control over the LLVM revision, at the cost of maintaining a large C++ build.

Release cadence, licensing and upgrade cost

The repository is not archived and the last push was on 2026-09-23. Recent releases show two parallel tracks rather than one line: v1.9.2607 (DX Compiler Release for July 2026) on 2026-07-29, and a Shader Model 6.10 preview line with v1.10.2605.24 on 2026-05-26 and v1.10.2605.37 (Shader Model 6.10 Preview Release (May 2026) - Patch 2) on 2026-08-12. The naming makes the distinction visible: a stable compiler release and a preview of a newer shader model, patched separately. Teams that need stability should track the non-preview line; teams that want the newer language surface accept preview churn.

Upgrade cost is dominated by where you get the binary. If you consume the NuGet package or the Releases page, you control the version and can pin it. If you consume the Windows SDK or the Vulkan SDK, the compiler version moves with the SDK, and the SDK build is DXIL-only. Because the README does not document rollback, pinning is the only reliable way to avoid an unwanted compiler change.

On licensing, the README states that DirectX Shader Compiler is distributed under the terms of the University of Illinois Open Source License, and points to LICENSE.TXT and ThirdPartyNotices.txt for details. The repository's licence field is not a standard SPDX identifier, so read those two files rather than relying on the metadata. The project is a fork of LLVM and Clang, and ThirdPartyNotices.txt is where the obligations attached to that lineage should be recorded. This is not legal advice; the files are the source of truth.

Editorial conclusion

Adopt it if you ship DirectX or Vulkan content and need the compiler that produces DXIL, or if you want SPIR-V out of the same HLSL sources. Do not adopt it expecting a portable, self-contained build: the Windows SDK build is DXIL-only, the SPIR-V path is documented as a community contribution, and Metal output depends on Apple's converter being present at configure time. Before committing, verify which release channel you are pulling from (the repository releases page, the Microsoft.Direct3D.DXC NuGet package, the Windows SDK, or the Vulkan SDK), confirm your target shader model against the driver support notes for your GPU vendor, and read docs/HLSLChanges.rst to see how this fork diverges from upstream LLVM.

Frequently asked questions

Official sources

1. Issues
2. microsoft/DirectXShaderCompiler on GitHub
3. README
4. Releases