Files

T

marfrit a4e7d8ab90 initial seed: retrofit campaign lineage from local working trees

panvk-bifrost campaigns (r1..r4 Vulkan compositor + r5.video1 Vulkan
video decode) shipped before this repo existed; the deliverable
patches live in marfrit-packages, but the reasoning chain, phase docs,
and source-state evidence lived only in local working trees on the
development host.

This retrofit imports:
- mesa-panvk-bifrost/   — r1..r4 era phase docs (iter1..iter18)
                          (libmali stub blobs at iter18/blob/ excluded
                          — 109MB of RE artifacts replaced with a README
                          pointer)
- mesa-panvk-bifrost-video/ — sibling campaign phase docs + probe
- evidence/             — frozen .tgz source snapshots at each milestone
                          (basis for the 0005 patch diff generation)

Future iterations should branch off here from day one, so each iter is
a commit rather than a snapshot. See [[feedback-session-local-process-pins]]
for the process drift this retrofit closes.

Total: 1.9 MB across 124 files.

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

2026-05-23 05:25:37 +02:00

4.7 KiB

Raw Permalink Blame History

Phase 0 — substrate lock for iter14

Goal: Brave actually engages VAAPI hardware video decode via libva-v4l2-request-fourier on PineTab2 / Mali-G52 r1 MC1 / RK3566, building on iter13's ANGLE-Vulkan unlock.

Closed 2026-05-20 after iter13 close. Brave currently plays bbb_1080p30_h264.mp4 in pure software:

Renderer pegs a core at 106% CPU
lsof /dev/video1 is empty (hantro-vpu V4L2 decoder idle)
chrome://gpu reports "Video Decode: Hardware accelerated" but this is misleading (a chromium-wide chrome://gpu lie pattern, see iter11 evidence)

Confirmed working in isolation

The libva backend itself is healthy:

$ pacman -Q libva libva-v4l2-request-fourier
libva 2.23.0-1
libva-v4l2-request-fourier 1:1.0.0.r380.9898331-1

$ LIBVA_DRIVER_NAME=v4l2_request vainfo
v4l2-request: auto-selected codec device: /dev/video1 + /dev/media0
Trying display: wayland
vainfo: VA-API version: 1.23 (libva 2.22.0)
vainfo: Driver version: v4l2-request
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointVLD            ← bbb
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD            ← bbb
      VAProfileH264MultiviewHigh      :	VAEntrypointVLD
      VAProfileH264StereoHigh         :	VAEntrypointVLD
      VAProfileVP8Version0_3          :	VAEntrypointVLD

VAProfileH264ConstrainedBaseline matches bbb_1080p30_h264.mp4's profile. Decoder hardware path is RK3566 → hantro-vpu (V4L2 stateless H.264 frontend) → /dev/video1.

What's missing from Brave's current invocation

The packaged brave-vulkan launcher uses iter9's combo:

brave --use-gl=disabled --enable-features=Vulkan --use-vulkan=native \
      --ozone-platform=x11 --no-sandbox --disable-gpu-sandbox --ignore-gpu-blocklist

Three reasons this can't engage VAAPI:

No LIBVA_DRIVER_NAME set. libva defaults to vendor-string-based driver autodetection, which on Mali-G52 / Mesa returns nothing useful — libva-v4l2-request-fourier is not auto-selected. Brave's vaapi_wrapper.cc:1658 then logs "vaInitialize failed: unknown libva error" (we saw this in iter11).
--use-gl=disabled. Brave's VAAPI delivery path uploads decoded frames into GL textures for compositing. With no GL backend, there's no destination for decoded surfaces → the wrapper bails before opening /dev/video1. iter13 unlocked the real GL backend (ANGLE on Vulkan); we need to use it here.
No AcceleratedVideoDecodeLinuxGL feature flag. Brave 148 has a Linux-specific Finch gate that disables VAAPI by default on non-Nvidia GPUs unless this feature is explicitly enabled.

Brave 148 VAAPI feature inventory

strings /opt/brave-bin/brave | grep VaapiOnEnableVideo produces:

AcceleratedVideoDecodeLinuxGL — primary Linux gate
AcceleratedVideoDecodeLinuxZeroCopyGL — zero-copy GPU→GL path
VaapiVideoDecoder — generic switch (likely needed too)
VaapiIgnoreDriverChecks — disables the driver-vendor allowlist (libva-v4l2-request-fourier reports "v4l2-request" as vendor, not on chromium's known-good list)
VaapiOnNvidiaGPUs — irrelevant here
Metrics: Media.HasAcceleratedVideoDecode.H264, Media.VaapiVideoDecoder.DecodeError, Media.VaapiVideoDecoder.VAAPIError

iter14 plan

Phase-bridge: iter11 was "VAAPI engagement on Brave" but stalled because:

ANGLE-Vulkan didn't work (no VK_EXT_transform_feedback) → iter12 forced --use-gl=disabled → no GL backend → no VAAPI delivery path

iter13 fixed the underlying ANGLE-Vulkan gap. iter14 now wires:

env: LIBVA_DRIVER_NAME=v4l2_request
flags: --use-gl=angle --use-angle=vulkan + --enable-features=Vulkan,AcceleratedVideoDecodeLinuxGL,AcceleratedVideoDecodeLinuxZeroCopyGL,VaapiVideoDecoder,VaapiIgnoreDriverChecks
keep: --ozone-platform=x11 --no-sandbox --disable-gpu-sandbox --ignore-gpu-blocklist

Regression probe (Phase 3): play bbb_1080p30_h264.mp4 in Brave with this combo and verify empirically:

lsof /dev/video1 shows Brave holding it
Renderer CPU drops well below 100% (HW decode = ~5-15% renderer CPU, software = 100-130% on this hardware)
chrome://media-internals shows the decoder is "VaapiVideoDecoder" not "FFmpegVideoDecoder"

Out of scope for iter14

Hardware encode (chrome://gpu reports "Video Encode: Software only"; libva-v4l2-request-fourier is decode-only).
VP9 / AV1 / HEVC. Even though some profiles are reported by vainfo, RK3566 lacks the hardware for these in this configuration.
Decoder buffer descriptor format mismatches (NV12 vs NV15/NV20). Will surface in Phase 4 if it does; defer until then.

— claude-noether, 2026-05-20

4.7 KiB Raw Permalink Blame History