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>
This commit is contained in:
@@ -0,0 +1,94 @@
|
||||
# Phase 0 — substrate for iter13
|
||||
|
||||
Opened **2026-05-20** after iter11 partial-GREEN + iter12 RED-with-known-causes (γ and δ both walled off by hard constraints in Brave + PanVk-Bifrost).
|
||||
|
||||
iter13 is a **substantial implementation effort**, not a "flip a gate" iter. Estimate: **days to two weeks of focused work**.
|
||||
|
||||
## Locked research question — iter13
|
||||
|
||||
> **Implement `VK_EXT_transform_feedback` in Mesa's PanVk Vulkan driver for the JM-class architectures (Bifrost v6/v7 primary target; Valhall-JM v9 free-rider). The extension is currently implemented for *no* PanVk arch.** Land the extension as proper code in `src/panfrost/vulkan/`, validated by:
|
||||
>
|
||||
> 1. A focused probe (iter1-style) that does a minimal XFB capture (one vertex shader emitting 3 vec4s to an output buffer, read back, verify byte-exact match).
|
||||
> 2. Mesa-internal validation: build + KHR validation layer report zero warnings.
|
||||
> 3. The downstream campaign objective: **ANGLE on PanVk-Bifrost engages GLES3 cleanly without the `eglCreateContext ES 3.0 failed` error**, which means Brave's VAAPI delivery path can engage hardware video decode (closing the iter11/12 gap).
|
||||
|
||||
## Why this shape
|
||||
|
||||
iter12 established that Brave's VAAPI hardware delivery is blocked by ANGLE requiring GLES3, which requires `VK_EXT_transform_feedback` from the underlying Vulkan driver, which PanVk-Bifrost doesn't expose.
|
||||
|
||||
The Bifrost **hardware** can do XFB — `src/gallium/drivers/panfrost/pan_shader.c` proves it via `pan_nir_lower_xfb`, which Panfrost-Gallium runs on vertex shaders when GLES3 XFB is active. The path is:
|
||||
|
||||
```
|
||||
Panfrost-Gallium does this:
|
||||
1. nir_io_add_intrinsic_xfb_info (standard Mesa NIR pass)
|
||||
2. pan_nir_lower_xfb (Panfrost's own NIR transformation —
|
||||
emits Bifrost-compatible buffer stores)
|
||||
3. Compile a SECOND shader variant (key.vs.is_xfb=true)
|
||||
4. At draw time: bind XFB buffers + run the is_xfb VS instead of the regular VS
|
||||
```
|
||||
|
||||
What's missing in PanVk-Vulkan: the Vulkan-API plumbing. **The shader compilation knowledge already exists** in `pan_nir_lower_xfb` — we just need to wire it through the panvk path and add the VkCmd* handlers.
|
||||
|
||||
So this is **API porting work**, not Bifrost RE work. Vastly cheaper than the libmali trace-and-diff approach mentioned in the campaign README.
|
||||
|
||||
## Hypothesis space
|
||||
|
||||
1. **`pan_nir_lower_xfb` is reusable as-is.** It operates on NIR; doesn't know about Gallium vs Vulkan. The output bindings might assume specific buffer slot conventions that Panfrost-Gallium sets up — we'd need to match those conventions in PanVk's command path.
|
||||
|
||||
2. **Vulkan XFB binding ↔ Bifrost attribute buffer / SSBO slot mapping.** Vulkan's `vkCmdBindTransformFeedbackBuffersEXT(firstBinding, bindingCount, buffers, offsets, sizes)` maps to up to 4 stream binding slots. On Bifrost, these need to be programmed as buffer descriptors visible to the lowered XFB shader. Looking at how Panfrost-Gallium does it will tell us the exact convention.
|
||||
|
||||
3. **Shader variant selection.** Vulkan compiles each pipeline shader once; XFB is per-draw state. So PanVk must either:
|
||||
- Cache TWO shader variants (regular + is_xfb=true) per pipeline, mirror Gallium's approach.
|
||||
- Or pre-compile both eagerly when XFB extension is enabled by the pipeline layout.
|
||||
The latter is simpler; the former is more memory-efficient.
|
||||
|
||||
4. **Query support.** `VK_EXT_transform_feedback` ships with two new query types: `VK_QUERY_TYPE_TRANSFORM_FEEDBACK_STREAM_PRIMITIVES_WRITTEN_EXT` and the matching `OVERFLOW` query. Bifrost has occlusion query support; we'd need to plumb a similar shape for XFB-primitives counters.
|
||||
|
||||
5. **Pause/Resume XFB.** Vulkan supports interrupting an XFB feedback and resuming. Bifrost may or may not have hardware counter-state save. If not, we need software-state shadow.
|
||||
|
||||
6. **Risk: `rasterizerDiscardEnable`.** When XFB is the only purpose of a draw (no fragment output), apps set `rasterizerDiscardEnable=VK_TRUE`. PanVk should honor that — skip the rasterizer entirely. May already work; may need wiring.
|
||||
|
||||
7. **Risk: validation layer requirements.** Once we advertise the extension, Khronos validation will check that all required entry points are present, all required features are reported, all property constraints hold. Some of these might require new query handling, new property struct fields, etc. The full extension surface is more than just the obvious vkCmd*'s.
|
||||
|
||||
## Files to touch (preliminary)
|
||||
|
||||
- `src/panfrost/vulkan/panvk_vX_physical_device.c` — expose `EXT_transform_feedback`, populate `VkPhysicalDeviceTransformFeedbackPropertiesEXT` + features
|
||||
- `src/panfrost/vulkan/panvk_vX_shader.c` — wire `pan_nir_lower_xfb` into the NIR lowering chain when XFB is enabled
|
||||
- `src/panfrost/vulkan/jm/panvk_vX_cmd_draw.c` — hook XFB-variant shader selection + buffer bindings into draw
|
||||
- `src/panfrost/vulkan/jm/panvk_vX_cmd_xfb.c` — **NEW FILE** — vkCmdBeginTransformFeedbackEXT, vkCmdEndTransformFeedbackEXT, vkCmdBindTransformFeedbackBuffersEXT, vkCmdDrawIndirectByteCountEXT
|
||||
- `src/panfrost/vulkan/jm/panvk_vX_cmd_query.c` — add VK_QUERY_TYPE_TRANSFORM_FEEDBACK_* handlers
|
||||
- `src/panfrost/vulkan/jm/panvk_vX_cmd_buffer.c` — XFB state on command buffer (active streams, bound buffers, paused, etc.)
|
||||
- `src/panfrost/vulkan/meson.build` — list new files
|
||||
|
||||
## Phase plan (8-loop)
|
||||
|
||||
- **Phase 0 (this doc)**: lock substrate.
|
||||
- **Phase 1: source-deep-read.** Map `pan_nir_lower_xfb` semantics + buffer conventions. Identify the exact slot binding pattern Panfrost-Gallium uses. Output: `phase1_iter13_source_map.md`.
|
||||
- **Phase 2: situation analysis.** Confirm the implementation sketch is sound. Second-model review of the design. Output: `phase2_iter13_situation.md`.
|
||||
- **Phase 3: regression test.** Write `iter13/probe_xfb.c` — minimal Vulkan probe that creates a pipeline with XFB, runs a single triangle draw with rasterizer-discard, reads back captured vertices, verifies. iter1-style. Probe lives on its own; doesn't depend on iter9 wrappers.
|
||||
- **Phase 4: implementation.** Add extension exposure, command handlers, shader-lowering wiring, query support. Test against the Phase 3 probe.
|
||||
- **Phase 5: second-model review.** Per CLAUDE.md, reviews are never skippable. Specifically check for: spec compliance (all entry points + features), edge cases (pause/resume, multi-stream, query overflow), no regressions in existing JM-path tests (iter1-7 probes still pass).
|
||||
- **Phase 6: integration test.** Run with ANGLE on PanVk-Bifrost — does `eglCreateContext ES 3.0` succeed now? Does Brave's VAAPI delivery engage? (This is the campaign-level value test.)
|
||||
- **Phase 7: perf baseline.** Compare WebGL benchmark (Browser-internal WebGL via Zink/ANGLE-on-PanVk-Bifrost with our XFB) to other Bifrost SBC baselines if any.
|
||||
- **Phase 8: close + ship.** Add to `arch/mesa-panvk-bifrost/` PKGBUILD, bump pkgrel, Gitea CI rebuild, 3-point check.
|
||||
|
||||
## In-scope (LOCKED 2026-05-20 for iter13)
|
||||
|
||||
- VK_EXT_transform_feedback for JM-arch PanVk (Bifrost v6/v7 + free-rider Valhall-JM v9).
|
||||
- Validation against an iter1-style probe.
|
||||
- Downstream: ANGLE-GLES3 success on PanVk-Bifrost → Brave VAAPI delivery.
|
||||
|
||||
## Out-of-scope (LOCKED 2026-05-20 for iter13)
|
||||
|
||||
- Valhall-CSF / fifth-gen XFB (different arch, separate work; out of campaign scope unless trivially free).
|
||||
- Geometry / tessellation shader XFB (`VK_EXT_geometry_shader` not exposed at all in PanVk yet; we're vertex-only).
|
||||
- libmali RE — explicitly NOT needed; Mesa Panfrost-Gallium is the oracle.
|
||||
- Upstreaming patches (per `feedback_no_upstream`, but the patches will be MIT-licensed and we can hand them to Collabora if they want).
|
||||
- Conformance testing — not the goal; "ANGLE works + WebGL benchmark runs" is the bar.
|
||||
|
||||
## Reference
|
||||
|
||||
- Panfrost Gallium XFB code: `src/gallium/drivers/panfrost/pan_shader.c` lines 125-130, 378-378, 511, 593-603, 642-646. **`pan_nir_lower_xfb` is the load-bearing function.**
|
||||
- Vulkan spec: VK_EXT_transform_feedback extension chapter.
|
||||
- Prior iter closes: [iter1](phase8_iteration1_close.md) – iter11 partial GREEN.
|
||||
- Campaign motivation: this enables both WebGL in Brave AND the iter11/12 missing piece (VAAPI delivery via ANGLE GLES3).
|
||||
Reference in New Issue
Block a user