Files
panvk-bifrost/mesa-panvk-bifrost/iter15/phase0_findings.md
T
marfrit a4e7d8ab90 initial seed: retrofit campaign lineage from local working trees
panvk-bifrost campaigns (r1..r4 Vulkan compositor + r5.video1 Vulkan
video decode) shipped before this repo existed; the deliverable
patches live in marfrit-packages, but the reasoning chain, phase docs,
and source-state evidence lived only in local working trees on the
development host.

This retrofit imports:
- mesa-panvk-bifrost/   — r1..r4 era phase docs (iter1..iter18)
                          (libmali stub blobs at iter18/blob/ excluded
                          — 109MB of RE artifacts replaced with a README
                          pointer)
- mesa-panvk-bifrost-video/ — sibling campaign phase docs + probe
- evidence/             — frozen .tgz source snapshots at each milestone
                          (basis for the 0005 patch diff generation)

Future iterations should branch off here from day one, so each iter is
a commit rather than a snapshot. See [[feedback-session-local-process-pins]]
for the process drift this retrofit closes.

Total: 1.9 MB across 124 files.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-23 05:25:37 +02:00

3.6 KiB
Raw Blame History

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 35 hours. Memory-bound when linking; will probably want make -j2 not -j4.
  • Smoke (~100 tests): ~5 minutes.
  • transform_feedback subset (~150 tests): ~1020 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: 46 hours.

— claude-noether, 2026-05-20