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>
Adds 0007-panvk-bifrost-xfb-component-base-fix.patch — eliminates a
reliable SIGSEGV in vkCreateGraphicsPipeline whenever an XFB-bound
vertex output is declared with non-zero `layout (component=N)`.
Surfaced by dEQP-VK.transform_feedback.simple.holes_vert (Mali-G52 r1
MC1, PAN_ARCH 7). Backtrace lands 11 frames into libvulkan_panfrost.so
called from vkt::TransformFeedback::TransformFeedbackHolesInstance::
iterate.
Root cause: iter17's lower_xfb_output_iter17 (and upstream
pan_nir_lower_xfb, which has the identical `// TODO`) computes the
source-channel mask as `mask << channel_idx`, where channel_idx is
the varying-location component (0..3) but src only contains channels
starting at nir_intrinsic_component(intr). For a scalar declared
component=2, the lowering computed `mask << 2` against a 1-component
src — out-of-range; the malformed nir_def segfaulted in downstream
NIR constant-folding (nir_constant_expressions.c::evaluate_*).
Fix translates channel_idx to source-channel space by subtracting
nir_intrinsic_component(intr) before shifting the mask, and replaces
the elided release-mode asserts with explicit release-mode guards
(closes the same elision class as the original bug).
Verified on PineTab2 (Mali-G52 r1 MC1, PAN_ARCH 7) against vulkan-cts
1.3.10.0:
- holes_vert / holes_extra_draw_vert no longer SIGSEGV (now Fail
on color-check; that is a separate iter20 finding).
- basic_*: 36/36 Pass. depth_clip_*: 1 Pass + 4 NotSupported.
lines_or_triangles*: 16 NotSupported. 0 Fail across the set.
Caveat (not regressions): max_output_components_64/_128/_256 were
never reached on the r5 sweep — watchdog killed transform_feedback
after the holes_vert crash. With this fix in place, they now run
and surface their own pre-existing coredumps, confirmed on shipped
r6 baseline too. iter20+ territory.
Phase 5 (2nd-model) review: APPROVE WITH CHANGES (non-blocking).
Changes applied: release-mode defensive guards on both preconditions
plus a dispatcher-side comment clarifying the i*2+j semantics.
Cross-refs:
- ~/src/panvk-bifrost/iter19/phase{0,1,2,3}_holes_vert*.md
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Backports Mesa main's unconditional flip of VK_EXT_legacy_dithering.
Pure-software composition; no new HW path. vk_render_pass already gates
on enabled_features.legacyDithering and panvk_vX_blend + pan_format
already plumb the dithered BLEND descriptor (BFMT2 table has MALI_BLEND_AU
encodings for RGB565/RGB5A1/RGBA4/RGB10A2 on PAN_ARCH 7). Our r5 base
just hadn't picked up the cherry-pick.
Phase 7 verify on ohm (PineTab2 / RK3566 / Mali-G52 r1 MC1) with a
locally-built r6 lib at /tmp/r6_test_lib/:
Feature advertisement:
r5: VK_EXT_legacy_dithering not in extension list, legacyDithering=false
r6: VK_EXT_legacy_dithering rev 2 advertised, legacyDithering=true
dEQP subsets (delta):
dEQP-VK.api.*.legacy_dithering* r5/r6 both: 2 P / 0 F (identical)
dEQP-VK.renderpass.dithering.* r5/r6 both: 0 P / 0 F / 94 NS (identical)
dEQP-VK.renderpass2.dithering.* r5/r6 both: 0 P / 0 F / 94 NS (identical)
Net: zero regressions, advertisement-only delta as expected.
Second-model review (per bugfix-process step 4) traced the full code
path through vk_render_pass + panvk_vX_cmd_draw + panvk_vX_blend +
pan_format BFMT2. No interaction with our r1 nullDescriptor (disjoint
paths). Mesa upstream marks ext DONE for panvk in docs/features.txt.
ARM's own libmali r51p0 driver (BXODROIDN2PL, 2024-08) lists
VK_EXT_legacy_dithering in its Vulkan extension string table,
confirming the feature is shipped by ARM for Mali-G52-class hardware.
Follow-up out of scope: the 94 renderpass-dithering tests show as
NotSupported on both r5 and r6 — there's a separate panvk-side
prereq the dEQP harness checks (likely a specific format-feature
combination). Worth investigating in a future iteration.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Backports Mesa main's unconditional flip of .fragmentStoresAndAtomics
to true in src/panfrost/vulkan/panvk_vX_physical_device.c. Closes
the Dawn-WebGPU adapter rejection at PhysicalDeviceVk.cpp:250 that
caused brave-vulkan to fall back to the SwiftShader CPU adapter on
PineTab2/Mali-G52, per marfrit/panvk-bifrost#2.
Phase 7 verify on ohm (PineTab2, RK3566, Mali-G52 r1 MC1) with a
locally-built r5 lib installed to /tmp/r5_test_lib/:
dEQP-VK.glsl.atomic_operations.*:
r4: 48 pass / 0 fail / 992 NotSupported (1040 total)
r5: 80 pass / 0 fail / 960 NotSupported (1040 total)
delta: +32 newly-passing, zero new failures
dEQP-VK.image.store.*:
r4: 2772 pass / 0 fail / 238 NotSupported (3010 total)
r5: 2772 pass / 0 fail / 238 NotSupported (3010 total)
delta: identical (image.store is independent of the flag)
The disjunction with instance->force_enable_shader_atomics is kept as
a documented kill-switch even though the compiler folds it away —
it leaves the DRI option pan_force_enable_shader_atomics semantically
wired for future rebases or downstream debugging.
Patch reviewed via 2nd-model pass (per bugfix-process step 4):
recommended keeping the disjunction (applied), Bifrost-only-vs-unconditional
left unconditional to match upstream (applied), pre-ship CTS subset
(applied with results above).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Both PKGBUILDs referenced url=https://github.com/marfrit/panvk-bifrost,
which was a hallucinated URL — no such repo existed. The campaign's
real source-of-truth home was just created at
https://git.reauktion.de/marfrit/panvk-bifrost (mfritsche, 2026-05-23).
Point both PKGBUILDs at the real URL so `pacman -Si` and any consumer
reading package metadata follows a working link.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
iter17 closes the 162 winding_* CTS failures from iter15's baseline by
replacing the upstream pan_nir_lower_xfb call with a panvk-specific NIR
pass (panvk_per_arch(nir_lower_xfb)) that handles per-primitive
decomposition for non-LIST topologies (LINE_STRIP, TRIANGLE_STRIP,
TRIANGLE_FAN, and the four _WITH_ADJACENCY variants).
Topology + per-instance output vertex count are threaded as new sysvals
(vs.xfb_topology + vs.xfb_output_count) so the NIR pass can dispatch
per-topology at runtime without compiling 7+ shader variants.
dEQP-VK.transform_feedback.simple.* result (133596 cases total):
iter15 baseline -> iter17
Pass: 796 958 (+162)
Fail: 243 81 (-162; resume_* by-design only)
NotSupported: 132551 132551
Fatal-skip: 6 6
Pass rate of runnable: 76.2% -> 91.7% (+15.5pp)
100% of the iter15 winding-fail cluster closed. The remaining 81 fails
are all resume_* (pause/resume XFB, by design — we advertise
transformFeedbackDraw=false).
Second-model review (janet) produced 3 findings; Findings 1+2 were
already fixed in the in-tree applied state (stale applied_state/ snapshot
read by reviewer), Finding 3 (degenerate N underflow on N<2) addressed
by gating non-LIST emission on `output_count > 0` predicate.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
iter12 hit a wall: Brave's ANGLE-Vulkan path requires GLES3, which
requires VK_EXT_transform_feedback, which PanVk-Bifrost did not
implement. This iter implements that extension, unlocking the full
ANGLE-Vulkan-on-Bifrost stack.
The implementation follows Panfrost-Gallium's well-validated XFB lowering
(nir_io_add_intrinsic_xfb_info + pan_nir_lower_xfb) wired into the PanVk
shader pipeline after nir_lower_io. Adds 4 XFB buffer address sysvals
plus per-draw num_vertices to the graphics sysval struct. Buffer state
is tracked on the cmd buffer; per-draw sysval upload populates either
the bound buffer's GPU address or PAN_SHADER_OOB_ADDRESS (memory-sink)
so XFB-capable pipelines used outside Begin/End survive without GPU
fault — the Panfrost-Gallium idiom from gallium/drivers/panfrost/
pan_cmdstream.c:1350.
Verified on PineTab2 (Mali-G52 r1 MC1, RK3566):
- /tmp/panvk-iter13/probe_xfb: 3 vertices captured byte-exact
- /tmp/panvk-iter13/probe_xfb_nodraw: XFB pipeline used without Bind/
Begin/End survives — DEVICE_LOST regression closed
- Brave 148 with --use-angle=vulkan: WebGL 2.0 (OpenGL ES 3.0) creates
cleanly, renderer reports
"ANGLE (ARM, Vulkan 1.2.335 (Mali-G52 r1 MC1), panvk)"
- chrome://gpu graphics feature status: Canvas/Compositing/OpenGL/
Rasterization/WebGL/WebGL2/WebGPU/Video Decode all hardware accelerated
Phase docs:
- ~/src/panvk-bifrost/phase4_iter13_close.md (build green)
- ~/src/panvk-bifrost/phase5_iter13_close.md (review fixes applied)
- ~/src/panvk-bifrost/phase6_iter13_close.md (Brave integration green)
pkgver bumped 26.0.6.r2 -> 26.0.6.r3; iter13 patch applied via
unified-diff (the 328-line change scope is past sed-of-individual-
lines territory). Sanity checks in prepare() verify the patch landed.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
iter9 of the panvk-bifrost campaign — operator-confirmed Vulkan output
on PineTab2 (Mali-G52 r1 MC1) 2026-05-20.
Patches Mesa 26.0.6's PanVk Vulkan driver:
- VK_KHR/EXT_robustness2 + nullDescriptor exposed for PAN_ARCH 6/7
- has_vk1_1 / has_vk1_2 = true on Bifrost
Patches applied via sed in PKGBUILD prepare() (cleaner than maintaining
a Mesa fork for two two-line tweaks; upstream context drifts between
Mesa releases would make a literal .patch brittle).
Co-installs at /usr/lib/panvk-bifrost/ — stock mesa untouched. Stock
libvulkan_panfrost.so and its ICD JSON keep working for everyone not
opting into the patched driver.
Ships /usr/bin/brave-vulkan that wires up:
VK_ICD_FILENAMES=/usr/lib/panvk-bifrost/icd.json
PAN_I_WANT_A_BROKEN_VULKAN_DRIVER=1
MESA_VK_VERSION_OVERRIDE=1.2 # ANGLE needs apiVersion>=1.1; the
# has_vk1_x flags don't move it, so
# the env-var override carries that
brave --use-gl=disabled --enable-features=Vulkan --use-vulkan=native
--ozone-platform=x11 --no-sandbox --disable-gpu-sandbox
--ignore-gpu-blocklist "$@"
Side-steps the stock "GLES3 is unsupported / GPU process exits" failure
documented in panvk-bifrost/README's "Consumer-side benefit" section.
Known limitation: WebGL/WebGL2 in-page won't work — ANGLE needs GLES3
which needs VK_EXT_transform_feedback, which PanVk-Bifrost doesn't
currently support. Browser chrome + standard page rendering work fine.
Gitea Actions job mesa-panvk-bifrost-aarch64 added to build.yml,
patterned on libva-v4l2-request-fourier-aarch64. Mesa build is slow
(~30-60min on actrunner-aarch64). Standalone (no needs:),
continue-on-error so it doesn't block other jobs.
Campaign artifacts: ~/src/panvk-bifrost/{README.md, phase8_iteration9_close.md,
phase0_evidence/iter9_brave_vulkan_breakthrough.txt}.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
marfrit