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>
4.6 KiB
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_BITandvideoCodecOperations = VK_VIDEO_CODEC_OPERATION_DECODE_H264_BIT_KHR. - Video session create/destroy: opens real V4L2 fds to
/dev/video1+/dev/media0, negotiates multi-planarH264_SLICEOUTPUT +NV12CAPTURE formats, REQBUFS both queues withV4L2_MEMORY_DMABUF, allocates 18 request_fds viaMEDIA_IOC_REQUEST_ALLOC, sets device-levelDECODE_MODE_FRAME_BASED + START_CODE_ANNEX_Bcontrols, 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_decodedoesS_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 JMpanvk_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 tojm/panvk_vX_video_decode_cmd.cso 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 paramsvk_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 atpanvk_device_memory.c:400). Requires extendingpanvk_bufferto track its bound memory, OR usingvk_buffer's implicit binding. - MMAP path: REQBUFS with
V4L2_MEMORY_MMAPinstead 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.
- DMABUF path: walk VkBuffer→bound VkDeviceMemory→
-
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'sbuild_decode_paramsfinds 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