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.5 KiB

Raw Blame History

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.

4.5 KiB Raw Blame History