Skip to main content

ferrum-gpu

Pure-Rust GPU compute substrate with Python bindings. FFT kernels run on NVIDIA GPUs today via cuda-oxide (Rust source compiled to PTX, no CUDA C). Cross-vendor support via spirv-oxide → Vulkan is the v0.2 roadmap.

v0.1.0 is live on PyPI:

pip install ferrum-gpu
# or, faster:
uv pip install ferrum-gpu
import numpy as np
import ferrum_gpu as fgpu

dev = fgpu.cuda.Device(0)
arr = np.array([1+0j, 2+0j, 3+0j, 4+0j], dtype=np.complex64)
print(fgpu.fft.fft_1d_c2c_pow2(arr, log_n=2, device=dev))
# [10+0j, -2+2j, -2+0j, -2-2j]

29 GPU integration tests verify the 1D and 2D Stockham FFTs against numpy.fft.fft / numpy.fft.fft2 (1D: 16 cases, 2D: 13 cases) within 1e-3 to 1e-4 relative error.

The workspace ships:

  • ferrum-gpu-core: Backend trait, KernelArtifact, errors. no_std + alloc.
  • ferrum-gpu-cuda: impl Backend for Cuda over cudarc 0.19.
  • ferrum-gpu: facade with Device<B> and Buffer<T, B>.
  • ferrum-gpu-fft: 1D + 2D radix-2 power-of-2 C2C FFT host scaffolding + CPU Stockham reference.
  • ferrum-gpu-py: Python bindings via PyO3 + maturin. ferrum_gpu.cuda.Device(0) persistent handle + ferrum_gpu.fft.fft_1d_c2c_pow2 + ferrum_gpu.fft.fft_2d_c2c_pow2.
  • ferrum-gpu-bench: cuFFT comparison binary (1D, batched).
  • examples/vector-add: end-to-end demo using hand-written PTX through the substrate.
  • examples/vector-add-cuda-oxide: same kernel in Rust, compiled to PTX by cuda-oxide.
  • examples/fft-1d-c2c: 1D Stockham FFT in Rust, GPU-vs-CPU on 8 cases (N from 4 to 4096, batched, forward + inverse).

Runtime requirements (wheel users)

  • Linux x86_64 with glibc >= 2.34 (Ubuntu 22.04+, RHEL 9+, Fedora 36+, etc.)
  • NVIDIA GPU of compute capability >= 8.0 (Ampere or newer); the wheel ships sm_80 PTX that the driver JITs forward to your architecture
  • NVIDIA driver supporting CUDA 13.x (driver 580+)
  • Python 3.10+

The wheel does not bundle libcuda; users need the NVIDIA driver installed.

Source build requirements (developers)

  • Linux x86_64
  • CUDA Toolkit 13.x
  • NVIDIA driver compatible with the installed Toolkit
  • Rust 1.99.1 (pinned via rust-toolchain.toml)
  • cargo-oxide: cargo install --git https://github.com/NVIDIA/cuda-rust cargo-oxide
  • For the Python bindings: Python 3.10+ with maturin + pytest + numpy

Quick start: vector-add via hand-written PTX

git clone https://github.com/alejandro-soto-franco/ferrum-gpu
cd ferrum-gpu
make example-vector-add

Expected:

vector_add: 1048576 elements verified

Quick start: vector-add via Rust source + cuda-oxide

cargo install --git https://github.com/NVIDIA/cuda-rust cargo-oxide
cargo oxide doctor       # one-time codegen-backend bootstrap
make example-vector-add-oxide

Expected:

vector_add (cuda-oxide): 1048576 elements verified

Quick start: 1D Stockham FFT

make example-fft

Runs 8 cases (N=4 through N=4096, batched, forward + inverse), each verified against a CPU Stockham reference within 1e-4 relative error.

Python development

uv is the Python package manager written in Rust by Astral; it is a drop-in faster replacement for pip + venv. The Makefile targets and the wheel install path work the same on pip for users who prefer it.

uv venv ~/.venvs/ferrum-gpu
source ~/.venvs/ferrum-gpu/bin/activate
uv pip install maturin pytest numpy
make develop                       # builds the cdylib + installs into the venv
python3 -c "
import numpy as np, ferrum_gpu as fgpu
arr = np.array([1+0j, 2+0j, 3+0j, 4+0j], dtype=np.complex64)
print(fgpu.fft.fft_1d_c2c_pow2(arr, log_n=2))
"

