daedalus-fourier/docs/phase3.md

phase, status, date_opened, date_closed, parent, host, artifacts

phase	status	date_opened	date_closed	parent	host	artifacts
3	closed 2026-05-18	2026-05-18	2026-05-18	phase2.md	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)	build/bench_neon_idct, build/bench_vulkan_dispatch, build/noop.spv

Phase 3 — Baseline measurements

Per dev_process.md:

Take concrete measurements before any changes. Raw before derived. Real data, not theatre.

These numbers anchor every Phase 4+ decision. Re-run with the same harness on the same hertz before drawing any new conclusions in later phases.

M1 — bit-exact correctness gate (Phase 1)

Method	10 000 random VP9-plausible coefficient blocks + random pred[64], compare daedalus_vp9_idct_idct_8x8_add_ref C output vs vendored FFmpeg ff_vp9_idct_idct_8x8_add_neon
Run	./bench_neon_idct --blocks 1000000 --iters 5 (built 2026-05-18)
Result	10 000 / 10 000 = 100.0000 %
DC-only path frequency	11 / 10 000 = 0.11 %
Notes	Random generator: xorshift64, biased toward 1–16 non-zero coeffs per block; eob mostly ∈ [4, 63]. DC-only frequency is incidental; Phase 7 may revisit if it materially affects the throughput number.

Gate passes. Throughput measurement was authorized to run.

M3 — NEON throughput (single-core)

Kernel	ff_vp9_idct_idct_8x8_add_neon from FFmpeg n7.1.3 (vendored, see external/ffmpeg-snapshot/PROVENANCE.md)
Method	Pre-generate 1 M random blocks + preds. Per iteration: memcpy refresh of all blocks/preds (NEON path zeroes blocks), then call NEON kernel 1 M times. Subtract setup memcpy time from the measured wall-clock. 5 iterations, single thread, no CPU pinning.
Compiler flags	-O3 -march=armv8-a+simd
Run	./bench_neon_idct --blocks 1000000 --iters 5
Throughput	8.171 Mblock/s
Per-block	122.4 ns
Equivalent 1080p frame rate	252.2 FPS (32 400 blocks per 1080p frame, assuming pure 8×8 work)
Elapsed (kernel)	0.612 s / 5 M blocks
Elapsed (setup-only)	0.250 s / 5 M iters
Cross-check	Cycle estimate at 2.8 GHz: 122.4 ns × 2.8 GHz ≈ 342 cycles/block. Plausible for a fully-unrolled NEON 8-point IDCT with butterflies + saturated narrow stores; the FFmpeg implementation interleaves loads/computes/stores aggressively.

M3 implications

• A single A76 core handles ~8 M blocks/s = 252 FPS at 1080p. Real decode needs ~60 FPS = 4.2× headroom on one core, ~16× headroom on all four cores. NEON is not the bottleneck for current YouTube workloads on Pi 5.
• The QPU offload story is not "make decode faster" — decode is already fast enough single-threaded. The story has to be "free CPU cycles for the rest of the system" (browser, audio, the 11 LXD containers on hertz).
• For a per-kernel R = QPU / NEON measurement (per phase1.md §"Decision rules"), the QPU has to hit ≥4 M blocks/s to score R ≥ 0.5. That's the gate.

M5 — Vulkan compute dispatch overhead

Method	Allocate empty pipeline (no descriptors, no push constants), bind+dispatch a void main(){} shader on local_size_x=64. Time vkQueueSubmit + vkQueueWaitIdle round-trip. 50 000 iterations, warm.
Device	V3D 7.1.7.0 via Mesa v3dv 25.0.7 (selected past llvmpipe by strstr("V3D"))
Run	./bench_vulkan_dispatch --iters 50000
M5a — empty CB submit+wait	22.66 µs / op
M5b — 1-WG noop dispatch submit+wait	55.60 µs / op
M5 delta — per-vkCmdDispatch + pipeline-bind	32.95 µs

M5 implications — the load-bearing finding for Phase 4

This is the single most important number from Phase 3.

• Per-dispatch cost (55.6 µs) is ~455× the NEON per-block cost (122 ns).
• A per-block QPU dispatch is structurally impossible — overhead dominates by two-and-a-half orders of magnitude.
• Break-even batch size for a hypothetical zero-cost QPU kernel: ≥ 556 blocks per dispatch. Real kernel cost on top of that.
• Frame-level batching is mandatory: a 1080p frame has 32 400 8×8 blocks; one dispatch per frame amortizes M5b to 1.7 ns/block — well below NEON's 122 ns.
• Tile-level batching is borderline: a typical VP9 64×64 superblock has 64 sub-blocks; 55.6 µs / 64 ≈ 870 ns/block, ~7× NEON. Probably too coarse — frame-level or full-plane is the right granularity.

M5 measurement caveats

• vkQueueWaitIdle after each submit forces a full GPU sync, modelling the "submit and need the result now" case. Real decode pipelines can submit multiple frames ahead and wait less often — the per-dispatch cost in a pipelined deployment will be lower (probably bounded below by M5a ≈ 22.66 µs as the pure submit cost).
• Empty CB (M5a) at 22.66 µs is the floor. This is Mesa command-list construction + kernel DRM_IOCTL_V3D_SUBMIT_CL + scheduler RTT. Cannot be optimised at the userspace level without changing Mesa or kernel.
• Both numbers include vkQueueWaitIdle overhead; pure submit-without-wait would be lower. For Phase 1's threshold analysis the with-wait number is the right one to use because end-to-end frame decode must wait for its output to be readable.

Phase 3 closure

Two anchor measurements captured, both with verbatim raw output (see bench_neon_idct and bench_vulkan_dispatch source for the print format). No estimates, no inferences, no recall from prior sessions or sibling-host memory.

Phase 4 (plan) opens against these numbers. Its first decision: given the 32.95 µs per-dispatch floor, what is the batch granularity for the first kernel? The answer is either frame-level (32 400 blocks/dispatch) or row-level (~120 blocks/dispatch for one 1920-wide row of 8×8 → still ~460 ns/block overhead, ~4× NEON). Frame-level is the only granularity that amortises overhead enough to leave kernel compute room to win.

Open thread for a later phase (not blocking Phase 4):

• Multi-core NEON sweep (M3'): single-core NEON is the right competitor floor, but the actual ARM headroom on hertz is 4× this number under load.
• Memory-bandwidth contention measurement (M6): does NEON's rate change when concurrent QPU is reading the same LPDDR4x bus? Needs the QPU kernel to exist first.
• Power-draw delta via Himbeere plug (M7): same — needs a real GPU workload to differentiate from idle.