---
cycle: 5
phase: 7
status: closed 2026-05-18 — M1 PASS, R₅=0.116 ORANGE, M4 same-kernel NEGATIVE, M4 mixed-kernel POSITIVE
date_opened: 2026-05-18
date_closed: 2026-05-18
parent: k5_cdef_phase6 (no doc — phase 6 is the shader + bench commit)
host: hertz
verdict: CDEF baseline = CPU; QPU dispatch path exists for opportunistic use. Better than predicted (ORANGE not RED).
---

# Cycle 5, Phase 7 — Verification (CDEF on V3D)

## Phase 6 deliverable

- `src/v3d_cdef.comp` — 256 inv/WG, 4 blocks/WG, no barrier,
  uint16 tmp via `GL_EXT_shader_16bit_storage`, uint8 dst.
- `tests/bench_v3d_cdef.c` — 3-way M1 (QPU vs C ref vs NEON) per
  Phase 5 YELLOW-1, M2 throughput, R₅ band classifier.
- `tests/bench_concurrent_mixed.c` extended with K_CDEF on both
  CPU and QPU sides for M4.

shaderdb:
```
SHADER-DB-4a79c02a... 387 inst, 2 threads, 0 loops, 133 uniforms,
  21 max-temps, 0:0 spills:fills, 0 sfu-stalls, 5 nops
```

2 threads (not 4 as plan hoped) — register pressure same as
cycle 3 MC. 133 uniforms under the 144 gate. No spills.

## M1 — 3-way bit-exact

```
=== M1₅: QPU vs C-ref vs NEON 3-way ===
  C ref vs NEON parity check: 0/4096 mismatches
  QPU vs C ref: 4096 / 4096 blocks bit-exact (100.0000%)
  QPU vs NEON:  4096 / 4096 blocks bit-exact (100.0000%)
```

All three implementations agree. Phase 5 RED-1, RED-2, RED-3 fixes
verified (meta layout, sec_shift clamp, ivec2 dirs table).

## M2 — QPU throughput

```
=== M2₅: QPU throughput ===
  blocks/dispatch: 4096
  iters:           50
  total blocks:    204 800
  elapsed (kernel)=0.462 s
  M2₅ throughput  = 0.443 Mblock/s
  per-block       = 2256.1 ns
  per-dispatch    = 9241.0 us
```

R₅ = 0.443 / 3.809 = **0.116 → ORANGE band**.

**Better than predicted** (Phase 4 estimated R₅ = 0.02-0.05, deep
RED). The prediction was extrapolated from cycle 3 MC's R₃ = 0.067
× scaling for higher per-block compute weight. The actual QPU
overhead per block (387 inst at 2 threads) doesn't scale as
badly as that linear projection suggested — likely because
the constrain() inner loop has less filter-coefficient overhead
than MC's 8-tap subpel and the 16-bit tmp loads are well-suited
to the V3D 7.1 storage path.

30fps@1080p floor: 0.443 / 0.972 = **0.46× margin (isolation)**.
**Below the user-facing floor as sole substrate.** But CDEF is
not commonly applied to every block in real video — it's
strength-gated per superblock. Effective CDEF rate in real
content is often < 0.5 Mblock/s. Within reach.

## M4 — concurrent matrix

All windows 6 s, hertz, `bench_concurrent_mixed`.

### M4 same-kernel (cycle 5 closure)

| Config | CPU CDEF agg | QPU CDEF | total | per-core CPU |
|---|---|---|---|---|
| **NEON-3 + QPU** | 8.080 | 0.381 | 8.461 | 2.69 avg |
| **NEON-4 + QPU** | 7.866 | 0.385 | 8.251 | 1.97 avg |

NEON-3 + QPU > NEON-4 + QPU (8.46 > 8.25). NEON CDEF is
**bandwidth-saturated at 4 cores** despite per-block compute
weight (262 ns) suggesting compute-bound — the per-core
throughput drop from 2.69 (NEON-3) to 1.97 (NEON-4) confirms it.
Same pattern as cycle 1 IDCT and cycle 2 LPF.

Without a "no QPU" baseline in this bench (rerun with cycle 5's
M3 alone gives 3.8 Mblock/s per core × 4 ≈ 15 Mblock/s
theoretical), the same-kernel M4 verdict:
- NEON-4 alone CDEF estimated ~9-10 Mblock/s (saturation
  reduces from theoretical 15 to actual; matches per-core 2.5
  trend)
- NEON-3 + QPU CDEF (8.46) is **below NEON-4 alone**
- Same-kernel M4: **NEGATIVE**

This matches the pessimistic same-kernel-bench framing
(`feedback_m4_same_kernel_worst_case.md`).

### M4 mixed-kernel (deployment shape)

| Config | CPU side | CPU agg | QPU CDEF |
|---|---|---|---|
| **NEON-3 MC + QPU CDEF** | MC | 34.17 Mblock/s | 0.424 Mblock/s |
| **NEON-3 LPF4 + QPU CDEF** | LPF4 | 31.48 Medge/s | 0.414 Mblock/s |

