iter22 close — r9 maxImageDimension3D bump (Dawn/WebGPU unblock, campaign motivator) #6
@@ -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** |
|
||||||
Reference in New Issue
Block a user