v2.2.0 — RGA-accelerated 10-bit export, fenced and guarded

v2.2.0 — the per-frame copy moves to the 2D engine: RGA-accelerated 10-bit export, fenced and guarded

The export copy on RGA3. When a client imports a decoded surface, the driver copies the frame into the
exported buffer. For 10-bit that meant repacking NV15 to P010 on the CPU, every frame. v2.2.0 runs that
conversion on the RK3588's RGA3 2D engine instead. RKVA_RGA_P010=0 forces the old CPU repack if you need
to compare.

Fenced, not hopeful. RGA copies now wait on the destination buffer's read fences
(DMA_BUF_IOCTL_EXPORT_SYNC_FILE into rd.in_fence_fd) rather than assuming the consumer is finished, and
every copy is bounds-checked against the actual buffer size before submission.

Pinned to the cores that can do it. Only rga3_core0 and rga3_core1 have IOMMUs — jobs landing on
rga2 fail with scheduler core[4] unsupported mm_flag[0x0]. Jobs are pinned to the RGA3 cores, and RGA3's
stride rules (16-byte 8-bit, 64-byte 10-bit, even hstride) are verified before a job is queued.

librga initialised once. Implicit librga init was happening on the first blit, costing 100 ms+ mid-frame.
It now happens when the decode context is created.

8-bit stays on the CPU by default. The NV12 copy behaves as it did in 2.1.5. RKVA_RGA_COPY=1 opts into
the RGA imcopy path; RKVA_RGA_COPY=0 disables both RGA copy lanes entirely.

Unchanged: surfaces described by created depth (2.1.5), panthor/panfrost symlinks (2.1.5), surface pool
128 (2.1.4), 10-bit zero-copy (2.1.3), the H.264 PPS fix (2.1.2).

You may need to update your MPP library

If long 10-bit VP9 playback corrupts after roughly 18 minutes at 60 fps (45 minutes at 24 fps), with
mpp_rkvdec2 ...rkvdec-core: resetting for err 0x23 filling dmesg, that is not this driver — see
KI-10. It reproduces with Rockchip's own headless mpi_dec_test, which does not involve VA-API, a display,
or this driver at all.

The cause is in the librockchip_mpp your system is using. Several downstream builds carry a patch that
reverts upstream's fix[hal_vp9d]: not support fast mode for rk3588, re-enabling two parallel VP9 HAL tasks
on a SoC where upstream deliberately disables them. Upstream MPP is unaffected at every point tested,
including the exact commit those builds branch from.

Fix: use an MPP built from upstream — https://github.com/rockchip-linux/mpp

Workaround if you cannot change the library, at a cost of roughly 10-17% decode throughput (well clear
of real-time):

echo 1 > /proc/mpp_service/rkvdec-core1/disable_work

8-bit VP9 and HEVC Main10 are unaffected, verified past 70,000 frames each.

Install

sudo dpkg -i rockchip-vaapi-driver_2.2.0_arm64.deb
vainfo | head -3            # expect: Rockchip MPP VA-API Driver 2.2.0 (defcom5)

Requires a BSP kernel exposing /dev/mpp_service. If libva cannot find the driver, set
LIBVA_DRIVER_NAME=rockchip.

Verified

Built and install-tested on an Orange Pi 5B (RK3588S), kernel 6.1.0-1027-rockchip: 9 profiles advertised,
10-bit VP9 Profile 2 decoding zero-copy to a Wayland compositor.

Thanks to JFL on the Armbian forum, whose testing on an Orange Pi 5 Plus through the rc series caught
what a single board could not — including a clean result that disproved a theory I was sure of.