panvk-bifrost/iter22_campaign_close_2026-05-25.md

iter22 — maxImageDimension3D bump for Dawn/WebGPU (campaign close)

Shipped: 2026-05-25 PR: marfrit/marfrit-packages#103 Merge commit: 520f2fce337d Package: mesa-panvk-bifrost-26.0.6.r9-1-aarch64

What shipped

Two-hunk patch (0008-panvk-bifrost-bump-max-image-dim-3d-for-dawn.patch):

1. Bump maxImageDimension3D from 512 to 2048 on Bifrost (PAN_ARCH 7..10). File: src/panfrost/vulkan/panvk_vX_physical_device.c:651.
2. Remove three wrong-invariant asserts in get_max_3d_image_size() (src/panfrost/vulkan/panvk_physical_device.c:1018-1020) that encoded "per-format max >= basic limit" — the opposite of what the Vulkan spec mandates.

How surfaced

panvk-bifrost-perf-measurement iter1 spike (task #98) was setting up an A/B MotionMark test of stock GL vs panvk Vulkan in Brave. The spike showed that Brave's WebGPU/Dawn detects our shipped r7 driver as a valid Vulkan adapter:

Mali-G52 r1 MC1 - panvk: Mesa 26.0.6
  vendorId=0x13b5 deviceId=0x74021000
  backend=BackendType::Vulkan type=AdapterType::IntegratedGPU

But immediately rejects it:

Warning: Insufficient Vulkan limits for maxTextureDimension3D.
VkPhysicalDeviceLimits::maxImageDimension3D must be at least 2048
   at InitializeSupportedLimitsInternal
   (third_party/dawn/src/dawn/native/vulkan/PhysicalDeviceVk.cpp:746)

The perf measurement was premature — there was no point comparing MotionMark scores if Dawn refused to use the panvk adapter in the first place. r9 was the actual unblock for the campaign's stated motivator (Chromium GPU process Vulkan boot on PineTab2 / Bifrost SBCs).

Why both hunks

Phase 5 (2nd-model) review caught a release-mode-masked semantic bug: the three asserts in get_max_3d_image_size() encoded the wrong invariant. The shipped b_ndebug=if-release build no-ops them, but debug builds (CTS, devs running meson defaults) would abort the first time Dawn called vkGetPhysicalDeviceImageFormatProperties(3D, format) post-r9. Hunk 2 removes them.

Verification

Check	Result
vulkaninfo: maxImageDimension3D	2048 (was 512)
Brave/Dawn: "Insufficient" warning	eliminated
dEQP-VK.api.copy_and_blit.core.image_to_image.3d_images.*	6/6 Pass (unchanged)
Phase 5 2nd-model review	APPROVE WITH CHANGES — both applied

Three-point ship-check verdict

1. ✓ PR #103 merged at 520f2fce337d
2. ✓ CI runs #1486 (mesa-panvk-bifrost-aarch64) + #1487 (mesa-panvk-bifrost-video-aarch64) both success
3. ✓ pacman -Q mesa-panvk-bifrost on ohm reports 26.0.6.r9-1; installed lib BuildID 63911eae...; vulkaninfo confirms 2048; Brave headless mode produces standard non-conformant warnings only — no Dawn rejection.

Why not bump max_img_size_B too?

The current arch <= 10 ? u_uintN_max(32) (4 GB) caps the per-format runtime limit at ~1023 per axis for RGBA8. We could bump to u_uintN_max(48) to widen the address space and let larger per-format 3D images actually be creatable. But that requires HW evidence that the Bifrost MMU + kernel driver actually handle 48-bit image offsets, which is uncertain pre-CSF. Held for a future iter with HW probing.

Open follow-ups

• panvk-bifrost-perf-measurement iter2 — re-do the MotionMark A/B now that Dawn accepts the adapter. The original task #98 close doc was preempted by this finding; iter2 would actually capture the comparison numbers.
• Brave / Chromium GPU process real-world testing — confirm in windowed mode (not headless) that the GPU process boots with our Vulkan path and renders without falling back.

Lineage

rev	What	Date
r1	KHR_robustness2 + nullDescriptor on Bifrost	iter8
r2	has_vk1_1/has_vk1_2 = true on Bifrost	iter9
r3	VK_EXT_transform_feedback	iter13
r4	XFB primitive decomposition	iter17
r5	fragmentStoresAndAtomics = true	2026-05-23
r6	VK_EXT_legacy_dithering	2026-05-25
r7	XFB packed-varying channel-extract fix	2026-05-25
(r8)	KHR_depth_clamp_zero_one trim — abandoned	2026-05-25
r9	maxImageDimension3D = 2048 for Dawn	2026-05-25