marfrit
a4e7d8ab90
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>
panvk-bifrost
Future campaign — chartered 2026-05-05 during libva-multiplanar iter5. Not yet started. Sequenced after the planned fourier-fresnel campaign (porting the libva-multiplanar fork from ohm RK3568 to fresnel RK3399 / Pinebook Pro). May open after fourier-fresnel wraps, or much later — operator's call.
Goal
Complete PanVk (Mesa's open-source Vulkan-on-Mali) for Bifrost-gen Mali GPUs, starting with Mali-G52 MP1 (RK3566 / PineTab2). Mesa's PanVk currently prioritizes Valhall-gen GPUs; Bifrost is incomplete. The hardware supports Vulkan in silicon — the gap is the open-source userspace driver.
Why
- Mali-G52 / Bifrost is shipped on a wide range of SBCs (RK3568, RK3568B2, similar Allwinner / Amlogic Bifrost SoCs). Vendor-stack Android is the typical OS, with all the usual telemetry/exfiltration concerns.
- Linux desktop on these SBCs falls back to GLES via Panfrost. Works, but anything insisting on Vulkan (libplacebo
--vo=gpu, Firefox WebGPU, certain games via DXVK, Vulkan-only compute) is unusable. - A Bifrost PanVk would unlock GPU compute + modern rendering across that whole SBC ecosystem.
- Desktop games on PineTab2 currently route GL through Panfrost. A working PanVk-Bifrost enables Zink-on-PanVk (GL→Vulkan translation) as an alternate path; on other Mali generations Zink has matched or beaten the native GLES driver thanks to a leaner submit model. Concrete end-user payoff: TuxRacer smoother on PineTab2 — not just an ecosystem story, a real day-to-day win on the operator's own SBC.
Consumer-side benefit (libva-multiplanar discovery, 2026-05-05)
A working Vulkan would also unblock Chromium-family browsers' GPU process boot on Bifrost SBCs. Stock Brave / Chromium on PineTab2 (Mali-G52 + Panfrost on kernel 6.19.10) currently dies at GL bindings init: GLES3 is unsupported (default), InitializeStaticGLBindingsOneOff failed (with --use-gl=egl or --use-gl=desktop). Chromium has been migrating its compositor toward Vulkan (--enable-features=Vulkan); a usable Mali-G52 Vulkan device would let Chromium take that path and side-step the GL stack failures entirely.
This doesn't fix VAAPI engagement (Chromium's VAAPI codepath is independent of compositor) but it does obsolete the GL-stack workarounds that the parallel chromium-fourier campaign needs to carry. Net for the SBC ecosystem: PanVk-Bifrost would meaningfully reduce the per-distro Chromium-patch burden on Bifrost-class boards.
Not an iter1 driver, but a real second-order benefit worth naming.
Precedent
Mesa's existing Mali userspace stack (Panfrost, lima, PanVk-Valhall) was built by reverse-engineering Arm's proprietary blob — Alyssa Rosenzweig's panwrap / panloader trace-and-compare work, then continued by Collabora. Bifrost has the same blob available (libGLES_mali.so from Rockchip vendor BSPs); PanVk just hasn't been prioritized there because Valhall is the newer market.
Scope sketch
- Use Arm's proprietary Mali Vulkan userspace blob (Bifrost) as the oracle.
- Trace-and-diff against Mesa's PanVk-Valhall + Bifrost GLES backend that already exists.
- Recover descriptor / command-buffer / queue-submission structures.
- Fill missing Vulkan-specific plumbing on top of the already-working Bifrost ISA support in Mesa.
- Upstream patches (or carry out-of-tree if upstream-relations are slow).
Existing Mesa state to leverage
- Bifrost ISA is fully supported in Mesa via Panfrost GLES + OpenCL backends — we don't need to RE the instruction set, just the Vulkan-specific plumbing.
- PanVk-Valhall code is the structural template — most of the code can carry across, only the ISA-emit and some descriptor layouts differ.
What blocks starting
- Wrap libva-multiplanar (iter5 in progress, possibly more iters).
- Run fourier-fresnel campaign first — apply the libva-multiplanar fork to Pinebook Pro RK3399 hantro G1 (note: G2 absent on RK3399), validate generality of iter1+2+3+4 fixes on a second hardware target.
- Then this campaign opens.
Charter operator
mfritsche.
Cross-references
- Hardware reality:
~/src/libva-multiplanar/.claude/.../memory/reference_pinetab_no_vulkan.md— current state of Vulkan on Mali-G52 + why it's outside libva-multiplanar's scope. - Predecessor RE work: Alyssa Rosenzweig's blog posts (rosenzweig.io) on Panfrost development, Collabora's PanVk merge requests on
gitlab.freedesktop.org/mesa/mesa.
Stop point
We're going in. Phase 0 closed 2026-05-19 — see phase0_findings.md. iter1 in progress. Inherits the libva-multiplanar campaign's 8-phase loop discipline.