matrix: fp16 persist + zero-copy import are no longer blanks (ork-driver#1) Regenerated from the source tree (make matrix). Two f16 cells flip, and the old 'by design' rationale was wrong in the direction this page warns about -- it explained a missing implementation as a design decision. fp16 weights are packed resident tiles like int8 ones and ork_w_dump was always dtype-agnostic, so only the read-back was absent. Also records that 'zero-copy import / adopt' now over-reports for f16 (and always did for i4): fp16 has the dma-buf import but not the daemon-routed adopt, because ORKD_IMPORT is int8-hardcoded end to end. The name-based classifier cannot split that row, which is the exact limitation the page's closing note already describes.
wiki: 7B prefill parity REPRODUCES (73.03 t/s, a config); refresh the capability matrix Exp-2026-07-28-7B-Prefill-Parity: add the 2026-08-03 reproduction banner. The 71.89 t/s reproduces at 73.03 on a clean boot with the current tree — the 2026-07-30 "not reproducible / bandwidth gap" revision was a wrong-config artifact (P=485 under sudo). The config that matters: P=256 (one full ubatch, avgM=256; P=485 splits into two and the partial second batch drops it to ~59) and the lean no-sudo 10.07 GiB layout (sudo forces 12.26 GiB and is slower). The ork@256-vs-rkllm@485 token-count caveat still stands. Precision-Capability-Matrix: regenerate against the current tree. Counts i8=167 f16=57 i4=63 i16=18 -> i8=179 f16=65 i4=62 i16=22, and drop the "run - single core / f16" dagger: it existed only because fp16's entry point was the untagged legacy ork_mm_run, and the dtype-first migration renamed it ork_f16_mm_run so the generator now matches it directly (the override row was retired in tools/precision_overrides.tsv on 2026-08-20). Table body now byte-matches `make matrix` and README.
wiki: matrix daggers now cite a symbol and are build-gated; drop the false i16 multicore claim Each shared-implementation dagger moved to tools/precision_overrides.tsv and must name the function doing the work; check_registry check 8 fails the build if it stops existing. That immediately removed a row this page asserted by hand: 'run — multicore / i16 — routed through the int8 chain' had no symbol behind it because no i16 multicore path exists. The only i16 x multicore thing in the tree is ORK_OP_MATMUL_I16OUT_I8 — an int8 matmul that EMITS int16, which belongs to the int8 row. Cell is now a blank, folded into the unmotivated-but-open group with async stream and bmm. Also records which drift direction stays unguarded (new sharing added with no row → silent under-report; no ground truth to diff a name-based classifier against) and why the fix for that is probe-anchoring rather than symbol renaming.
wiki: Precision Capability Matrix — what each dtype implements, and which blanks are real Generated table (tools/precision_matrix.sh, mirrored in README) plus the analysis the table cannot carry: sorting every blank into by-design vs genuinely-open. The headline is that the 167-vs-18 function gap between int8 and int16 is mostly not a hole. int4 has no SDP/activation rows because RK3588 is W8A8 or W4A4 symmetric and the SDP LUT op consumes int8/int16 — there is no int4 activation path to write. int16 is the ACTIVATION precision, not a weight-storage tier, so none of the pack/load/import machinery applies to it. fp16 weights are transient, so nothing to persist. Genuinely open, and small: fp16 HW chain and slice-and-dice, int4 resident-KV and M-fold, int16 async stream and bmm — each with a note on whether it is motivated. Also documents the matrix's one blind spot: it classifies by dtype token in the symbol name, so a shared implementation serving several precisions is invisible to it. Those are the OVERRIDES rows in the generator and must be added by hand — fp16's multicore path IS i8/colsplit.c, and counting it as int8 is part of why int8 looks so large.