panvk-bifrost/mesa-panvk-bifrost/iter16/phase8_close.md

Phase 8 close — iter16: DEFERRED

Result: iter16 closes as Path D — investigation complete, fix deferred. The 162 winding-order CTS fails categorized in iter15 remain known/documented; campaign's iter13 + iter15 deliverables unchanged.

What was attempted

Driver-side primitive decomposition for transform_feedback on non-LIST topologies (TRIANGLE_STRIP / LINE_STRIP / TRIANGLE_FAN / *_WITH_ADJACENCY). Plan: inside panvk_per_arch(CmdDraw), when XFB-active + non-LIST, build a synthetic index buffer encoding the spec-required decomposition, dispatch as indexed-LIST.

Infrastructure built (all working, tested):

• panvk_vX_winding.c — topology decomposition tables for 7 topologies
• panvk_winding_table struct + panvk_per_arch(get_winding_table) API
• cmdbuf->state.gfx.xfb.decomposed_count field + sysval override for vs.num_vertices
• IB + topology state save/restore around the synthetic dispatch
• IB dirty bit + MESA_VK_DYNAMIC_IA_PRIMITIVE_TOPOLOGY dirty bit set
• Regression probe (iter16/probe_winding.c) parametrized for 3+ topologies

What didn't work (Path A & Path B both):

• Calling panvk_cmd_draw_indirect directly with a manually-constructed VkDrawIndexedIndirectCommand (Path A)
• Calling panvk_per_arch(CmdDrawIndexed) from inside the injection after state mutation (Path B, per architect's recommendation)

Both produce the same 8-entry non-indexed output (0,1,2,3,4,5,6,7 for an 8-vert triangle strip), not the expected 18-entry decomposed output (0,1,2,1,3,2,...).

What was definitively isolated

• iter13 XFB + vkCmdDrawIndexed via public entries: works — confirmed by iter16/probe_idx.c. 6 indices [10,11,12,13,14,15] captured exactly.
• Render-pass scope isn't the issue: vkCmdBindIndexBuffer AFTER pBeginRendering works fine if it's a real vkCmd call.
• info.index.size being zero isn't the issue (architect's diagnosis): my draw construction set it correctly to 4.
• The mystery: state-mutation-from-within-CmdDraw doesn't reproduce what a separate vkCmdBindIndexBuffer2 call sets up. Hypotheses still on the table:
  • Pipeline-bind-time descriptor emission captures IB-bound state at that moment
  • VK_FROM_HANDLE(panvk_buffer) in CmdBindIndexBuffer2 registers BO with batch in a way direct state writes skip
  • Mali JM dirty-tracking needs explicit invalidation we're missing
• Resolving requires either Mali Graph Profiler / RGP (we don't have) or significantly more time in driver internals.

What ships from iter16

• ALL Phase 0-3 docs in iter16/ (substrate, source map, design lock, probe + Makefile)
• The full WIP code in iter16/applied_state/ — panvk_vX_winding.c plus the modifications to panvk_cmd_draw.h, panvk_vX_cmd_draw.c, jm/panvk_vX_cmd_draw.c, meson.build — applied on ohm but reverted from any published package
• iter16/probe_winding.c + probe_idx.c — both probes work as regression tests if iter16 resumes
• iter16/phase4_progress.md — detailed status for resumer, including the architect consultation outcome
• iter16/phase8_close.md — this doc

What does NOT ship from iter16

• No code changes to the published mesa-panvk-bifrost-26.0.6.r3 package
• No CTS rerun (the 162 winding fails remain — same as iter15's measurement)
• No upstream Mesa MR

Why deferred and not "Path C — NIR-pass decomposition"

Path C is the remaining structural option and probably the right long-term fix (200-400 LoC in pan_nir_lower_xfb to emit multiple nir_store_global calls per VS invocation — one per primitive each vertex contributes to). It would bypass the dispatch-level mystery entirely. But:

• It's multi-day Mesa-internals work (NIR builder + shader-cache invalidation + per-topology lowering rules).
• Real-world impact is approximately zero: ANGLE on Vulkan (the iter13/Brave motivator) doesn't trigger this path because ANGLE pre-decomposes strip topologies before issuing the Vulkan call (mirroring OpenGL's own decomposition rules).
• The iter13 + iter15 standing campaign deliverables (Vulkan-on-Brave + 75.7% transform_feedback CTS pass rate) are NOT affected by leaving this open.

Path C remains the right move if someone returns to iter16 with time/motivation.

ohm state cleanup

The WIP iter16 patches are still applied on ohm at /home/mfritsche/mesa-build/mesa-26.0.6/. They build clean. The patched lib is in /home/mfritsche/panvk-patched-libs/libvulkan_panfrost.so but the system-installed /usr/lib/panvk-bifrost/ is r3 untouched. So the campaign's published-package behavior is unchanged.

To fully revert ohm to a clean iter13-only source state (if needed for a future iter): the patches are in iter16/applied_state/. Easy to identify (all marked with iter16: comments) and reverse-patch.

Bottom line

iter16 = investigation closed. Path D (defer) chosen because Path B (architect's pick) didn't pan out and Path C (NIR pass) wasn't worth a multi-day investment given zero real-world impact on the iter9/iter13 ANGLE-on-Vulkan campaign target. Anyone resuming iter16 should start from iter16/phase4_progress.md and the listed hypotheses.

— claude-noether, 2026-05-21