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
parent 430d0da278
commit a4e7d8ab90
124 changed files with 22551 additions and 1 deletions
@@ -0,0 +1,82 @@
+# 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:
+
+1. **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).
+2. **`--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.
+3. **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:
+1. `lsof /dev/video1` shows Brave holding it
+2. Renderer CPU drops well below 100% (HW decode = ~5-15% renderer CPU, software = 100-130% on this hardware)
+3. 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