claude-noether/daedalus-fourier
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Cycle 2 (deblocking) Phase 1-3: M3'' = 48.285 Medge/s baseline

Browse Source 
Second kernel candidate per phase7_M4.md verdict "next-kernel cycle
authorised". VP9 4-tap inner loop filter, horizontal direction,
8-pixel edge (libavcodec ff_vp9_loop_filter_h_4_8_neon as baseline).
Different workload shape from IDCT - boundary streaming, lighter
compute per unit, per-row conditionals - tests whether QPU win
generalises.

docs/k2_deblock_phase1.md - goal-setting. Same R-band decision rules
as cycle 1 (phase1.md), with the cycle-1 calibration adjustment:
ORANGE band is no longer auto-close because M4 showed mixed > pure
CPU even at modest R when CPU bandwidth-saturates.

docs/k2_deblock_phase2.md - situation analysis. C reference already
in vendored snapshot (vp9dsp_template.c:1780-1898). Fetched
vp9lpf_neon.S fresh (1334 lines, LGPL-2.1+, FFmpeg n7.1.3 pin,
SHA-256 384e49e7...). PROVENANCE.md updated.

docs/k2_deblock_phase3.md - NEON baseline:

  M1''_c bit-exact     100.0000 % (10000 random edges)
  M3'' throughput      48.285 Medge/s  (20.7 ns/edge, single A76)
  per-frame 1080p-eq   748 FPS (worst case 64 530 edges/frame)
  cycles/edge          ~58 (=20.7ns x 2.8GHz), ~7 cycles/row

LPF is 5.9x faster per-unit than IDCT M3 (20.7 vs 122 ns), so the
QPU break-even point moves down. Predicted R''_v1 band ~0.5-0.9
- frame-level batching amortises the same 33us dispatch overhead;
workload becomes bandwidth-bound rather than compute-bound
(~5.7 MB/frame traffic at 64 530 edges x ~88 B per edge).

New artifacts:
- tests/vp9_lpf_ref.c    - standalone bit-exact C ref (8-bit, wd=4
                           inner only; clean transcription)
- tests/bench_neon_lpf.c - M1''_c gate + M3'' time-based bench
                           (5s window, edge-content-biased RNG for
                           realistic fm/hev hit rates)
- external/ffmpeg-snapshot/libavcodec/aarch64/vp9lpf_neon.S
- CMakeLists.txt updated with bench_neon_lpf target

