Build1 publisher2 min readPublished
NVIDIA routes Rust GPU kernels to PTX through a custom rustc codegen backend
The kernel was the one place a Rust AI stack still had to change language. NVIDIA's cuda-oxide closes that gap, if you have Linux, a compute capability 8.0 card, CUDA 12.x and the nightly-2026-04-03 toolchain.
The Engineer · Build desk

What happened
- NVIDIA said in September 2026 that GPU kernels written in Rust now compile natively to PTX under a project called CUDA Rust, instead of wrapping code generated from another language.
- There are two tracks, matching CUDA's own models: SIMT, where you write what one thread does and launch thousands, and Tile, where you write what one tile of data does and the Tile IR compiler handles the mapping.
- NVIDIA already ships Rust in the Nova Linux driver, in Dynamo's core and in NVTX bindings, and it names the kernel as the remaining exception, launchable from Rust but written elsewhere.
- The post calls CUDA C++ and CUDA Python mature, enterprise-grade toolchains and says NVIDIA will be growing and maturing CUDA Rust into 2027 and beyond.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- capability A Rust platform team can keep the kernel and its launch site in one crate, because the #[cuda_module] macro generates the host-side load, prepare and safe launch functions alongside the device code.
- decision A team that adopted Rust for control over memory now has to decide whether to accept Tile's compiler-chosen mapping per architecture or stay on SIMT and keep managing threads and memory itself.
- cost The pin to nightly-2026-04-03 means an upstream repository chooses the kernel crate's toolchain version, and build images have to carry that nightly next to whatever the rest of the workspace compiles with.
- constraint Kernel builds stay on Linux hosts with compute capability 8.0 or later cards, so a shop on Windows laptops or older GPUs keeps a second machine class in the loop just to compile.
`cargo oxide run` drives a build in which a custom rustc codegen backend intercepts compilation. Functions marked `#[kernel]` go through Rust MIR, then the community Pliron IR framework, then LLVM IR, and come out as PTX; everything else in the crate is handed to the standard backend [11]. The GPU dialects sitting on top of Pliron are NVIDIA's, and every dialect and transform stays in Rust until the standard LLVM backend takes over [12]. The first `cargo oxide run` builds that codegen backend, which NVIDIA says takes a while, and later runs reuse the cache [15]. A CI runner with a cold cache pays that build every time.
`cargo oxide doctor` is the gate. It checks for Linux, a GPU with compute capability 8.0 or later, a CUDA toolkit 12.x or newer, clang with its libclang headers, the pinned nightly toolchain, and optionally a system LLVM [13]. The install command pulls cargo-oxide from the NVlabs GitHub repository and names the pin in the invocation: `cargo +nightly-2026-04-03` [14]. The post is dated September 2026, which puts the required nightly roughly five months behind the announcement [22].
The scaffolded kernel shows where Rust's guarantees land in device code. The output parameter is a `DisjointSlice<f32>`, and the store happens only inside `if let Some(c_elem) = c.get_mut(idx)`, while the two inputs are read with the plain `usize` returned by `idx.get()` [18]. Above the function, `#[launch_bounds(256)]` caps threads per block so the compiler can budget registers, and `#[launch_contract(domain = 1, block = (256, 1, 1))]` declares one-dimensional indexing with 256-thread blocks [19].
On which track to build, NVIDIA's guidance is to reach for Tile first, because the compiler decides how tiles map onto each architecture and the source then does not encode architecture-specific choices; you drop to SIMT when you need that control or want to manage memory and threads yourself [9]. Tile is available on the C++ and Python frontends too, so that advice is not specific to Rust [8].
The evidence in the post is correctness. The worked example is elementwise addition over 1,024 floats, written on both tracks, both complete programs that run and print the same line [17], and the scaffolded version reports `PASSED: all 1024 elements correct` [16]. The post does not include performance numbers. Whether PTX from cuda-oxide costs anything against PTX from CUDA C++ on a kernel that matters is a measurement the adopting team makes on its own workload, on its own architecture, with its own occupancy limits.
NVIDIA also says it plans to support inter-language interop, so a team that picks the Rust frontend is not meant to be locked out of the others [10].
What to watch
- Whether cuda-oxide moves off a pinned nightly and off Linux-only, which is what makes it usable in a normal stable-Rust CI image.
- Whether the promised inter-language interop ships, letting a Rust kernel crate call existing CUDA C++ device code.
- Any published comparison of PTX emitted by cuda-oxide against PTX from CUDA C++ for the same non-trivial kernel.