iter22 close: r9 maxImageDimension3D bump (Dawn/WebGPU unblock)

Campaign-motivator unblock — Brave/Dawn detects panvk-bifrost on Mali-G52 but was rejecting the adapter due to maxImageDimension3D < 2048. r9 bumps to 2048 + removes three wrong-invariant asserts. PR #103 merged; CI green; r9-1 installed on ohm; vulkaninfo confirms; Brave/Dawn no longer rejects. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-25 20:51:20 +02:00
parent 9632b658ac
commit 35f9deaacb
1 changed files with 103 additions and 0 deletions
@@ -0,0 +1,103 @@
+# iter22 — maxImageDimension3D bump for Dawn/WebGPU (campaign close)
+
+Shipped: 2026-05-25
+PR: https://git.reauktion.de/marfrit/marfrit-packages/pulls/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** |