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

h264: deblock chroma_v + chroma_h (CPU/NEON, bS<4) #10

Merged
marfrit merged 1 commits from noether/h264-deblock-chroma into main 2026-05-24 21:55:58 +00:00
Conversation 0 Commits 1 Files Changed 5
+315
marfrit commented 2026-05-24 21:53:34 +00:00
Owner
Copy Link
Copy Source

Continues the deblock buildout. Adds the two chroma orientations (CV=11, CH=12 in the kernel enum) via the same recipe-to-CPU pattern PR #9 established for luma_h. Vendored FFmpeg already has both NEON symbols.

C reference derived from H.264 §8.7.2.4: chroma bS<4 uses tC = tc0_seg+1 (no luma-style ap/aq side bonus) and only updates p0/q0. Tile shapes: 8×4 for V (4 segments × 2 cols), 4×8 for H (4 segments × 2 rows). PASS 256/256 bytes bit-exact per orientation on hertz.

All 7 H.264 kernels in test_api_h264 now bit-exact: idct4, idct8, deblock_lv, deblock_lh, deblock_cv, deblock_ch, qpel_mc20. bS<4 8-bit 4:2:0 deblock matrix is complete. Remaining deblock backlog: bS=4 intra variants.

Continues the deblock buildout. Adds the two chroma orientations (CV=11, CH=12 in the kernel enum) via the same recipe-to-CPU pattern PR #9 established for luma_h. Vendored FFmpeg already has both NEON symbols. C reference derived from H.264 §8.7.2.4: chroma bS<4 uses tC = tc0_seg+1 (no luma-style ap/aq side bonus) and only updates p0/q0. Tile shapes: 8×4 for V (4 segments × 2 cols), 4×8 for H (4 segments × 2 rows). PASS 256/256 bytes bit-exact per orientation on hertz. All 7 H.264 kernels in test_api_h264 now bit-exact: idct4, idct8, deblock_lv, deblock_lh, **deblock_cv, deblock_ch**, qpel_mc20. bS<4 8-bit 4:2:0 deblock matrix is complete. Remaining deblock backlog: bS=4 intra variants.
marfrit added 1 commit 2026-05-24 21:53:34 +00:00
h264: deblock chroma_v + chroma_h (CPU/NEON, bS<4) a5c47aa51c 
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.
marfrit merged commit ce436bfd96 into main 2026-05-24 21:55:58 +00:00
marfrit deleted branch noether/h264-deblock-chroma 2026-05-24 21:55:58 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claude-noether (Claude (noether)) marfrit (Markus Fritsche)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marfrit/daedalus-fourier#10
Delete Branch "noether/h264-deblock-chroma"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?