#[non_exhaustive]pub enum AccessPattern {
Sequential,
Spatial,
}Expand description
The tile shape an op wants its input delivered in.
The scheduler negotiates tile shapes from this declaration (ADR-0003):
runs of Sequential ops move full-width strips, matching how codecs
produce and consume rows, while Spatial segments switch to square tiles
to bound redundant border work. A rolling line-cache is inserted at the
seam between the two. Declaring Spatial when Sequential would do
costs throughput; declaring Sequential when the op actually reads
neighbours is a correctness bug.
§Shape, not order
This says nothing about the order tiles are produced in. An op that
mirrors vertically reads no neighbours and wants full-width strips, so it
is Sequential — even though it consumes those strips bottom-up.
Order is not declared at all: the scheduler derives it from
Op::input_regions and inserts a materialization buffer only where a
non-forward demand sequence meets a forward-only source (ADR-0009). Keeping
order out of this enum is deliberate — it is a property of the seam
between an op and its upstream, not of the op, so the same op streams or
buffers depending on what it is connected to.
Variants (Non-exhaustive)§
This enum is marked as non-exhaustive
Sequential
Each output pixel depends on input pixels from a single row.
Wants full-width strips. Pointwise ops (modulate, flatten, channel
extraction) and row-preserving geometry remaps (crop, flop, flip)
are sequential — including flip, which reverses row order but still
reads one input row per output row.
Spatial
Output pixels depend on a neighbourhood spanning multiple input rows.
Wants square tiles. Convolution and resize with filter support are spatial.