# Mali-G52 r1 MC1 Feature Delta — r6/r7 Candidate Audit (2026-05-24)

Multi-language research (EN/CN/RU/KO/JA/Bayrisch) into HW capabilities of
Mali-G52 r1 MC1 vs what Mesa 26.0.6 panvk advertises. Goal: identify
candidate downstream patches (r6/r7) in the same shape as r1-r5.

## Hardware

- ARM Mali-G52 r1 MC1 (Bifrost gen-2, PAN_ARCH 7)
- Single shader core, 800 MHz peak
- Shipped in RK3566 (PineTab2, PineNote, Quartz64-B)
- TBDR architecture with tile memory (~16 KB per shader core, 8 KB per
  pixel per ARM developer docs)

## Authoritative sources

- ARM developer docs:
  - "Bifrost Shader Core" — developer.arm.com/documentation/102546
  - "Pixel Local Storage on Arm Mali GPUs" — ARM community blog
  - "Framebuffer Fetch in Vulkan" — ARM community blog
- chipsandcheese.com Bifrost-G52 teardown (May 2025)
- Mesa 26.0 / 26.1 release notes
- Christian Gmeiner's "PanVK Extension Sprint" blog post (Apr 2026)
- Rockchip RK3566 datasheet (boardcon mirror)

## Confirmed HW-supported features under-exposed by upstream Mesa (PAN_ARCH < 9 gates)

These are candidate flips in the same shape as r1..r5.

### High-confidence pure-software flips (small-scope r6 candidates)

| Feature | Why HW-doable | Why panvk hides it |
|---|---|---|
| `VK_EXT_pipeline_robustness` | Software-level robustness selector; composes on top of our r1 KHR_robustness2 flip | Not advertised on PAN_ARCH<10. No HW dep. |
| `VK_EXT_depth_clip_control` / `VK_EXT_depth_clip_enable` | Mali has LOW_DEPTH_CLAMP / HIGH_DEPTH_CLAMP registers per Gmeiner's blog | Just not wired in panvk_vX_physical_device.c |
| `VK_EXT_provoking_vertex` | Panfrost GL already supports it on Bifrost; just a selector | Not wired |
| `VK_EXT_load_store_op_none` / `VK_KHR_load_store_op_none` | Pure Vulkan spec relaxation; no HW change | Not advertised |
| `VK_EXT_pageable_device_local_memory` / `VK_EXT_memory_priority` | Pure software; UMA-friendly | Not advertised |

### Medium-confidence HW-touch flips (need NIR plumbing, not just flag)

| Feature | HW support evidence | Effort |
|---|---|---|
| `shaderStorageImageMultisample` | Bifrost ALU + tile memory can do MSAA SSBO stores per ARM blob exposure | NIR dirty-bit work |
| `shaderStorageImageReadWithoutFormat` / `WriteWithoutFormat` | Bifrost LD/ST has typed + untyped paths; Mesa 25.1 flipped `shaderStorageImageExtendedFormats` already | NIR pass refinement |
| `VK_EXT_extended_dynamic_state3` (subset) | Each piece is dynamic-state plumbing, not new HW | Per-piece evaluation |

### High-confidence HW-real flips (multi-week r7 territory)

| Feature | HW evidence | Engineering scope |
|---|---|---|
| `VK_EXT_rasterization_order_attachment_access` | TBDR tile memory exists; Panfrost GL implements FB fetch (Mesa MR !5755) | Real PanVK FB-fetch plumbing — port from GL path |
| `VK_KHR_dynamic_rendering_local_read` | Maps to FB fetch / tile memory which G52 has | Pairs with the above; design together |
| Tile-image / pixel-local-storage Vulkan exposure | Mali tile memory ~16 KB per SC; ARM exposes PLS GLES-only natively | Substantive driver feature |

## Confirmed HW limitations (NOT candidates)

These are silicon-absent on G52, not patch surface:

