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>
59 lines
4.5 KiB
Markdown
59 lines
4.5 KiB
Markdown
# 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.
|