API Reference

Every op here is used the same way: construct it once, then call it. The constructor takes what the kernel is compiled with — tile sizes, dimensions treated as constants, dtypes — and the call takes the tensors. Both appear under each op as __init__ and forward, where forward is what runs when you write op(...).

import torch
from tileops.ops import GemmOp

op = GemmOp()                        # construct once, reuse
d = op(a, b)                         # the specialized kernel is built on first call

The pages are ordered along the stack a caller works through: the dense matmul first, then attention and its linear replacements, then the elementwise and reduction primitives, then FFT.

Page	What it covers
GEMM	dense matmul — plain, batched, and the fp8 variants
Attention	forward and backward attention, including the paged and decode kernels
Linear Attention	the linear-attention family: DeltaNet, GLA, KDA, and their kin
Mamba	the SSD scan, its decode step, and the chunked forms
MHC	multi-head compression
Normalization	RMSNorm, LayerNorm, GroupNorm, BatchNorm and the fused variants
Elementwise	unary and binary maps, activations, and the in-place forms
Reduction	sums, extrema, arg-reductions, cumulative scans, softmax
FFT	the discrete transform
Quantization	fp8 quantization — interface not yet stable
Top-k	top-k selection — interface not yet stable
Trace	the in-kernel timeline tracer, a tool rather than an op

Two things this reference does not carry:

• What each op is allowed to receive. The authoritative dtype domains, shape rules and measured workloads are in the op's spec; see Writing a Spec.
• How fast it is. Device time against the fastest alternative on each workload is on the Benchmarks pages.

These pages are generated from the docstrings in TileOPs, so an op whose docstring is thin reads thin here. The fix belongs upstream, in src/tileops/ops/.