cuda-oxide compiles Rust kernels into NVIDIA PTX
cuda-oxide is a 65.5 MB Rust workspace that keeps CPU and GPU code in the same source file. A #[kernel] function is compiled through Rust MIR, the project's Pliron-based intermediate representation, LLVM IR, and finally PTX. The host side gets generated, typed launch methods instead of manually loading a string of kernel arguments. That makes it attractive to Rust teams that want CUDA's thread, warp, shared-memory, barrier, atomic, and cluster concepts without maintaining a separate CUDA C++ codebase.
The project includes more than 190 examples, ranging from vector addition and generics to tensor-memory operations, device FFI, and asynchronous pipelines. cargo oxide inspect prints PTX, pipeline exposes the compiler stages, sanitize invokes NVIDIA Compute Sanitizer, and debug opens cuda-gdb. These tools support day-to-day compiler work beyond the bundled demos. The cuda-oxide README also explains which launch calls remain unsafe and how a launch contract can produce a checked API.
CUDA 13.0+ and Linux are the entry price
The documented baseline is Linux, an Ampere-class or newer NVIDIA GPU, driver 580+, CUDA Toolkit 13.0+, Clang 21+, LLVM 21+, and a pinned Rust nightly. Ubuntu 24.04 is the tested distribution. Windows is unsupported. The toolkit must expose cuda.h and curand.h, while LLVM needs its NVPTX backend. This is a specialist compiler environment, so a developer with a working Rust installation still has several system layers to align before the first kernel runs.
The installation guide gives three routes: manual packages, a devcontainer, or a Nix shell. The latter two assemble CUDA 13, Clang, LLVM, and the nightly compiler, but neither can supply a suitable host driver or GPU. cargo oxide doctor checks the chain and reports missing headers, compiler components, driver access, and backend state. That diagnostic command is useful because toolkit and driver compatibility can fail at different stages.
What happened when we ran it
Our sandbox installed 173 packages in 91 seconds. The checkout contained 3,377 files, roughly 788,923 source lines, and used 65.5 MB before those dependencies. We ran commit 6abfaa0 in an unprivileged Debian container with 3 CPUs and 12 GB of RAM, following our testing method. The repository scan found 11 CI workflow files, no Dockerfile, and no top-level tests directory.
The build exited with code 101 after 109 seconds. Its final diagnostic said neither CUDA_TOOLKIT_PATH nor CUDA_HOME was set, and it checked /usr/local/cuda-13.3, /usr/local/cuda-13.2, /usr/local/cuda-13, and /usr/local/cuda without finding a CUDA 13.0+ toolkit. The test command ended with the same exit code after 101 seconds and the same prerequisite message. The logs do not show a later compiler or test assertion failure because configuration stopped both commands first.
That result does not tell us whether the Rust-to-PTX pipeline produces correct kernels on supported hardware. It does establish that a fresh Debian environment cannot build this checkout after Cargo dependencies alone. The README documents the missing requirement clearly, and its devcontainer gives users a packaged route, yet teams still need the matching NVIDIA host layer. Our run establishes setup behavior only; it says nothing about GPU performance.
Typed launches reduce mistakes, while raw geometry remains unsafe
The quick-start kernel uses Rust generics and a closure capturing a scalar, then exposes a typed host method after compilation. Device buffers, pinned transfers, streams, scoped atomics, barriers, and asynchronous DeviceOperation values live in the associated runtime crates. For 1-dimensional work, LaunchConfig::for_num_elems expresses the thread count directly. The generated method checks argument types, which removes a class of hand-packed launch errors common in lower-level CUDA loading code.
Launch dimensions and resource choices are still the caller's responsibility unless the kernel has a launch contract. The README marks the raw launch unsafe because the compiler cannot prove that its dimensions match the kernel's indexing assumptions. That is a fair boundary, but the phrase "safe Rust" needs that footnote. Open issue 883 on pointer casts is labeled as a bug and possible miscompile, another reason to test generated code against known outputs on every target architecture.
Alpha status matters more than the v0.2.1 tag
GitHub recorded 3,263 stars, 50 open issues and pull requests, and a last push on September 11, 2026. The true open-issue search returned 37 issues, while current items were being updated through September 10. That combination shows active work and active fault discovery. It also matches the README's alpha warning: users should expect incomplete features, bugs, and API changes rather than treating the NVIDIA organization name as a stability guarantee.
The latest release is v0.2.1 from June 10, 2026, but repository work continued into September. Its notes describe fixes for convergent device calls, architecture selection, NaN literals, and Rust ABI alignment. Those are compiler-correctness details with real consequences. Current full-debug lowering issue 1219 documents another narrow failure mode. The issue discussion is specific and recent, which is healthy, though it also shows how many code-generation paths still need scrutiny.
CubeCL is the clearer choice for cross-vendor work
A 788,923-line compiler tied to CUDA 13.0+ makes sense only when NVIDIA semantics are the goal. The project's own Rust GPU comparison names Rust-CUDA as its closest neighbor, with a more Rust-first device model. CubeCL trades full Rust language coverage for a controlled DSL that can target CUDA, ROCm, and WGPU. wgpu sits farther away, using WGSL and WebGPU for portable compute and graphics.
Choose cuda-oxide when a Rust team wants direct access to CUDA's SIMT model and can test on the exact GPU generations it ships. The 173-package install is manageable; the harder commitment is the compiler, toolkit, driver, and hardware matrix. For a cross-vendor product, a stable production service, or a developer fleet split across Windows and macOS, that commitment overwhelms the benefit of keeping kernels in ordinary Rust files.