# rust-gpu: Rust as a shader language via a rustc SPIR-V backend

> rust-gpu is a rustc codegen backend plus a GPU standard library that compiles Rust shader crates to SPIR-V. It is technically usable today, but the README says it is not production-ready, and the project only supports building from the latest main branch.

**Rust-GPU/rust-gpu** — 🐉 Making Rust a first-class language and ecosystem for GPU shaders 🚧

- Repository: https://github.com/Rust-GPU/rust-gpu
- Website: https://rust-gpu.github.io
- Stars: 3,381 · Forks: 127
- Language: Rust
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/rust-gpu-rust-gpu

## The problem rust-gpu targets: shader codebases without a module system

HLSL and GLSL were designed for small shader programs, not for large codebases. The README is blunt about this: these languages "have failed to provide mechanisms for dealing with large codebases, and have generally stayed behind the curve compared to other programming languages." The project's answer is to move shader authoring into Rust, and with it the parts of Rust that matter at scale: the package and module system, crates.io publishing, and the compiler's checks. The README lists built-in safety against race conditions and out of bounds memory access among the benefits, alongside the tooling around Cargo.

The audience is graphics and compute engineers who already write Rust and want one language across CPU and GPU, plus teams that want to share code between a host application and its shaders. It is not aimed at people who want a shader language that is stable and documented. The README states the project is "still heavily in development and is at an early stage," and that while it is "technically usable," it is "not yet production-ready." That sentence is the scope of the project in one line, and it should shape every decision about adopting it.

## How rust-gpu works: a rustc codegen backend plus spirv-std

rust-gpu is not a separate compiler. The compiler component is `rustc_codegen_spirv`, which plugs into rustc through `-Z codegen-backend`, the same mechanism used by rustc_codegen_cranelift and rustc_codegen_gcc. Because it is a codegen backend, the front end of the pipeline is ordinary rustc: parsing, name resolution, type checking and borrow checking all run as they would for a CPU crate. Only the final lowering step targets SPIR-V instead of an object file.

The repository is a monorepo. `crates/rustc_codegen_spirv` holds the backend, `crates/spirv-std` provides GPU intrinsics and types, and `crates/spirv-builder` is described as "a convenient way of building a GPU crate in a CPU build.rs file." There is also `crates/cargo-gpu`, the command line tool used in the getting started flow, and `docs/src/rfcs` for design documents. Shader code reaches the GPU through attributes rather than a separate language: the README example annotates an entry point with `#[spirv(fragment)]` and marks parameters with `#[spirv(frag_coord)]`, `#[spirv(push_constant)]` and an output reference.

SPIR-V is the only target planned today. The README says the scope is "Currently only SPIR-V support is planned," with DXIL or WGSL mentioned as possibilities for a future version. If your pipeline is built on DirectX shader compilation, there is no path here today.

## Installing rust-gpu and compiling a first shader with cargo gpu

The README does not carry install instructions itself. It points to "The `rust-gpu` Dev Guide" at https://rust-gpu.github.io/rust-gpu/book/ for getting started, and notes that you can experiment with rust-gpu shaders in-browser at SHADERed. The repository ships `crates/cargo-gpu` and `crates/cargo-gpu-install`, which are the tooling the guide builds on.

A shader crate declares the SPIR-V target through rustc flags. The README shows the attribute style used on entry points, which is the pattern you write in your own crate:

```rust
use glam::{Vec3, Vec4, vec2, vec3};

#[spirv(fragment)]
pub fn main(
    #[spirv(frag_coord)] in_frag_coord: &Vec4,
    #[spirv(push_constant)] constants: &ShaderConstants,
    output: &mut Vec4,
) {
    let frag_coord = vec2(in_frag_coord.x, in_frag_coord.y);
    *output = tonemap(sky(get_ray_dir(frag_coord, vec3(0.0, 0.0997, 0.2), vec3(0.0, 75.0, -1000.0)), vec3(0.0, 75.0, -1000.0))).extend(1.0)
}
```

That snippet is adapted from the README's sky shader example, which is the canonical first program. The full version lives in `examples/shaders/sky-shader`, and the repository also has `simplest-shader`, `compute-shader`, `mouse-shader` and `reduce` under `examples/shaders/`.

To build a shader crate, `spirv-builder` is meant to be driven from a CPU crate's `build.rs`. The README describes it as "a convenient way of building a GPU crate in a CPU build.rs file," which is the intended integration point:

```rust
// in build.rs of the host crate
// spirv-builder emits the shader module consumed by the renderer
fn main() {
    // see the Dev Guide for the current spirv-builder API
}
```

What you should see after a successful build is a SPIR-V module you can load into a Vulkan pipeline. The repository's `examples/runners/` directory contains `ash`, `wgpu` and `cpu` runners, and `examples/run-wasm` for the browser path. If the build fails, the failure will usually be a codegen limitation rather than a syntax error in your shader, because the front end accepted code the backend cannot lower yet.

## Where rust-gpu breaks down: coverage gaps and no stability contract

The honest limitation is coverage. The README says that compiling and running simple shaders works and that "a significant portion of the core library also compiles," but immediately adds that "many things aren't implemented yet." A significant portion is not all of it, and there is no list in the README of what is missing. You find out by compiling.

