OxiFFT 0.4.1 Released — A Critical GPU Async-Copy Race Fix Arrives via OxiCUDA 0.5.3

A silent GPU correctness bug, closed — without OxiFFT’s own code changing a line.

Today we released OxiFFT 0.4.1 — a small, focused release whose only change is pulling in OxiCUDA 0.5.3, which fixes a race condition in async GPU memory transfers that could corrupt cuda-feature FFT results under load.

No C. No Fortran. No FFTW. No FFI. OxiFFT’s default build is still 100% Pure Rust — this release only touches the optional cuda/metal GPU backends, and even there it’s a dependency bump, not new native surface.

Why 0.4.1 matters

OxiFFT’s own source is unchanged in this release — but if you build with the cuda feature, this bump matters:

• The bug: oxicuda-fft’s shared copy_dtoh_async/copy_htod_async helpers enqueued cuMemcpyDtoHAsync/cuMemcpyHtoDAsync but returned before the transfer actually completed. On a non-blocking stream, the caller’s very next line could read a destination buffer that was still mid-transfer, or a source buffer could be dropped before the upload landed.
• The impact: exactly the kind of bug that hides in light testing — a device-to-host copy racing the read could produce a silently all-zero transform result; a host-to-device copy racing a dropped buffer could have the driver read freed host memory.
• The fix: both helpers now call stream.synchronize() before returning, closing the race.
• The scope: oxicuda-driver/oxicuda-fft/oxicuda-metal bumped 0.5.2 → 0.5.3. That’s the entire diff for this release — no OxiFFT API changed, no new features, nothing to migrate.

Getting Started

cargo add oxifft --features cuda

The core API is unchanged from prior releases — a forward 1D FFT still reads:

use oxifft::{Complex, Direction, Flags, Plan};

let plan = Plan::dft_1d(1024, Direction::Forward, Flags::ESTIMATE)
    .expect("1024-pt plan");
let input = vec![Complex::new(1.0_f64, 0.0); 1024];
let mut output = vec![Complex::new(0.0_f64, 0.0); 1024];
plan.execute(&input, &mut output);

GPU dispatch via cuda/metal is opt-in and transparent to this API — the fix in 0.4.1 lives entirely in the backend’s async memory-transfer plumbing.

What’s New in 0.4.1

Dependencies

• oxicuda-driver / oxicuda-fft / oxicuda-metal (optional GPU backends) updated 0.5.2 → 0.5.3, picking up a fix for the async-copy race condition described above.

Tips

• On --features cuda or --features metal? Update now. The previous OxiCUDA release could silently produce all-zero or corrupted results on a non-blocking CUDA stream under load — this isn’t a theoretical edge case, it’s a real race in the copy helpers every GPU transform path shares.
• Default (Pure Rust, no GPU features) builds are unaffected. This bump only matters if cuda, metal, or gpu features are enabled in your Cargo.toml.
• Re-test under real load, not just a smoke test. Race conditions like this one are load- and timing-dependent — a single-transform sanity check can pass while the bug is still there.
• No code changes needed on your side. cargo update -p oxicuda-fft (or a fresh cargo add oxifft --features cuda) is enough — the fix is entirely internal to the GPU backend’s synchronization.

This is the foundation

OxiFFT is the spectral layer of the COOLJAPAN ecosystem, a direct dependency of 21 other COOLJAPAN projects — including SciRS2, NumRS2, OxiBLAS, OxiCUDA (its GPU backend), ToRSh, OxiWhisper, SkleaRS, TenfloweRS, OxiMedia, and OxiPhysics. Keeping the GPU path correct under load matters precisely because so much downstream signal, audio, and tensor work leans on it.

Repository: https://github.com/cool-japan/oxifft

Star the repo if Pure Rust spectral computing belongs in your stack — and if you run OxiFFT on GPU under real load, this update is for you.

Pure Rust spectral computing — fast, safe, and sovereign, from a laptop to a GPU cluster.

— KitaSan at COOLJAPAN OÜ July 27, 2026