Closes the H.264 8x8 qpel buildout. Adds the remaining 12 avg_
biprediction positions:
4 quarter-axis: avg_mc{10,30,01,03}
8 diagonals : avg_mc{11,12,13,21,23,31,32,33}
Each follows the established pattern: same half-pel formula as the
put_ sibling, then L2 average with the existing dst contents per
H.264 §8.4.2.3.1.
Scope:
- 12 new kernel enums (MC10..MC33 avg_ = 34..45) → CPU.
- 12 NEON externs for the vendored ff_avg_h264_qpel8_mc*_neon.
- 12 CPU dispatches via existing DEFINE_QPEL_CPU_DISPATCH macro.
- 12 public dispatches via DEFINE_QPEL_DISPATCH macro.
- 12 recipe wrappers via DEFINE_QPEL_RECIPE macro.
- 12 header decls via DECLARE_QPEL_AVG macro.
- tests/h264_qpel8_avg_rest_ref.c — references via two parametric
macros: DEFINE_AVG_QUARTER for the 4 ¼-pel L2 forms,
DEFINE_AVG_DIAG for the 8 two-half-pel-avg forms.
- Test harness extended with a RUN(MC) sub-macro that derives both
the ref name and dispatch name from the bare mcXX. (The ref
is daedalus_avg_h264_qpel8_<mc>_ref; the dispatch is
daedalus_recipe_dispatch_h264_qpel_avg_<mc>. Macro had a typo
on first try that duplicated "avg_" in the ref name — caught at
compile, fixed.)
Verified on hertz:
$ ./build/test_api_h264 | tail -12
H.264 qpel avg_mc10: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel avg_mc30: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel avg_mc01: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel avg_mc03: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel avg_mc11: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel avg_mc12: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel avg_mc13: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel avg_mc21: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel avg_mc23: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel avg_mc31: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel avg_mc32: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel avg_mc33: 2048/2048 bytes bit-exact (100.0000%)
All 12 new positions bit-exact PASS first try.
Final qpel matrix state:
put_: mc00 (none — integer copy)
mc01 ✓ mc02 ✓ mc03 ✓
mc10 ✓ mc11 ✓ mc12 ✓ mc13 ✓
mc20 ✓ (QPU+CPU) mc21 ✓ mc22 ✓ mc23 ✓
mc30 ✓ mc31 ✓ mc32 ✓ mc33 ✓
avg_: same 15-of-16 coverage, all CPU.
Every B-slice biprediction case the libavcodec intercept can throw
at us is now serviceable. QPU shaders remain mc20-only (cycle 9);
the other 29 positions are CPU NEON. Whether to write more QPU
shaders depends on real perf measurement — at NEON ~10 ns per
8x8 block, full qpel coverage at 1080p is ~2-3 ms of total work,
well inside budget.
Begins the avg_ qpel buildout for B-slice biprediction. Each avg_
form computes the same half-pel formula as its put_ sibling, then
L2-averages the result with the existing dst contents — the caller
pre-loads dst with the list0 prediction; the avg_ call adds list1
per H.264 §8.4.2.3.1.
Scope (3 anchors, sets the pattern for the remaining 13 avg_
variants):
- 3 new kernel enums (AVG_MC20=31, AVG_MC02=32, AVG_MC22=33) → CPU.
- 3 NEON externs for the vendored ff_avg_h264_qpel8_{mc20,mc02,mc22}_neon.
- 3 CPU dispatches via existing DEFINE_QPEL_CPU_DISPATCH macro
(the macro is type-agnostic so it didn't need changes for avg_).
- 3 public dispatches via DEFINE_QPEL_DISPATCH macro.
- 3 recipe wrappers via DEFINE_QPEL_RECIPE macro.
- tests/h264_qpel8_avg_anchors_ref.c — per-cell helpers + L2 avg.
- Test harness: run_avg_qpel() seeds dst with random content so
the L2 averaging is actually exercised (not just put_-style
overwrite that would silently pass).
Verified on hertz:
$ ./build/test_api_h264 | tail -3
H.264 qpel avg_mc20: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel avg_mc02: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel avg_mc22: 2048/2048 bytes bit-exact (100.0000%)
All 3 anchors bit-exact PASS first try.
Why anchors only in this PR: the avg_ pattern is uniform across all
16 positions (each is just "put_ result + L2 with dst"). Landing
the anchors first confirms the macro pattern works for both put_
and avg_; the remaining 13 (avg_mc10/30/01/03 + avg_mc11..33) follow
the same template in a follow-up PR.
State of the qpel matrix after this PR:
put_ : 15 of 16 positions ✓ (mc00 is integer copy, no wrapper)
avg_ : 3 of 16 positions ✓ (mc20, mc02, mc22 anchors)
13 follow-up positions
Closes the qpel buildout. All 8 remaining diagonal positions land
in one PR. Each is the rounded average of two half-pel intermediates
per H.264 §8.4.2.2.1 / Table 8-4, with the decomposition matching
the FFmpeg .S reference structure (verified by reading
external/ffmpeg-snapshot/.../h264qpel_neon.S lines 622-758).
Decomposition table (the formula for each output cell at (r,c)):
mc11 ¼¼ : avg(mc20[r, c], mc02[r, c])
mc12 ¼½ : avg(mc22[r, c], mc02[r, c])
mc13 ¼¾ : avg(mc20[r+1, c], mc02[r, c])
mc21 ½¼ : avg(mc22[r, c], mc20[r, c])
mc23 ½¾ : avg(mc22[r, c], mc20[r+1, c])
mc31 ¾¼ : avg(mc20[r, c], mc02[r, c+1])
mc32 ¾½ : avg(mc22[r, c], mc02[r, c+1])
mc33 ¾¾ : avg(mc20[r+1, c], mc02[r, c+1])
The (r±1, c±1) offsets capture the position-dependent shift that
the FFmpeg .S encodes by pre-incrementing x1 (src pointer) before
branching into the common mc11/mc21 code paths.
Scope (tightly macro-ised):
- 8 new kernel enums (MC11..MC33 = 23..30) → CPU.
- 8 NEON externs for the vendored ff_put_h264_qpel8_mc*_neon.
- 8 CPU dispatches via existing DEFINE_QPEL_CPU_DISPATCH macro.
- 8 public dispatches via DEFINE_QPEL_DISPATCH macro.
- 8 recipe wrappers via DEFINE_QPEL_RECIPE macro.
- Header decls condensed via a DECLARE_QPEL_DIAG macro that
expands to both recipe + dispatch decls per name.
- C references via DEFINE_DIAG_REF macro: each ref is a 6-line
wrapper around the per-cell hpel_h / hpel_v / hpel_hv helpers
(the latter being the per-cell version of mc22's 13-row int16
tmp[] computation).
- Test wrapper: test_qpel_diag_all() drives all 8 through the
existing run_quarter_axis_qpel() harness.
Verified on hertz (Pi 5 / V3D 7.1):
$ ./build/test_api_h264 | tail -8
H.264 qpel mc11: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel mc12: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel mc13: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel mc21: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel mc23: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel mc31: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel mc32: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel mc33: 2048/2048 bytes bit-exact (100.0000%)
ALL 8 diagonal positions bit-exact PASS first try. Meaningful
because the position-dependent (r±1, c±1) source offsets are easy
to get wrong by transcription, and any of them would surface on
random inputs immediately.
After this PR the H.264 qpel 8x8 put_ matrix is complete:
mc00 mc01 mc02 mc03
mc10 mc11 mc12 mc13
mc20 mc21 mc22 mc23
mc30 mc31 mc32 mc33
15 of 16 positions exposed through the daedalus API; mc00 is just
integer copy and rarely needs a dispatch wrapper (libavcodec sets
the function pointer table directly). mc20 retains its QPU shader
(cycle 9 / v3d_h264_qpel_mc20.spv); all other 14 are CPU NEON.
What this does NOT cover (still in backlog):
- avg_ variants (the "add" form for biprediction, 16 more
positions). Currently the API only exposes put_.
- 16x16 qpel (separate function family in FFmpeg; the 8x8 path
can be used twice to substitute when 16x16 isn't critical).
- QPU shaders for any qpel position other than mc20.
Closes the 4 single-axis quarter-pel positions in one PR. Each is
a half-pel lowpass clipped to u8 followed by L2 rounded-average
with an integer-aligned source pixel per H.264 §8.4.2.2.1:
mc10 ¼-H ("a" pos): clip255(mc20(s)) avg src[r,c]
mc30 ¾-H ("c" pos): clip255(mc20(s)) avg src[r,c+1]
mc01 ¼-V ("d" pos): clip255(mc02(s)) avg src[r,c]
mc03 ¾-V ("n" pos): clip255(mc02(s)) avg src[r+1,c]
The mc10/mc30 pair and mc01/mc03 pair only differ in WHICH integer
source pixel they average with — the half-pel computation is the
same. Putting them in one PR is justified by that uniformity.
Scope:
- 4 new kernel enums: MC10=19, MC30=20, MC01=21, MC03=22 → CPU.
- 4 NEON externs for the vendored ff_put_h264_qpel8_mc{10,30,01,03}_neon.
- 4 CPU dispatch wrappers via DEFINE_QPEL_CPU_DISPATCH macro
(collapses ~50 LOC of repetition).
- 4 public dispatch fns via DEFINE_QPEL_DISPATCH macro.
- 4 recipe wrappers via DEFINE_QPEL_RECIPE macro.
- tests/h264_qpel8_quarter_axis_ref.c covers all four via shared
hpel_h() / hpel_v() inlines + per-mode L2 average.
- Test refactor: generic run_quarter_axis_qpel() harness exercises
all 4 positions through a single helper (~50 LOC for 4 tests vs
~200 if each was hand-rolled).
Verified on hertz:
$ ./build/test_api_h264 | tail -8
H.264 deblock chroma h intra: 256/256 bytes bit-exact (100.0000%)
H.264 qpel mc20: 1024/1024 bytes bit-exact (100.0000%)
H.264 qpel mc02: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel mc22: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel mc10: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel mc30: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel mc01: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel mc03: 2048/2048 bytes bit-exact (100.0000%)
All 4 new positions bit-exact PASS first try.
Coverage matrix update:
put_ mc00 mc10 mc20 mc30
mc01 — ✓ — ✓
mc11 — — ✓ — ← this row
mc21 — — — —
mc31 — — — —
mc02 — — ✓ — ← mc02 + mc22 anchor
mc03 — — ✓ —
After this PR: 7 of 16 single-axis + diagonal positions done.
Remaining 9 are the off-axis quarter-pel combinations
(mc11/mc12/mc13/mc21/mc23/mc31/mc32/mc33) — each combines a 2D
lowpass intermediate with L2 averaging against a 1D-lowpass output.
Next PR scope.
Why no QPU shaders: same R-band logic as the prior CPU additions.
At ~10 ns per 8x8 NEON block, all 16 qpel positions together
would land in ~1.3 ms/frame at 1080p worst case — comfortably
inside the 33 ms budget. QPU shader for mc20 already exists
(cycle 9 / v3d_h264_qpel_mc20.spv); the other 15 follow once a
clear perf reason emerges.
Adds the "j position" 2D half-pel via cascaded H + V 6-tap lowpass
with intermediate 16-bit precision per H.264 §8.4.2.2.1. One of the
most common qpel positions in real H.264 streams — many encoders
emit 1/2-1/2 motion vectors as their best-RD choice.
Algorithmically distinct from the 1D mc20/mc02 siblings:
- Horizontal 6-tap produces 13 rows of int16 intermediate (no
per-stage clip/round — full precision retained).
- Vertical 6-tap on the intermediate, then +512 >> 10 (the
double-shift compensates for both 6-tap scalings) + clip255.
The intermediate-precision requirement means the C reference can't
just be "call mc20 then mc02" — that would double-clip and produce
the wrong result. The 13-row int16 tmp[] buffer is the central
invariant.
Scope (same pattern as mc02 PR #15):
- Public API: daedalus_dispatch_h264_qpel_mc22 + recipe wrapper.
- Internal: dispatch_h264_qpel_mc22_cpu calling
ff_put_h264_qpel8_mc22_neon.
- Recipe table: DAEDALUS_KERNEL_H264_QPEL_MC22 = 18 → CPU.
- C reference: tests/h264_qpel8_mc22_ref.c — explicit tmp[13][8]
int16 staging buffer; spec-derived shifts and rounding.
- Test: test_qpel_mc22 in test_api_h264, 8 tiles at 16×16 with
output positioned at (SRC_ROW=3, SRC_COL=3) so the kernel's
[-2 .. +10] read window stays in-tile.
Verified on hertz:
$ ./build/test_api_h264 | tail -5
H.264 deblock chroma v intra: 256/256 bytes bit-exact (100.0000%)
H.264 deblock chroma h intra: 256/256 bytes bit-exact (100.0000%)
H.264 qpel mc20: 1024/1024 bytes bit-exact (100.0000%)
H.264 qpel mc02: 2048/2048 bytes bit-exact (100.0000%)
H.264 qpel mc22: 2048/2048 bytes bit-exact (100.0000%)
All 13 H.264 kernels in api_smoke now bit-exact PASS.
mc22 being right first try is meaningful — the +512 >> 10 scaling
+ int16 intermediate sequence has multiple sign/shift/clip pitfalls
and any of them would surface on random inputs immediately.
Coverage matrix update:
put_ mc20 ✓ (QPU+CPU) put_ mc02 ✓ (CPU) put_ mc22 ✓ (CPU)
→ 12 single put_ positions still missing (¼/¾ + HV combos with
L2 averaging).
Mirror of cycle 9's mc20 transposed to vertical orientation. Wires
up the second qpel half-pel position via the vendored
ff_put_h264_qpel8_mc02_neon symbol, closes the "missing vertical
sibling" gap that mc20 left open since cycle 9.
Scope:
- Public API: daedalus_dispatch_h264_qpel_mc02 + recipe wrapper.
- Internal: dispatch_h264_qpel_mc02_cpu calling the NEON entry.
- Recipe table: DAEDALUS_KERNEL_H264_QPEL_MC02 = 17 → CPU.
Explicit SUBSTRATE_QPU returns -1 (no shader yet).
- C reference: tests/h264_qpel8_mc02_ref.c — vertical 6-tap
transpose of mc20 (reads src[(r±N)*stride + c] instead of
src[r*stride + c±N]).
- Test: test_qpel_mc02 in test_api_h264, 8 tiles × 16×16 cols
× 16 rows, random input, bit-exact compare against the C ref.
Verified on hertz:
$ ./build/test_api_h264
...
H.264 qpel mc20: 1024/1024 bytes bit-exact (100.0000%)
H.264 qpel mc02: 2048/2048 bytes bit-exact (100.0000%)
All 12 H.264 kernels in the api_smoke now bit-exact PASS.
Why CPU-only: same R-band logic as the deblock _h sibling pattern.
mc02 at ~7.6 ns per 8x8 block on NEON (per the cycle 9 baseline
measurements) gives ~700 us for 8160 MBs × 4 8x8 luma blocks at
1080p — comfortably inside the 33 ms budget. QPU shader is a
fast-follow once the V vs H shader work is consolidated (the
transpose for the V shader is not mechanical — different SIMD
access pattern than the H shader).
Coverage matrix update:
qpel position put_ status avg_ status
------------- ----------- -----------
mc00 (copy) not wired not wired
mc10 (¼-H) not wired not wired
mc20 (½-H) ✓ QPU+CPU not wired
mc30 (¾-H) not wired not wired
mc01 (¼-V) not wired not wired
mc02 (½-V) ✓ CPU not wired (this PR)
mc03 (¾-V) not wired not wired
mc11..mc33 not wired not wired
13 more qpel positions to go for the full put_ matrix. Adding them
follows the same template; each is a small contained PR.
Third intra-prediction primitive after PR #12 (Intra_4x4 luma) and
PR #13 (Intra_16x16 luma). Covers Intra_8x8 chroma per H.264 §8.3.3:
4 modes used for BOTH Cb and Cr planes at 4:2:0.
Mode quirks worth flagging in code review:
- Mode 0 DC is asymmetric per quadrant. The 8x8 chroma block
splits into four 4x4 quadrants with different DC formulas:
(0,0) top-left : (sum_top[0..3] + sum_left[0..3] + 4) >> 3
(0,1) top-right : (sum_top[4..7] + 2) >> 2
(1,0) bot-left : (sum_left[4..7] + 2) >> 2
(1,1) bot-right : (sum_top[4..7] + sum_left[4..7] + 4) >> 3
The top-right quadrant deliberately IGNORES the top-left half
even though it's available — that's per spec §8.3.3.2.
- Mode 3 Plane uses slope coefficient 34 (not 5 like Intra_16x16
luma). Centre is (x-3, y-3) instead of (x-7, y-7). Sums span
4 differences instead of 8. Easy to copy-paste-bug from the
luma Plane if you don't notice the constants change.
Test highlights:
- DC quadrants: distinct expected values per quadrant (16, 16,
40, 28 from asymmetric top/left halves) — any quadrant mix-up
would surface immediately. Hand-derived from the formulas
in the test comment.
- Plane uniform: all-100 context → all-100 output (a = 3200,
H = V = 0, (3200+16) >> 5 = 100 exactly).
- Plane gradient: top + left = 0..7, hand-derives pred[0][0] = 1
and pred[7][7] = 15 via the full arithmetic chain (H = V = 56,
b = c = 30, a = 224). Same hand-traced spec-walkthrough as
the Intra_16x16 Plane gradient test.
Verified on hertz:
$ ./build/test_intra_pred_chroma8x8
Horizontal (mode 1) PASS
Vertical (mode 2) PASS
DC quadrants (mode 0) PASS
Plane uniform (mode 3) PASS
Plane gradient (mode 3) PASS (corners 1, 15)
ALL Intra_8x8 chroma mode references PASS
All 5 tests PASS first try. The DC quadrant correctness is meaningful
(4 different formulas in one kernel) and the Plane gradient corners
validate the slope=34 + centre=(x-3,y-3) constants vs the luma
equivalents.
Combined coverage after this PR:
- Intra_4x4 luma: 9 modes ✓ (PR #12, all 9 PASS)
- Intra_16x16 luma: 4 modes ✓ (PR #13, all 5 tests PASS)
- Intra_8x8 chroma: 4 modes ✓ (this PR, all 5 tests PASS)
- Intra_8x8 luma (High profile): 9 modes + smoothing — pending.
Remaining backlog: Intra_8x8 luma (High profile, 9 modes + 1-2-1
smoothing pre-filter — distinct algorithm from Intra_4x4 because of
the pre-filter), neighbour-availability fallback, dispatch wrappers.
Second piece of the intra-prediction primitive set after PR #12
(Intra_4x4 luma 9 modes). Covers the Intra_16x16 luma MB type
per H.264 §8.3.2: 4 modes (Vertical, Horizontal, DC, Plane).
Scope:
- tests/h264_intra_pred_16x16_ref.c — 4 spec-derived modes.
Same FFmpeg-style interface as the 4x4 sibling:
void daedalus_h264_pred_16x16_<name>_ref(uint8_t *dst, ptrdiff_t stride);
Assumes all neighbours valid (interior-MB case).
The Plane mode is the algorithmically heaviest of the four —
spec §8.3.2.4 has two slope sums (H, V) over the asymmetric
top/left contexts, a clipped quadratic evaluation per cell,
and a top-left-corner participant at i=7 / j=7. Implementation
follows the spec straightforwardly with `clip_u8` on the final
saturating cast.
- tests/test_intra_pred_16x16.c — 5 test cases:
* V, H, DC: standard contexts (gradient top / gradient left /
small uniform pair).
* Plane (uniform): all neighbours = 100 → H = V = 0 →
output = (16*200 + 16) >> 5 = 100. Verifies the
orientation-free portion of the formula.
* Plane (gradient): top + left both 0..15, spec-derived
corner expectations pred[0][0] = 1 and pred[15][15] = 31.
The arithmetic chain (H = V = 400 → b = c = 31, a = 480)
is fully hand-traced in the test comment so the expected
values are auditable.
- CMakeLists.txt — new test_intra_pred_16x16 binary; pure-CPU
library, no daedalus_core dependency (same separation as the
4x4 ref).
Verified on hertz:
$ ./build/test_intra_pred_16x16
Vertical (mode 0) PASS
Horizontal (mode 1) PASS
DC (mode 2) PASS
Plane (mode 3, uniform) PASS
Plane (mode 3, gradient) PASS (corners 1, 31)
ALL Intra_16x16 mode references PASS
Plane mode being right first try is meaningful — H/V sums, b/c
slope shifts, and the a-baseline arithmetic have many sign / index
error opportunities. The asymmetric gradient test would have caught
any of them; it didn't.
What this does NOT cover (still in the intra-pred backlog):
- Intra_8x8 chroma (4 modes per H.264 §8.3.3).
- Intra_8x8 luma (High profile, 9 modes per §8.3.2.1 + the 1-2-1
smoothing pre-filter — distinct algorithm from Intra_4x4).
- Neighbour-availability fallback for boundary MBs.
- Dispatch wrappers (same architectural question as before — wait
for decoder Stage 2a strategy decision).
Lays the bit-exact gate for H.264 §8.3.1.4 Intra_4x4 luma prediction.
Spec-derived C reference covering all 9 modes; standalone test
exercises each against hand-computed expected 4x4 patterns.
Why fourier (not the decoder) gets this: it's a reusable spec-level
primitive — both daedalus-decoder (Phase 1 Stage 2a intra prediction)
and any future shader work will need the same bit-exact reference.
Putting it in fourier alongside the IDCT / deblock refs keeps the
"spec implementations" library cohesive.
Why CPU C reference, not NEON or QPU: the vendored FFmpeg snapshot
(external/ffmpeg-snapshot/libavcodec/aarch64/) has h264dsp/idct/qpel
but NOT h264pred. Vendoring h264pred_neon.S would expand the snapshot
surface; deferring that pending real perf data. Per the cycle 9
NEON benches that take ~5 ns per 8x8 qpel block, intra prediction
at ~5 ns per 4x4 block × 16 blocks/MB × 8160 MBs = ~650 us/frame at
1080p — well inside budget even at NEON, and much further inside at
plain C. Not the critical-path concern.
Scope:
- tests/h264_intra_pred_4x4_ref.c — 9 prediction modes per
H.264 spec §8.3.1.4 sub-clauses, FFmpeg-style interface:
void daedalus_h264_pred_4x4_<name>_ref(uint8_t *dst, ptrdiff_t stride);
Reads top/top-right/left/top-left neighbours from dst[-stride/-1]
offsets, writes 4×4 output at dst[0..3][0..3]. Assumes all 13
neighbour bytes are valid (interior-MB case; availability
fallbacks are caller-side per spec).
- tests/test_intra_pred_4x4.c — 10 cases:
* 9 uniform-context degenerate tests (one per mode), establishing
that nothing is structurally broken (all output cells must
equal the uniform input value).
* 1 asymmetric Vertical_Right sanity test with 16 distinct
expected cells hand-computed from spec §8.3.1.4.6 — the
"really exercise orientation + row/col arithmetic" gate.
- CMakeLists.txt — new test_intra_pred_4x4 binary (no daedalus_core
dependency; pure-CPU library doesn't need a context to construct).
Verified on hertz:
$ ./build/test_intra_pred_4x4
Vertical (mode 0) PASS
Horizontal (mode 1) PASS
DC (mode 2) PASS
DiagDownLeft (mode 3) PASS
DiagDownRight (mode 4) PASS
VerticalRight (mode 5) PASS
HorizontalDown (mode 6) PASS
VerticalLeft (mode 7) PASS
HorizontalUp (mode 8) PASS
VR asym (sanity) PASS
ALL 10 intra-4x4 mode references PASS
The VR asym test passed first try; the DC test fell on the first
attempt because my test expectation miscomputed the rounding shift
(I wrote 4, actual is 2 = (16+4)>>3). Fixed in the test. Reference
itself never had the bug.
What this does NOT cover (next-step backlog):
- Intra_16x16 luma prediction (4 modes per H.264 §8.3.2): vertical,
horizontal, DC, plane.
- Intra_8x8 chroma prediction (4 modes per H.264 §8.3.3): DC,
horizontal, vertical, plane.
- Intra_8x8 luma prediction (High profile, 9 modes per §8.3.2.1) —
these are the High-profile siblings of the modes in this PR with
the 1-2-1 smoothing pre-filter. Different but well-defined.
- Neighbour availability fallback (top-edge MB, left-edge MB,
slice-boundary, top-right unavailable in some positions).
- Dispatch wrappers — these refs aren't surfaced through
daedalus_dispatch_*(). Whether to do that depends on the
daedalus-decoder Stage 2a architecture (per-block CPU vs
per-diagonal GPU wavefront — TBD).
Closes the deblock matrix: adds the four bS=4 intra-strength loop
filters used at I-MB edges (and other boundaries where H.264
§8.7.2.1 forces boundary strength to 4). After this PR fourier
covers all 8 standard 8-bit 4:2:0 deblock combinations:
bS<4 bS=4
----- -----
luma_v ✓ (cycle 8 QPU) ✓ (CPU)
luma_h ✓ (CPU, PR #9) ✓ (CPU)
chrm_v ✓ (CPU, PR #10) ✓ (CPU)
chrm_h ✓ (CPU, PR #10) ✓ (CPU)
Scope:
- 4 new kernel enums (LV_INTRA=13, LH_INTRA=14, CV_INTRA=15,
CH_INTRA=16), all → CPU substrate in the recipe table.
- 4 new public dispatch fns + 4 recipe wrappers (defined via two
DEFINE_INTRA_DISPATCH / DEFINE_INTRA_RECIPE macros to keep the
boilerplate tight).
- 4 new extern decls for the vendored
ff_h264_{v,h}_loop_filter_{luma,chroma}_intra_neon symbols.
- C reference: tests/h264_intra_loop_filter_ref.c covers all four
orientations. Algorithm per H.264 §8.7.2.3:
Luma: per-side strong/weak filter selector
strong_p = (|p2-p0| < β) AND (|p0-q0| < (α>>2)+2)
strong_q = (|q2-q0| < β) AND (|p0-q0| < (α>>2)+2)
Strong updates p0/p1/p2 (and mirror); weak updates p0 only.
Chroma: always weak, only p0/q0 updated.
- daedalus_h264_deblock_meta is REUSED for intra dispatches; the
tc0[] field is ignored (bS=4 hardcodes the strength). Callers
can build a single edge list and route by kernel without an
extra struct.
- Test refactor: an intra_test_spec table + run_intra_test helper
drives all four orientations through one harness, keeping the
new test surface compact (~50 LOC for 4 kernels vs ~200 if each
had its own test_deblock_*_intra fn).
Verified on hertz (Pi 5 / V3D 7.1):
$ ./build/test_api_h264
=== Phase 8a API smoke: H.264 kernels via recipe dispatch ===
...
H.264 deblock luma v intra: 1024/1024 bytes bit-exact (100.0000%)
H.264 deblock luma h intra: 1024/1024 bytes bit-exact (100.0000%)
H.264 deblock chroma v intra: 256/256 bytes bit-exact (100.0000%)
H.264 deblock chroma h intra: 256/256 bytes bit-exact (100.0000%)
...
All 11 H.264 kernels bit-exact PASS — the deblock matrix is closed.
The bit-exact match on first try is meaningful for these kernels:
the strong/weak filter selector + per-side asymmetry would have
surfaced any sign / shift / rounding mistake immediately. The
C reference is now a usable spec checkpoint for the eventual QPU
shader work.
QPU shader follow-up: not in this PR. The intra path's 3-cell
per-side update + strong/weak branch is structurally more complex
than the bS<4 path that already has a V shader (v3d_h264deblock.spv).
Per the prior R-band logic for deblock, intra edges are < 20% of
total deblock work at typical bit-rates, so NEON-only at ~ 10 ns/edge
fits comfortably in the budget.
Continues the deblock buildout after PR #9 (luma_h). Adds the two
chroma orientations via the same recipe-table-routed-to-CPU pattern;
QPU shaders for chroma deblock are still a follow-up.
Scope:
- Public API: 4 new fns (dispatch + recipe wrapper × {v, h}).
- Internal: dispatch_h264_deblock_chroma_{v,h}_cpu calling the
vendored ff_h264_{v,h}_loop_filter_chroma_neon symbols.
- Recipe table: DAEDALUS_KERNEL_H264_DEBLOCK_CV = 11,
DAEDALUS_KERNEL_H264_DEBLOCK_CH = 12, both → CPU. Explicit
SUBSTRATE_QPU returns -1 (no shader yet).
- C reference: tests/h264_chroma_loop_filter_ref.c — covers both
orientations. Algorithm per H.264 §8.7.2.4 (bS<4 chroma inter):
tC = tc0_seg + 1 (no luma-style ap/aq side bonus); only p0/q0
are updated (chroma never modifies p1/p2/q1/q2).
- Tests: test_deblock_chroma_v (8x4 tile, edge at row 2) +
test_deblock_chroma_h (4x8 tile, edge at col 2), 4 segments x
2 cells per segment per spec.
Verified on hertz (Pi 5 / V3D 7.1):
$ ./build/test_api_h264
=== Phase 8a API smoke: H.264 kernels via recipe dispatch ===
H264_IDCT4 recipe substrate: 2 (1=CPU, 2=QPU)
H264_IDCT8 recipe substrate: 2
H264_DEBLOCK_LV recipe substrate: 2
H264_QPEL_MC20 recipe substrate: 2
H264_DEBLOCK_LH recipe substrate: 1 (CPU, no QPU H shader yet)
H264_DEBLOCK_CV recipe substrate: 1 (CPU)
H264_DEBLOCK_CH recipe substrate: 1 (CPU)
H.264 IDCT 4x4: 2048/2048 bytes bit-exact (100.0000%)
H.264 IDCT 8x8: 2048/2048 bytes bit-exact (100.0000%)
H.264 deblock luma v: 2048/2048 bytes bit-exact (100.0000%)
H.264 deblock luma h: 1024/1024 bytes bit-exact (100.0000%)
H.264 deblock chroma v: 256/256 bytes bit-exact (100.0000%)
H.264 deblock chroma h: 256/256 bytes bit-exact (100.0000%)
H.264 qpel mc20: 1024/1024 bytes bit-exact (100.0000%)
All 7 kernels bit-exact PASS. Chroma test sizes are smaller (256
bytes per orientation) because the per-MB chroma deblock surface is
smaller than luma — accurate to the production geometry.
Why no QPU shader yet (per the established pattern):
- Chroma deblock is ~25% of total deblock work at 4:2:0 (one quarter
the pixel count of luma per MB) — modest QPU win even after the
shader exists.
- Same R-band considerations as the luma _h follow-up: the V shader
transpose isn't mechanical, and the 8-cell tile is small enough
that NEON's per-edge cost (~3 ns) is already inside the budget.
- Total bench at 1080p: 8160 MBs × 4 chroma edges × 3 ns = ~100 us.
Negligible compared to the IDCT layer's 10 ms (CPU NEON).
Now coverage in fourier for the bS<4 8-bit 4:2:0 deblock matrix is
complete: luma_v ✓, luma_h ✓, chroma_v ✓, chroma_h ✓. Remaining
deblock work: bS=4 intra variants (luma + chroma, V + H).
What this unblocks downstream:
- daedalus-decoder Stage 4 deblock can now dispatch all four bS<4
edge categories that a typical inter MB needs.
The previous commit unintentionally added .claude/scheduled_tasks.lock
which is an agent-runtime artefact, not source. Untrack it and add
.claude/ to .gitignore so it stays out of future commits.
Adds the horizontal-edge sibling of cycle 8's deblock_luma_v. The
vendored FFmpeg snapshot already includes ff_h264_h_loop_filter_luma_neon
in libavcodec/aarch64/h264dsp_neon.S — this PR wires up the symbol,
the bit-exact reference, and the recipe-table entry so daedalus-decoder
and other consumers can call the H variant through the same dispatch
shape they use for _v.
Scope:
- Public API: daedalus_dispatch_h264_deblock_luma_h(ctx, sub, ...)
+ daedalus_recipe_dispatch_h264_deblock_luma_h(ctx, ...) wrapper.
- Internal: dispatch_h264_deblock_h_cpu() calls the NEON entry.
- Recipe table: new DAEDALUS_KERNEL_H264_DEBLOCK_LH = 10, mapped
to DAEDALUS_SUBSTRATE_CPU until a QPU shader is written. An
explicit SUBSTRATE_QPU request on the H dispatch returns -1
(fails fast, no silent CPU degradation).
- C reference: tests/h264_h_loop_filter_luma_ref.c — the
column-axis transpose of h264_deblock_ref.c. Same per-segment
kernel; pix[-4..+3] accesses cols instead of rows*stride.
- Test: test_api_h264 grows a test_deblock_h() with 8 tiles
(8 cols x 16 rows each, edge at col 4), random alpha/beta/tc0;
compares NEON dispatch against reference byte-for-byte.
Verified on hertz (Pi 5 / V3D 7.1):
$ ./build/test_api_h264
=== Phase 8a API smoke: H.264 kernels via recipe dispatch ===
H264_IDCT4 recipe substrate: 2 (1=CPU, 2=QPU)
H264_IDCT8 recipe substrate: 2
H264_DEBLOCK_LV recipe substrate: 2
H264_QPEL_MC20 recipe substrate: 2
H264_DEBLOCK_LH recipe substrate: 1 (CPU, no QPU H shader yet)
H.264 IDCT 4x4: 2048/2048 bytes bit-exact (100.0000%)
H.264 IDCT 8x8: 2048/2048 bytes bit-exact (100.0000%)
H.264 deblock luma v: 2048/2048 bytes bit-exact (100.0000%)
H.264 deblock luma h: 1024/1024 bytes bit-exact (100.0000%)
H.264 qpel mc20: 1024/1024 bytes bit-exact (100.0000%)
All 5 kernels bit-exact PASS. The new H variant joins the suite
with 1024 random-input bytes per tile x 8 tiles.
Why CPU-only for now: the daedalus-decoder downstream needs the H
edge dispatched somewhere — even at CPU NEON cost (~6 ns/edge per
the cycle 8 M3 baseline) a frame's worth at 1080p is
~ 8160 MBs * 4 edges = 32 640 edges = ~200 us — well inside the
30 fps budget. Writing the V3D H-edge shader is a follow-up
(would be cycle 8' or similar; the V-edge shader's transpose isn't
mechanical because of how the workgroup organisation maps to columns
vs rows).
Backlog addition (out of scope for this PR):
- V3D shader for the H variant (mirror of v3d_h264deblock.spv).
- bS=4 intra-strength filter (different algebra; both _v and _h).
- Chroma deblock luma_v/_h (8-cell variants).
Per the QPU-default substrate decree 2026-05-23, cycle 6 (H.264
IDCT 4x4 + add) was the highest-priority H.264 kernel to flip
from NEON-only to QPU-capable. The same shape as VP9 IDCT 8x8
(cycle 1) — two-pass butterfly with shared-memory transpose —
but at 4x4 scale: 4 lanes per block, 16 blocks per WG.
What's added:
- src/v3d_h264_idct4.comp: GLSL compute shader implementing
the H.264 §8.5.12.1 1D butterfly twice (row pass then column
pass), with (val + 32) >> 6 rounding and clip-to-u8 add to
dst. Block memory layout is column-major (matches FFmpeg
`ff_h264_idct_add_neon` convention).
- CMakeLists: glslang rule + install entry for v3d_h264_idct4.spv.
- dispatch_h264_idct4_qpu() in daedalus_core.c: lazy pipeline
init, 3 SSBOs (coeffs / dst / meta as uvec4), push-constant
(n_blocks, dst_stride), 16 blocks per WG dispatch. Matches
the existing dispatch_*_qpu patterns; uses
v3d_runner_create_buffer / destroy_buffer (will swap to
pool API once PR #6 lands).
- daedalus_dispatch_h264_idct4() replaces ROUTE_CPU_ONLY with
the same CPU/QPU substrate switch the deblock dispatch uses.
- daedalus_recipe_substrate_for(H264_IDCT4) returns QPU now
that the shader exists.
Verification on hertz (Pi 5 + V3D 7.1):
$ ./test_api_h264
=== Phase 8a API smoke: H.264 kernels via recipe dispatch ===
H264_IDCT4 recipe substrate: 2 (1=CPU, 2=QPU)
H264_IDCT8 recipe substrate: 1
H264_DEBLOCK_LV recipe substrate: 2
H264_QPEL_MC20 recipe substrate: 1
H.264 IDCT 4x4: 2048/2048 bytes bit-exact (100.0000%) ← QPU
H.264 IDCT 8x8: 2048/2048 bytes bit-exact
H.264 deblock luma v: 2048/2048 bytes bit-exact
H.264 qpel mc20: 1024/1024 bytes bit-exact
The AUTO-substrate path now picks QPU for H.264 IDCT 4x4, and
the output is bit-exact against the C reference (which is
identical to the NEON .S code by construction — same FFmpeg
upstream).
Remaining cycle-6/7/9 work in task #165:
- cycle 7: H.264 IDCT 8x8 (template same shape; 8 lanes per
block, fewer blocks per WG)
- cycle 9: H.264 luma qpel mc20 (different shape — 6-tap MC
not a transform)
This commit lands the cycle-6 piece of task #165.
Per the user decree 2026-05-23 — "what can be done in QPU will
be done in QPU" — this lands two coupled changes that flip
production-decode kernels with existing V3D shaders from
CPU-by-recipe to QPU-by-recipe:
1) daedalus_recipe_substrate_for() returns SUBSTRATE_QPU for
every kernel that has a shipped V3D compute shader:
cycle 1 VP9 IDCT 8x8 QPU (was QPU; unchanged)
cycle 2 VP9 LPF wd=4 QPU (was QPU; unchanged)
cycle 3 VP9 MC 8h QPU (FLIPPED from CPU — v3d_mc_8h.spv)
cycle 4 VP9 LPF wd=8 QPU (was QPU; unchanged)
cycle 5 AV1 CDEF 8x8 QPU (FLIPPED from CPU — v3d_cdef.spv)
cycle 6 H.264 IDCT 4x4 CPU (no shader yet; task #165)
cycle 7 H.264 IDCT 8x8 CPU (no shader yet; task #165)
cycle 8 H.264 deblock luma-v QPU (FLIPPED from CPU — v3d_h264deblock.spv)
cycle 9 H.264 qpel mc20 CPU (no shader yet; task #165)
The R-band cost/benefit framework still applies but is now
superseded for substrate selection by the decree. Where R
stays RED, the cost is in dispatch overhead, which is a
fixable engineering issue (tasks 160 buffer-pool, 161
persistent cmdbuf, 162 dmabuf import).
2) daedalus_ctx_create_no_qpu() now honours an env-var override:
set DAEDALUS_FORCE_QPU=1 in the process and create_no_qpu
silently escalates to a full daedalus_ctx_create(). Lets
the libavcodec substitution shims in marfrit-packages (which
pthread_once a create_no_qpu ctx — see
libavcodec/aarch64/h264_idct_daedalus.c) fire QPU paths
without rebuilding those patches.
Firefox / mpv consumers stay on the Vulkan-free path by
default (env var unset). The daedalus-v4l2 daemon will set
DAEDALUS_FORCE_QPU=1 explicitly before dlopen'ing libavcodec
(separate daedalus-v4l2 follow-up).
Smoke (hertz, Pi 5, kernel 6.18.29):
=== test_api_h264 ===
H264_IDCT4 recipe substrate: 1 (1=CPU, 2=QPU)
H264_IDCT8 recipe substrate: 1
H264_DEBLOCK_LV recipe substrate: 2 ← flipped
H264_QPEL_MC20 recipe substrate: 1
H.264 IDCT 4x4: 2048/2048 bytes bit-exact
H.264 IDCT 8x8: 2048/2048 bytes bit-exact
H.264 deblock luma v: 2048/2048 bytes bit-exact ← QPU path
H.264 qpel mc20: 1024/1024 bytes bit-exact
=== test_api_idct === all substrates (CPU/QPU/AUTO) bit-exact
=== test_api_lpf === all substrates bit-exact wd=4 and wd=8
The dispatch wrapper's fall-through logic (eff == SUBSTRATE_QPU
&& !ctx_has_qpu(ctx) → eff = SUBSTRATE_CPU) handles the case
where the recipe says QPU but the consumer didn't opt in — it
falls back to CPU silently, no regression.
Closes daedalus-fourier tasks #163, #164.
Refs the 2026-05-23 "QPU default substrate" decree.
Phase 2 of the QPU-default substrate campaign — eliminate
vkAllocateCommandBuffers from the dispatch hot path.
Attaches a VkCommandBuffer to each v3d_pipeline, allocated once in
v3d_runner_create_pipeline() and freed in destroy_pipeline(). The
five dispatch_*_qpu sites switch from v3d_runner_alloc_cmdbuf() to
v3d_runner_pipeline_cmdbuf_reset() — vkResetCommandBuffer is O(1)
versus the driver-side allocation walk. Pool was already created
with VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT so reset is
permitted.
Microbench (hertz, Pi 5, kernel 6.18.29, V3D 7.1):
before (task 160 pool only):
steady-state p50: 76.44 us
steady-state mean: 77.95 us
after (task 160 pool + task 161 persistent cb):
steady-state p50: 54.56 us
steady-state mean: 56.00 us
-> 28% per-dispatch reduction
The remaining ~54 us steady-state is dominated by vkQueueWaitIdle +
shader execution + the two memcpy(in/out) on the dst buffer — task
162 (dmabuf import for dst) targets the memcpy half.
test_api_idct stays bit-exact across CPU/QPU/AUTO substrates.
Refs daedalus-fourier task #161.
Per the QPU-default substrate decree 2026-05-23: the per-dispatch
vkAllocateMemory in dispatch_*_qpu was the biggest single fixable
contributor to QPU dispatch overhead. This pools v3d_buffer
allocations by power-of-2 size class so the second-and-subsequent
dispatch hits a freelist instead of paying ~10-50us of Mesa-V3D7
memory-allocation cost per call.
API additions (v3d_runner.h):
- v3d_runner_acquire_buffer(): pulls from per-bucket freelist;
falls through to v3d_runner_create_buffer() on miss.
- v3d_runner_release_buffer(): pushes back onto the freelist; the
backing VkBuffer/VkDeviceMemory only get vkFreeMemory'd in
v3d_runner_destroy().
- v3d_runner_pool_total_bytes(): diagnostic watermark.
Size classes 2^8..2^23 (256 B to 8 MiB). Oversize requests fall
through to non-pooled (vkAllocateMemory) for both ends — pool stays
correct, just degenerates to old behaviour for those calls.
Migration: daedalus_core.c dispatch_*_qpu paths globally swap
create_buffer → acquire_buffer and destroy_buffer → release_buffer.
All five QPU dispatch functions (idct8 / lpf / mc_8h / cdef /
h264_deblock) now reuse buffers across calls. test_api_idct stays
bit-exact (4096/4096 bytes on CPU/QPU/AUTO substrates on hertz).
Microbench (tests/bench_pool_overhead.c) on hertz (Pi 5,
6.18.29+rpt-rpi-2712, V3D 7.1):
call 0: 434.89 us (cold — 3x vkAllocateMemory)
call 1: 100.06 us (pool hit on all 3 buffers)
steady-state:
p50: 76.44 us
p90: 90.52 us
mean: 77.95 us
first-call / steady-state ratio: 5.7x
The remaining ~76us steady-state is dominated by vkQueueWaitIdle +
shader execution + per-call descriptor-set update + command-buffer
allocation — addressed in follow-on tasks 161 (persistent cmdbuf)
and 162 (dmabuf import for dst, eliminates memcpy in/out).
Refs daedalus-fourier task #160.
The pkg-config file was generated at *configure* time with
`prefix=${CMAKE_INSTALL_PREFIX}`, which captured whatever
CMAKE_INSTALL_PREFIX happened to be set to at `cmake -B build`
time — typically the default `/usr/local`. `cmake --install
build --prefix /foo` then put the files under /foo but the .pc
still pointed pkg-config at /usr/local/include and /usr/local/lib,
which broke downstream consumers configuring against the install
tree.
Concrete bite encountered today on hertz: the daedalus-v4l2 daemon
CMake configure on a /tmp/df-prefix install tree resolved
DAEDALUS_FOURIER_INCLUDE_DIRS to /usr/local/include (empty path on
the test host), so main.c failed to find <daedalus.h>.
Fix: write the .pc with `prefix=${pcfiledir}/<rel>` where <rel> is
the configure-time-computed relative path from
<prefix>/<libdir>/pkgconfig back to <prefix>. pkg-config
substitutes ${pcfiledir} with the actual on-disk location of the
.pc at lookup time, so the resolved prefix tracks wherever the
install tree is moved to — including DESTDIR-staged builds, apt
package installs, and ad-hoc `cmake --install --prefix /tmp/foo`
test installs.
The relative-path computation handles GNUInstallDirs layouts that
add multiarch tuples (Debian's lib/aarch64-linux-gnu) without
hard-coding `../..`. Tested on hertz (Debian trixie, libdir=lib):
prefix=${pcfiledir}/../../
...
$ pkg-config --variable=prefix daedalus-fourier
/tmp/df-prefix-test/lib/pkgconfig/../../
# mv preserves relocation:
$ mv /tmp/df-prefix-test /tmp/df-prefix-moved
$ pkg-config --variable=prefix daedalus-fourier
/tmp/df-prefix-moved/lib/pkgconfig/../../
This unblocks the daedalus-v4l2 daemon out-of-tree builds against
local daedalus-fourier installs and is a prerequisite for tidy
test-rig deployments (per the hertz reload session 2026-05-23).
Original draft (PR #3) speculated wrongly on host-to-SoC mapping:
- hertz and tesla were listed under RK3588. Verified via
/proc/device-tree/compatible: both are raspberrypi,5-model-b /
brcm,bcm2712 (tesla is an LXD container hosted on hertz, so
necessarily shares the host SoC).
- boltzmann (the only actual RK3588 in the fleet, 32 GB, kernel-
dev / MCP hub, 8 W always-on) was omitted entirely.
- noether (Pi 4 / BCM2711, the user's interactive workstation,
where Firefox and mpv actually run) was omitted entirely.
Corrects the per-SoC coverage table:
BCM2712 Pi 5 — higgs, hertz, broglie, tesla (LXD on hertz)
BCM2711 Pi 4 — noether (workstation), dcw3, dcw2
RK3588 — boltzmann
Allwinner H6 — (not in fleet)
Reasoning consequences:
- Pi 5 row is now four hosts but one SoC. Adding a fifth Pi 5
doesn't pressure-test the architecture; substrate decisions
are identical across the row.
- The realistic forcing function for the Pi 4 path is "HW decode
on noether matters and rpivid is still unstable upstream" —
noether is a daily-driver Pi 4 workstation, so this is closer
than the original draft implied.
- The realistic forcing function for an RK3588 caps file is
"AV1 playback on boltzmann matters" — rkvdec doesn't cover
AV1, so Mali Valhall compute substrate becomes the only HW
acceleration option there.
"Re-read this when" list at the top + "Why deferred" section
+ decision log all updated. No change to the architecture sketch
(caps directory, plugin layout, two-backend conclusion) — those
were correct in the original; only the host-to-SoC mapping
underneath them was wrong.
Refs PR #3 (the merged original).
Captures the design draft for generalizing the daedalus daemon
across the fleet (Pi 5 + Pi 4 + RK3588 + Allwinner H6) while
explicitly DEFERRING the work until a second SoC creates a
forcing function.
Key conclusions:
- The recipe layer in daedalus-fourier (daedalus_recipe_dispatch_*)
already abstracts substrate selection per kernel; scaling to
multi-SoC is a data extension (caps/<soc>.toml), not new
architecture.
- libva-v4l2-request-fourier already abstracts over any V4L2
stateless decoder node; the cross-SoC seam is at the V4L2
device level, where the upstream stateless API put it.
- The conceptual gap is that hardware decoders are NOT made of
shaders — rkvdec on RK3588, Hantro G1/G2, VPU8, rpi-hevc-dec
on Pi 5 are bitstream-in NV12-out monoliths. A generalized
daemon needs TWO backends: substrate-composed (today's path)
and codec-level pass-through to vendor V4L2 decoders.
- On RK3588 + every codec rkvdec supports, the daedalus daemon
is bypassed entirely — libva talks to rkvdec directly. The
daemon is only ever in the path on SoCs where at least one
codec needs substrate composition.
Forcing functions for revisiting:
- Pi 4 enters daily use with rpivid still unstable upstream
(would require a V3D4 substrate-composed path with its own
caps file and substrate verdicts).
- A third-party user needs to swap shaders for V3D firmware
experiments without rebuilding the daemon.
- An x86 / panvk host enters the fleet needing dynamic SoC
discovery rather than build-time pinning.
Until then: keep daedalus daemon Pi 5 specific, push cross-SoC
abstraction up to libva-v4l2-request-fourier (which already does
most of it).
Document covers:
- current stack diagram (cycles 1-9 closed)
- per-SoC codec coverage matrix
- refined sketch: /usr/lib/daedalus/{shaders,caps,plugins}
- illustrative bcm2712.toml + rk3588.toml caps files
- where it gets hard (probing, fallback, stateful vs stateless,
CI matrix, libva node selection)
- open questions
- decision log
No code changes; document only.
Refs reauktion/daedalus-v4l2#11 substitution arc closing; pivot
to bug-fix backlog (#145 daemon SEGV, #146 D-state) is the next
work block once cycle 9 deploys.
Extends daedalus-fourier with daedalus_recipe_dispatch_h264_qpel_mc20
so libavcodec.so can route H264QpelContext.put_h264_qpel_pixels_tab[1][2]
through the recipe layer instead of ff_put_h264_qpel8_mc20_neon directly.
API additions (header + library):
- daedalus_h264_qpel_meta { dst_off, src_off }
- daedalus_dispatch_h264_qpel_mc20(ctx, sub, dst, src, stride,
n_blocks, meta)
- daedalus_recipe_dispatch_h264_qpel_mc20(...) (AUTO wrapper)
- DAEDALUS_KERNEL_H264_QPEL_MC20 = 9 in the recipe-query enum
- daedalus_recipe_substrate_for() returns CPU NEON for cycle 9
The 6-tap horizontal half-pel filter signature matches FFmpeg's
H264QpelContext convention exactly: dst and src share a single stride
and src already points at output column 0 (filter reads cols -2..+3).
Single-stride API to make the marfrit-packages FFmpeg shim a
straight pointer-pass; no buffer rearrangement.
Verdict per docs/k9_h264qpel_mc20.md: CPU NEON. Per-block 7.6 ns
gives 135x margin over 30 fps 1080p; QPU dispatch floor at ~250 ns
makes any V3D shader strictly worse. Recipe table reflects that —
the recipe_dispatch entry is a one-line forward to the CPU path.
CMakeLists changes:
- h264qpel_neon.S added to the daedalus_core static lib (only the
bench targets owned it before; now the public API needs it too)
- tests/h264_qpel8_mc20_ref.c added to the test_api_h264 target
Phase 8a/8b smoke gains a 4th case (test_qpel_mc20): 1024/1024
bytes bit-exact via daedalus_recipe_dispatch_h264_qpel_mc20.
Refs reauktion/daedalus-v4l2#11 — substitution arc step 2 cycle 9.
Make daedalus_core installable so sibling consumers (Phase 8 V4L2
daemon, future libva-v4l2-request-fourier integration tests, etc.)
can `pkg_check_modules(DAEDALUS REQUIRED daedalus-fourier)` against
a system-installed copy.
Installs:
- lib/libdaedalus_core.a
- include/daedalus.h
- lib/pkgconfig/daedalus-fourier.pc
- share/daedalus-fourier/shaders/*.spv (only when
DAEDALUS_BUILD_VULKAN is ON; consumers using
daedalus_ctx_create_no_qpu() don't need them)
pkg-config surfaces the static-archive transitive deps via
Libs.private (-lpthread -ldl -lm) and Requires.private (vulkan),
so a consumer doing `pkg-config --static --libs daedalus-fourier`
gets the full link line. Non-static consumers (using the
no_qpu path) get just `-ldaedalus_core`.
No behaviour change to existing tests / benches.
Verified on hertz (Pi 5, dev host): clean build, all 7 SPIR-V
shaders + the static lib + the header + the .pc file land in
the install prefix.
User created the sibling repo under reauktion/ org. Updates
all 5 cross-links in the README.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The Phase-0-era README is updated to reflect the kernel-library
project's actual state:
- Status: 9 cycles closed (VP9 IDCT/LPF/MC, AV1 CDEF, H.264
IDCT4/IDCT8/deblock/MC) with deployment recipe table as the
headline result.
- Architecture: clarifies that 3 kernels deploy on QPU primary,
6 on CPU primary, 2 with opportunistic-QPU helper paths;
V4L2 wrapper is the sibling daedalus-v4l2 (Option B + γ +
sibling per locked Phase 8 architecture).
- Layout: shows actual repo structure (include/, src/, tests/,
docs/k*_phase*.md, external/ffmpeg-snapshot + dav1d-snapshot).
- Build + run: concrete cmake commands and example bench
invocations.
- Consuming the kernel library: code snippet showing the
public API (daedalus_ctx_create, daedalus_recipe_dispatch_*).
- Conventions: updated dev process reference, current
claude-noether SSH alias convention.
- Sibling projects: added daedalus-v4l2 link.
Old "single-kernel proof-of-concept negative result will close
the project" framing replaced — the negative result test passed;
project is alive and now in deployment phase.
Project voice (Daedalus myth, higgs framing, honest-target
posture) preserved.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Last unmeasured H.264 kernel. mc20 picked as representative
(horizontal half-pel, 6-tap filter; canonical for the H.264 luma
qpel family). M1 PASS 10000/10000 first try, M3 = 131.477
Mblock/s on a single core (7.6 ns/block), 135x the 1080p30 floor.
Per the cycles 6+7 lightweight-kernel rationale, Phase 4 deferred:
QPU dispatch floor (~250 ns/block) is 33x above the NEON per-block
cost; R9 ≈ 0.03 deep RED. No realistic QPU offload value.
Generalization: all H.264 luma MC variants (mc02, mc11, mc22,
etc.) will share this verdict. No need to measure each variant
individually.
H.264 NEON is dramatically faster than VP9 NEON across the board:
- IDCT 4x4: 175 vs N/A (no VP9 analog)
- IDCT 8x8: 151 vs 8.2 Mblock/s (18x faster)
- MC 6/8-tap: 131 vs 7.0 (19x faster)
- Deblock: 92 vs 48 Medge/s (2x faster)
H.264 deployment recipe: all CPU NEON except deblock (opportunistic
QPU). On a Pi 5 running H.264-only, the QPU is mostly idle.
Cycles 1-9 complete. Public API exposes all 9.
Next: daedalus-v4l2 sibling repo per locked Phase 8 architecture
(B + γ + sibling), then README polish.
- external/ffmpeg-snapshot/libavcodec/aarch64/h264qpel_neon.S
vendored (1467 lines, all qpel variants)
- tests/h264_qpel8_mc20_ref.c: 40-line C ref (clip255 of
6-tap convolution)
- tests/bench_neon_h264qpel_mc20.c: M1 + M3 bench
- docs/k9_h264qpel_mc20.md: cycle 9 closure with comparison
matrix
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Wires QPU dispatch for cycles 3 (VP9 MC), 5 (AV1 CDEF), 8 (H.264
deblock) through the public API. These three kernels have recipe
substrate = CPU, but per Issue 003 the mixed-kernel helper value
is real — the dispatch path must exist so override-mode callers
can request QPU on the side.
Pattern mirrors dispatch_idct8_qpu (lazy pipeline + per-call SSBO
alloc + memcpy + dispatch + readback). Each kernel has its own
push-constant struct (mc_pc 3-field, cdef_pc 3-field, deblock_pc
2-field shared with lpf).
Notable bug caught + fixed in test_api_opportunistic_qpu: the
initial dispatch_mc_8h_qpu sized src_max using CPU-side reach
(src_off + 3 + 8 + 7*stride), but the QPU shader reads src[
src_off + row*stride + 0..14] for row=0..7. Last block had 3
uninitialized bytes → 99.8% match → 100% after fix.
After this commit, the public API surface fully covers cycles 1-8:
Cycle 1 (IDCT 8x8): CPU + QPU + AUTO bit-exact
Cycle 2 (LPF wd=4): CPU + QPU + AUTO bit-exact
Cycle 3 (MC 8h): CPU recipe; QPU override bit-exact
Cycle 4 (LPF wd=8): CPU + QPU + AUTO bit-exact
Cycle 5 (CDEF): CPU recipe; QPU override (untested in this
test — bench_v3d_cdef is the authoritative 3-way M1)
Cycle 6 (H.264 IDCT 4x4): CPU only (no QPU shader by recipe)
Cycle 7 (H.264 IDCT 8x8): CPU only
Cycle 8 (H.264 deblock luma-v): CPU recipe; QPU override bit-exact
Tests: test_api_opportunistic_qpu adds CPU-vs-QPU bit-exact
comparison for VP9 MC and H.264 deblock through the API.
test_api_idct, test_api_lpf, test_api_h264 still pass.
Per the locked Phase 8 architecture (project_phase8_architecture
memory): next session opens daedalus-v4l2 sibling repo with
Option B (kernel V4L2 shim + userspace daemon), Option γ (dlopen
FFmpeg parser).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Per goal "c8p3..c8p7, then p8 — surface if user intervention is
required": this is the surface point.
Kernel-library work is complete (cycles 1-8 all dispatchable via
public API, all CPU paths bit-exact, 3 QPU paths bit-exact, 3
opportunistic-QPU paths shader-exists-API-TODO).
V4L2 wrapper architecture needs 4 user decisions:
- Q1: Option A (v4l2loopback) / B (kernel V4L2 shim) / C (libva direct)
- Q2: Parser source: FFmpeg-vendored / dav1d+libvpx mix / FFmpeg-dlopen
- Q3: In-repo or sibling repo (daedalus-v4l2)?
- Q4: End-to-end test target (tiny clips / 1080p30 / both)
Recommended defaults (A / γ / sibling / both) documented;
explicit confirmation requested before committing to days of work
that locks in months of follow-on choices.
Mechanical TODOs that can proceed in parallel without blocking V4L2
decision: cycle 3+5+8 opportunistic-QPU dispatch wiring through API,
or cycle 9 (H.264 luma qpel MC, predicted CPU-only per cycle 6/7
pattern).
24 commits pushed to marfrit/daedalus-fourier this autonomous arc.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Extends include/daedalus.h with cycles 6, 7, 8 (H.264 IDCT 4x4,
IDCT 8x8, luma deblock luma-v). All recipe-substrate = CPU
(matches per-cycle Phase 7 verdicts).
src/daedalus_core.c: NEON-path implementations + recipe routing.
daedalus_core library now links the full FFmpeg H.264 NEON
snapshot (h264idct + h264dsp) plus existing VP9 + dav1d.
tests/test_api_h264.c: smoke test covering all 3 H.264 kernels
via daedalus_recipe_dispatch_*. All pass 2048/2048 bit-exact.
Public API coverage after this commit:
- Cycles 1 IDCT 8x8 + 2 LPF4 + 4 LPF8: CPU+QPU+AUTO dispatch
(test_api_idct, test_api_lpf, both pass)
- Cycle 3 MC 8h: CPU only (QPU dispatch stub returns -1)
- Cycle 5 CDEF: CPU only (QPU stub)
- Cycle 6 H.264 IDCT 4x4: CPU only (recipe + only NEON wired)
- Cycle 7 H.264 IDCT 8x8: CPU only
- Cycle 8 H.264 deblock: CPU only (QPU opportunistic — not wired
through API yet; bench_v3d_h264deblock exists for direct test)
Next Phase 8 sub-step: wire opportunistic QPU dispatch for cycles
3+5+8 through the API (so override-mode users can request QPU).
Then surface V4L2-wrapper architecture decisions to user.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
marfrit
claude-noether