daedalus-fourier/docs/k2_deblock_phase3.md

cycle, phase, status, date_opened, date_closed, parent, host

cycle	phase	status	date_opened	date_closed	parent	host
2	3	closed 2026-05-18	2026-05-18	2026-05-18	k2_deblock_phase2.md	hertz (Pi 5, 8 GB, Debian Trixie, kernel 6.12.75+rpt-rpi-2712, Mesa 25.0.7-2+rpt4, V3D 7.1.7 @ 1 GHz, A76 @ 2.8 GHz)

Cycle 2, Phase 3 — NEON M3'' baseline

Per dev_process.md: real measurements, before any changes.

Raw

=== M1''_c: bit-exact correctness (10000 random edges) ===
M1''_c correctness: 10000 / 10000 edges bit-exact (100.0000%)

=== M3'': NEON throughput ===
M3'' NEON throughput:
  edges/batch:     65536
  batches done:    2009
  total edges:     131 661 824
  elapsed (kernel)=2.726785 s  (setup-subtracted)
  elapsed (setup) =2.273954 s
  throughput      = 48.285 Medge/s
  per-edge        = 20.7 ns
  equiv 1080p     = 748.3 FPS  (~64530 edges/frame, worst case)

Numbers

M1''_c (bit-exact)	100.0000 % vs daedalus_vp9_loop_filter_h_4_8_ref
M3'' (throughput)	48.285 Medge/s (single A76 core @ 2.8 GHz)
per-edge	20.7 ns
cycles/edge	20.7 ns × 2.8 GHz ≈ 58 cycles (~7 cycles per pixel-row)
1080p FPS-equivalent	748 FPS (worst-case 64 530 edges)

Comparison vs cycle-1 IDCT M3

	IDCT 8×8	LPF h_4_8	ratio
Per-unit (block / edge)	122.4 ns	20.7 ns	LPF 5.9× faster
1080p FPS-eq, single core	252 FPS	748 FPS	LPF 3.0×
Realistic CPU ceiling (4-core, bw-saturated from M4)	~7 Mblock/s	(not yet measured)	TBD

LPF is much lighter per-unit than IDCT — fewer ops, smaller working set per call. Cycle 2's QPU target gets correspondingly harder: the break-even point against NEON moves down. Predicted at Phase 4.

Setup overhead caveat

Notable: setup (memcpy of 65 536 × 64 B per batch = 4 MiB pred restore) is 45 % of total wall-clock. The subtraction step matters here more than for IDCT (where setup was ~9 %). Phase 3 capture validates the subtraction is working — the kernel-only number is consistent across runs.

Decision thresholds for the upcoming QPU kernel (M2'' / R'')

Per k2_deblock_phase1.md §"Decision rules", R'' = M2'' / M3'' bands:

R''	Verdict	Implication
≥ 1.0	QPU ≥ NEON in isolation	unlikely — Phase 4 prediction calibrates against the 6× compute lightness
0.5 ≤ R'' < 1.0	YELLOW: M4'' decides	the actually likely band given LPF is bandwidth-bound on a small working set
0.1 ≤ R'' < 0.5	ORANGE: M4'' may still rescue	run M4'' anyway per cycle-1 calibration
< 0.1	RED: structural	Phase 9 close cycle 2

Naive prediction for M2'': the IDCT cycle hit R = 0.92 because LPF's per-block compute is so much lighter than IDCT's. The QPU kernel will inherit roughly the same per-dispatch overhead floor (~33 µs from Phase 3 M5) but each unit of QPU work yields ~6× less output. Predicted R''_v1: 0.15–0.30 if the kernel is bandwidth/launch-bound, 0.5+ if computation is hidden under dispatch/sync. Phase 4 will sharpen this.

What's not in this number

• M3'' is single-core. Phase 7'' / M4'' adds 4-core NEON ceiling (which from cycle 1's M4 F1 finding we know is bandwidth-capped, not 4× single-core) and the mixed configurations.
• Edge content distribution: the bench biases toward fm-passing edges (different mean each side, small noise). Real bitstream distributions may flip the fm-pass rate. Phase 7 may revisit.
• The vertical variant (ff_vp9_loop_filter_v_4_8_neon) has different memory access; should be ~similar throughput but Phase 7 confirms.

Artifacts

• tests/vp9_lpf_ref.c — standalone C reference (clean transcription of vp9dsp_template.c:1780-1898, 4-tap inner only)
• tests/bench_neon_lpf.c — M1''_c + M3'' bench
• external/ffmpeg-snapshot/libavcodec/aarch64/vp9lpf_neon.S — vendored at FFmpeg n7.1.3 commit f46e514 (SHA-256 in PROVENANCE.md)
• CMakeLists.txt — adds bench_neon_lpf target with the LPF .S source built against the existing FFASM_FLAGS shim

Phase 4 next: plan the QPU LPF compute shader. The IDCT cycle's phase4.md is the template; constraints C1-C10 carry forward unchanged.