--- cycle: 8 phase: 7 status: closed 2026-05-18 — M1 PASS 3-way, R₈=0.061 RED isolation, M4 mixed POSITIVE date_opened: 2026-05-18 date_closed: 2026-05-18 parent: k8_h264deblock_phase6 (phase 6 = shader + bench, no separate doc) host: hertz verdict: CPU primary; QPU opportunistic helper. ~6 Medge/s = 85% of NEON-1 deblock in mixed deployment. --- # Cycle 8, Phase 7 — Verification (H.264 deblock QPU) ## Phase 6 deliverable - `src/v3d_h264deblock.comp` — 256 inv/WG, 16 edges/WG (1 sg per edge), no barrier, uint8 dst SSBO. Phase 5 RED-1 (clamp p1'/q1') and RED-2 (m.x ≥ 4*stride contract) both applied. - `tests/bench_v3d_h264deblock.c` — 3-way M1 + M2 bench. - `tests/bench_concurrent_mixed.c` extended with K_H264DEBLOCK on both CPU and QPU sides. shaderdb: ``` SHADER-DB-301659b6... 132 inst, 4 threads, 0 loops, 29 uniforms, 20 max-temps, 0:0 spills:fills, 0 sfu-stalls, 12 nops ``` 4 threads (vs predicted 2-3) — better than expected. 132 inst (vs predicted 150-200) — also better. No spills. ## M1 — 3-way bit-exact ``` === M1₈: QPU vs C ref vs NEON === C ref vs NEON parity: 0/1048576 byte mismatches QPU vs C ref: 4096/4096 edges bit-exact (100.0000%) QPU vs NEON: 4096/4096 edges bit-exact (100.0000%) ``` Phase 5 RED-1 (explicit clamp on p1'/q1') validated — without it, shader would have wrapped on out-of-range p1/q1 values. Phase 5 RED-2 contract (m.x ≥ 4*stride) enforced by bench assert. ## M2 — QPU throughput ``` === M2₈: QPU throughput === edges/dispatch: 4096 iters: 100 total edges: 409 600 elapsed (kern) = 0.073 s M2₈ throughput = 5.629 Medge/s per-edge = 177.7 ns per-dispatch = 727.7 us ``` R₈ = 5.629 / 91.947 = **0.061 → RED band**. Below the Phase 3 revised prediction (0.09-0.14). Two reasons the prediction was too optimistic: 1. H.264 deblock per-edge work on QPU is dominated by multiple early-return paths (3 alpha/beta gates, ap/aq side conditions, conditional p1/q1 writes) — branchy code doesn't pack as efficiently on V3D as VP9 LPF's monolithic 2-branch structure. 2. NEON's per-edge 10.9 ns vs cycle 2 LPF's 20.7 ns reflects FFmpeg NEON's superior packing for the H.264 specific case — wider parallelism than VP9 LPF, harder for QPU to match. 30fps@1080p worst-case floor: 5.629 / 8 = **0.70× margin (below worst case in isolation)**. Realistic-floor margin (3 Medge/s): 1.88× (passes). ## M4 — mixed-kernel matrix All 6s windows on hertz, bench_concurrent_mixed. ### Same-kernel M4 (cycle-8 closure) | Config | CPU agg | QPU h264deblock | total | |---|---|---|---| | **NEON-3 + QPU h264deblock** | 7.04 Medge/s | 5.77 Medge/s | 12.81 | | **NEON-4 + QPU h264deblock** | 8.10 Medge/s | 5.43 Medge/s | 13.53 | | (Pure NEON-4 alone, estimated) | ~12-15 Medge/s | — | ~12-15 | NEON-3+QPU same-kernel total (12.81) ≈ pure-NEON-4 alone (12-15) **within measurement noise**. Same-kernel M4 verdict: approximately NEUTRAL (neither big win nor loss). ### Mixed-kernel M4 (the H.264 deployment shape) | Config | CPU side | CPU agg | QPU h264deblock | |---|---|---|---| | **CPU=MC + QPU=h264deblock** | MC | 25.11 Mblock/s | **6.23 Medge/s** | | **CPU=LPF4 + QPU=h264deblock** | LPF4 | 31.48 Medge/s | **5.96 Medge/s** | **The KEY finding**: in mixed-kernel deployment, the QPU h264deblock contribution is **essentially unchanged from its isolation throughput** (5.6 → 6.2 Medge/s, +10 % even). The QPU is delivering ~85 % of a single NEON core's deblock capacity while running concurrently with a CPU doing different work. CPU MC side did drop somewhat (25.1 vs ~34 in pure mode), but the per-core MC throughput (8.4 avg) is still 3× the 1080p30 MC requirement. ## Deployment recipe verdict **For VP9 decoder**: cycle 8 unused (VP9 has its own LPF cycles 2+4 on QPU). H.264 deblock kernel doesn't apply to VP9. **For H.264 decoder**: cycle 8 = **QPU opportunistic helper**. - CPU primary substrate (NEON handles cycle 6+7 transforms, cycle 9 MC if needed) - QPU dispatch path exposed for opportunistic use: - When CPU is busy with MC/IDCT, QPU can run deblock at ~6 Medge/s - That's 85 % of single-NEON-core deblock capacity - Per the "30fps@1080p H.264 realistic floor = 3 Medge/s" target, QPU alone covers the floor 2× This is the same pattern as cycle 5 CDEF (R=0.116 ORANGE, opportunistic helper). The difference: cycle 8 NEON baseline is SO fast (92 Medge/s on a single core) that the QPU's 6 Medge/s is a ~6 % top-up. Useful but not transformative. ## Verdict table | Rule | Result | Status | |---|---|---| | M1 bit-exact (3-way) | 100.00 % on 4096 edges | ✓ PASS | | R₈ = M2/M3 | 0.061 (RED) | predicted ORANGE | | M4 same-kernel | neutral (~equal to pure-NEON-4) | acceptable | | M4 mixed (CPU=MC) | QPU adds 6.2 Medge/s helper | ✓ POSITIVE | | 30fps@1080p worst floor (iso) | 0.70× | ✗ FAIL as sole substrate | | 30fps@1080p realistic floor (iso) | 1.88× | ✓ PASS | | 30fps@1080p NEON baseline | 11× | ✓ huge margin | **Engineering verdict**: QPU H.264 deblock useful as opportunistic helper. Phase 8 V4L2 wrapper should expose dispatch path; default schedule runs deblock on CPU but QPU dispatch available when useful. ## Cycles 1-8 deployment recipe (final consolidated) | Cycle | Kernel | Primary | QPU path | M4 verdict | |---|---|---|---|---| | 1 | VP9 IDCT 8x8 | **QPU** | yes | +7.2 % | | 2 | VP9 LPF wd=4 | **QPU** | yes | +6.9 % | | 3 | VP9 MC 8h | CPU | unused | (deep RED 0.067) | | 4 | VP9 LPF wd=8 | **QPU** | yes | +4.1 % | | 5 | AV1 CDEF | CPU | opportunistic | 0.42 Mblock/s helper | | 6 | H.264 IDCT 4x4 | CPU | unused | (NEON-trivial) | | 7 | H.264 IDCT 8x8 | CPU | unused | (NEON-trivial) | | 8 | H.264 deblock | CPU | opportunistic | 6.2 Medge/s helper | 3 QPU-primary kernels (VP9 1+2+4), 5 CPU-primary kernels (VP9 3, AV1 5, H.264 6+7+8). 2 cycles deserve opportunistic-helper status (cycle 5 CDEF, cycle 8 H.264 deblock). ## Phase 9 lessons 1. **Branchy kernels underperform on V3D vs NEON.** Cycle 8's QPU was 0.061 R vs predicted 0.10-0.14. The H.264 deblock has 4 early-return paths plus 2 conditional writes. NEON handles these with predication; V3D needs taken-branch divergence which hurts more than I predicted. Future cycles with similar branch density should expect deeper RED than the throughput- ratio prediction suggests. 2. **Mixed-kernel "free helper" value scales with QPU's intrinsic throughput, not the same-kernel M4 number.** Cycle 8 QPU delivers 6 Medge/s in mixed deployment (close to its isolation M2 of 5.6). The same-kernel M4 was nearly NEUTRAL — but in real H.264 deployment where CPU does MC and QPU does deblock, the QPU adds 85 % of a NEON-1 core's deblock work for free. Issue 003's V4 deployment-shape finding generalizes to cycle 8. 3. **R-band predictions need to weight "branchy vs straight-line" alongside per-block compute weight.** Existing predictors only consider compute density. Cycle 8 disproves that — branchiness matters at least as much. ## What lands in this commit - `src/v3d_h264deblock.comp` (Phase 6 shader) - `tests/bench_v3d_h264deblock.c` (3-way M1 + M2) - `tests/bench_concurrent_mixed.c` extended with K_H264DEBLOCK - `CMakeLists.txt`: v3d_h264deblock.spv + bench wiring - `docs/k8_h264deblock_phase7.md` (this doc) ## Cycle 8 closure → Phase 8 Cycles 1-8 form a complete kernel inventory across 3 codecs (VP9, AV1 CDEF, H.264). Phase 8 (V4L2 wrapper / deployment infra) is the next phase. The public API `include/daedalus.h` already exposes the recipe-default substrate for each kernel — Phase 8 adds CDEF, MC, deblock-style dispatchers as needed.