# 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

1. Located Rockchip's standard libmali distribution mirror (JeffyCN/mirrors libmali branch — the community-canonical source for Rockchip's binary BSP).
2. Downloaded `libmali-bifrost-g52-g24p0-dummy.so` (most recent driver release, dummy variant = cleanest static-analysis target without display-platform link noise).
3. 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
4. Cross-checked 4 additional G52 variants (g2p0 / g13p0 / g24p0 with different x11/wayland/gbm tags): all zero Vulkan symbols.
5. 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:

1. **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.
2. **iter13**: VK_EXT_transform_feedback implementation → only Vulkan transform_feedback that exists on Mali-G52.
3. **iter15**: 75.7% of runnable XFB CTS — the absolute reference for what's measurable, not a relative parity number.
4. **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