- `sparseResidency*` — Bifrost MMU lacks sparse residency model (Mesa gates to v10+)
- `subgroupSize` ≥ 16 / advanced subgroup ops — Bifrost is 4- or 8-wide warps
- `VK_EXT_nested_command_buffer` — needs CSF (v10+)
- `VK_KHR_shader_untyped_pointers` — explicit "Bifrost has issues" per Gmeiner blog
- Video codec extensions — Mali has no video silicon (hantro VPU territory; covered by mesa-panvk-bifrost-video sibling)
- `shaderInt64`, 64-bit atomics, mesh shaders, hardware ray tracing, fragment shading rate — all silicon-absent

## Needs HW probing (uncertain)

- `sampleRateShading` — Vulkan 1.0 mandatory; if currently false on v7 it's likely a flip candidate
- `VK_EXT_sample_locations` — Bifrost rasterizer has programmable sample positions per ARM docs
- `dualSrcBlend` on v7 — Panfrost GL supports dual-source per Icecream95 notes; PanVK status unclear
- `VK_EXT_filter_cubic` — unclear if Bifrost texturing has cubic sampler natively

Test path: run targeted dEQP-VK subsets against the existing r5 driver and observe `NotSupported` vs `Fail` distribution; cross-reference with Panfrost GL coverage of the same hardware paths.

## Multi-language source notes

- 🇨🇳 Chinese: Rockchip RK3566 datasheet (boardcon mirror) confirms Mali-G52 2EE, Vulkan 1.1, OpenCL 2.0, AFBC/ASTC. Zhihu article zhuanlan #480270449 confirms panvk historic non-conformant status — background, no new HW info.
- 🇷🇺 Russian: opennet.ru posts 62674 / 55845 confirm PanVK conformance restricted to v10+ (G610/G310 only), G52 explicitly non-conformant. Matches English sources.
- 🇯🇵 Japanese: 0 useful Mali-G52-specific hits across Qiita / Hatena.
- 🇰🇷 Korean: 0 hits. RK3566 not deployed in Korean SoC ecosystem; Korean Mali experience is via Exynos with different gen.
- 🇩🇪 Bayrisch: 0 Stammtisch threads on Mali-G52. Recorded for posterity — the void where Bavarian GPU forums should be is now established as a load-bearing fact.

## The leaked ARM Software Developer's Manual

**Not found in the wild.** Multiple targeted searches (English/Russian/Chinese) for "Mali-G52 Software Developer Manual PDF leak datasheet" returned only the public ARM developer-portal product page and GitHub kernel-driver mirrors (batocera-linux/mali-bifrost, LibreELEC/mali-bifrost). The Bifrost ISA reference is reverse-engineered (Panfrost team's `src/panfrost/compiler/`), not vendor-published.

Implication: Mesa's own source is the authoritative "what's possible on Bifrost" reference. For future iterations, grep `src/panfrost/compiler/bi_test_*.c` and panvk feature gates (`PAN_ARCH < N` checks) before chasing leaks.

Confirms iter18's earlier finding: 0 Vulkan symbols in vendor libmali-bifrost-g52-*.so. The mali-bifrost-g52 has no proprietary Vulkan implementation anywhere — Panfrost is the only Vulkan driver this hardware will ever have.

## Top 3 ranked recommendations

1. **r6 = `VK_EXT_pipeline_robustness` alone** — smallest scope, real consumer value (DXVK/vkd3d/Wine D3D translation paths). 1-line panvk_vX_physical_device.c flip.
2. **r6.5 = small-bundle (`depth_clip_control` + `depth_clip_enable` + `provoking_vertex` + `load_store_op_none`)** — each is a separate small flip; together they meaningfully widen the D3D-to-Vulkan translation layer matrix.
3. **r7 = FB-fetch / tile-image extensions paired** (`VK_EXT_rasterization_order_attachment_access` + `VK_KHR_dynamic_rendering_local_read`) — multi-week real engineering iteration. Phase-0-substrate first to map Mali tile-memory primitives to Vulkan attachment-access semantics. Unlocks deferred-shading paths without bouncing through main memory.

## Out of scope

- Upstreaming any of these — per [[feedback-no-upstream-proposals]] our channel is marfrit-packages downstream.
- Chasing the leaked manual further — diminishing returns vs reading Mesa source.

🤖 Research compiled by Claude Opus 4.7 (general-purpose subagent + main thread) on 2026-05-24.