Backend Kernel Groups #
GraphKernelPlan chooses a capsule for each runtime-relevant IR node. A GroupedKernelPlan places
adjacent choices with the same operation and complete capsule in one audit group, so a graph with
twenty consecutive ReLU nodes produces one audit row instead of twenty. Grouping does not translate
graph semantics, fuse operations, or claim that a group executes as one kernel launch.
One audit group, with source IR node ids retained for diagnostics.
- op : BackendOp
- capsule : KernelCapsule
Instances For
Instances For
Project the operation and capsule selected for this group.
Instances For
Whether a planned node can share this audit group without losing contract evidence.
Matching dispatch identities alone is insufficient: a caller can supply capsules with the same name, operation, provider, and device but different trust or numerical policies.
Instances For
Append a node to an existing group, preserving source-node provenance.
Instances For
Source IR node ids covered by the grouped plan, in graph order.
Instances For
Selected capsule names, in group order.
Instances For
Project groups to the capsule rows consumed by the contract check.
Instances For
Audit the selected backend boundaries of the grouped plan.
Instances For
Place one graph-planned node in its own group.
Instances For
Add one planned node, sharing the preceding group when the boundary is identical.
Instances For
Adjacent nodes with the same backend boundary share one audit group.