Rust kernels require a CUDA development stack
cuda-oxide compiles Rust GPU kernels into CUDA PTX while keeping host and device code in the same source file. Consider it when writing kernels in Rust and controlling CUDA threads are specific requirements. Its documented setup extends beyond a Rust compiler.
The supplied repository-level build attempt stopped after 33 seconds because no CUDA 13.0+ toolkit was found. The record does not identify the selected component, so this is not evidence of a cuda-oxide-specific build failure.
CUDA Rust contains cuda-oxide, cutile-rs and a shared host runtime. cuda-oxide uses the SIMT model, with explicit thread and block indexing. cutile-rs works on tensor tiles and lets the compiler decide how those tiles map onto the architecture. The repository says kernels from both models can share streams and device buffers.
What happened when we ran it
The sandbox run on 2026-10-17 used repository commit e84e5b3. Its install step succeeded in 9 seconds and recorded 56 dependencies. The build attempt failed with exit 101 after 33 seconds. The test attempt failed with exit 101 after 20 seconds.
Both failing logs reported that neither CUDA_TOOLKIT_PATH nor CUDA_HOME was set and that no CUDA 13.0+ toolkit was found in the checked locations under /usr/local and /opt. They asked for one of those variables to point to a CUDA 13.0+ toolkit directory. This supports the missing-toolkit diagnosis for these attempts.
The harness records an empty subdirectory and omits the commands and selected manifests or packages. The component scope remains unverified. The CUTILE_SETUP_DIAGNOSTICS entry in the logs does not identify which component was selected. Neither failure should be assigned specifically to cuda-oxide or cutile-rs.
The recorded sandbox configuration was 3 CPUs, 12 GB RAM and image label lab-rust:1. It does not establish the actual Rust or operating-system version. The attempts stopped at the toolkit prerequisite, leaving GPU execution, kernel correctness and performance unassessed. The supplied record contains no passing-test count.
Check the current prerequisites on your intended machine
The current cuda-oxide README lists Linux, a pinned Rust toolchain with compiler components, CUDA Toolkit 13.0+, a CUDA 13.x driver and Clang development headers. These describe the current documentation, not a verified environment for commit e84e5b3.
The documented next step is cargo oxide doctor. The README then gives cargo oxide run vecadd and cargo oxide sanitize vecadd to run an example and check it with NVIDIA Compute Sanitizer. No successful execution of those commands is established by this review.
Nix and devcontainer setups are also documented. Neither was evaluated in the supplied run. Use the prerequisite check on the intended development machine before judging whether this compiler fits your workflow.
Typed arguments leave raw launch obligations
The CUDA Rust overview says both programming models extend Rust ownership across GPU launches: mutable buffers are partitioned into disjoint pieces, immutable buffers are shared, and launchers retain borrows while GPU work is in flight. These are documented design properties, not results verified by the blocked sandbox attempts.
The cuda-oxide README also states that the caller must prove that raw LaunchConfig dimensions and resources match the kernel. Its quick-start example therefore uses an unsafe launch. Kernels with a launch contract instead use a checked PreparedLaunch through the generated safe method. A typed kernel signature alone does not establish that a raw launch is valid.
The repository's model comparison leaves thread synchronization and shared memory under the cuda-oxide programmer's control. Choose that model when those controls are necessary. Consider cutile-rs when the workload fits tensor computations and you want the compiler to handle scheduling details. This review did not execute either model successfully.
Alpha status limits the recommendation
The cuda-oxide README calls the project alpha and warns about bugs, incomplete features and API breakage. Teams requiring stable compiler and launch APIs should avoid adopting it on that assumption. Teams evaluating Rust-authored SIMT kernels should check their own outputs on the intended hardware and account for API changes before relying on it.
The README provides concrete prerequisites, diagnostic commands and an explanation of unsafe launch responsibilities. Its linked book is marked work in progress. Those are useful documentation features, but the supplied run does not establish whether the instructions are sufficient for a successful setup. Documentation usability, supported-environment setup ease, support responsiveness and operational maturity therefore have no numerical rating here.
Alternatives depend on what you need to write
cudarc provides Rust wrappers for CUDA libraries and NVRTC runtime kernel compilation. Its README demonstrates compiling a CUDA-language kernel at runtime. Consider it when your Rust host application can use CUDA libraries or CUDA-language kernels without compiling device code from Rust.
Triton describes itself as a language and compiler for custom deep-learning primitives. Consider it when that workload is the priority and a separate kernel language is acceptable.
Neither alternative was measured alongside this repository. If Rust-authored SIMT kernels are the requirement, start with cuda-oxide's documented prerequisite check, then validate a small kernel on the machine that will run it.