From e323aa2316715ce96b933fb26b6085b886557e87 Mon Sep 17 00:00:00 2001 From: Markus Fritsche Date: Mon, 25 May 2026 15:54:18 +0200 Subject: [PATCH] mesa-panvk-bifrost r9: bump maxImageDimension3D to 2048 (iter22, unblocks Dawn/WebGPU) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- ...frost-bump-max-image-dim-3d-for-dawn.patch | 118 ++++++++++++++++++ arch/mesa-panvk-bifrost/PKGBUILD | 15 ++- 2 files changed, 132 insertions(+), 1 deletion(-) create mode 100644 arch/mesa-panvk-bifrost/0008-panvk-bifrost-bump-max-image-dim-3d-for-dawn.patch diff --git a/arch/mesa-panvk-bifrost/0008-panvk-bifrost-bump-max-image-dim-3d-for-dawn.patch b/arch/mesa-panvk-bifrost/0008-panvk-bifrost-bump-max-image-dim-3d-for-dawn.patch new file mode 100644 index 000000000..ce57b04a3 --- /dev/null +++ b/arch/mesa-panvk-bifrost/0008-panvk-bifrost-bump-max-image-dim-3d-for-dawn.patch @@ -0,0 +1,118 @@ +From: marfrit-packages noether +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 diff --git a/arch/mesa-panvk-bifrost/PKGBUILD b/arch/mesa-panvk-bifrost/PKGBUILD index b5bff3977..423853aed 100644 --- a/arch/mesa-panvk-bifrost/PKGBUILD +++ b/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() {