Merge pull request 'iter22 close — r9 maxImageDimension3D bump (Dawn/WebGPU unblock, campaign motivator)' (#6) from claude-noether/panvk-bifrost:noether/iter22-close into main
Reviewed-on: #6
This commit was merged in pull request #6.
This commit is contained in:
@@ -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