# Phase 0 — substrate lock for iter15 (CTS conformance on iter13)

**Goal:** measure how much of the proprietary Mali blob's Vulkan coverage is now reachable via the open mesa-panvk-bifrost stack — concretely, by running targeted Khronos CTS subsets against the system-published `mesa-panvk-bifrost 26.0.6.r3-1` ICD on ohm (PineTab2 / Mali-G52 r1 MC1).

Operator framing (2026-05-20): "we never touched the vendor Mali blob, and I'd like to know how much of that now ships with panvk-bifrost."

## Substrate state

Hardware: PineTab2, Mali-G52 r1 MC1 (PAN_ARCH 7, Bifrost gen), RK3566, 4× Cortex-A55, 7.5 GB RAM.

Software:
- ICD under test: `/usr/lib/panvk-bifrost/libvulkan_panfrost.so` (mesa-panvk-bifrost 26.0.6.r3-1, the iter13 published package).
- Build deps: cmake 4.3.2, gcc 16.1.1, clang 22.1.5, make 4.4.1, git 2.54, python 3.14.5 — all present.
- Disk: 53 GB free on `/` — sufficient for CTS source + build (~13 GB combined).
- No vk-gl-cts installed; needs fresh clone + build on ohm.

## Scope (locked Phase 2-style here since the operator picked early)

**Targeted subsets, not full CTS.** Three groups, each with a specific motivation:

1. `dEQP-VK.api.smoke.*` — sanity. ~100 tests. Validates the CTS harness + the ICD's basic API plumbing. If smoke fails, the run is broken; no point looking deeper.
2. `dEQP-VK.transform_feedback.*` — iter13 territory. The XFB implementation we shipped. ~150 tests covering basic capture, multi-buffer, multi-stream, query interaction, pause-resume. Many will SKIP because we advertise `transformFeedbackQueries=false`, `transformFeedbackDraw=false`, `geometryStreams=false`.
3. `dEQP-VK.robustness.*` — iter8 territory. The KHR/EXT_robustness2 + nullDescriptor exposure flip. Tests that out-of-bounds reads/writes don't fault and nullDescriptor sampling returns zeroes.
4. `dEQP-VK.info.*` — capabilities introspection. Not a pass/fail measurement; produces the device's reported limits + extensions list that future iters can diff against.

Out of scope:
- The full must-pass list (would take a day-plus and we'd hit "panvk is not conformant" by design on many tests).
- OpenGL / GLES tests (chromium-fourier territory, separate campaign).
- Bug fixing inside Mesa for any failure (iter15 reports findings; fixes belong to follow-up iters or upstream Mesa MRs).

## Out-of-scope failure modes

- **CTS itself doesn't build.** Falling back to a pre-built binary is unlikely on aarch64; will need debugging if hit.
- **CTS launcher refuses non-conformant driver.** `PAN_I_WANT_A_BROKEN_VULKAN_DRIVER=1` env should keep panvk enumerable through CTS's pipeline.
- **CTS subset doesn't match expected names.** Khronos has reorganized test trees across versions. Phase 1 will pin the exact CTS commit/tag based on what builds clean.

## Plan

1. Phase 1: clone vk-gl-cts at a recent stable tag (last tag matching Vulkan 1.2.x conformance), build out-of-source on ohm.
2. Phase 3: smoke run first (`dEQP-VK.api.smoke.*`) to verify the harness works.
3. Phase 4: run the three targeted subsets, collect logs + categorize PASS / FAIL / NOT_SUPPORTED / CRASH.
4. Phase 6: report the numbers — total tests / passed / failed / skipped + per-subset breakdown.

## Time budget

ohm at 4× A55:
- CTS build: estimated 3–5 hours. Memory-bound when linking; will probably want `make -j2` not `-j4`.
- Smoke (~100 tests): ~5 minutes.
- transform_feedback subset (~150 tests): ~10–20 minutes.
- robustness subset (~300 tests): ~30 minutes.
- info subset (~50 tests, all read-only): ~2 minutes.

Total run time after build: well under 1 hour. Total wallclock including build: 4–6 hours.

— claude-noether, 2026-05-20