mesa-panvk-bifrost r9: bump maxImageDimension3D to 2048 (iter22, unblocks Dawn/WebGPU)

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

Hunk 1: Bumps maxImageDimension3D from 512 to 2048 on Bifrost (PAN_ARCH 7..10).
Surfaced by panvk-bifrost-perf-measurement iter1 spike: Brave's WebGPU/Dawn
detects panvk-bifrost as a Vulkan adapter on Mali-G52 r1 MC1 but rejects it
because the advertised limit is below WebGPU's 2048 minimum (per
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.

Per Vulkan 1.3 spec §43.1, maxImageDimensionXD is the upper bound on any
creatable image; per-format limits 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 address constraint. Apps trying 2048^3 with thick formats
hit the per-format limit at image-create — per-spec behavior.

Hunk 2: Removes three asserts in get_max_3d_image_size() that encoded the
wrong invariant (per-format >= basic), opposite of what the Vulkan spec
mandates. The asserts were release-mode-masked via NDEBUG, but debug
builds would abort the first time Dawn (or any client) called
vkGetPhysicalDeviceImageFormatProperties on a 3D image format. Surfaced
by Phase 5 2nd-model review.

Verified on PineTab2 (Mali-G52 r1 MC1, PAN_ARCH 7):
  - vulkaninfo: maxImageDimension3D = 2048
  - Brave/Dawn: "Insufficient Vulkan limits" warning eliminated; adapter
    accepted for WebGPU.
  - CTS regression: dEQP-VK.api.copy_and_blit.core.image_to_image.3d_images.*
    6/6 Pass (unchanged from r7 baseline).

Phase 5 (2nd-model) review: APPROVE WITH CHANGES — both changes applied
(release-mode + debug-mode assert exposure addressed by removing the
wrong-invariant asserts).

Note on numbering: r8 was attempted (KHR_depth_clamp_zero_one trim) but
abandoned mid-Phase-3 when it surfaced that 5 more post-1.3.10 KHR
extensions are advertised — surgically false-gating all of them would
risk undoing r1's KHR_robustness2 work for Chromium Dawn. Documented at
~/src/panvk-bifrost/iter21/phase0to3_close_no_ship.md.

Cross-refs:
  - ~/src/panvk-bifrost/iter22/phase0to2_max3d_close.md (Phase 0-2 close)

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

arch/mesa-panvk-bifrost/0008-panvk-bifrost-bump-max-image-dim-3d-for-dawn.patch

@@ -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

arch/mesa-panvk-bifrost/PKGBUILD

@@ -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() {