# 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

1. Wrap libva-multiplanar (iter5 in progress, possibly more iters).
2. 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.
3. 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](phase0_findings.md). iter1 in progress. Inherits the libva-multiplanar campaign's 8-phase loop discipline.