daedalus-fourier/docs/issues/002-lpf-vertical-variants.md

Issue 002 — VP9 LPF vertical variants (v_4_8 / v_8_8)

Status: open, not blocking Type: kernel-cycle (cycle 5/6 candidate) Predicted verdict: similar to horizontal cousins (k2/k4 = YELLOW PASS) Priority: low (different memory pattern; completeness) Filed: 2026-05-18

Background

Cycles 2 and 4 implemented the horizontal-direction LPF inner filters (h_4_8, h_8_8). The corresponding vertical-direction filters (v_4_8, v_8_8) have the same arithmetic but a different memory access pattern: column-strided reads of 8 pixels (one per row) vs row-strided reads of 8 pixels (one per column).

Concretely from vp9dsp_template.c:

• h_*_*_neon: stridea=stride, strideb=1 (advance rows, neighborhood in cols)
• v_*_*_neon: stridea=1, strideb=stride (advance cols, neighborhood in rows)

The vertical variant tests whether the QPU's "8 lanes per row, contiguous read" assumption (cycles 2/4 wd=4/wd=8) generalises to the strided memory pattern. The TMU's coalescing behaviour may differ significantly when 8 lanes need to load from 8 different rows of the same column (cache-line-miss-y) vs 8 different cols of the same row (sequential).

What to do

Cycle 5 or 6 (after CDEF), one cycle per variant:

1. v_4_8 — vertical 4-tap inner, 8-pixel edge (vertical edge, filter spans rows above/below).
2. Optional v_8_8 — vertical 8-tap inner.

Each cycle: same shape as cycle 2/4 but

• C reference: same loop_filter function, instantiated via lf_8_fn(v, 4, 1, stride) (note: stridea + strideb swapped).
• NEON: ff_vp9_loop_filter_v_4_8_neon (in vendored vp9lpf_neon.S).
• QPU geometry: same 32-edges/WG, but per-edge memory access shape changes — lanes now span 8 rows (strided by stride) of one column.

Key question to answer

Does the QPU's mixed-mode +6.9 % win (cycle 2 wd=4 horizontal) hold for the vertical variant? The TMU latency / cache behaviour on column-strided reads is the main unknown. If positive: deployment recipe gains v variants symmetrically. If negative: deployment recipe needs to split by orientation (h on QPU, v on CPU).

Expected outcome

Quantity	Predicted
M1 bit-exact	100 %
M3 NEON	similar to h (NEON handles both orientations well)
M2 QPU isolation	possibly LOWER than h variant (TMU column reads less coalesced)
R isolation	0.30-0.45 (ORANGE)
M4 mixed	UNKNOWN — this is the load-bearing experiment

Acceptance criteria

• v_4_8 cycle 1-7 complete with M4 measurement
• Decision: "v variants → QPU same as h" OR "v variants → CPU only"
• Deployment recipe updated
• Optional: v_8_8 follow-on cycle if v_4_8 was positive

Why deferred

• Out of cycle 4's compressed scope (cycle 4 was a focused wd=4 → wd=8 extension)
• User-stated cycle 5 direction was CDEF (AV1 coverage), not VP9 variant completeness

Related

• docs/k2_deblock_phase4.md §"3. Workgroup geometry" discusses the 32-edges-per-WG mapping that needs revisiting for v variant
• external/ffmpeg-snapshot/libavcodec/aarch64/vp9lpf_neon.S — NEON refs already vendored for both v_4_8 and v_8_8
• phase0.md §2 device profile — TMU read patterns relevant for the column-strided question