# Iteration 7 close — GREEN

Closed **2026-05-19**, same session as iter1–6. **Operator-witnessed.**

## Locked question

(From [phase0_findings_iter7.md](phase0_findings_iter7.md))

> Run `vkcube --c 120 --wsi wayland` on ohm (Plasma/Wayland) with `PAN_I_WANT_A_BROKEN_VULKAN_DRIVER=1`. Verify: process exits 0, frames rendered, no GPU faults, no kernel-side panfrost errors. Operator may visually confirm.

## Result: GREEN

3 runs (120 frames + 120 frames + 240 frames), all RC=0. Validation layer active in run #2 — zero warnings.

**Operator visual confirmation: "Ich hab' ihn gesehen."** — vkcube's rotating textured cube rendered correctly on the PineTab2 screen.

Performance: 240 frames in 4.352s = **~55 FPS sustained**, vsync-locked.

No GPU faults, no MMU faults, no panfrost kernel errors across any run.

Evidence: [`phase0_evidence/iter7_vkcube_run.txt`](phase0_evidence/iter7_vkcube_run.txt).

## What the close tells us

All five hypotheses in [phase0_findings_iter7.md](phase0_findings_iter7.md) — **none materialized.**

- **VK_KHR_wayland_surface** works on PanVk-Bifrost against live Plasma compositor.
- **Swapchain** path is functional (vkcube allocates a swapchain, runs through 240 frames).
- **Present queue support** materializes correctly with a real surface (despite "present support = false" in headless vulkaninfo).
- **Continuous frame submission** + acquire/present cycle works for hundreds of frames.
- **vkcube's combined workload** (MVP UBO + textured cube + depth + present) — works.

This is the **first off-the-shelf application** in the campaign. It works. The PineTab2 + Mali-G52 + Mesa 26.0.6 + PanVk-Bifrost + Plasma stack can drive a rotating textured Vulkan cube at display refresh rate.

## Cumulative state — seven iters, ~43 runs, zero driver failures, operator-witnessed real-app workload

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

| Surface | Iter |
|---|---|
| Compute pipeline | iter1 |
| Image transfer ops | iter2 |
| Graphics pipeline + dynamic rendering | iter3 |
| Sampled textures + texelFetch | iter4 |
| Vertex buffers + UBO + varying interp | iter5 |
| Depth attachment + multi-draw | iter6 |
| **Real app (vkcube) + WSI + Wayland + swapchain + continuous frames** | **iter7** |

## iter7 in-tree artifacts

- [`phase0_findings_iter7.md`](phase0_findings_iter7.md) — lock
- [`phase0_evidence/iter7_vkcube_run.txt`](phase0_evidence/iter7_vkcube_run.txt) — run captures + operator-witness statement
- (No iter7/ source dir — used stock vkcube)

## Next iter — iter8 lock proposal

**Zink-on-PanVk smoke: run a simple OpenGL ES application via Mesa's Zink driver (GL → Vulkan translation) backed by PanVk-Bifrost.** This is the bridge to TuxRacer.

Approach:
1. Verify Zink is available in Mesa 26.0.6 on ohm (`MESA_LOADER_DRIVER_OVERRIDE=zink`).
2. Run something simple under Zink: `glmark2-es2-wayland` (already present per pacman check in iter0; verify) or `es2_info` to confirm bindings, or write a minimal GL probe.
3. Verify: GL context creates, GL rendering works, no crashes during a brief workload.

iter8 question:
> **Verify Zink-on-PanVk works on ohm — run `glmark2-es2-wayland` (or equivalent stock ES2 demo) with `MESA_LOADER_DRIVER_OVERRIDE=zink` + `PAN_I_WANT_A_BROKEN_VULKAN_DRIVER=1` against Plasma/Wayland. Verify: at least one benchmark scene completes, no GPU faults, no Zink/Mesa crashes. If glmark2 has issues unrelated to Zink, fall back to es2gears or a minimal GL probe.**

If iter8 GREEN: PanVk-Bifrost is real and TuxRacer-via-Zink is on the path.

Pacing per 8-phase loop. iter8 opens immediately.