T

claude-noether 8dce724b8c Phase 0: architectural correction — VP9 is a wiring patch, not a port

Rockchip BSP inspection (mpp_rkvdec2.c, soc.cmake, vp9d/CMakeLists.txt)
overturns the initial premise. The same physical rkvdec IP on RK3588
accepts two register-protocol dialects within its 0x400 MMIO window:

- vdpu381 dialect (Casanova mainline naming) — H.264 + HEVC
- vdpu34x dialect (Rockchip legacy naming)    — VP9 + AVS2

BSP rkvdec_rk3588_data uses rkvdec_v2_hw_info + rkvdec_v2_trans, the
same dispatch tables as RK356X. MPP userspace builds the vdpu34x VP9
backend for RK3588 because no vdpu381 VP9 backend exists; it isn't
needed — the existing vdpu34x register layout drives this hardware.

Implication: mainline rkvdec_vp9_fmt_ops (vdpu34x layout, written for
RK3399) can drive RK3588 rkvdec hardware as-is. VP9 enablement is a
< 100-line wiring patch (third entry in vdpu381_coded_fmts[] + maybe a
codec-aware IRQ split), not a 1000+ line backend port.

Open questions revised; risk register tightened.

Phase 1 starts by reading BSP rkvdec_rk3588_hw_ops IRQ + power-on
routines to resolve O2/O3 (codec-aware dispatch needed? mode-switch
register?) and BSP vp9d_vdpu34x.c for max-resolution + RCB usage.

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

2026-05-16 22:57:36 +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

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.