T

claude-noether 5a8403a0bb Phase 1 v3 amendment: VP9 writes 4 segments not 5, narrow common-file split

Janet AMEND-cycle re-review of v2 returned 2 surgical corrections:

A. OFFSET_POC_HIGHBIT_REGS is HEVC/H.264 only — POC isn't a VP9
   concept. rkvdec-vdpu381-vp9.c writes 4 segments (COMMON,
   CODEC_PARAMS, COMMON_ADDR, CODEC_ADDR), not 5. Confirmed via BSP
   hal_vp9d_vdpu382.c — no poc_highbit reference anywhere in VP9
   path.

B. Common-file split narrowed: only spec-computation functions
   (probability init, segmap state, entropy update) move into a
   rkvdec-vp9-common.h header as static-inline helpers. The
   register-writing functions (config_seg_registers,
   config_ref_registers, config_registers) STAY in legacy
   rkvdec-vp9.c — they touch the legacy flat struct rkvdec_regs
   and can't share with the new vdpu381 struct without abstracting
   the register backend (over-engineering). The new backend
   rewrites these against the vdpu381 struct.

Bonus implementation hint: VDPU381_MODE_VP9=2 is already defined in
rkvdec-vdpu381-regs.h:22 — Casanova's v7.0 series had VP9 in mind
from the start, just didn't ship a backend.

RCB sizing tuning deferred to Phase 6 (vp9d_refine_rcb_size formula
from BSP).

With both amendments applied, Janet's verdict carry-forward is
PROCEED. Phase 2 implementation begins next session.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

2026-05-16 23:12:47 +00:00

phase0_findings.md

Phase 0: architectural correction — VP9 is a wiring patch, not a port

2026-05-16 22:57:36 +00:00

phase1_plan_v2.md

Phase 1 plan + v2 amendment per Janet architect review

2026-05-16 23:08:52 +00:00

phase1_plan_v3_amendment.md

Phase 1 v3 amendment: VP9 writes 4 segments not 5, narrow common-file split

2026-05-16 23:12:47 +00:00

phase1_plan.md

Phase 1 plan + v2 amendment per Janet architect review

2026-05-16 23:08:52 +00:00

README.md

Phase 0: open campaign + substrate findings

2026-05-16 22:48:26 +00:00

README.md

ampere-vp9-enablement

Stand-alone port + upstream-targeting work to enable VP9 hardware decode on Rockchip RK3588's rkvdec (vdpu381 register layout).

Status (2026-05-17 ~01:00)

Upstream RK3588 mainline rkvdec (Casanova v7.0 series, landed in Linux 7.0) supports H.264 + HEVC only. VP9 is on Collabora's stated roadmap but no WIP series has been posted to linux-media as of this campaign open. The legacy rkvdec-vp9.c (RK3399 / vdpu341 hardware) is feature-complete at 1042 lines but its register-config logic does not translate directly to vdpu381.

This campaign:

Ports VP9 enablement to vdpu381 register layout (new file rkvdec-vdpu381-vp9.c)
Registers VP9 V4L2 controls in vdpu38x_vp9_ctrl_descs[]
Adds VP9 fmt to vdpu381_coded_fmts[] with the new ops
Verifies bit-perfect HW vs SW decode (per feedback_compare_hw_against_sw_reference)
Proposes upstream via linux-media

Sibling campaign: ampere-kernel-decoders closed at HEVC bit-perfect (kernel-agent#14 + #15 are the prerequisite kernel fixes).

Scope (out of)

VP9 on RK3399 (works via legacy rkvdec-vp9.c already in mainline)
VP9 on hantro (hantro decoder on RK3588 doesn't expose VP9; this campaign targets rkvdec)
AV1 on RK3588 (separate work; AV1 is on hantro fdc70000 already + per Collabora)
VP8 (already works via hantro)
HEVC (closed in ampere-kernel-decoders)

Process

8-phase loop (per ~/.claude/CLAUDE.md). All commits via claude-noether identity. Patches will be RFC-quality and routed via kernel-agent once ready.