Browser-native FFT whitepaper
This site is the evaluation front-end for gpu-fft: a JavaScript / TypeScript FFT library with a WebGPU execution core, explicit CPU fallback paths, and contract-first real-input APIs. It is written for interviewers, maintainers, and engineers who want to see exactly what the project does, what it does not do, and how to verify those claims.
GPU-accelerated FFT core, CPU-only analysis utilities, zero runtime dependencies, and documentation that keeps those boundaries explicit.
Current product slice
Capability matrix
| Surface | GPU | CPU | Notes |
|---|---|---|---|
| 1D FFT / IFFT | Native | Fallback | Complex interleaved input contract |
| 1D RFFT / IRFFT | Wrapped | Native | Half-spectrum contract |
| 2D FFT / IFFT | Native | Fallback | Row-column decomposition |
| Spectrum analyzer | — | CPU only | Built on window functions and CPU FFT |
| Image filter | — | CPU only | Frequency-domain utility, not a GPU shader pipeline |
Guide
Start with the guided evaluation path before reading implementation detail.
Open the guideAcademy
Choose the shortest route for evaluators, DSP learners, or contributors.
Open the academy mapArchitecture
Follow the execution planner, GPU passes, and CPU-only utility boundary.
Open architectureEvidence
Measured results, explicit caveats, and decision records sit in one place.
Open evidenceReference
Foundational papers, related libraries, and learning resources are curated here.
Open referencesSystem map
The project is intentionally narrow. Public APIs define the FFT contract, the execution layer owns planning and resources, GPU passes handle the transform core, and application utilities stay on CPU.
Layer 01
createFFTEngine(), real-input FFT APIs, CPU shortcuts, and utilities define the supported contract.
Layer 02
FFTEngine owns validation, execution-plan caching, buffer lifetime, and dispatch sequencing.
Layer 03
Bit reversal, butterfly stages, and scaling passes form the WebGPU FFT path.
Layer 04
Spectrum analysis and image filtering stay on the CPU path and should never be described as GPU-native.
What this page optimizes for
The goal is not to make the library look larger than it is. The goal is to let a technical reader understand the actual product slice quickly enough that deeper questions become more interesting than basic clarification.
What not to infer
| If you need | Start here |
|---|---|
| A fast technical evaluation | Guided Start |
| A reading sequence for interviews or code review | Academy Reading Map |
| The execution model and capability boundary | Architecture Overview |
| Empirical performance context | Benchmarks |
| The scholarly and ecosystem backdrop | Reference Hub |
