What NVIDIA released

NVIDIA now supports writing GPU kernels directly in Rust, with two separate tracks for doing it. The announcement came on September 8, 2026. Before it, you could launch kernels from Rust, but the kernel itself usually had to be written in another language.

The two tracks match the two tracks CUDA already has. SIMT is the model developers know from CUDA C++ and Numba: you describe what one thread does and launch thousands of them. Tile is the newer model, already available in C++ and Python, where you describe what one tile of data does and the compiler handles the mapping.

Each track has its own project. cuda-oxide handles SIMT, and cutile-rs handles Tile. Both compile Rust to PTX instead of wrapping code from somewhere else. NVIDIA states in the same post that neither project is production-ready.

The SIMT track: cuda-oxide

cuda-oxide is a custom rustc codegen backend. It routes functions marked with #[kernel] through Rust MIR, the community Pliron IR framework, and LLVM IR down to PTX, while the rest of the crate goes through the standard backend.

You install it as a Cargo subcommand from the repository with a pinned nightly toolchain, then scaffold a project with cargo oxide new. The generated template is a complete vector addition program that prints PASSED: all 1024 elements correct. The first cargo oxide run builds the codegen backend, so it takes a while; later runs reuse the cache.

The requirements are specific. The SIMT track needs Linux, a GPU with compute capability 8.0 or later, a CUDA toolkit 12.x or newer, clang with its libclang headers, and the pinned nightly toolchain. cargo oxide doctor checks that list, including the optional system LLVM.

A kernel's output parameter is a DisjointSlice, which gives each thread exclusive access to one element. A mutable slice cannot do that job, because every thread would need the same mutable borrow and Rust refuses it. DisjointSlice splits the single mutable borrow into per-thread pieces.

Launch configuration is checked rather than assumed. A launch_contract attribute declares the indexing shape and block size, and a prepare function validates your configuration against that declaration and the live device limits before returning a token the safe launch method requires. A kernel without a contract exposes only raw unsafe launch methods.

The Tile track: cutile-rs

cutile-rs works a level higher, on tiles instead of scalars. Each tile block runs the kernel body once as a single logical thread over one sub-tensor, and the compiler decides how many real GPU threads back it.

Its requirements are lighter, which matters for anyone deciding what to try first: a GPU with compute capability 8.0 or later, CUDA 13.3, stable Rust 1.89 or newer, and Linux. There is no nightly toolchain requirement and no LLVM build. The crate is on crates.io, so setup is cargo add cutile in a new project.

The kernel is embedded in the host binary and JIT-compiled through CUDA Tile IR the first time it runs. On the host side, partition does three jobs at once: it gives each tile exclusive ownership of its own chunk, it fixes the grid size, and it supplies the tile width, which is why it never appears at the call site. Nothing executes until sync_on, so the entire program before that point is a description that has been recorded rather than submitted.

What the compiler catches

Both tracks make the same claim about memory. Inputs are shared, and the output has one writer.

The post demonstrates that passing the SIMT kernel's output buffer as one of its own inputs fails to compile, and that the equivalent aliasing mistake on the Tile side also fails. The errors differ: cuda-oxide rejects the launch call, while cutile-rs follows ownership across the launch boundary, which is the stronger of the two guarantees.

This matters because thousands of threads reach the same buffers with no guaranteed order. When two of them target the same address and one writes, the ordering decides the result, and those bugs do not usually reproduce on demand. Tile removes shared memory and thread indexing from the developer's hands entirely, so there are no threads to race. SIMT keeps that control, and shared memory currently requires unsafe, which NVIDIA says it is working to change.

One shared input block fans out to four worker blocks, each writing to a separate slice of one output buffer.
Concept diagram of shared input reads and separate output ownership; the four lanes are illustrative, not a fixed GPU thread count.

Installation guides and examples

NVIDIA points readers to the cuTile Rust documentation and a hello world example in the repository.

The cuda-oxide book covers setup details, and the repository takes issue reports.

Both tracks are Linux-only as described. The post does not mention Windows or macOS support.

What is still missing

Neither project is ready for production workloads. cuda-oxide is early alpha. cutile-rs is further along and is already used outside NVIDIA in HuggingFace's Grout inference engine and in mistral.rs, but the post says coverage is incomplete and APIs will move.

The nightly toolchain requirement on the SIMT track is the kind of friction NVIDIA says it wants to remove. Performance claims and benchmark comparisons are absent from the post, so there is no published basis yet for judging either track against a tuned CUDA C++ kernel.

Two other threads are worth watching. NVIDIA says it plans inter-language interoperability between CUDA Rust, CUDA C++, and CUDA Python, which would let teams mix frontends in one codebase. The project also publishes a paper, Fearless Concurrency on the GPU, and its authors presented at RustConf 2026 in Montréal.

Where this sits in the Rust GPU stack

Rust on GPUs is not new. rust-cuda, rust-gpu, and cudarc came first, and NVIDIA says it has worked with the rust-cuda maintainers as both efforts mature. The cuda-oxide book includes an ecosystem appendix that maps the new projects against the existing ones.

What is new is the level of investment. NVIDIA says it will grow CUDA Rust into 2027 and beyond, and points to Rust already running in parts of its own stack, including the Nova Linux driver, a Rust core in Dynamo, and NVTX bindings.

If you want to test the current state, the Tile track is the cheaper first experiment. It runs on stable Rust, publishes to crates.io, and its constraints are easier to satisfy than the SIMT toolchain. Keep the production caveat in mind: both projects say their APIs will change, so the right use today is evaluation and small experiments rather than a migration.