mesa-panvk-bifrost r9: bump maxImageDimension3D to 2048 (iter22, unblocks Dawn/WebGPU) #103
Reference in New Issue
Block a user
Delete Branch "claude-noether/marfrit-packages:mesa-panvk-bifrost-r9"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
0008-panvk-bifrost-bump-max-image-dim-3d-for-dawn.patch(iter22 / r9)maxImageDimension3Dfrom 512 to 2048 on Bifrost (PAN_ARCH 7..10) — unblocks Brave/Dawn WebGPU adapter acceptance on Mali-G52 r1 MC1 (PineTab2)get_max_3d_image_size()(Phase 5 review finding)Why now
panvk-bifrost-perf-measurement iter1 spike (post-r7) found Brave's WebGPU/Dawn detects panvk-bifrost as a valid Vulkan adapter on Mali-G52 r1 MC1 — but rejects it with
Insufficient Vulkan limits for maxTextureDimension3D. VkPhysicalDeviceLimits::maxImageDimension3D must be at least 2048(dawnPhysicalDeviceVk.cpp:746). Bumping to 2048 closes that gate.Test plan
maxImageDimension3D = 2048--enable-features=Vulkan --use-vulkan --use-angle=vulkan)dEQP-VK.api.copy_and_blit.core.image_to_image.3d_images.*6/6 Pass (unchanged vs r7)pacman -Syu mesa-panvk-bifroston consumer (ohm) reports r9Note 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 also advertised — surgically false-gating each would risk undoing r1's KHR_robustness2 work that Chromium Dawn depends on. Documented at
~/src/panvk-bifrost/iter21/phase0to3_close_no_ship.md. Version skips r7 → r9 intentionally.Cross-refs:
~/src/panvk-bifrost/iter22/phase0to2_max3d_close.md(Phase 0-2 close)🤖 Generated with Claude Code
Co-Authored-By: Claude Opus 4.7 noreply@anthropic.com
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>