The documentation has two layers. The library layer starts from installation, plans, streams, workspace, errors, and API contracts. The research layer separates the architecture claim from kernel implementation and measurement evidence. Application users should begin with Getting Started; architecture and paper readers should begin with Design Overview.
| Document | Question answered |
|---|---|
| Getting Started | How is the library configured, built, installed, tested, and called? |
| C Plan API | How do handle, descriptor, plan, workspace, arbitrary shape, tuning cache, and logs compose? |
| General Shape Mapping | How are exact, embedded, and rank-two workloads lowered to the same architecture mapping? |
| v0.6 Implementation Status | Which general-shape, API, selection, and boundary features are complete, and what remains outside the claim? |
| Programming Guide | What are the plan, device, stream, layout, workspace, concurrency, and lifetime contracts? |
| API Reference | What does each public type, configuration field, and plan member mean? |
| Error Handling | Which exceptions are reported synchronously and where can asynchronous CUDA errors surface? |
| Capability and Compatibility Matrix | Which operators, types, toolchains, optional components, and runtime features are supported? |
| Operator Catalog | What does each transform compute, which mappings does it reuse, and which operators come next? |
| Examples | Which minimal, build-checked example matches each integration style? |
| Device API | What is the shortest device-pointer integration recipe? |
| Runtime Mapping Selector | How does a supported workload resolve to a calibrated mapping? |
Application integration. Follow Getting Started, run the Examples, then use the Programming Guide and C++ API Reference as the contract. Check the Capability and Compatibility Matrix before depending on an optional backend, GPU, or execution feature.
Architecture and paper review. Begin with the Design
Overview for the D x S iteration domain and its four
space-time factors. Continue with Hardware Mapping
Methodology for resource demand and selection,
then Complete Butterfly Design Space for the formal
object boundaries. Research Positioning and
V100 Research Status delimit the contribution and claims.
Kernel and generator development. Read FFT Design Space, FFT Pipeline Generator, and Processing-Unit Design Space. Together they show how a logical stage decomposition is lowered into physical execution groups, how online layout boundaries are generated, and where operator-specific codelets plug in.
Experimental reproduction. Start with Reproducibility, regenerate the derived tables, and use Single-GPU Comprehensive Benchmark only when new timings are needed. The focused NCU reports explain mechanisms; the comprehensive and scaling reports define the paper-facing comparison protocol.
| Document | Question answered |
|---|---|
| Design Overview | Why are data and stage work each unfolded in space and time, and how does that map to a GPU? |
| Hardware Mapping Methodology | How do the unfolding factors translate into GPU resource demand? |
| Complete Butterfly Design Space | How are graph, architecture, processing unit, layout, realization, selection, and hardware separated? |
| FFT Design Space | Which semantic, factorization, two-axis mapping, processing-unit, and hardware parameters are enumerable? |
| FFT Pipeline Generator | How are stage partitions, local units, boundaries, measured search, and runtime dispatch separated? |
| Candidate Implementations | Which processing units and kernel forms are implemented or planned? |
| Getting Started | How is the project built and used? |
| Programming Guide | How do plans, layouts, streams, workspaces, devices, concurrency, and determinism compose? |
| C Plan API | What is the professional C integration and selection contract? |
| General Shape Mapping | How do non-power-of-two and rank-two lowerings preserve operator semantics? |
| C++ API Reference | What is the contract of each installed public API type and member? |
| Error Handling | How are validation, backend, CUDA launch, and asynchronous failures reported? |
| Capability and Compatibility Matrix | Which public semantics, optional builds, and runtime integrations are supported? |
| Operator Catalog | Which local pair updates are implemented and how do they share the architecture mapping? |
| Examples | Which build-checked program demonstrates each primary API path? |
| Device API | How are plans, caller-owned CUDA memory, streams, and workspaces composed in an application? |
| Runtime Mapping Selector | How does a semantic workload resolve to a measured V100 mapping and an auditable decision? |
| Experimental Results | Which experiment tests each architecture claim, what has been measured, and where are the gaps? |
| Single-GPU Comprehensive Benchmark | How are lengths, precision, semantics, implementations, and external baselines compared together? |
| V100 Comprehensive Results | What does the controlled full-suite comparison currently establish? |
| V100 Length/Batch Scaling | How do saturation and the best mapping change when length and batch are swept independently? |
| V100 Mapping Selector | How accurately can the measured V100 mappings be selected with a held-out shape? |
| V100 Counter Attribution | Which hardware services explain the observed saturation and mapping crossovers? |
| Structured 2x2 V100 Results | Does a parameterized dense pair unit preserve the mapping methodology across precision and length? |
| V100 External Baselines | What do matching-protocol Dao FHT and GPU-NTT comparisons establish? |
| V100 Library/Base/Search Comparison | How much comes from search, and where does the selected point stand against specialized libraries? |
| V100 Research Status | Which claims are closed, what are the current performance boundaries, and what remains? |
| General-Shape V100 Selection Results | How much do composition and physical-core selection recover, and which boundaries remain? |
| v0.6 Implementation Status | What is implemented, validated, selected by default, retained only as a candidate, or deferred? |
| v0.3.0 Mapping-Selection Milestone | Which falsifiable goal, execution order, and definition of done shaped this release? |
| Numeric-Regime Mapping Study | How are precision, arithmetic, length, batch, and core choice related to resource cliffs, and what did the first quick screen establish? |
| Reproducibility | How are sweeps, external baselines, and profiler data reproduced? |
| Research Positioning | What is the intended contribution relative to prior work? |
Repository maintenance and research priorities are documented in
CONTRIBUTING.md and ROADMAP.md.
- Hybrid2D GPU Mapping: Cooley-Tukey/NTT factorization and current CUDA realization.
- Processing-Unit Design Space: local arithmetic, coefficient, radix, and exchange choices.
- Generated Processing Units: build-time specialization for register DFT8, CTA DFT8, WMMA, register FWHT, and register-resident Structured 2x2.
- Processing-Core Integration: boundary between an imported codelet and a complete external library.
- Feature Coverage: implemented semantic and backend matrix.
- V100 Numeric-Regime Mapping Study
- V100 Numeric Boundary NCU Attribution
- V100 Numeric Piecewise Selector
- V100 Library/Base/Search Comparison
- V100 Comprehensive Results
- V100 Length/Batch Scaling
- V100 Mapping Selector
- V100 Counter Attribution
- V100 Matching-Protocol External Baselines
- V100 Initial NTT Results
- V100 NTT Parameter Matrix
- GPU-NTT Gap Analysis
- Cross-Operator Results
- Structured 2x2 V100 Results
- Structured 2x2 Counter Attribution
- Large-Length Results
- CTA DFT8 Space-Time Mapping
- FFT Library Comparison
- Nsight Compute Profiling
- Cross-GPU Experiment Matrix
Every performance statement should be read under one of these labels:
| Label | Meaning |
|---|---|
| measured | Produced on the stated machine using a checked-in command and raw record |
| derived | Computed from measured counters or timing using a stated equation |
| external | Same-machine result from a pinned third-party implementation |
| placeholder | Capture schema only; no performance value is claimed |
V100 is the only complete measured hardware profile in this revision.