Standalone experiment (Fable-directed): chaining a column's 32 row-tiles into
ONE drm_rocket_job (task_count>1) so only task 0 fetches the column's weights
DDR->CBUF and tasks 1..k reuse the SRAM-resident weights (CNA_CBUF_CON0_WEIGHT_
REUSE, gated on task_num>0) gives **4.33x** single-core (34->148 GFLOPS) and is
**bit-exact** vs the single-task path (0/65536 bytes differ). Confirms Fable's
diagnosis that the tiled matmul is DDR->CBUF weight-DMA bound (~130us/tile vs
~9us ideal-compute), not compute bound.
Integrated into rkt_npu_matmul: tiles are column-major, so a column's row tiles
are contiguous -> emit them as one multi-task job (rkt_g_task_num = 0..k-1,
chunked at RKT_MAXTASKS=32). Correctness re-verified (kscan all shapes, gemma4
pp512 clean). Neutral at current coverage (only the 2 largest bf16 ops offload,
already NPU-bound there); the 4.3x pays off once coverage is high (needs the
prepack buffer-type) and stacks with multi-fd 3-core.
NOTE: matching vendor (65 t/s) still needs the remaining pieces — Fable proved
single-fd caps at 2 NPU cores (DRM sched tie-break; core2 gets 0.2% of jobs) so
3 independent fds are required for 3-core (33/33/33, ~6.4x aggregate proven),
plus a prepack weight buffer-type for q8_0 coverage (CPU_REPACK blocks it) under
a hard 4GiB/fd IOVA budget (repacked E2B ~10.6GB -> must 3-way size-partition).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EWpfhDgYNA21tETDP9ueBE
mfritsche
412cba2601