Slang: A Shading Language for Large, Portable Shader Codebases

The problem Slang solves: shader codebases that outgrow one API

A rendering project usually starts with one target. Shaders are written in HLSL or GLSL, compiled for D3D12 or Vulkan, and shipped. The trouble begins when the same effect has to run on a second API, or when a studio wants one specialization path instead of a folder of preprocessor variants. The README frames Slang as a shading language for building and maintaining large shader codebases in a modular and extensible fashion, while keeping performance on modern GPUs.

The intended audience is real-time graphics developers working at scale, not someone writing a single fragment shader for a hobby renderer. The README states that most existing HLSL code compiles with the Slang compiler out of the box, or with minor modifications, and that a compatibility module covers most GLSL intrinsic functions and GLSL parameter binding syntax. That on-ramp matters: it means the migration cost is measured in edits, not a rewrite.

Slang is not a runtime. It is a compiler and a language, plus a command-line tool called slangc, a shared library and a slang.h header. The README credits collaboration between researchers at NVIDIA, Carnegie Mellon University, Stanford, MIT, UCSD and the University of Washington, which explains the research-flavoured features such as automatic differentiation sitting next to production graphics concerns.

How the compiler, modules and capability system fit together

The mechanism has three parts that reinforce each other. First, a single Slang source is compiled to many targets: D3D12, Vulkan, Metal, D3D11, CUDA, and CPU. For textual targets such as Metal Shading Language and CUDA, the README says the output preserves original identifier names along with type and call structure, which is what makes the generated code readable when you have to debug it.

Second, the module system. Slang modules can be compiled independently offline into a custom intermediate representation, optionally obfuscated, and linked at runtime to produce DXIL or SPIR-V. This is the part that changes team workflow: shader libraries can be built and shipped separately from the application that links them, and the custom IR gives a place to apply obfuscation before anything reaches a driver.

Third, the capability system. It checks at type-checking time that code only uses features available on the target platform, before final code generation. That ordering is the point. A feature mismatch becomes a compile error rather than a driver failure at runtime on one vendor's hardware.

Generics and interfaces sit on top of this. The README contrasts them with C++ templates: Slang's generics are pre-checked and do not produce cascading error messages. The same generic shader can be specialized for different types ahead of time or on the fly, under application control. Automatic differentiation is a separate capability: Slang can generate forward and backward derivative propagation code for functions with arbitrary control flow and dynamic dispatch, which lets an existing renderer become differentiable or serve as a kernel language in a PyTorch-driven framework through slangtorch.

Getting slangc and running a first compilation

The README points to pre-built binary packages on the GitHub releases page as the fastest route. Packages exist for x86_64 and aarch64 on Windows, Linux and macOS, and each binary release contains the slangc command-line compiler, a shared library and slang.h. Slang binaries are also included in the Vulkan SDK since version 1.3.296.0, so a machine with that SDK already has the compiler on disk.

Download the archive for your platform from the releases page and unpack it. The README does not publish extraction commands, and the repository files given here do not contain any, so there is no install snippet to quote. What the README does document is the next step: the user guide section on command-line compilation with slangc, which describes how the compiler is invoked. The repository also ships an examples directory with runnable projects such as hello-world, cpu-hello-world, ray-tracing, reflection-api and mlp-training, and those are the most reliable place to see a complete invocation in context.

If you would rather not install anything, the README describes the Slang Playground as a browser page that loads the compiler locally and runs all compilation in the browser, with no data sent to servers. It compiles Slang code to a variety of targets and can run some simple shaders directly. That is the lowest-friction way to check whether the language suits you before touching a build system.

The examples use a graphics abstraction layer called GFX that is bundled with Slang, but the README states GFX is being deprecated in favour of slang-rhi. New integrations should look at slang-rhi rather than copying the GFX setup wholesale.

Where Slang is the wrong choice

The clearest boundary is scale. If your project has one pipeline, one target API and a handful of shaders, the module system and capability system are overhead you will pay for and never collect on. HLSL compiled by the platform toolchain is a shorter path, and Slang's HLSL compatibility means you are not gaining a language so much as a compilation and linking layer.

