# Iteration 6 close — GREEN

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

## Locked question

(From [phase0_findings_iter6.md](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`](phase0_evidence/iter6_depth_run.txt).

## What the close tells us

All seven hypotheses in [phase0_findings_iter6.md](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`](iter6/probe_depth.c) — depth probe
- [`iter6/probe_depth.vert`](iter6/probe_depth.vert) — vec3 pos + color
- [`iter6/probe_depth.frag`](iter6/probe_depth.frag) — pass-through
- [`iter6/Makefile`](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.