The second limitation is stability. The README states plainly that "we make no guarantees about backwards compatibility and have no formal deprecation model in place," and that "currently we only support building from source with the latest `main` branch in our repository." That is a strong constraint for anyone with a release schedule. A shader that compiles this month may need edits next month, and the project asks early adopters to "evolve their code along with ours."

The third is target lock-in. SPIR-V is the only planned target, so a Vulkan or WebGPU pipeline fits and a DirectX-only pipeline does not. And the fourth is the nature of the failure mode: when something is not implemented, you do not get a warning about a missing feature. You get a compiler error from a backend you did not write, on code that rustc's front end already accepted. Debugging that means reading codegen issues, not shader code.

## Rust-GPU vs wgpu: two different layers, not two competitors

The comparison people reach for is Rust-GPU vs wgpu, and it is worth being precise because they do not occupy the same layer. wgpu is a graphics and compute API implementation with its own shading language, WGSL, which the README notes is "bijective with SPIR-V." You write WGSL, wgpu translates and executes it. rust-gpu produces SPIR-V from Rust; it expects an existing pipeline to consume that module, which is why the repository's own examples include a wgpu runner under `examples/runners/wgpu`.

So the real difference is what you write. With wgpu you write WGSL for the shader stage and Rust for the host. With rust-gpu you write Rust for both, at the cost of a nightly codegen backend, a much smaller implemented subset, and no compatibility guarantees. If your team already has WGSL shaders that work, rust-gpu replaces a language you have with one you would have to validate. If your shaders and host code share types and logic, that sharing is the argument for rust-gpu, and it is the argument the README makes when it describes facilitating code-sharing between GPU and CPU.

The other historical comparison in the README is CUDA and OpenCL, which it describes as vendor locked or not supporting the traditional graphics pipeline. That is a different trade: those ecosystems are mature, and rust-gpu is early.

## Licence, maintenance and the real cost of tracking main

The repository is dual licensed under Apache-2.0 and MIT, with `LICENSE-APACHE` and `LICENSE-MIT` at the top level and `license = "MIT OR Apache-2.0"` in the workspace manifest. Dual licensing under those two terms is the common Rust convention and is permissive for commercial use, but the specific obligations that apply to your distribution are a question for your own counsel, not something this article can settle.

The maintenance picture is unusual in a way that matters more than the licence. The last push to the default branch was on 2026-09-23, and the most recent release listed is `v0.10.0-alpha.1` from 2026-04-17. That is an alpha, and the workspace version in `Cargo.toml` is `0.10.0-alpha.1`, so the released artifacts and the source tree are on the same pre-release line. The README's statement that only the latest `main` is supported means the upgrade cost is not a version bump; it is a rebuild against a moving toolchain, with `rust-toolchain.toml` pinning the compiler the project expects.

Budget for that. A team adopting rust-gpu is signing up to re-validate shaders whenever the backend changes, and to carry a nightly toolchain in CI. That is a real, recurring cost, and it is the main reason a project like this belongs in a prototype or an internal tool before it belongs in a shipped renderer.

## Conclusion

Adopt rust-gpu if you are experimenting with Rust shaders, building a graphics tool, or want to help shape a compiler backend, and you can pin your toolchain and rebuild from main when APIs move. Do not adopt it for a shipping renderer or a production compute pipeline: the README states the project is not production-ready, makes no backwards compatibility guarantees, and has no formal deprecation model. Before you commit, verify that your shader compiles through cargo gpu, that your renderer can consume the SPIR-V entry points you need, and that you can absorb the cost of tracking main.

## FAQ

### What is rust-gpu used for?

It compiles Rust code to SPIR-V so shaders can be written in Rust instead of HLSL or GLSL. The compiler component is `rustc_codegen_spirv`, a rustc codegen backend that plugs in via `-Z codegen-backend`, and `spirv-std` supplies GPU intrinsics and types.

### How do I use rust-gpu in a project?

The README points to the rust-gpu Dev Guide at https://rust-gpu.github.io/rust-gpu/book/ for getting started, and says you can experiment with rust-gpu shaders in-browser at SHADERed. The repository provides `cargo-gpu` and `spirv-builder`, which the README describes as a way of building a GPU crate in a CPU `build.rs` file.

### Is rust-gpu production-ready?

No. The README states the project is still heavily in development and at an early stage, and that while it is technically usable it is not yet production-ready. It also makes no backwards compatibility guarantees and has no formal deprecation model in place.

### Which GPU targets does rust-gpu support?

SPIR-V is the only target currently planned, which the README describes as Vulkan's open compiler target. DXIL for DirectX and WGSL for WebGPU are mentioned only as possibilities for a future version.

### Does rust-gpu replace wgpu?

No, they sit at different layers. rust-gpu produces SPIR-V from Rust shader crates, while wgpu is a graphics and compute API implementation whose shading language, WGSL, the README notes is bijective with SPIR-V. The repository includes a wgpu runner under `examples/runners/wgpu`.

## Sources

- [License: Apache-2.0](https://github.com/Rust-GPU/rust-gpu/blob/main/LICENSE)
- [Project website](https://rust-gpu.github.io)
- [README](https://github.com/Rust-GPU/rust-gpu/blob/main/README.md)
- [Releases](https://github.com/Rust-GPU/rust-gpu/releases)
- [Rust-GPU/rust-gpu on GitHub](https://github.com/Rust-GPU/rust-gpu)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rust-gpu-rust-gpu