A second boundary is toolchain integration. Slang is a compiler, a shared library and a header. It is not a drop-in replacement for an engine's existing shader pipeline, and the README does not document rollback or migration tooling for teams moving an existing HLSL codebase. The claim is that most HLSL compiles out of the box or with minor modifications; the word most is doing real work there, and the README does not enumerate the exceptions.

Third, there is the question of what you are building on. The examples in the repository lean on GFX, and the README says that layer is being deprecated in favour of slang-rhi. Anyone reading the examples as a template is reading code built on a layer the project has already marked for replacement. That is a real cost of adoption, and it is stated plainly in the README rather than hidden.

Finally, automatic differentiation is a specialised feature. If your work is rasterisation and post-processing, the autodiff machinery is irrelevant, and the mlp-training and autodiff-texture examples are not models for your code. Slang's value proposition narrows considerably when you strip out the features you will not use.

Slang against GLSL, HLSL and cross-compilers

The obvious alternative is writing HLSL or GLSL directly and cross-compiling with an existing tool. The difference is in what gets checked and when. A cross-compiler typically takes a shader written for one API and translates it for another, and feature mismatches surface during translation or at runtime. Slang's capability system moves that check to type-checking, before final code generation, so the compiler refuses code that the target cannot support.

The second difference is the module boundary. A cross-compiler operates on shaders; Slang operates on modules that can be compiled offline into a custom IR, optionally obfuscated, and linked at runtime. That is a packaging and distribution model, not just a translation step, and it is the reason Slang appeals to teams shipping shader libraries rather than individual shaders.

The third difference is generics. Preprocessor-based specialization is the usual approach in HLSL and GLSL codebases, and the README explicitly contrasts that with Slang's generics and interfaces, which are pre-checked and avoid the cascading errors associated with C++ templates. If your current strategy is string-pasting or macro expansion to produce variants, that is the specific pain Slang is aimed at.

There is also a GLSL compatibility module, so the choice is not strictly between Slang and GLSL. A codebase can keep GLSL-style intrinsic calls and parameter binding syntax while gaining Slang's compilation model. The README presents this as an on-ramp, and it is the most practical reason to try Slang on an existing project rather than a greenfield one.

Maintenance cadence, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-22. Recent releases are close together: v2026.17 on 2026-09-04, v2026.17.1 on 2026-09-11, and v2026.18 on 2026-09-15. The version scheme is date-based, which makes it easy to see how far behind a pinned compiler is.

That cadence cuts both ways. Frequent releases mean fixes arrive quickly; they also mean a pinned slangc can fall several versions behind within a quarter. Because Slang compiles modules offline into a custom IR and links them at runtime, the compiler version and the runtime library version are coupled. The README does not document a compatibility policy between IR produced by one release and a runtime from another, so the safe assumption is that both should move together. That is the upgrade cost to plan for.

The licence field is NOASSERTION, and the repository contains a LICENSE file plus a LICENSES directory and a REUSE.toml, which is the REUSE compliance layout. The README file itself carries an SPDX header naming The Khronos Group, Inc. and CC-BY-4.0, but that header covers the README document, not the compiler source. The actual terms governing the code are in the LICENSE and LICENSES files, and anyone redistributing slangc or linking the shared library should read those files directly rather than inferring terms from the README header. This is not legal advice; it is a pointer to where the terms live.

Editorial conclusion

Adopt Slang if you maintain shaders across more than one graphics API, or if you want modules, generics and automatic differentiation without rewriting HLSL by hand. Skip it if you ship a single small pipeline on one API and do not need offline module compilation or a differentiable kernel language. Before committing, verify three things: that your target API appears in the compiler's supported target list for the version you download, that the licence terms in the repository's LICENSE and LICENSES directory fit your distribution model, and that slang-rhi, not the deprecated GFX layer, is what your integration will build on. The last push to the repository was on 2026-09-22.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. shader-slang/slang on GitHub