NVIDIA released version 0.3.0 of cuda-oxide on October 31, 2026, the compiler that lets developers write CUDA kernels in Rust, and with it the project leaves behind its dependency on nightly Rust: it now builds on stable Rust 1.99.1 and shares a single host runtime with cutile-rs inside the NVIDIA/cuda-rust monorepo.
CUDA Oxide 0.3 in 30 seconds
- NVIDIA released CUDA Oxide 0.3 on 10/31/2026, with nearly 600 commits from more than 45 contributors since 0.2.1.
- The SIMT compiler drops nightly builds and settles on stable Rust 1.99.1, though it still needs rustc-dev, LLVM tooling, and CUDA 13.0 or newer.
- cuda-oxide and cutile-rs now share a host runtime with buffers, streams, events, and CUDA graphs.
- cute-rs, still in preview, brings CuTe to Rust only for Blackwell sm_100a and sm_120a.
- NVIDIA still classifies the project as experimental.
According to the release notes on GitHub, this is the project’s biggest release so far. NVIDIA introduced CUDA Rust in September as a platform with two ways to write kernels, and this outlet covered at the time how NVIDIA brought CUDA to Rust without leaving the language. That first stage required a specific nightly toolchain for cuda-oxide. The 0.3 release changes that foundation, though it doesn’t fully simplify it.
The compiler still pins its Rust version in a rust-toolchain.toml file and needs the rustc-dev, rust-src, and llvm-tools components. The reason is technical: cuda-oxide is a code-generation backend for rustc and relies on internal compiler components (the librustc_driver library and rustc_public), which carry no stability guarantees across versions. The cargo-oxide tool manages that pinned toolchain. The practical difference is that developers no longer have to chase a nightly build that changes every day.
SIMT and Tile: two compilers on a shared runtime
The NVIDIA/cuda-rust repository groups two programming models. cuda-oxide follows the SIMT model (Single Instruction, Multiple Threads), the classic CUDA C++ approach: the developer writes what a single thread does and controls blocks, warps, and shared memory. It compiles ahead of time from Rust to PTX (Parallel Thread Execution, the intermediate language for NVIDIA GPUs) by way of rustc’s MIR representation, the Pliron IR framework, and LLVM.
cutile-rs implements the CUDA Tile model, which NVIDIA already offers in C++ and Python. Here the kernel works with full blocks of data (tiles), and the compiler decides how they’re distributed on each architecture; the code compiles at first launch into Tile IR and a cubin binary. This outlet previously explained how CUDA Tile works. cutile-rs doesn’t need the pinned toolchain: it works with stable Rust 1.89 or newer, and its documentation recommends CUDA 13.3, which is required for FP4 packing and block-scaled MMAs.
What’s new in 0.3 is that both now share a host runtime made up of cuda-bindings, cuda-core, cuda-core-derive, and cuda-async (version 0.5.0). The release notes describe a single async DeviceBuffer, Stream, Event, CudaGraph, and DeviceOp for both models, so a Tile kernel and a SIMT kernel can work on the same stream over the same buffers. It also adds virtual memory management, cross-GPU access, NVLink Switch multicast, and stream priorities, plus a #[tile_fn] attribute for exporting SIMT functions as libraries a Tile kernel can call.
cute-rs: CUTLASS in Rust, for just two Blackwell variants
The most eye-catching piece is cute-rs-preview, an experimental implementation of CuTe, the layout layer of CUTLASS (NVIDIA’s template library for linear algebra on GPUs). It compiles ahead of time using the pinned CUTLASS 4.7 compiler and, according to its own compatibility matrix, covers a validated subset of CuTeDSL 4.7, without full feature parity.
The targets are strict. In 0.3.0 it only supports sm_100a (data center Blackwell, the B200 class) and sm_120a (GeForce RTX 50). Ampere, Ada, and Hopper (sm_90a) are rejected before compiling, as are other Blackwell variants. The matrix also notes there’s no support for wgmma, the Tensor Core instruction specific to Hopper, nor for grouped kernels, MoE, mixed inputs, or FP8. On the main branch, after the release, sm_103a (B300 class) already appears too, but it isn’t part of version 0.3.0.
What it does offer is the ability to express layouts, TMA descriptors (Tensor Memory Accelerator, NVIDIA’s asynchronous memory-copy engine), producer-consumer pipelines, and Tensor Core MMAs in Rust’s type system, and to check them before generating code. The release includes 14 example kernels and two complete models that run on an RTX 5090: a 36-layer Qwen3-8B in BF16 (bfloat16, 16-bit floating point) and NVFP4 (NVIDIA’s 4-bit, block-scaled format), and Qwen3-TTS 1.7B. In NVFP4, the weights take up 3.64 GiB versus 12.94 GiB in BF16, 3.56 times less.
Debugging with cuda-gdb, testing, and installation requirements
For anyone who has to maintain kernels, 0.3 brings full DWARF (the standard debug-information format) debugging with cuda-gdb through the --device-debug and --lineinfo flags, which preserve source locations, closures, enum variants, and shared memory. The release notes say this is validated against cuda-gdb in continuous integration. It adds register, shared-memory, and spill diagnostics pulled from ptxas, with a warning when a kernel with launch bounds spills registers, and an in-kernel event-tracing system called IKET.
The compiler also gets changes for Blackwell and Hopper: 32-bit shared-memory pointers, a seven-stage pipeline with TMA and tcgen05 on B200, and Hopper wgmma accumulators kept in registers with no spills to local memory. NVIDIA also puts the number of verified intrinsics at more than 1,240, from sm_75 to sm_100a/sm_120a, and counts 241 GPU smoke tests, with 16 automated guards in the repository.
The requirements for cuda-oxide now look like this:
| Component | cuda-oxide 0.3 (SIMT) | cutile-rs (Tile) |
|---|---|---|
| Rust | Stable 1.99.1, pinned, with rustc-dev and llvm-tools | Stable 1.89 or newer |
| CUDA | Toolkit 13.0 or newer and driver 13.x (R580+) | 13.3 recommended |
| Compilation | Ahead of time, Rust to PTX | JIT, Rust to Tile IR and cubin |
| Other | cargo-oxide, Clang 21 for bindgen; LLVM 21 optional | sm_80 GPU or newer |
The documentation warns that LLVM 20’s llc and earlier versions can’t handle the TMA, tcgen05, and WGMMA intrinsics the compiler emits. And NVIDIA itself tempers expectations: the repository’s README describes it as an early-stage research project with bugs, incomplete features, and expected API changes, and its developer page calls it experimental.
There’s also no data showing that Rust compiled with cuda-oxide outperforms CUDA C++. The release notes talk about code improvements aimed, in its own words, at “closing the gap with hand-tuned CUDA C++,” which implies that gap still exists. The project also coexists with community efforts such as rust-cuda, which compiles Rust to NVVM IR, and Rust-GPU, aimed at SPIR-V and graphics; the cuda-oxide book states that NVIDIA collaborates with the rust-cuda maintainers and presents both projects as complementary.
Frequently asked questions
Does CUDA Oxide 0.3 already work with stable Rust?
Yes. It uses stable Rust 1.99.1, though it pins that version and needs the rustc-dev and llvm-tools components because the backend relies on internal parts of rustc.
What’s the difference between cuda-oxide and cutile-rs?
cuda-oxide follows the SIMT model and compiles to PTX with direct control over threads and shared memory. cutile-rs uses the CUDA Tile model, compiles at runtime, and leaves the work distribution to the compiler. Since 0.3, they share a host runtime.
Does cute-rs work on Hopper GPUs like the H100?
No. In version 0.3.0 it only supports sm_100a (B200 class) and sm_120a (RTX 50), and it rejects Hopper before compiling.
Is it ready for production?
NVIDIA describes it as experimental and early-stage, and warns of bugs and API changes. The demos show that it works, not that it outperforms CUDA C++.
Sources:
- NVIDIA/cuda-rust: cuda-oxide v0.3.0 release notes (GitHub)
- NVIDIA/cuda-rust: repository, README, and cute-rs compatibility matrix
- Official CUDA Rust documentation
- NVIDIA Developer: CUDA Rust
- NVIDIA Technical Blog: Introducing CUDA Rust: Two Tracks for Writing GPU Kernels
- Phoronix: CUDA Oxide 0.3 Vastly Improves Rust Support For NVIDIA CUDA Programming
- Rothy Yorn (Medium): NVIDIA Just Made Rust GPU Programming More Serious. CUDA Oxide 0.3 Is Why
This article is also available in Spanish: «CUDA Oxide 0.3 pasa a Rust estable y une SIMT y Tile en un mismo runtime», on revistacloud.com.
