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

3.9 KiB

Raw Blame History

Phase 0 — substrate + Phase 1 result for iter18

The headline

There is no Mali-G52 Vulkan blob. Every Bifrost-G52 variant Arm ships (via Rockchip's BSP mirrors) is OpenCL + OpenGL ES only. Zero vk_icdGetInstanceProcAddr, zero VK_KHR_*/VK_EXT_* extension strings, no Vulkan API surface.

panvk-bifrost provides the only working Vulkan implementation for Mali-G52 hardware, period. The proprietary Mali blob is not a Vulkan competitor on this SoC — it doesn't have Vulkan.

Method

Located Rockchip's standard libmali distribution mirror (JeffyCN/mirrors libmali branch — the community-canonical source for Rockchip's binary BSP).
Downloaded libmali-bifrost-g52-g24p0-dummy.so (most recent driver release, dummy variant = cleanest static-analysis target without display-platform link noise).
Static analysis:
- nm -D for exported Vulkan symbols → none
- strings | grep VK_KHR_|VK_EXT_ → 0 hits
- strings | grep -i vulkan → 110 hits, ALL of them SPIR-V compiler capability metadata (VulkanMemoryModel*) — used in OpenCL 3.0's SPIR-V too, not Vulkan API
Cross-checked 4 additional G52 variants (g2p0 / g13p0 / g24p0 with different x11/wayland/gbm tags): all zero Vulkan symbols.
Cross-checked Valhall-G610 (RK3588) variant: 197 VK_KHR/VK_EXT strings, vk_icdGetInstanceProcAddr exported. Valhall has Vulkan; Bifrost-G52 doesn't.

Why this matters

iter15's question — "how much of the proprietary Mali blob now ships with panvk-bifrost?" — assumed there was a blob-side Vulkan reference to compare against. There isn't, on our hardware.

	Mali-G52 r1 MC1 (RK3566 / PineTab2)	Mali-G610 (RK3588)
Hardware	Bifrost gen 2	Valhall gen 2
Proprietary Vulkan blob?	No (none ships, never has)	Yes (197 extensions, full ICD)
Mainline driver	panvk-bifrost (this campaign)	panvk + panthor (separate effort)
What you'd run if you wanted Vulkan on this hardware	mesa-panvk-bifrost (us)	choice of blob OR panvk+panthor

So:

Anyone who wants Vulkan on a PineTab2 / RK3566 / Mali-G52 device must use a mesa-based path. The Arm blob doesn't supply it.
panvk-bifrost's 75.7%-of-runnable-XFB-pass measurement (iter15) isn't a percentage of some other reference — it IS the reference for this hardware.
iter13's transform_feedback unlock, iter15's CTS measurement, and iter17's winding-decomposition fix are net-new Vulkan capability that didn't exist on Mali-G52 before our campaign.

Drivers's exported symbol counts (for the record)

nm -D --defined-only libmali-bifrost-g52-g24p0-dummy.so | wc -l: 1,999 symbols, all OpenCL CL_* / EGL / GLES.

For comparison, Valhall G610 g24p0 dummy:

Includes the 1999-ish OpenCL/GLES surface
PLUS the Vulkan ICD entrypoints (vk_icdGetInstanceProcAddr, vk_icdGetPhysicalDeviceProcAddr, vk_icdNegotiateLoaderICDInterfaceVersion)
PLUS the 197 advertised Vulkan extensions

The architectural delta from Bifrost to Valhall is exactly where Arm's blob crossed the Vulkan threshold. Mali-G52 (Bifrost) predates that decision.

Implications for the campaign's standing artifacts

Nothing to fix. The deliverables stand:

iter9: Brave/Chromium GPU process boots via Vulkan on PineTab2 → made possible BY mesa-panvk-bifrost. Without our work, no Vulkan on this hardware at all.
iter13: VK_EXT_transform_feedback implementation → only Vulkan transform_feedback that exists on Mali-G52.
iter15: 75.7% of runnable XFB CTS — the absolute reference for what's measurable, not a relative parity number.
iter17 (in flight): closes the winding-decomposition cluster → 162 fails → 0 fails per the targeted CTS subset.

Recommendation

Skip Phase 2 (the dynamic-comparison-against-blob plan). There's no blob to dynamically compare against. iter18 Phase 4 (the writeup) is the campaign-close artifact the operator asked for.

— claude-noether, 2026-05-21

3.9 KiB Raw Blame History