panvk-bifrost/mesa-panvk-bifrost/phase8_iteration6_close.md

Iteration 6 close — GREEN

Closed 2026-05-19, same session as iter1–5.

Locked question

(From phase0_findings_iter6.md)

Depth-tested multi-draw: 128×128 RGBA8 + D32_SFLOAT depth attachment, large red triangle at z=0.7 + small green triangle at z=0.3 fully inside it, depth test selects green in overlap.

Result: GREEN

7/7 runs PASS (1 baseline + 1 validation + 5 stability). All five verification pixels correct. Deterministic across runs: red=3850, green=1352, clear=11182, other=0. No GPU faults, no validation warnings.

Evidence: phase0_evidence/iter6_depth_run.txt.

What the close tells us

All seven hypotheses in phase0_findings_iter6.md — none materialized.

• D32_SFLOAT depth attachment works (optimalTilingFeatures=0xd601 includes DEPTH_STENCIL_ATTACHMENT_BIT)
• Depth-stencil image creation + layout + image view all clean
• Depth test plumbing wires through to tile descriptors correctly
• Depth writes back to depth attachment correctly (otherwise overlap region would be all-red or all-green)
• Multi-draw in one render pass: both vkCmdDraw calls produced their triangles
• z-coord from vertex shader propagates through to depth test
• 128×128 tile binning (64 tiles, 4× larger than iter3) clean

Coverage accounting clean:

• Triangle A (red, NDC area 1.28 / 4 sq NDC = 32% expected) → 5202 non-clear pixels (3850 red + 1352 green) ≈ expected
• Triangle B (green, NDC area 0.32 / 4 = 8% expected) → 1352 ≈ expected
• "other" count = 0: no banding, no z-fighting artifacts, no interp errors at edges

iter6 in-tree artifacts

• iter6/probe_depth.c — depth probe
• iter6/probe_depth.vert — vec3 pos + color
• iter6/probe_depth.frag — pass-through
• iter6/Makefile

Cumulative state — six iters, ~40 runs, zero driver failures

PanVk-Bifrost on Mali-G52 r1 v7 has now been proven functional for:

Surface	Works
Compute pipeline + dispatch + storage buffer	✓ iter1
Image clear + transfer ops + tile decode	✓ iter2
Graphics pipeline + dynamic rendering + tile binner	✓ iter3
Sampled texture + COMBINED_IMAGE_SAMPLER + texelFetch	✓ iter4
Vertex buffer + UBO + vertex-stage descriptors + varying interp	✓ iter5
Depth attachment + depth test + multi-draw	✓ iter6

The "PAN_I_WANT_A_BROKEN_VULKAN_DRIVER" gate continues to look defensive, not load-bearing.

Next iter — iter7 lock proposal

Jump to a real off-the-shelf app: vkcube on ohm with the live Wayland session.

Justifications:

• vkcube is the Vulkan reference demo — rotating textured cube, classic workload.
• It exercises continuous rendering (many submissions in a row) which our static probes haven't tested.
• It uses VK_KHR_swapchain (WSI) — first time we test the swapchain path.
• It uses Wayland surface on a live compositor (Plasma) — first time we test KHR_wayland_surface.
• If it works, that's massive validation toward TuxRacer-via-Zink.
• If it crashes, that's the first interesting bug, and we have a known-reference reproducer.

iter7 question:

Run vkcube --c 120 (120 frames) on ohm with PAN_I_WANT_A_BROKEN_VULKAN_DRIVER=1, XDG_RUNTIME_DIR=/run/user/$(id -u), WAYLAND_DISPLAY=wayland-0 (or detected). Verify: process exits 0, no GPU faults in dmesg, no kernel-side panfrost errors. Operator visual confirmation of correct cube rendering optional (PineTab2 is visible to operator).

Pacing per the 8-phase loop. Opening iter7 immediately.