Files

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

4.6 KiB

Raw Permalink Blame History

Phase 4 progress — panvk-bifrost-video Commits 1-6 landed; 7b residual

State at 2026-05-21 20:40 UTC. All evidence in phase0_evidence/.

What's working end-to-end

Three required Vulkan video extensions advertised: VK_KHR_video_queue, VK_KHR_video_decode_queue, VK_KHR_video_decode_h264 (probe_vkvideo PASS 5/5).
Video decode queue family advertised at Vulkan idx 1 (PAN_ARCH<9), with VK_QUEUE_VIDEO_DECODE_BIT_KHR | VK_QUEUE_TRANSFER_BIT and videoCodecOperations = VK_VIDEO_CODEC_OPERATION_DECODE_H264_BIT_KHR.
Video session create/destroy: opens real V4L2 fds to /dev/video1 + /dev/media0, negotiates multi-planar H264_SLICE OUTPUT + NV12 CAPTURE formats, REQBUFS both queues with V4L2_MEMORY_DMABUF, allocates 18 request_fds via MEDIA_IOC_REQUEST_ALLOC, sets device-level DECODE_MODE_FRAME_BASED + START_CODE_ANNEX_B controls, STREAMON.
Per-physical-device capability + format entrypoints: panvk_GetPhysicalDeviceVideoCapabilitiesKHR (max 1920×1088, 16 DPB slots, level 4.2), panvk_GetPhysicalDeviceVideoFormatPropertiesKHR (NV12).
Cmd*Video* entrypoints dispatch reaches our code: Begin/End/Control/Decode are called per the spec for vk-video-samples simple-test. The first frame's params parse correctly: sps_id=0, pps_id=0, IdrPicFlag=0, 0 refs, src bitstream 6273 bytes.
Std → V4L2 H.264 bridge compiled in: panvk_v4l2_h264_std_to_ctrl_sps, _pps, _scaling_matrix, _default_flat_scaling_matrix, _build_decode_params (460 LoC, agent-authored, field-by-field map cited to V4L2 kernel docs).
14-step V4L2 ioctl dance compiled in: panvk_v4l2_submit_h264_decode does S_EXT_CTRLS (request_fd-bound) → QBUF OUTPUT → QBUF CAPTURE → MEDIA_REQUEST_IOC_QUEUE → poll(POLLPRI, 200ms) → DQBUF OUTPUT/CAPTURE. Per Phase 2 D7.

What's deferred — Commit 7b

The CmdVideo entrypoints currently log entry and discard their inputs. To actually decode, they need to:

Access cmdbuf->video.{vs,params} fields. These fields exist on JM panvk_cmd_buffer (added in this iter). Access requires the per-arch header, which an arch-agnostic source file can't reach. Fix: relocate the four CmdVideo entrypoints to jm/panvk_vX_video_decode_cmd.c so they compile only for PAN_ARCH<9 and have native access to the JM cmdbuf struct.
Translate parameters per frame. The Std→V4L2 bridge is ready; call site needs:
- vk_video_find_h264_dec_std_sps(params, pStdPictureInfo->seq_parameter_set_id) — lookup active SPS from session params
- vk_video_find_h264_dec_std_pps(params, sps_id, pic_parameter_set_id)
- panvk_v4l2_h264_std_to_ctrl_sps/pps()
- panvk_v4l2_h264_default_flat_scaling_matrix() (Phase 1; real scaling matrix is later)
- panvk_v4l2_h264_build_decode_params(vs, h264_pi, pps, dst_slot, refs, ts, &c_dec)
Resolve VkBuffer→dmabuf and VkImage→dmabuf. Open work — panvk's buffer/image management doesn't expose a direct BO accessor for arbitrary VkBuffer handles. Two candidate paths:
- DMABUF path: walk VkBuffer→bound VkDeviceMemory→panvk_device_memory.bo→pan_kmod_bo_export() (pattern at panvk_device_memory.c:400). Requires extending panvk_buffer to track its bound memory, OR using vk_buffer's implicit binding.
- MMAP path: REQBUFS with V4L2_MEMORY_MMAP instead of DMABUF, mmap() the kernel-allocated buffers, copy bitstream in / decoded frame out at QBUF/DQBUF time. Slower (CPU copies) but completely sidesteps panvk's BO integration. Probably the right Phase 1 minimum.
Call panvk_v4l2_submit_h264_decode(). The function exists, takes the four control structs + src/dst dma_buf fds + timestamp, runs the 14-step dance synchronously.
Update vs->dpb[dst_slot] with the output timestamp so the next frame's build_decode_params finds the reference correctly.

Snapshot for resume

Source tarball: phase0_evidence/commits_1-6_source_snapshot_2026-05-21.tgz (47KB, 10 files)
Test output: phase0_evidence/vk_video_samples_commit4-6_2026-05-21.txt (entrypoint dispatch confirmed)
Probe baseline: phase0_evidence/probe_vkvideo_commit1_PASS_2026-05-21.txt (5/5 PASS, regression check)
Build host: ohm at /home/mfritsche/mesa-build/mesa-26.0.6/
Live patched lib: /home/mfritsche/panvk-patched-libs/libvulkan_panfrost.so
ICD JSON: /tmp/iter17_icd.json (points at patched lib)

Per dev_process

Phase 4 stays open (Commit 7b residual). Phase 5 (janet review), Phase 6 (real decode validation), Phase 7 (mpv-fourier consumer proof), Phase 8 (package r1 of mesa-panvk-bifrost-video) are all gated on 7b.

— claude-noether, 2026-05-21

4.6 KiB Raw Permalink Blame History Unescape Escape