Pip equivalent:

python3 -m venv ~/.venvs/ferrum-gpu
source ~/.venvs/ferrum-gpu/bin/activate
pip install maturin pytest numpy
make develop

Run the pytest matrix:

make pytest

29 cases (16 1D + 13 2D), each compared against numpy.fft within 1e-3 to 1e-4 relative error.

Performance

make perf-gate runs the in-tree specialised kernels against cuFFT for batched 1D forward C2C FFTs at N in {256, 1024, 4096}, batch = 256, with the GPU graphics clock locked. Numbers below are medians over 100 trials with a 10-trial warmup, alternating ferrum and cuFFT launches per trial so DVFS affects both backends symmetrically.

These are pure-Rust kernels (Rust → PTX via cuda-oxide; no CUDA C) measured against NVIDIA's hand-tuned cuFFT. The specialised radix-4 (256, 1024) and radix-8 (4096) Stockham kernels are 2–5× faster than the generic radix-2 fallback; against cuFFT they range from within 1.3× at N=256 to 3.7× at N=4096.

Hardware: RTX 5060 Laptop (sm_120, Blackwell), graphics clock locked to 1500 MHz. Driver: 580.159.03. CUDA Toolkit: 13.1. Date: 2026-05-29.

N kernel ferrum_event_us cufft_event_us ratio (ferrum / cufft)
256 radix-4 0.035 0.026 1.32
1024 radix-4 0.102 0.047 2.13
4096 radix-8 0.509 0.137 3.69

ratio = ferrum_event_us / cufft_event_us; 1.0 is parity, lower is better. Event-time brackets each kernel launch with CUDA events (excludes the host launch path); cuFFT's plan-init is amortised across the loop and not counted. make perf-gate reports a 0.9× target (10 % faster than cuFFT); that gate is not yet met at any size and is tracked as an aspirational target — closing it needs a multi-FFT-per-block, profiler-guided kernel redesign. Per-launch wall-clock (which includes the launch path) is measured jointly in alternating mode and is ≈ 0.05 / 0.10 / 0.35 µs per FFT at the three sizes.

Testing

CPU-only tests: make test.

GPU tests + all examples + pytest (requires CUDA + NVIDIA GPU): make verify-all.

Publishing a new release

Maintainers only. The public wheel is built locally via maturin (manylinux_2_34 tag forced via --compatibility, libcuda excluded via --auditwheel skip) then attached to a GitHub Release. The release.yml workflow downloads the asset and uploads to PyPI via OIDC trusted publishing.

make wheel             # builds dist/ferrum_gpu-*-manylinux_2_34_x86_64.whl
gh release create vX.Y.Z dist/*.whl --title "vX.Y.Z" --notes "..."
gh workflow run release.yml --field release_tag=vX.Y.Z --field target_index=pypi

For a glibc 2.28 baseline (RHEL 8, Ubuntu 20.04), use make wheel-manylinux instead; it runs the build inside a manylinux_2_28 Docker image.

License

Apache-2.0.

Metadata

Release files for ferrum-gpu 0.3.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Built distribution (wheel)

Table of built distributions (wheels) for ferrum-gpu 0.3.0
File Interpreter ABI Platform
ferrum_gpu-0.3.0-cp310-abi3-manylinux_2_28_x86_64.whl CPython 3.10 abi3 Linux glibc 2.28+ x86-64 Details

Release files / ferrum_gpu-0.3.0-cp310-abi3-manylinux_2_28_x86_64.whl

Download URL ferrum_gpu-0.3.0-cp310-abi3-manylinux_2_28_x86_64.whl
Size 498.1 kB
Tags CPython 3.10 Linux glibc 2.28+ x86-64 abi3
SHA-256 checksum
How to use checksums
021f1706a261a53454159b1f25f02760b51cb691ea3b771ec1c433a02258b0e7
BLAKE2b-256 checksum
How to use checksums
4aed6f1a922987a97914fba26a6e259bb4b53861a0f05ca03fbb5327cb5adaee
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.16

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 25, 2026.

Transparency log

Security for ferrum-gpu 0.3.0

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

Full provenance

All 1 file in this release has been uploaded with provenance metadata.

Attestation for ferrum_gpu-0.3.0-cp310-abi3-manylinux_2_28_x86_64.whl

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 25, 2026.

Transparency log

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page