marfrit
a4e7d8ab90
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>
56 lines
3.6 KiB
Markdown
56 lines
3.6 KiB
Markdown
# 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
|