QPU CDEF contributes 0.41-0.42 Mblock/s while the CPU side runs
near-maximum throughput. Compare against Issue 003 V1/V2
NEON-fallback proxy (1.7 Mblock/s): the real QPU CDEF is
~4× weaker than the NEON-on-core-3 proxy estimated, but still
positive helper value.

CPU MC agg in this mixed config (34.17 Mblock/s) is **higher**
than CPU MC in Issue 003 V1 (24.49) — because the V1 proxy used
NEON on core 3 which contended on the CPU memory bus, whereas
the real QPU contends on the QPU side. Real-substrate-cross
contention is gentler than NEON-core-3 proxy contention. **Issue
003 V1/V2 numbers underestimated CPU side**, but correctly
overestimated QPU helper magnitude.

## Verdict

| Rule | Result | Status |
|---|---|---|
| M1 bit-exact (3-way) | 100.00% on 4096 blocks | ✓ PASS |
| R₅ = M2₅/M3₅ | 0.116 (ORANGE) | better than predicted |
| M4 same-kernel | NEGATIVE (8.46 < ~10) | ✗ FAIL gate |
| M4 mixed-kernel (CPU=MC) | +0.42 Mblock/s QPU helper | ✓ POSITIVE |
| 30fps@1080p floor (isolation) | 0.46× | ✗ FAIL as sole substrate |
| 30fps@1080p floor (CPU baseline) | 8.46 / 0.972 = 8.7× | ✓ PASS via CPU |

**Engineering verdict**: CDEF QPU offload viable as
**opportunistic helper**; CPU NEON remains primary substrate.
Phase 8 V4L2 wrapper should expose CDEF QPU dispatch path, but
scheduler defaults to CPU CDEF.

**Surprise (positive)**: cycle 5 came in better than predicted
(ORANGE not RED). The "compute-bound → QPU bad" classification
held at the broad level, but the magnitude was less severe than
extrapolated.

## Deployment recipe update

| Cycle | Kernel | Primary | QPU dispatch path | Verdict |
|---|---|---|---|---|
| 1 IDCT 8×8 | QPU | yes | M4 +7.2 % validated |
| 2 LPF wd=4 | QPU | yes | M4 +6.9 % validated; V4 confirmed |
| 3 MC 8h    | CPU | exists, unused | QPU MC = 0.39 Mblock/s under any contention |
| 4 LPF wd=8 | QPU | yes | M4 +4.1 % validated |
| 5 CDEF     | CPU | exists, opportunistic | QPU CDEF = 0.42 Mblock/s mixed, ~half-floor on its own |

## Phase 9 lessons

1. **Predictions extrapolated linearly from one cycle can be too
   pessimistic.** Cycle 3 MC R₃ = 0.067 extrapolated → R₅ = 0.02-0.05
   predicted; actual R₅ = 0.116. The "compute-bound" axis isn't a
   single dimension — CDEF and MC are both compute-bound but have
   different inner-loop shapes that affect V3D compiled code
   differently.

2. **CDEF is bandwidth-bound on NEON despite high per-block ns.**
   Per-block 262 ns suggested "compute-bound" but per-core
   saturation at 4 cores (2.5 → 2.0 Mblock/s) shows the real
   constraint is memory bandwidth (192 u16 × 64 lanes/core reads
   + 64 byte writes per block). This is a re-calibration of the
   bandwidth-bound/compute-bound classification: the binary
   categorization needs nuance.

3. **Real-substrate-cross contention is gentler than same-side
   NEON proxy.** Issue 003 V1/V2 used NEON-on-core-3 as a "QPU
   helper" proxy; that overestimated the QPU's helper magnitude
   (because NEON-on-core-3 has more parallelism than QPU) but
   underestimated the CPU side throughput (because NEON-on-core-3
   contended on the CPU memory bus). The real QPU gives lower
   helper throughput but does NOT hurt the CPU side at all.

4. **3-way M1 (QPU vs C ref vs NEON) caught nothing — but it would
   have caught the Phase 5 REDs cleanly.** The Phase 5 review's
   recommendation (YELLOW-1) was correct prudence; in this case
   the Phase 5 fixes prevented all bugs the gate would have caught,
   but the 3-way structure is the right discipline going forward.

## What lands in this commit

- `src/v3d_cdef.comp` (Phase 6 shader, 387 inst, 2 threads)
- `tests/bench_v3d_cdef.c` (3-way M1, M2, R₅ classifier)
- `tests/bench_concurrent_mixed.c` extended with K_CDEF on both
  sides; uses real QPU CDEF (Issue 003 NEON fallback removed)
- `CMakeLists.txt`: build wiring for v3d_cdef.spv + bench_v3d_cdef
- `docs/k5_cdef_phase7.md` (this doc) — Phase 7 closure
- Memory: update `feedback_m4_same_kernel_worst_case.md` with
  cycle 5 real-QPU numbers (Issue 003 V1/V2 fallback proxy
  obsolete).