#1252's byte-exactness claim is gated by a test that compares the production path against the same seam, called from the test, on the same tier. That is a self-consistency check: it cannot observe a cross-tier value shift, because both sides move together. Its only cross-tier sensitivity comes from goldens at 1e-5 — a tolerance, not byte identity.
Found while closing #1252/#1259's aarch64 verification gap on thor (source 01ec21d67, 60-cell tier × thread sweep, all green).
The asymmetry
The sibling row does this correctly, which is what makes the gap visible:
| row |
byte-identity reference |
sees a cross-tier shift? |
#1259 Ltx2FuseLoraIntoTensor |
an in-test scalar reference (ScalarDeltaPlusWeight) |
yes — neon vs scalar byte equality is genuinely measured |
#1252 ltx2_text_encoder.cpp Linear |
vt::MatmulBT, called from the test, on the same tier |
no — both sides shift together |
So on aarch64, #1259's byte-exactness is directly gated and #1252's is not. Both pass everywhere today; the point is that one of them would keep passing if the kernel started returning different values on one tier.
Why this is worth fixing rather than noting
vt::MatmulBT is a dispatched seam whose selected kernel varies by architecture and by VT_CPU_MATMUL_TIER. A gate built from the same dispatch is structurally unable to detect the failure it is there for. The 1e-5 golden tolerance is a real check, but it is 2-3 orders of magnitude looser than the byte-identity the row's own spec and PR body claim, and the claim is what a reader will rely on.
This is a general shape, not a one-off: a gate that compares a shared helper against itself proves consistency, never correctness.
Suggested fix
Mirror #1259: add a small in-test scalar reference for the projection and assert byte equality against it, so neon-vs-scalar and avx2-vs-scalar are measured rather than assumed. The shapes involved are small enough that a scalar reference costs nothing, and #1259's ScalarDeltaPlusWeight is a working template.
Cheap and worth doing at the same time: keep the tier assertion honest by confirming which kernel was actually selected, the way test_ops_matmul_elem does — that is what proved the aarch64 sweep covered three distinct kernels rather than running one kernel four times.
Not claimed
No defect is observed. Every tier and thread count passes on both x86 and aarch64, and the numbers match exactly. This is a gate strength issue: the test cannot fail in the way its own claim asserts it can.
Also still unmeasured, separately: GB10 (sm_121a) and Orin. Both route through the same two aarch64 kernel paths that ran clean on Thor, but that is inference rather than measurement.
#1252's byte-exactness claim is gated by a test that compares the production path against the same seam, called from the test, on the same tier. That is a self-consistency check: it cannot observe a cross-tier value shift, because both sides move together. Its only cross-tier sensitivity comes from goldens at 1e-5 — a tolerance, not byte identity.
Found while closing #1252/#1259's aarch64 verification gap on
thor(source01ec21d67, 60-cell tier × thread sweep, all green).The asymmetry
The sibling row does this correctly, which is what makes the gap visible:
Ltx2FuseLoraIntoTensorScalarDeltaPlusWeight)neonvs scalar byte equality is genuinely measuredltx2_text_encoder.cppLinearvt::MatmulBT, called from the test, on the same tierSo on aarch64, #1259's byte-exactness is directly gated and #1252's is not. Both pass everywhere today; the point is that one of them would keep passing if the kernel started returning different values on one tier.
Why this is worth fixing rather than noting
vt::MatmulBTis a dispatched seam whose selected kernel varies by architecture and byVT_CPU_MATMUL_TIER. A gate built from the same dispatch is structurally unable to detect the failure it is there for. The 1e-5 golden tolerance is a real check, but it is 2-3 orders of magnitude looser than the byte-identity the row's own spec and PR body claim, and the claim is what a reader will rely on.This is a general shape, not a one-off: a gate that compares a shared helper against itself proves consistency, never correctness.
Suggested fix
Mirror #1259: add a small in-test scalar reference for the projection and assert byte equality against it, so
neon-vs-scalar andavx2-vs-scalar are measured rather than assumed. The shapes involved are small enough that a scalar reference costs nothing, and #1259'sScalarDeltaPlusWeightis a working template.Cheap and worth doing at the same time: keep the tier assertion honest by confirming which kernel was actually selected, the way
test_ops_matmul_elemdoes — that is what proved the aarch64 sweep covered three distinct kernels rather than running one kernel four times.Not claimed
No defect is observed. Every tier and thread count passes on both x86 and aarch64, and the numbers match exactly. This is a gate strength issue: the test cannot fail in the way its own claim asserts it can.
Also still unmeasured, separately: GB10 (
sm_121a) and Orin. Both route through the same two aarch64 kernel paths that ran clean on Thor, but that is inference rather than measurement.