Phase 4 next: plan the QPU LPF compute shader. Cycle 1's phase4.md
+ phase5.md + phase7.md learnings apply directly - bake in the v4
winning patterns from the start (WG=256, edges-per-subgroup
pattern adapted from blocks, uint8_t dst SSBO, oob flag, unrolled
writes).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Markus Fritsche
2026-05-18 12:28:57 +00:00
parent 8182e43c15
commit be7ff5587c
8 changed files with 2024 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/k2_deblock_phase1.md
+125
View File
@@ -0,0 +1,125 @@
---
cycle: 2
phase: 1
status: open
date_opened: 2026-05-18
parent_cycle1: phase9 (lessons distilled inline below)
target_kernel: VP9 loop filter — 4-tap inner-edge variant (horizontal direction, 8-pixel boundary)
dev_host: hertz
---
# Cycle 2, Phase 1 — Loop filter kernel goal
Cycle 1 (8×8 IDCT) closed with `phase7_M4.md` verdict GO. Per
Phase 1 §"Decision rules", the next-kernel cycle is authorised.
This doc is compact; it references cycle-1 phase docs for the
substrate framework rather than re-deriving it.
## Why deblocking, why this variant
Three candidates were on the table from `phase0.md §5`:
| candidate | covers | shape | why pick / skip |
|---|---|---|---|
| **VP9 loop filter (4-tap inner)** | **VP9 + AV1** (similar) | boundary streaming | **Picked.** Different memory access from IDCT → tests whether QPU win generalises beyond compute-bound small transforms |
| AV1 CDEF | AV1 only | per-superblock, 8-px halo | AV1-only is narrower; can come later |
| MC interpolation | VP9 + AV1 | convolution, multiply-heavy | Pure-multiply workload — V3D's SMUL24 + no INT8 MAC may bite harder than for IDCT; defer until we have more substrate confidence |
The specific variant: **VP9 4-tap inner-edge horizontal loop
filter, 8-pixel edge.** libavcodec symbol
`ff_vp9_loop_filter_h_4_8_neon` from
`libavcodec/aarch64/vp9lpf_neon.S` (already vendored in
`external/ffmpeg-snapshot/` at the FFmpeg n7.1.3 pin — verify in
Phase 2). Inner-edge means we *assume* the filter strength
parameters have been pre-computed by the caller (skipping the
per-edge strength-decision tree, which is the codec's contextual
work, not the filter itself).
## Measurable success criteria
Reusing `phase1.md §"Measurable success criteria"` structure
with cycle-2 numbering:
| ID | Measurement | Gate |
|---|---|---|
| **M1''** | Bit-exact match rate vs libavcodec C reference, ≥10 000 random edges | 100.000 % |
| **M2''** | QPU throughput in Medge/s (millions of edges processed per second) | recorded |
| **M3''** | NEON `ff_vp9_loop_filter_h_4_8_neon` throughput on same hertz, single-core, time-based | recorded |
| **M4''** | Concurrent NEON-3 + QPU vs pure NEON-4, both running deblocking | recorded |
Derived: **R'' = M2'' / M3''**.
## Decision rules (publish before measure)
Same R bands as cycle 1 — the substrate hasn't changed:
| R'' | Verdict | Next |
|---|---|---|
| ≥ 1.0 | QPU beats NEON in isolation | Phase 9 → Phase 1 of kernel 3 |
| 0.5 ≤ R'' < 1.0 | YELLOW: M4'' gate decides | Run M4''; if mixed > pure-CPU → continue |
| 0.1 ≤ R'' < 0.5 | ORANGE: M4'' may still rescue if QPU adds *anything* on top of saturated CPU (per cycle-1 F1+F2 findings) | Run M4'' anyway given M4 surprised |
| < 0.1 | RED: structural | Phase 9 close, deblocking unsuitable for QPU |
**Cycle-1 calibration adjustment:** the orange band is no longer
auto-close. Cycle 1 M4 showed mixed > pure-CPU even at R = 0.92;
similar bandwidth-contention dynamics may hold at lower R if the
QPU's memory channel stays underutilised by the CPU. Run M4'' as
the deciding measurement regardless of M2''.
## Cycle-1 lessons carried in (compressed)
From `phase7.md` + `phase7_M4.md`:
1. **The single biggest perf lever was workgroup-size scaling**
(64 → 256 invocations gave 2× throughput from latency hiding).
For cycle 2: jump straight to max WG size where shared-mem
fits, skip the small-WG exploration of cycle 1.
2. **`V3D_DEBUG=shaderdb` is load-bearing diagnostic.** Read
instruction count / threads / max-temps / spills:fills after
first compile. Multiply that by lane occupancy to predict
per-block cycle cost.
3. **Chained-ternary "spill killer" optimisation was a bust** —
v3d_compiler had already coalesced. Don't pre-emptively
restructure for spills; let shaderdb tell you first.
4. **Pi 5 LPDDR4x bandwidth is the realistic ceiling.** Per-core
NEON delivers 12.6 Mblock/s on cold-cache 1080p IDCT but only
1.77 Mblock/s when 4 cores compete. The QPU lives in an
underutilised channel; the marginal contribution counts.
5. **uint8_t SSBO with `storageBuffer8BitAccess`** is the
race-free dst write pattern (cycle-1 phase-5 finding 5).
Same applies to loop-filter output pixels.
6. **Barrier-safe oob flag pattern** (cycle-1 phase-5 finding 7):
never early-return before `barrier()`. Loop filter doesn't
need a barrier within the kernel (filter is straight pass) so
this may not bite; still good to keep in mind.
## What cycle-2 Phase 1 does *not* lock
- Vulkan-compute vs direct-DRM dispatch path. Cycle 1 picked
Vulkan; loop filter has the same justification (debuggability,
spirv-toolchain reuse).
- WG geometry (number of edges per WG). Phase 4 picks based on
shared-mem and SIMD-width arithmetic.
- Vertical vs horizontal variant — Phase 1 picks horizontal
arbitrarily; Phase 4/7 may revisit if there's a perf reason.
## Phase 2 → Phase 3 hand-off
Phase 2 inventory must produce:
- Verbatim quote of the C reference for `loop_filter_h_4_8`
(will be in `external/ffmpeg-snapshot/libavcodec/vp9dsp_template.c`
or `vp9lpf_template.c` — Phase 2 finds it).
- The NEON symbol signature (likely `void(uint8_t *dst, ptrdiff_t
stride, int E, int I, int H)` or similar).
- VP9 spec §8.8.1 (loop filter process) — at minimum which
conditions select the 4-tap inner filter.
- Whether the inner `loop_filter` function is exposed in the
vendored snapshot or needs additional .c files vendoring.
Phase 3 will then build `tests/bench_neon_lpf.c` and capture M3''.
docs/k2_deblock_phase2.md
+124
View File
@@ -0,0 +1,124 @@
---
cycle: 2
phase: 2
status: closed 2026-05-18
date_opened: 2026-05-18
parent: k2_deblock_phase1.md
target_kernel: VP9 loop filter h_4_8 (4-tap inner, 8-pixel horizontal-direction-on-vertical-edge)
---
# Cycle 2, Phase 2 — Loop filter situation analysis
## 1. Reference implementations
### 1.1 C reference (bit-exact gate)
- **Source**: `external/ffmpeg-snapshot/libavcodec/vp9dsp_template.c:1780-1898`
(already vendored; no additional fetch needed).
- **Function entry point**: `loop_filter_h_4_8_c` — generated by the macro
`lf_8_fn(h, 4, stride, 1)` at line 1892 + `lf_8_fns(4)` at 1900.
- **Signature**:
```c
void loop_filter_h_4_8_c(uint8_t *dst, ptrdiff_t stride,
int E, int I, int H);
```
- **Spec basis**: VP9 specification §8.8.1 (Loop filter process).
- **Algorithm (4-tap inner, the simplest path)**:
1. For each of 8 rows along the edge (`i = 0..7, dst += stride`):
1. Read 8 pixels straddling the edge: `p3, p2, p1, p0 | q0, q1, q2, q3`
(4 each side at strideb=1 spacing).
2. Compute `fm` (filter mask) — gating; if false, skip this row.
3. Compute `hev` (high edge variance) test from `(p1 - p0)` and `(q1 - q0)`.
4. If hev: write 2 pixels (`p0, q0`) with clipping.
If !hev: write 4 pixels (`p1, p0, q0, q1`) with clipping.
- All arithmetic is signed `int`; clipping via `av_clip_pixel` (8-bit → [0, 255]).
- Filter is **conditional per row**: `fm` may skip; `hev` selects between
2-pixel and 4-pixel updates. This is a *divergence-friendly* shape for
SIMD only if the divergence is rare; on real bitstreams it's frequent.
### 1.2 NEON reference (M3'' baseline)
- **Source**: `external/ffmpeg-snapshot/libavcodec/aarch64/vp9lpf_neon.S`
(vendored 2026-05-18; SHA-256
`384e49e7a6e838d9e38aedc00838ed4aebfa6c5bdb343ecaf23ef639bc10fbb7`).
- **Symbol**: `ff_vp9_loop_filter_h_4_8_neon`
- **Signature** (same as C):
```
void ff_vp9_loop_filter_h_4_8_neon(uint8_t *dst, ptrdiff_t stride,
int E, int I, int H);
```
Registers: `x0=dst, x1=stride, w2=E, w3=I, w4=H`.
- **Dependencies** (all already vendored):
- `libavutil/aarch64/asm.S` — `function`/`endfunc`/`movrel` macros
- `libavcodec/aarch64/neon.S` — `transpose_8x8B` / `transpose_4x8B`
- **Size**: ~40-60 instructions per export (after `.macro loop_filter` expansion).
Significantly simpler than the IDCT 8×8 (~270 inst, butterflies).
- **License**: LGPL-2.1-or-later (Google 2016, same as vp9itxfm_neon.S).
The vendored snapshot now covers cycle 1 + cycle 2 references with the
same FFmpeg n7.1.3 pin.
## 2. Workload model
Each call to `ff_vp9_loop_filter_h_4_8_neon` processes **one
8-pixel-tall edge** = 8 rows × 8 pixel-positions = 64 pixels touched
(but only a subset written depending on `fm`/`hev`).
For a 1920×1080 luma plane with VP9's 8×8-min-block partitioning, the
worst-case edge count is approximately:
- Vertical edges: (1920/8 - 1) × (1080/8) blocks-worth = 239 × 135 = 32 265 edges
- Horizontal edges: similarly ~32 265 edges
- Total per frame: ~64 530 edges
Real bitstreams have fewer edges (larger blocks merge edges away).
Phase 4/7 may model a realistic edge count from a sample stream;
for Phase 1 we measure raw edges/sec.
**Memory access shape**: per-edge, read 8 neighborhoods of 8 pixels
each = 512 bits worst case (8×8 = 64 bytes). Write 2-4 pixels per row
× 8 rows = 16-32 bytes. Per-edge read-modify-write footprint is
~80-100 bytes. Per-frame memory traffic (worst case all edges
processed) ≈ 64 530 × 96 B ≈ 6.2 MB read + 64 530 × 32 B ≈ 2.1 MB
written = ~8.3 MB/frame, *similar to IDCT's 8 MB/frame*. Bandwidth
prediction transfers.
## 3. Per-edge workload diversity (vs IDCT)
| | IDCT 8×8 | LPF h_4_8 |
|---|---|---|
| Per-block math | Heavy: 30 ops × 2 passes per block | Light: ~10-20 ops per row × 8 rows = 80-160 ops per edge |
| Per-block memory | 256B in (coeffs) + 64B in (pred) + 64B out | 64B in + 16-32B out per edge |
| Parallelism | Fully data-parallel, no conditionals | Per-row conditionals (`fm`, `hev`) cause divergence |
| Compute / memory | High | Low (memory-bound) |
| Predicted v3d fit | "good" — fits the SMUL24 + Q14 shape | "marginal" — divergence cost, lighter compute |
The LPF kernel is **deliberately a different workload class** so we
test whether v3d wins generalise.
## 4. Constraints carried from cycle 1
All cycle-1 V3D 7.1 device limits (Phase 0 §2) apply unchanged.
Specifically:
- C2 shared mem ≤ 16 KiB — LPF needs even less than IDCT (no
intermediate transposed scratch)
- C3 ≤ 8 SSBO bindings — LPF needs only 2 (dst, edge_meta)
- C5 SMUL24 — covers the small constants in clip/abs
- shaderInt8 = false — uint8_t writes via storageBuffer8BitAccess
(same race-safe pattern as cycle 1)
## 5. What Phase 2 does *not* close
- Per-edge meta layout (E/I/H thresholds as packed u32 per edge, or
uniform across all edges?). Phase 4 picks. For Phase 3 NEON
baseline, we use the same thresholds for every edge to simplify.
- Divergence handling: NEON's hand-tuned LPF predicates per-lane;
the QPU shader will need to either predicate too (some lanes
idle when `fm` fails) or always-execute (write zero updates when
`fm` fails) — Phase 4 picks.
- Vertical vs horizontal: Phase 1 picked `h_4_8`. The `v_4_8`
variant has a different memory access shape (read columns 8 wide,
not rows of 8 stride apart) and would be a useful comparator in
Phase 7.
Phase 3 next: build `tests/bench_neon_lpf.c` (clone of
`bench_neon_idct.c` shape, swap kernel) and capture M3'' baseline.
docs/k2_deblock_phase3.md
+107
View File
@@ -0,0 +1,107 @@
---
cycle: 2
phase: 3
status: closed 2026-05-18
date_opened: 2026-05-18
date_closed: 2026-05-18
parent: k2_deblock_phase2.md
host: 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.