Module pipeline

Module pipeline 

Source
Expand description

2026-10-02: The numeric pipeline of a node: the formats it reads, the ordered steps inside it (activation and weight preparation, the multiply’s operands, accumulation, scale application, element-wise compute, cache and state precision, routing and blending) each with its precision, and the formats it writes. One pipeline is REQUIRED per node of a plan (require: the circuit’s formats under the serving policy) and one is DECLARED per kernel family, point or kernel in KERNEL_FAMILIES.toml (declare); check refuses a plan whose kernels declare anything but exactly what the plan requires.

Owner: metrale-circuit (pipeline). Invariants:

  • The step vocabulary of every op is one table (vocab::steps_of); a pipeline names every step of its op’s vocabulary in that order, and nothing else.
  • Every value has one canonical spelling that parses back to itself (Value::parse(k, v.name()) == Ok(v)), so the golden plans and the manifests read one text per value.
  • Nothing defaults: a step whose precision cannot be stated is an error, never a guess.
  • Precision is about values, not instructions: a BF16 activation held in an FP32 register is BF16, an E4M3 weight widened exactly is the precision it widens to; which unit and atom carry the multiply is the compute unit’s (venn::compute).

Re-exports§

pub use check::PlanPipelines;
pub use check::check_plan;
pub use require::Need;
pub use require::required;

Modules§

check
2026-10-02: The check a plan must pass: for every node of every group, the pipeline the group’s kernel family declares for it (super::declare) equals the pipeline the plan requires of it (super::require), inputs, every step and outputs alike. A fused group composes its nodes’ pipelines: each member’s outputs are handed to the next member in the format the kernel declares, which must be the format the plan stores or the rule states it holds, so a fused edge cannot change format silently.
declare
2026-10-02: The DECLARED side: the pipeline each kernel family implements, as KERNEL_FAMILIES.toml states it (pipeline.<op>, per point [[family.point]] pipeline.<op>, per kernel kernel_pipeline."<kernel>".<op>), and its resolution for one node of one plan group.
query
2026-10-02: The “what we need” view (met circuit precision): the required pipeline of every planned node whose id matches a glob, with the rule and kernels that run it on the device.
require
2026-10-02: The REQUIRED pipeline of a node: what the circuit’s formats, under the serving policy and the plan’s stated routing, ask each step to compute at. This is the “what we need” view (met circuit precision) and the side every kernel declaration is checked against (super::check).
vocab
2026-10-02: The step vocabulary: which steps each op’s pipeline has, in order, and the shape and spelling of each step’s value. The one table every requirement, declaration and rendering reads.

Structs§

Mismatch
2026-10-02: One node whose kernel declares another pipeline than its plan requires.
NodePipeline
2026-10-02: A node’s pipeline: input formats in the node’s input order, the op’s steps in vocabulary order, output formats in the node’s output order.
Stated
2026-10-02: The parts of a pipeline a plan’s rule states rather than the reference: steps, and the inputs and outputs whose in-group hand-off format it states (holds). Rendered (rule).
Step
2026-10-02: One step and its value.

Enums§

Num
2026-10-02: The element precision of a value inside a kernel (registers, operands, sums).
PipelineError
2026-10-02: Why a pipeline could not be required, declared or matched.
StepKind
2026-10-02: A step of a node’s pipeline. Each has one value shape (vocab::shape_of).
Value
2026-10-02: A step’s value.

Functions§

differences
2026-10-02: What differs between a required and a declared pipeline, one entry per field (in[1], weight, out[0]), as field: required X, declared Y.
state_name
2026-10-02: The spelling of a state dtype (the circuit TOML’s, StateDtype::name).