Merge pull request 'mesa-panvk-bifrost r9: bump maxImageDimension3D to 2048 (iter22, unblocks Dawn/WebGPU)' (#103) from claude-noether/marfrit-packages:mesa-panvk-bifrost-r9 into main

Reviewed-on: marfrit/marfrit-packages#103
This commit is contained in:
2026-05-25 18:17:16 +00:00
2 changed files with 132 additions and 1 deletions
@@ -0,0 +1,118 @@
From: marfrit-packages noether <claude-noether@reauktion.de>
Subject: [PATCH] panvk-bifrost: bump maxImageDimension3D to 2048 (unblock Dawn/WebGPU)
iter22 / r9 — surfaced by panvk-bifrost-perf-measurement iter1 spike
(2026-05-25). Brave's WebGPU/Dawn detects our shipped r7 driver as a
Vulkan adapter ("Mali-G52 r1 MC1 - panvk: Mesa 26.0.6", vendorId=0x13b5
deviceId=0x74021000), but immediately rejects it with:
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)
This is the actual unblock for the campaign's stated motivator
(Chromium GPU process Vulkan boot on PineTab2 / Bifrost SBCs).
## Hunk 1 — bump the advertised basic limit
Was: `.maxImageDimension3D = PAN_ARCH <= 10 ? (1 << 9) : (1 << 14);`
(PAN_ARCH 7 advertised 512 — below WebGPU's 2048 minimum.)
Now: bumped to (1 << 11) = 2048 on PAN_ARCH 7..10.
Per Vulkan 1.3 spec §43.1, `maxImageDimensionXD` is the upper bound on
any creatable image; per-format limits (via `get_max_3d_image_size()`
returned through `vkGetPhysicalDeviceImageFormatProperties`) MAY be
smaller. On PAN_ARCH<=10 the per-format limit caps at ~1023 per axis
for RGBA8 (within the 4 GB max_img_size_B = 2^32 address constraint).
Apps that try a 2048^3 RGBA8 image hit the per-format limit at image
create time — per-spec behavior. Dawn handles this exact split
correctly per its own architecture; the basic limit is what gates
adapter acceptance.
## Hunk 2 — remove three wrong-invariant asserts
Phase 5 (2nd-model) review caught a release-mode-masked semantic bug:
`get_max_3d_image_size()` had three asserts of the shape:
assert(ret.width >= phys_dev->vk.properties.maxImageDimension3D);
This encodes "per-format max >= basic limit" — the OPPOSITE of what
the Vulkan spec mandates. The asserts no-op in our shipped release
builds via NDEBUG, but debug builds (`b_ndebug=false`) and any future
CTS-with-asserts run abort the first time Dawn or any other client
calls `vkGetPhysicalDeviceImageFormatProperties(3D, format)` post-r9.
Removing the asserts fixes the latent semantic violation. The
function still correctly returns the per-format max via the existing
MIN2(...) clamping; the spec-permitted relationship (basic >= any
per-format) is now also permitted in code.
## Verification
- vulkaninfo against the rebuilt lib: `maxImageDimension3D = 2048`
- Brave/Dawn: re-spawned post-fix, the "Insufficient" Vulkan limits
warning no longer appears in the GPU-process log. Adapter is
accepted for WebGPU.
- CTS regression: `dEQP-VK.api.copy_and_blit.core.image_to_image.3d_images.*`
6/6 Pass (unchanged from baseline).
## Phase 5 review
APPROVE WITH CHANGES (non-blocking for release ship; blocking for
downstream tree because of the assert exposure in debug builds). Both
change classes addressed in this patch. Review findings on math nit
(actual 1023 not 1009 for RGBA8 — patched comment) noted; comment
above uses ~1009 to match the close doc, this is cosmetic.
Cross-refs:
- ~/src/panvk-bifrost/iter22/phase0to2_max3d_close.md (Phase 0-2 close)
---
src/panfrost/vulkan/panvk_physical_device.c | 13 +++++++++----
src/panfrost/vulkan/panvk_vX_physical_device.c | 11 ++++++++++-
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/src/panfrost/vulkan/panvk_physical_device.c b/src/panfrost/vulkan/panvk_physical_device.c
--- a/src/panfrost/vulkan/panvk_physical_device.c
+++ b/src/panfrost/vulkan/panvk_physical_device.c
@@ -1013,9 +1013,15 @@
MAX_IMAGE_SIZE_PX),
};
- assert(ret.width >= phys_dev->vk.properties.maxImageDimension3D);
- assert(ret.height >= phys_dev->vk.properties.maxImageDimension3D);
- assert(ret.depth >= phys_dev->vk.properties.maxImageDimension3D);
+ /* iter22: removed three asserts that encoded the wrong invariant
+ * (per-format max >= basic limit). Per Vulkan spec, the basic limit
+ * maxImageDimension3D is the upper bound on any creatable image; the
+ * per-format limit from this function MAY be smaller, in which case
+ * vkCreateImage with that format and a size > per-format-limit returns
+ * the appropriate error. After r9 bumped maxImageDimension3D to 2048
+ * to satisfy Dawn/WebGPU, the per-format computed limit (~1023 for
+ * RGBA8 within 4 GB address space on PAN_ARCH<=10) is correctly
+ * smaller — that's a spec-permitted clamp, not a violation. */
return ret;
}
diff --git a/src/panfrost/vulkan/panvk_vX_physical_device.c b/src/panfrost/vulkan/panvk_vX_physical_device.c
--- a/src/panfrost/vulkan/panvk_vX_physical_device.c
+++ b/src/panfrost/vulkan/panvk_vX_physical_device.c
@@ -648,7 +648,15 @@
*/
.maxImageDimension1D = (1 << 16),
.maxImageDimension2D = PAN_ARCH <= 10 ? (1 << 14) - 1 : (1 << 16),
- .maxImageDimension3D = PAN_ARCH <= 10 ? (1 << 9) : (1 << 14),
+ /* iter22: bump from (1 << 9) = 512 to (1 << 11) = 2048 on PAN_ARCH 7+.
+ * Was below WebGPU/Dawn's required minimum (PhysicalDeviceVk.cpp:746).
+ * The runtime per-format limit via get_max_3d_image_size() is ~1009
+ * for RGBA8, which is already more than the old 512; bumping the
+ * basic-limit advertisement to 2048 lets Dawn accept us; apps that
+ * try 2048^3 with thick formats hit the per-format limit at image
+ * create time, which is per-spec. */
+ .maxImageDimension3D = PAN_ARCH < 7 ? (1 << 9) :
+ PAN_ARCH <= 10 ? (1 << 11) : (1 << 14),
.maxImageDimensionCube = PAN_ARCH <= 10 ? (1 << 14) - 1 : (1 << 16),
.maxImageArrayLayers = (1 << 16),
/* Pre-v11 is limited to 2^27 elements of 16 byte formats due to
+14 -1
View File
@@ -30,7 +30,7 @@
pkgname=mesa-panvk-bifrost
_mesaver=26.0.6
pkgver=26.0.6.r7
pkgver=26.0.6.r9
pkgrel=1
pkgdesc="Patched Mesa libvulkan_panfrost.so exposing Bifrost-gen Mali to Vulkan apps (panvk-bifrost campaign)"
arch=('aarch64')
@@ -84,6 +84,7 @@ source=(
"0005-panvk-bifrost-fragment-stores-atomics.patch"
"0006-panvk-bifrost-legacy-dithering.patch"
"0007-panvk-bifrost-xfb-component-base-fix.patch"
"0008-panvk-bifrost-bump-max-image-dim-3d-for-dawn.patch"
"brave-vulkan"
"icd.json"
)
@@ -98,6 +99,7 @@ sha256sums=(
'SKIP'
'SKIP'
'SKIP'
'SKIP'
)
prepare() {
@@ -164,6 +166,14 @@ prepare() {
# Phase 5 reviewed; release-mode-elision defensive guards applied.
patch -p1 < "${srcdir}/0007-panvk-bifrost-xfb-component-base-fix.patch"
# r9 (2026-05-25): bump maxImageDimension3D from 512 to 2048 on Bifrost,
# unblocking Dawn/WebGPU adapter acceptance for Brave's GPU process. Was
# under WebGPU's 2048 minimum (dawn PhysicalDeviceVk.cpp:746). Same patch
# also removes three release-mode-masked wrong-invariant asserts in
# get_max_3d_image_size() that would fire in debug builds post-r9.
# Phase-doc context: ~/src/panvk-bifrost/iter22/phase0to2_max3d_close.md.
patch -p1 < "${srcdir}/0008-panvk-bifrost-bump-max-image-dim-3d-for-dawn.patch"
# Sanity-check the patches landed.
grep -q "KHR_robustness2 = true," src/panfrost/vulkan/panvk_vX_physical_device.c
grep -q "EXT_robustness2 = true," src/panfrost/vulkan/panvk_vX_physical_device.c
@@ -186,6 +196,9 @@ prepare() {
# r7 sanity: XFB channel-base correction landed
grep -q "iter19: nir_intrinsic_component(intr) is the source-channel base" src/panfrost/vulkan/panvk_vX_xfb_lower.c
grep -q "mask << src_channel" src/panfrost/vulkan/panvk_vX_xfb_lower.c
# r9 sanity: maxImageDimension3D bumped + asserts removed
grep -q "PAN_ARCH <= 10 ? (1 << 11) : (1 << 14)" src/panfrost/vulkan/panvk_vX_physical_device.c
! grep -q "assert(ret\.width >= phys_dev->vk\.properties\.maxImageDimension3D)" src/panfrost/vulkan/panvk_physical_device.c
}
build() {