Cycle 3 (MC interpolation) closure: M1'''=100%, R'''=0.067 RED, M4=-19.5%

Third daedalus-fourier kernel — VP9 8-tap regular subpel filter,
horizontal direction, 8-wide output. Multiply-heavy by design to
stress V3D's no-DP4A deficit. Full cycle Phase 1-7 + M4'''.

Phase 5''' second-model review delivered cleanly — caught 1 RED
bug pre-implementation (src_off off-by-3 indexing convention) and
2 YELLOW gaps (assert MUST language, shaderdb filter-LUT gate).
Without the review, M1''' would have failed silently on first run
with cryptic "high-index source pixels wrong" symptoms.

Phase 6 v1 first-light: M1''' 100.0000% bit-exact (65536/65536
blocks across all 16 mx phases). Phase 5''' filter-LUT prediction
materialised exactly: 197 uniforms (gate was 144), 2 threads (down
from cycle-2's 4 due to register pressure).

Performance:

  M2''' = 1.413 Mblock/s     (707.9 ns/block)
  M3''' = 20.997 Mblock/s    (NEON baseline phase3)
  R'''  = 0.067              (RED band — structural mismatch)
  shaderdb: 488 inst, 2 threads, 197 uniforms, 25 max-temps, 0 spills

M4''' concurrent matrix (8s windows):

  NEON 1-core           14.479 Mblock/s
  NEON 4-core           15.248 Mblock/s   <- baseline (compute-bound,
                                              not bandwidth-saturated
                                              like cycles 1+2!)
  QPU only               1.380 Mblock/s
  MIXED NEON-3 + QPU    12.277 Mblock/s   <- -19.5% (FAIL gate)
  MIXED NEON-4 + QPU    12.158 Mblock/s   <- -20.3%

NEW cross-cycle finding (Phase 9 lesson 2): compute-bound CPU
workloads make the QPU-offload story collapse. Cycles 1+2 were
bandwidth-saturated (4-core scaling 0.56-0.82x of 1-core), so
freeing a CPU core via QPU offload added throughput. Cycle 3 MC
is compute-bound (4-core scaling 1.05x of 1-core — near-linear),
no free cycles to free. QPU contribution (0.45 Mblock/s in
contention) doesn't compensate for losing 1 NEON core delivering
~3.8 Mblock/s.

But 30fps@1080p floor: PASS in every config (1.4x to 15.7x
isolation margin). Per project_30fps_floor_is_fine.md, user-facing
test never fails — daily YouTube playback works fine on any CPU/QPU
split.

DEPLOYMENT RECIPE for higgs (cycle 3 confirmed split):

  IDCT (k1)  -> QPU   (R=0.92, +7% mixed, frees CPU core)
  LPF  (k2)  -> QPU   (R=0.41, +7% mixed, frees CPU core)
  MC   (k3)  -> CPU   (R=0.067, -19.5% mixed — stays on CPU)
  Entropy    -> CPU   (structurally serial)

Mixed-substrate deployment, not "QPU does everything". Realistic for
higgs: entropy + MC on 2-3 ARM cores; IDCT + LPF dispatched to QPU
concurrently; 1-2 ARM cores left for vscode etc.

New artifacts:
- src/v3d_mc_8h.comp               — GLSL kernel
- tests/vp9_mc_ref.c               — standalone C ref (REGULAR filter
                                     embedded; clean transcription)
- tests/bench_neon_mc.c            — M1'''_c + M3''' bench
- tests/bench_v3d_mc.c             — M1''' + M2''' bench with contract
                                     asserts + 30fps margin display
- tests/bench_concurrent_mc.c      — M4''' pthread bench
- external/ffmpeg-snapshot/libavcodec/aarch64/vp9mc_neon.S    (vendored)
- external/ffmpeg-snapshot/libavcodec/vp9_subpel_filters_table.c
                                     (hand-extracted; provides
                                      ff_vp9_subpel_filters symbol
                                      without dragging in full vp9dsp.c)
- docs/k3_mc_phase{1,2,3,4,5,7}.md — full cycle documentation

Memory updates: project_30fps_floor_is_fine.md (user's 30fps target
recalibration), MEMORY.md index updated.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-05-18 12:51:43 +00:00
parent 36eca40ff2
commit 356e446a49
15 changed files with 2545 additions and 1 deletions
+104
View File
@@ -0,0 +1,104 @@
---
cycle: 3
phase: 1
status: open
date_opened: 2026-05-18
parent_cycle: k2_deblock_phase7.md (cycle 2 closed YELLOW-via-M4'' PASS)
target_kernel: VP9 8-tap MC interpolation, regular filter, horizontal, 8×N block
dev_host: hertz
---
# Cycle 3, Phase 1 — MC interpolation kernel goal
Per `k2_deblock_phase7.md` verdict (project continues). MC interpolation
chosen because: most-common per-frame work in real bitstreams (every
inter block); multiply-heavy → stresses V3D SMUL24 / lack of DP4A
directly; VP9+AV1 both use the same 8-tap structure.
## Kernel under test
**VP9 8-tap regular subpel filter, horizontal direction, 8×N block,
"put" (non-averaging) mode.**
libavcodec symbol: `ff_vp9_put_8tap_regular_8h_neon` (and equivalents
for smooth/sharp filter types). C reference: `put_8tap_regular_8h_c`
from `libavcodec/vp9dsp_template.c` (instantiated via the
`filter_fn_1d(8, h, mx, regular, FILTER_8TAP_REGULAR, put)` macro
expansion).
I/O contract (per VP9 spec § 8.5.1 — subpel motion compensation):
```c
void put_8tap_regular_8h_c(uint8_t *dst, ptrdiff_t dst_stride,
const uint8_t *src, ptrdiff_t src_stride,
int h, int mx, int my);
```
- `dst` : destination block, written
- `dst_stride` : destination row stride
- `src` : source block, read (with -3..+4 column overhang for horizontal)
- `src_stride` : source row stride
- `h` : block height (typically 8 for 8×8)
- `mx` : x-axis subpel phase ∈ [0, 15]
- `my` : y-axis subpel phase (unused for horizontal-only filter)
Per output pixel:
```
out[r][c] = clip(sum_{k=0..7} filter[k] * src[r][c+k-3] + 64) >> 7
```
Filter coefficients: `ff_vp9_subpel_filters[FILTER_8TAP_REGULAR][mx][0..7]`
(int16, signed; 16 phases; sum to 128).
## Measurable success criteria (cycle-3 numbering)
| ID | Measurement | Gate |
|---|---|---|
| **M1'''** | Bit-exact match rate vs C reference, ≥10 000 random 8×8 blocks (all 16 mx phases sampled) | 100.0000 % |
| **M2'''** | QPU throughput in Mblock/s | recorded |
| **M3'''** | NEON `ff_vp9_put_8tap_regular_8h_neon` throughput, single-core | recorded |
| **M4'''** | MIXED NEON-3 + QPU vs pure NEON-4 (only if YELLOW band) | conditional |
Derived: **R''' = M2''' / M3'''**.
## Decision rules (same as cycle 1/2)
R''' bands and verdicts unchanged (see `phase1.md` and `k2_deblock_phase1.md`).
Cycle-2 calibration adjustment: ORANGE band (0.1 ≤ R''' < 0.5) is
no longer auto-close — run M4''' regardless.
Predicted R''' band: **0.40.8.**
- MC is more compute-bound than LPF (8 mults + 7 adds per output
pixel; 64 pixels per block → ~960 ops per block)
- Bandwidth-equivalent to LPF (per-block ~120 B read + 64 B write
≈ 184 B → similar 5-6 MB/frame at 32 400 blocks)
- V3D SMUL24 covers the 8b×8b → 16b mults without overflow
- But no DP4A means we lose the typical "4× INT8 speedup" CPUs get
via SDOT — V3D does these as scalar SMUL24
## Cycle 1+2 lessons baked in from start
Per `k2_deblock_phase7.md §"Phase 9 lessons"`:
1. WG=256, 2-per-subgroup adaptation, uint8_t SSBO, oob early-return,
NO chained ternary — these are the v1 defaults.
2. Phase 5 second-model review is mandatory.
3. R isolation is misleading; M4''' is the real gate.
4. Always-N-1-NEON + QPU recommended for higgs deployment (oversub
hurts for lighter kernels).
5. shaderdb at 4 threads / 0 spills = compiler delivered; further
optimisation must target algorithm, not compile shape.
## Phase 2 → Phase 3 hand-off
Phase 2 must:
- Vendor `libavcodec/aarch64/vp9mc_neon.S` from FFmpeg n7.1.3
(matches existing snapshot pin)
- Confirm `ff_vp9_subpel_filters` definition source
(`libavcodec/vp9dsp.c:32`, just the 16 × 8 REGULAR row needed)
- Pin the exact NEON symbol naming
Phase 3 must:
- Write standalone C ref (`tests/vp9_mc_ref.c`) with REGULAR filter
table embedded
- Write `tests/bench_neon_mc.c` (M1'''_c gate + M3''')
- Capture M3''' before any QPU work
+109
View File
@@ -0,0 +1,109 @@
---
cycle: 3
phase: 2
status: closed 2026-05-18
date_opened: 2026-05-18
parent: k3_mc_phase1.md
---
# Cycle 3, Phase 2 — MC situation analysis
## 1. C reference
- **Source**: `external/ffmpeg-snapshot/libavcodec/vp9dsp_template.c`
(already vendored from cycle 1).
- **Function**: `put_8tap_regular_8h_c` generated by
`filter_fn_1d(8, h, mx, regular, FILTER_8TAP_REGULAR, put)`
expands to call `do_8tap_1d_c` with `ds=1` (horizontal) and the
REGULAR filter bank.
- **Underlying primitive**: `do_8tap_1d_c` iterates `h` rows;
per row, iterates `w=8` columns; per column, computes the
`FILTER_8TAP` macro: `clip((sum_{k=0..7} F[k] * src[x+k-3]
+ 64) >> 7, 0, 255)`.
- **Spec**: VP9 specification § 8.5.1 (subpel motion compensation).
## 2. NEON reference
- **Source**: `external/ffmpeg-snapshot/libavcodec/aarch64/vp9mc_neon.S`
(vendored 2026-05-18, FFmpeg n7.1.3, SHA-256
`6b1d50f9821742584fdd47758057f810644aff3a008faaa774ff5b9cac4d1fef`).
- **Symbol**: `ff_vp9_put_regular8_h_neon` (note: filter type baked
into name, width=8 baked in, h-direction baked in)
- **Signature** (VP9 `vp9_mc_func` typedef):
```c
void ff_vp9_put_regular8_h_neon(uint8_t *dst, ptrdiff_t dst_stride,
const uint8_t *src, ptrdiff_t src_stride,
int h, int mx, int my);
```
Registers: `x0=dst, x1=dst_stride, x2=src, x3=src_stride, w4=h, w5=mx, w6=my`.
- **Dependencies**:
- `libavutil/aarch64/asm.S` ✓ (already vendored)
- `ff_vp9_subpel_filters[3][16][8]` symbol — provided by
`external/ffmpeg-snapshot/libavcodec/vp9_subpel_filters_table.c`
(hand-extracted from `libavcodec/vp9dsp.c` of the same n7.1.3
pin; copying just the constant data avoids dragging in the
rest of `vp9dsp.c` which would require linking the entire VP9
decoder).
## 3. Workload model
Per 8×8 block output:
- 8 multiplies × 8 columns × 8 rows = **512 multiplies**
- 7 additions × 8 columns × 8 rows = 448 additions
- 1 round (+64), 1 shift (>>7), 1 clip per pixel × 64 = 192 ops
- Total ~1150 integer ops per block
Per-block memory (horizontal-only filter, 8-pixel-wide output):
- Read: 8 rows × (8 output cols + 7 tap overhang) = 8 × 15 = **120 source bytes**
- Write: 8 rows × 8 cols = **64 dst bytes**
- Total: **~184 bytes / block**
Per 1080p frame (32 400 8×8 blocks, worst case all-MC):
- ~5.9 MB total memory traffic
- ~37 Mops compute
- At GPU 4 GB/s share: 1.48 ms / frame = 675 FPS = 21.9 Mblock/s
- At V3D 92 GFLOPS theoretical scalar (SMUL24 throughput ≈ FP MUL): 0.4 ms compute / frame = 2500 FPS theoretical → **compute is NOT the bottleneck** at this shape
So MC is **bandwidth-bound on the QPU**, similar to LPF cycle 2.
## 4. Per-row workload diversity (vs cycle 1+2)
| | IDCT (k1) | LPF (k2) | MC (k3) |
|---|---|---|---|
| Per-block math | Heavy butterflies (~60 ops/block via separable transform) | Light: 0-30 ops per edge × 8 rows | 8-tap convolution: 1150 ops per block |
| Per-block memory | ~320 B in + 64 B out | ~64 B in + ~24 B out per edge | 120 B in + 64 B out |
| Compute / memory ratio | High | Low (memory-bound, lots of skipping) | Medium (compute-rich but bandwidth-bound at GPU) |
| Conditional? | No (always-execute) | Yes (fm/hev divergence per row) | No (deterministic per pixel) |
| QPU mult intensity | Q14 16b×16b mults | Light (compares, small clips) | 16b×8b mults (filter × pixel) |
MC is interesting because it's **compute-rich AND bandwidth-bound** —
the closest match in workload shape to a real-world GPU compute kernel
the V3D was designed for (graphics filtering).
## 5. Constraints carried from cycle 1+2
Same V3D 7.1 device profile (vulkaninfo unchanged). The relevant
specifics for MC:
- No DP4A → 8-tap convolution must be 8 separate SMUL24 + ADDs
(the typical GPU "dot4" packing is not available)
- shaderInt16 = false → filter coefficients widened to int32 in
registers; the filter table itself can be a uint16-storage SSBO
- shaderInt8 = false → source pixels widened to int32 in registers
- 1024-byte (16 KiB / 16) shared mem per WG is ample for MC source
staging if useful (15 cols × 8 rows × 1 byte per block-row × 32
blocks per WG = 3 840 B per row); for v1 we skip shared-mem
staging and let TMU handle reads directly
## 6. What Phase 2 does *not* close
- Per-block (block_y, block_x) layout / meta format. Phase 4 picks.
Likely same shape as cycle 2 (uvec4 per block: dst_offset,
src_offset, mx, _pad).
- Filter table residency: as SSBO load every row, push-constants
per dispatch (different mx per dispatch), or constant baked into
shader (one filter per shader = 16 specialised shaders for the 16
mx phases). Phase 4 picks; v1 likely SSBO for simplicity.
- Vertical / "hv" / "avg" / 4-pixel / 16-pixel / 32-pixel / 64-pixel
variants — out of cycle 3 scope; cycle 4+ if needed.
Phase 3 next: build `tests/bench_neon_mc.c`, capture M3'''.
+77
View File
@@ -0,0 +1,77 @@
---
cycle: 3
phase: 3
status: closed 2026-05-18
date_opened: 2026-05-18
parent: k3_mc_phase2.md
host: hertz
---
# Cycle 3, Phase 3 — NEON M3''' baseline
## Raw
```
=== M1'''_c bit-exact (10000 random blocks) ===
M1'''_c correctness: 10000 / 10000 blocks bit-exact (100.0000%)
mx phase coverage: min=577 max=668 (16 phases sampled)
=== M3''' NEON throughput ===
M3''' NEON throughput:
blocks/batch: 65536
batches done: 939
total blocks: 61 538 304
elapsed (kernel)=2.930751 s
elapsed (setup) =2.075477 s
throughput = 20.997 Mblock/s
per-block = 47.6 ns
equiv 1080p = 648.1 FPS (32400 blocks/frame)
```
## Numbers
| | |
|---|---|
| **M1'''_c (bit-exact)** | **100.0000 %** vs `daedalus_vp9_put_regular_8h_ref` |
| mx coverage | all 16 phases sampled, uniformly within ±10 % of expected count |
| **M3''' (throughput)** | **20.997 Mblock/s** single-core |
| per-block | 47.6 ns |
| cycles/block | 47.6 ns × 2.8 GHz ≈ 133 cycles |
| 1080p FPS-eq | 648 FPS |
## Comparison across cycles
| | IDCT (k1) | LPF (k2) | MC (k3) |
|---|---|---|---|
| Per-unit ns (NEON) | 122 | 20.7 (per edge) | 47.6 |
| 1080p FPS-eq | 252 | 748 (worst edges) | 648 |
| Compute character | Q14 butterflies + transpose | abs+compare+small mults | 8-tap convolution, mult-heavy |
| NEON win | SMLA + transpose | SMULL + saturate | SDOT-style packing |
MC NEON is fast — at ~2.6× IDCT throughput per unit. The A76's SDOT
or SMULL-pair pattern handles 8-tap convolution extremely well; this
is precisely the workload NEON SIMD was built for. **The QPU's
break-even point on cycle 3 is correspondingly tight.**
## Predictions for M2''' / R'''
V3D 7.1 has SMUL24 (8b×8b → 16b sufficient) but **no DP4A**, so the
QPU must do 8 separate SMULL + ADD per output pixel. Bandwidth-wise
MC is similar to LPF (~6 MB / 1080p frame). Compute-wise much heavier
than LPF.
- Compute-envelope (idealised): 32 400 blocks × 1 150 ops = 37 Mops
per frame. At v3d 92 GFLOPS theoretical × 23 % util ≈ 21 GOPS
effective → 1.8 ms / frame → 540 FPS → 17.5 Mblock/s
- Bandwidth-envelope: 5.9 MB/frame ÷ 4 GB/s ≈ 1.48 ms/frame → 22 Mblock/s
- Combined: min(compute, bandwidth) ≈ 17.5 Mblock/s
**Predicted R''' = 17.5 / 21.0 ≈ 0.83** isolation. Likely YELLOW
band by a small margin.
Honest lower bound: if SMUL24-vs-DP4A penalty is bigger than
estimated (CPU SDOT does 4 INT8 MACs in one instruction; the QPU
needs 4× more cycles for the same work in the worst case), R'''
could land near 0.5-0.6. Phase 7''' measures.
Phase 4 next.
+207
View File
@@ -0,0 +1,207 @@
---
cycle: 3
phase: 4
status: open (awaiting Phase 5''' review)
date_opened: 2026-05-18
parent: k3_mc_phase3.md
template: phase4.md (cycle 1) + k2_deblock_phase4.md (cycle 2) — same constraints, same patterns
---
# Cycle 3, Phase 4 — Plan QPU MC kernel
Compact plan. Cycle 1+2 phase4 docs cover the constraint matrix
(C1-C10) and the dev-discipline patterns. Phase 4''' references
them rather than re-deriving.
## 1. Constraints (carried)
Same V3D 7.1 device. New for MC specifically:
- SMUL24 covers 16-bit filter × 8-bit pixel mults (max ~32K product, fits)
- Sum of 8 products fits in int32 trivially
- No DP4A — must use 8 separate scalar muls per output pixel
- 16 filter phases × 8 taps × 2 B = 256 B — too big for push constants
(max 128 B), small enough for one const array in shader
## 2. Workload model
Per 8×8 block:
- 512 SMUL24 (8 mults × 64 output pixels)
- 448 ADD (7 adds × 64 output pixels)
- 64 round (+64 → >>7) operations
- 64 clip-to-[0,255]
- ≈ 1150 ALU ops per block
- 120 B read + 64 B write = 184 B per block
Per 1080p frame (32 400 blocks):
- ~37 Mops compute → 1.8 ms at v3d 23 % sustained (compute-bound estimate)
- ~5.9 MB traffic → 1.48 ms at 4 GB/s GPU share (bandwidth-bound estimate)
## 3. Workgroup geometry
Bake in the v4 lesson and the cycle-2 single-WG-size-from-start:
- `local_size_x = 256` (16 subgroups × 16 lanes)
- 8 lanes per block (1 lane per row r=0..7), 2 blocks per subgroup
- **32 blocks per WG**
- 1080p: 1 013 WGs
Same lane decomposition as cycle 2 LPF:
```
edge_slot = lane_in_sg >> 3 // 0 or 1 — "which block in this subgroup"
row = lane_in_sg & 7 // 0..7
block_local = sg_in_wg * 2 + edge_slot
block_idx = wg_id * 32 + block_local
oob = block_idx >= n_blocks
```
No barrier needed, no shared mem. Safe early-return on oob.
## 4. Per-thread algorithm
```glsl
if (block_idx >= pc.n_blocks) return;
uvec4 m = u_meta.meta[block_idx];
uint dst_off = m.x;
uint src_off = m.y;
uint mx = m.z & 15u;
// Read 15 source pixels for this row.
uint src_row_addr = src_off + row * pc.src_stride_u8;
int s0 = int(u_src.src[src_row_addr + 0u]);
int s1 = int(u_src.src[src_row_addr + 1u]);
int s2 = int(u_src.src[src_row_addr + 2u]);
int s3 = int(u_src.src[src_row_addr + 3u]);
int s4 = int(u_src.src[src_row_addr + 4u]);
int s5 = int(u_src.src[src_row_addr + 5u]);
int s6 = int(u_src.src[src_row_addr + 6u]);
int s7 = int(u_src.src[src_row_addr + 7u]);
int s8 = int(u_src.src[src_row_addr + 8u]);
int s9 = int(u_src.src[src_row_addr + 9u]);
int s10 = int(u_src.src[src_row_addr + 10u]);
int s11 = int(u_src.src[src_row_addr + 11u]);
int s12 = int(u_src.src[src_row_addr + 12u]);
int s13 = int(u_src.src[src_row_addr + 13u]);
int s14 = int(u_src.src[src_row_addr + 14u]);
// Filter coefficients — const REGULAR table, indexed by mx.
int F0 = FILTER_REGULAR[mx][0]; ... int F7 = FILTER_REGULAR[mx][7];
// 8 output pixels (each = 8-tap convolution of 8 consecutive source).
uint dst_row_addr = dst_off + row * pc.dst_stride_u8;
int o0 = F0*s0 + F1*s1 + F2*s2 + F3*s3 + F4*s4 + F5*s5 + F6*s6 + F7*s7;
int o1 = F0*s1 + F1*s2 + F2*s3 + F3*s4 + F4*s5 + F5*s6 + F6*s7 + F7*s8;
int o2 = F0*s2 + F1*s3 + F2*s4 + F3*s5 + F4*s6 + F5*s7 + F6*s8 + F7*s9;
int o3 = F0*s3 + F1*s4 + F2*s5 + F3*s6 + F4*s7 + F5*s8 + F6*s9 + F7*s10;
int o4 = F0*s4 + F1*s5 + F2*s6 + F3*s7 + F4*s8 + F5*s9 + F6*s10+ F7*s11;
int o5 = F0*s5 + F1*s6 + F2*s7 + F3*s8 + F4*s9 + F5*s10+ F6*s11+ F7*s12;
int o6 = F0*s6 + F1*s7 + F2*s8 + F3*s9 + F4*s10+ F5*s11+ F6*s12+ F7*s13;
int o7 = F0*s7 + F1*s8 + F2*s9 + F3*s10+ F4*s11+ F5*s12+ F6*s13+ F7*s14;
u_dst.dst[dst_row_addr + 0u] = uint8_t(clamp((o0 + 64) >> 7, 0, 255));
u_dst.dst[dst_row_addr + 1u] = uint8_t(clamp((o1 + 64) >> 7, 0, 255));
u_dst.dst[dst_row_addr + 2u] = uint8_t(clamp((o2 + 64) >> 7, 0, 255));
u_dst.dst[dst_row_addr + 3u] = uint8_t(clamp((o3 + 64) >> 7, 0, 255));
u_dst.dst[dst_row_addr + 4u] = uint8_t(clamp((o4 + 64) >> 7, 0, 255));
u_dst.dst[dst_row_addr + 5u] = uint8_t(clamp((o5 + 64) >> 7, 0, 255));
u_dst.dst[dst_row_addr + 6u] = uint8_t(clamp((o6 + 64) >> 7, 0, 255));
u_dst.dst[dst_row_addr + 7u] = uint8_t(clamp((o7 + 64) >> 7, 0, 255));
```
Mirrors `tests/vp9_mc_ref.c` directly.
## 5. SSBOs / push constants
| binding | name | type | usage |
|---|---|---|---|
| 0 | `meta` | `readonly uvec4[]` | per-block (dst_off, src_off, mx, _pad) |
| 1 | `dst` | `uint8_t[]` | output pixels |
| 2 | `src` | `readonly uint8_t[]` | input pixels |
Push constants (16 B):
```
n_blocks, dst_stride_u8, src_stride_u8, _pad
```
Filter table: hard-coded in shader as
`const int FILTER_REGULAR[16][8] = { ... };` — 128 const ints.
**Race safety:** lane r writes `dst[dst_off + r*dst_stride + 0..7]`
(8 contiguous bytes). For rows r and r+1, writes are `r*stride + 7`
and `(r+1)*stride + 0`. Disjoint iff `dst_stride ≥ 8`.
**Contracts (revised per phase5''' findings 4 + 6):**
1. `dst_stride_u8 ≥ 8` (race-safety lower bound)
2. `src_stride_u8 ≥ 15` (per-row read span)
3. `dst_off + 7 + (r_max)*dst_stride < dst_buffer_size`
4. `src_off + 14 + (r_max)*src_stride < src_buffer_size`
5. **`src_off` is the byte offset of the FIRST byte of the source
block's row 0 in the SSBO buffer — NOT shifted by +3.** The
C bench's `src + 3` C-caller convention does not carry into
the SSBO offset. Shader reads `s[k] = u_src.src[src_off +
row*stride + k]` for k=0..14, which equals
`master_src[block_base + row*stride + k]`, matching the C ref's
per-row read of `master_src[block_base + row*stride + (x..x+7)]`
for output col x ∈ 0..7.
**Phase 6 MUST** add `assert(dst_stride_u8 >= 8 && src_stride_u8 >= 15)`
in `bench_v3d_mc.c`'s meta-construction loop. **Phase 6 MUST** also
run `V3D_DEBUG=shaderdb` after first compile and record uniform
count. If uniform count > ~144 (a fall-out indicator that the
filter LUT inflated unfavorably), escalate filter to a dedicated
SSBO binding 3.
## 6. Predicted M2''' / R'''
From Phase 3:
- Compute envelope: 17.5 Mblock/s
- Bandwidth envelope: 22.0 Mblock/s
- min ≈ 17.5 Mblock/s
- R''' isolation = 17.5 / 20.997 ≈ **0.83** (YELLOW, near GREEN)
Honest lower bound R''' = 0.5-0.6 if SMUL24-vs-DP4A penalty bites
harder. Phase 7''' measures.
## 7. WILL / WILL NOT touch
WILL (Phase 6 creates):
- `src/v3d_mc_8h.comp` — GLSL shader
- `tests/bench_v3d_mc.c` — harness with contract asserts
- CMake updates
WILL NOT touch:
- Cycle 1/2 artifacts (frozen Phase 3 baselines)
- `external/ffmpeg-snapshot/` (frozen vendored sources, including
the just-added `vp9_subpel_filters_table.c`)
- `src/v3d_runner.{c,h}` (reusable as-is)
## 8. Phase 5''' review prompts
Specific high-risk decisions:
1. **Orientation / arithmetic correctness** — the 8 `o0..o7`
expressions in §4 are stencil-aligned. Verify the off-by-one
in `F[k] * s[c+k]` matches `F[k] * src[x+k-3]` after the
`src+3` indexing shift used by the bench.
2. **Filter table residency** — hard-coded const array vs SSBO
vs push constants. Const is simplest but may cause v3d_compiler
to generate a large constant LUT. Worth verifying via shaderdb.
3. **Race safety** — same shape as cycle 2 (different rows of
same block disjoint iff stride ≥ row-width). Verify
`dst_stride ≥ 8` contract.
4. **`src+3` index shift** — the bench's source layout puts the
"row-0 col-0 source pixel" at `src + 3` (so src has -3..+12
reachable). Make sure the QPU shader applies this offset
consistently to its `src_off` meta value.
**RESOLVED (phase5''' finding 4, RED):** `src_off` is the raw
block-base offset (NOT +3-shifted). See §5 contract 5.
5. **Anything missing.**
## 9. Phase 6 execution order
1. Write shader, get glslang to accept (likely 0 spills, ≥2 threads)
2. Write bench with asserts + meta layout
3. Run M1''' bit-exact (gate)
4. Run M2''' (throughput)
5. If R''' < 1.0 → M4''' concurrent
6. Phase 7''' verdict
+71
View File
@@ -0,0 +1,71 @@
---
cycle: 3
phase: 5
status: closed 2026-05-18 — PASS-WITH-REVISIONS, revisions applied
date_opened: 2026-05-18
date_closed: 2026-05-18
parent: k3_mc_phase4.md
reviewer: Claude Sonnet (general-purpose Agent, fresh context)
plan_author: Claude Opus 4.7 (this session)
verdict: PASS-WITH-REVISIONS
---
# Cycle 3, Phase 5 — Second-Model Review of MC Plan
Same handoff: in-session Agent (Sonnet, fresh context), files read
direct from disk, 5 review prompts + "anything else."
Outcome: **1 RED (off-by-3 `src_off` indexing bug)**, **2 YELLOW**
(shaderdb LUT gate for filter table, "MUST" assert language for
contracts). Cycle-1+2 RED patterns (write race, barrier UB,
subgroup-ops table error) did not recur.
**Phase 5 paid off again.** The RED would have caused a bit-exact
mismatch on the first run with cryptic "high index source pixels are
wrong" symptoms — likely 1-2 debug cycles to track down without the
review.
## Review (verbatim)
````markdown
## Verdict
PASS-WITH-REVISIONS — no RED-class correctness bugs. Two YELLOW findings
require plan amendments before Phase 6 proceeds. ...
[full review preserved — reviewer's RED finding 4 traces the off-by-3:
shader's `src_off = block_base + 3` + `src_stride_u8 = 16` + reading
`s[0..14]` causes high-index reads to spill into next row]
````
*(Verbatim review in agent output; key findings paraphrased below.)*
| # | Severity | Issue | Resolution |
|---|---|---|---|
| 1 (orientation) | GREEN | All 8 oN expressions stencil-aligned correctly | accepted |
| 2 (filter LUT) | YELLOW | `const int FILTER_REGULAR[16][8]` may inflate uniform count or compile to large LUT | Phase 6 to record uniform count via `V3D_DEBUG=shaderdb`; if >~144 uniforms, escalate filter to SSBO binding 3 |
| 3 (race safety) | GREEN-w/note | `stride ≥ 8` contract correct; phrasing softer than cycle-2 standard | applied: §5 MUST assert |
| 4 (`src_off` semantics) | **RED** | Plan said "src_off mirrors src+3"; with stride=16 shader's `s13`/`s14` read into next row's first 2 bytes | **applied: src_off = raw block base (no +3 shift); shader reads s[0..14] from there** |
| 5 (missing) | GREEN-w/note | Coefficient overflow safely fits int32 (worked bound); no missing barrier-UB or write-race issues | accepted |
| 6 (assert MUST language) | YELLOW | "Bench enforces with asserts" softer than cycle-2 MUST pattern | applied: §5 MUST language |
| 7 (no barrier OK) | GREEN | Cycle-1 finding-7 doesn't apply (no barrier) | accepted |
| 8 (filter table matches) | GREEN | `vp9_mc_ref.c` filter values match `vp9_subpel_filters_table.c[1]` verbatim | accepted |
## Resolution (applied to phase4 inline)
1. **§4** — Clarified `src_off` is the byte offset of the **first byte
of the source block in the SSBO buffer** (NOT shifted by +3). The
C bench's `src + 3` C-caller convention does NOT carry into the
SSBO offset. Shader reads `s[k] = u_src.src[src_off + row*stride + k]`
for k=0..14, which equals `master_src[block_base + row*stride + k]`,
matching the C ref's per-row read of `master_src[block_base + row*stride + (x..x+7)]`
for output col x ∈ 0..7.
2. **§5** — Hardened "Bench enforces" to "Phase 6 MUST add
`assert(dst_stride_u8 >= 8 && src_stride_u8 >= 15)` in
`bench_v3d_mc.c`'s meta-construction loop." Cycle-2 finding-4
pattern applied.
3. **§5** — Added: "Phase 6 MUST run `V3D_DEBUG=shaderdb` after first
compile and record uniform count. If uniform count > ~144,
escalate filter to a dedicated SSBO binding 3."
After revisions: **Phase 4''' APPROVED for Phase 6''' implementation.**
+152
View File
@@ -0,0 +1,152 @@
---
cycle: 3
phase: 7
status: closed 2026-05-18 — RED engineering / PASS 30fps-floor / M4 NEGATIVE
date_opened: 2026-05-18
date_closed: 2026-05-18
parent: k3_mc_phase4.md (revised per phase5''')
host: hertz
verdict: cycle 3 closes; MC stays on CPU for higgs deployment; engineering negative documented
---
# Cycle 3, Phase 7 — Verification (v1 + M4''')
## v1 first-light
```
=== v3d MC 8h bench ===
n_blocks: 65536 iters: 100
=== M1''': QPU vs C reference bit-exact ===
blocks bit-exact: 65536 / 65536 (100.0000 %)
=== M2''': QPU throughput ===
M2''' = 1.413 Mblock/s
per-block = 707.9 ns
per-dispatch = 46390.5 us
R''' = 0.067 → RED band
30fps@1080p floor: 1.5x margin (isolation)
```
shaderdb (v1 MC):
```
SHADER-DB-ffcca249...: 488 inst, 2 threads, 0 loops, 197 uniforms,
25 max-temps, 0:0 spills:fills, 0 sfu-stalls, 488 inst-and-stalls, 7 nops
```
**Phase 5''' finding 2 prediction confirmed**: filter LUT inflated
uniforms to 197 (gate was at ~144). Compiler also forced to 2 threads
(from cycle-2's 4) due to register pressure (25 max-temps vs cycle-2's
21). The "no DP4A" structural deficit shows up directly here — 8
SMUL24 + 7 ADD per output pixel × 64 pixels per block × 8-lane
geometry = 488 instructions, 30× heavier than the LPF kernel.
## M4''' concurrent matrix (8s windows)
| Config | Mblock/s | per-core (NEON) | vs NEON-4 | 30fps |
|---|---|---|---|---|
| NEON 1-core | 14.479 | — | — | 14.9× |
| **NEON 4-core** | **15.248** | 3.24 4.48 | **baseline** | 15.7× |
| QPU only | 1.380 | — | — | 1.4× |
| **Mixed NEON-3 + QPU** | **12.277** | 3.78 4.16 | **19.5 %** | 12.6× |
| Mixed NEON-4 + QPU | 12.158 | 2.49 3.35 | 20.3 % | 12.5× |
**M4 gate: FAIL.** Mixed (12.28) < pure NEON-4 (15.25) by 2.97
Mblock/s. The QPU's 0.45 Mblock/s contribution under contention
doesn't compensate for losing one NEON core that delivers ~3.8.
## Cross-cycle comparison
| | Cycle 1 IDCT | Cycle 2 LPF | Cycle 3 MC |
|---|---|---|---|
| R isolation | 0.92 | 0.41 | **0.067** |
| 30fps floor margin (isolation) | 7.9× | 10× | **1.5×** |
| M4 mixed vs pure NEON-4 | +7.2 % | +6.9 % | **19.5 %** |
| 30fps floor margin (mixed) | 7.2× | 7.2× | **12.6×** |
| Verdict for higgs | GO QPU | GO QPU | **STAY CPU** |
| NEON 4-core scaling vs 1-core | 0.56× (bw-bound) | 0.82× (bw-bound) | **1.05× (compute-bound)** |
The MC result is **structurally consistent** with the V3D substrate
profile from `phase0.md`:
- No DP4A → 8-wide convolution doesn't pack as it does on NEON SDOT
- Filter coefficients drive uniform count high → register pressure → 2 threads
- High per-output-pixel multiply count → compiled instruction count
3× cycle 1, 6× cycle 2
NEON 4-core is *compute*-bound for MC (not bandwidth-bound like
the other two kernels). So 4-core scales nearly linearly with cores —
the NEON CPU has plenty of headroom and the QPU has nothing to add
even in concurrent mode.
## Deployment recipe (for higgs / libva-v4l2-request-fourier)
Per `project_consumer_target.md`, the eventual integration target is
V4L2 stateless → libva-v4l2-request-fourier → firefox-fourier. The
back-end-on-QPU/CPU split for the consumed decoder pipeline:
- **IDCT (cycle 1)** → QPU. R = 0.92, +7 % mixed, frees a CPU core.
- **LPF (cycle 2)** → QPU. R = 0.41, +7 % mixed, frees a CPU core.
- **MC (cycle 3)** → **CPU NEON**. R = 0.067, 19.5 % mixed.
Compute-bound on CPU but CPU already comfortably exceeds 30fps;
offload makes things worse.
- **Entropy** (VP9 Bool / AV1 ANS) → CPU. Structurally serial.
This is a **mixed-substrate deployment**, not a "QPU does everything"
plan. Realistic for higgs: entropy + MC on 2-3 ARM cores; IDCT + LPF
dispatched to QPU concurrently; 1-2 ARM cores left for vscode / etc.
## Decision per Phase 1 rules + 30fps-floor calibration
| Rule | Result | Status |
|---|---|---|
| M1''' bit-exact | 100.0000 % | ✓ PASS |
| R''' = M2'''/M3''' | 0.067 (RED) | structural mismatch |
| M4''' > pure-CPU 4-core | 19.5 % | ✗ FAIL gate |
| 30fps@1080p floor (isolation) | 1.5× | ✓ PASS (user-facing) |
| 30fps@1080p floor (mixed) | 12.6× | ✓ PASS (user-facing) |
**Engineering cycle verdict: do not deploy MC on QPU; deploy on CPU.**
**User-facing cycle verdict: 30fps floor easily met in any
configuration; either path works for daily YouTube.**
For the deployment recipe above, **MC stays on CPU**. The Phase 1
ORANGE/RED "honest close" rule applies here: cycle 3 closes as a
documented negative for this kernel without affecting the
project-level "continue" verdict (cycles 1+2 GO results stand).
## Phase 9 lessons (added to project memory)
1. **Multiply-heavy workloads expose V3D's no-DP4A deficit** in a way
that cycle 1+2 didn't. CPU SDOT/UDOT pack 4 INT8 MACs in one
instruction; V3D's SMUL24 is one scalar mult at a time. The 4×
gap shows up directly as a 6-15× per-block slowdown.
2. **Compute-bound CPU workloads make the QPU offload story collapse.**
When NEON 4-core scales near-linearly (not bandwidth-saturated),
the "freed-core" argument from cycle 1+2 doesn't apply — there
are no free cycles to free. Mixed mode is strictly worse.
3. **The 30fps@1080p user-facing test (`project_30fps_floor_is_fine.md`)
passes regardless of engineering verdict.** All three cycles pass
it in isolation. This is a project-level win to communicate
separately from per-cycle engineering R numbers.
4. **The shaderdb filter-LUT gate from phase5''' finding 2 fired
exactly as predicted** (197 uniforms > 144 threshold; 2 threads
instead of 4). This validates the cycle-discipline of running
`V3D_DEBUG=shaderdb` early and using the result as an actionable
gate. Cycle 4 (if any) should bake this in from Phase 4 §design.
## Leaves open
- Cycle 3 v2 with filter LUT escalated to SSBO (per phase5''' finding 2
trigger). Would reduce uniforms to ~30, potentially restore 4
threads. Expected upside: ~2× → R''' = 0.13. Still RED, still M4-
negative. Skipped — even doubling doesn't change the deployment
recipe.
- Vertical / hv / 4-tap / wider variants — all of cycle 3 same
multiply-shape, same structural verdict expected. Not worth Phase
1+ for those.
- Cycle 4 candidates (per phase7_M4.md §"Cycle 3 candidates"):
CDEF (AV1-only directional filter), Loop Restoration (AV1-only),
or higgs deployment plumbing.