Rust Treats the GPU as One Big SIMD Register

NVIDIA has spent twenty years insisting its GPUs run "SIMT" — single instruction, multiple threads — a programming model where you write scalar code and the hardware quietly executes it 32 lanes at a time. Every CUDA veteran knows the truth underneath: a warp is a vector unit with good marketing. Vectorware, the startup staffed by the maintainers of Rust's two GPU compiler projects, just built that truth into a compiler. Rust's portable SIMD type Simd<T, 32> now maps directly onto an NVIDIA warp, and the same source function compiles for your CPU's AVX units or a GPU without changing a line.

That's a more interesting claim than "Rust runs on GPUs," which has been true for years. It's a claim about which abstraction survives the trip.

Running ISPC's trick in reverse

The intellectual lineage here is worth spelling out. In 2011, Intel's ISPC went one direction: take SPMD code — the CUDA style, scalar-looking programs over implicit lanes — and compile it onto CPU vector registers. It worked because SIMT and SIMD are the same execution model with the mask managed by different parties. Vectorware runs the mapping the other way: take explicit vector types, where the programmer holds the lanes and masks in hand, and lower them onto hardware that was designed to hide them.

Rust's std::simd gives you Simd<T, N> — N elements of T, with portable operations that compile to whatever vector ISA the target has. Vectorware's observation is that a GPU is just one more vector target, with a warp's 32 lanes standing in for a 512-bit register's 16 floats. Warp intrinsics that CUDA programmers reach for by hand — shuffles, ballots, reductions, scans — become the lowering for portable SIMD's cross-lane operations. Gathers, scatters, and atomics map similarly, and the team built an architecture-agnostic IR, encoded in Rust's type system, to keep lane bookkeeping sound. They note the compiler itself needed modification to get there; this isn't a library trick.

There's a subtle win hiding in the inversion. SIMT's chronic headache is divergence: threads in a warp take different branches and the hardware serializes and reconverges them behind your back, with performance cliffs that don't appear in the source. Explicit SIMD has no hidden control flow — you compute a mask, you select with it, and the cost is visible in the code. For the class of kernels this covers, the SIMD model is arguably more honest about what the hardware does than CUDA is.

Here's what the shape of it looks like using the standard nightly API — elementwise work, a comparison mask, a horizontal reduction:

use std::simd::{Simd, cmp::SimdPartialOrd, num::SimdFloat};

fn relu_dot(a: Simd<f32, 32>, b: Simd<f32, 32>) -> f32 {
    let prod = a * b;
    let mask = prod.simd_gt(Simd::splat(0.0));
    mask.select(prod, Simd::splat(0.0)).reduce_sum()
}

On x86 that's a handful of AVX instructions. Under Vectorware's toolchain, the 32 lanes are a warp and reduce_sum becomes a shuffle-based warp reduction. Same function, no FFI, no extern "C" boundary, no separate .cu file with its own build system bolted onto Cargo.

Who actually needs this

The audience isn't ML kernel authors — more on that below. It's the substantial population of Rust systems programmers who already write SIMD by hand: JSON and format parsers, compression, image and video processing, crypto, physics, search. Today, offloading any of that to a GPU means rewriting in CUDA C++ and maintaining a bindings layer, which is why almost nobody does it for workloads that are merely good GPU fits rather than great ones. A single-source path changes that calculus, and it fills a real gap in the Rust GPU story: rust-gpu compiles Rust to SPIR-V shaders and Rust-CUDA emits NVIDIA kernels, but neither gave you one function running on both processors.

Now the catches, and they're substantial.

You can't use it yet. The compiler isn't released. A founder said on Hacker News that the tentative plan is to open-source the compiler and standard-library work with commercial products on top — the rust-gpu/rust-cuda stewardship record lends that credibility, but today this is a demo you're taking on faith.

portable_simd is still nightly, years into development, with no stabilization date. Building a GPU strategy on an unstable feature is a bet that Vectorware's usage helps force the issue. It might. It hasn't yet.

"Portable" means the API, not the performance. The zero-cost mapping only holds when your vector width equals the warp width. NVIDIA warps are 32 lanes; AMD's compute GPUs run wave64. Because N is a const generic baked into your types, truly portable code either strip-mines (with idle-lane overhead) or gets compiled per target width. Vectorware is upfront about this, and it's the same width-portability problem CPU SIMD never fully solved either.

No benchmarks. The post argues the model is sound, not that it's fast. Real GPU performance lives in memory choreography — shared-memory tiling, async copies, occupancy — which vector types say nothing about. And tensor cores, where modern GPUs spend most of their FLOPs, sit entirely outside the lane-wise SIMD model. That territory belongs to Triton and CUTLASS, and Vectorware acknowledges tensor cores are future work.

The campaign, not the feature

Read this as the third move in a deliberate sequence: Rust's standard library on the GPU via syscall-like hostcalls in January, threads after that, now SIMD. Vectorware calls itself a GPU-native software company — the GPU owns the control loop, the CPU is the peripheral — and it's methodically making Rust's existing vocabulary work there. That's the same single-source future Modular is promising with Mojo, pursued the harder way: retrofitting a language people already ship, instead of launching a new one and asking everyone to move.

My read: this is a genuine direction, not hype — the warp-as-vector mapping is technically sound, and it's coming from the people who own the relevant compiler surface. But it's a research preview wearing a product announcement's clothes. The honest checklist before it matters in production: a released toolchain, numbers against hand-written CUDA, and an AMD story that survives the wave64 problem. Until those land, keep your .cu files — but if you maintain CPU SIMD code in Rust, this is the project to watch, because it's the first credible claim that you'll never have to translate that code again.