Files

T

claude-noether 358801be06 Track F (V4L2_MEMORY_DMABUF on OUTPUT): research + DROP verdict

Sonnet architect researched the candidate that's been carried for
five iterations. Key findings:

- FFmpeg kwiboo, GStreamer v4l2codecs, Chromium V4L2 VDA: all use
  V4L2_MEMORY_MMAP on OUTPUT. Zero production consumers use DMABUF.
- Mainline hantro + Rockchip rkvdec drivers advertise VB2_DMABUF
  capability but no consumer exercises it. Untested kernel path
  for hantro H.264 OUTPUT-DMABUF.
- Original cap_pool-race justification: closed organically by
  iter5+iter6+iter7. No residual motivation.
- Zero-copy-from-upstream-producer alternative benefit: no
  realistic producer in the campaign's pipeline (Firefox/mpv
  don't allocate compressed bitstream via dma-heap).

Bonus campaign-docs finding: PineTab2 is RK3566 (rkvdec2/vdpu346
target — no mainline driver yet, Christian Hewitt patch series
LKML 2025/12/26/206 not merged), not RK3568 as the campaign
docs have stated. The hantro rk3568-vpu DT compatible works
because the silicon is close enough; not a correctness issue,
just nomenclature accuracy.

Verdict: DROP. Track F off the iter8+ roadmap. Reopen criterion
documented for hardware-pipeline scenarios that are not on any
currently-chartered Rockchip SoC.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-06 11:19:00 +00:00

5.7 KiB

Raw Permalink Blame History

Track F (V4L2_MEMORY_DMABUF on OUTPUT) — research + verdict

Authored 2026-05-06 in response to operator request after iter7 close. The candidate had been carried for five iterations as "high-risk architectural" without concrete research. This document records the research outcome and the final disposition.

Prior art (every production V4L2 stateless H.264 consumer)

Consumer	OUTPUT (bitstream input)	CAPTURE (decoded frames)	Reference
FFmpeg kwiboo (`libavcodec/v4l2_request.c`)	`V4L2_MEMORY_MMAP`	`V4L2_MEMORY_MMAP` + `VIDIOC_EXPBUF`	The empirical authority for the campaign per `feedback_ffmpeg_v4l2_request_is_authority.md`
GStreamer `v4l2codecs` (`gstv4l2decoder.c`)	`V4L2_MEMORY_MMAP`	`V4L2_MEMORY_MMAP` + DMABUF export	All REQBUFS/CREATE_BUFS calls pass `.memory = V4L2_MEMORY_MMAP`
Chromium V4L2 VDA (`v4l2_video_decode_accelerator.cc`)	`V4L2_MEMORY_MMAP`	`V4L2_MEMORY_DMABUF` import (when in IMPORT mode for compositor)	OUTPUT stays MMAP regardless of mode
Mainline hantro driver (`drivers/media/platform/verisilicon/hantro_drv.c`)	advertises `VB2_MMAP \| VB2_DMABUF`	advertises `VB2_MMAP \| VB2_DMABUF`	Kernel exposes both as capabilities
Rockchip rkvdec staging driver (`drivers/staging/media/rkvdec/rkvdec.c`)	advertises `VB2_MMAP \| VB2_DMABUF`	advertises `VB2_MMAP \| VB2_DMABUF`	Same pattern as hantro

Takeaway: every real consumer uses MMAP on OUTPUT. The kernel exposes DMABUF as a capability but no production code path exercises it. A campaign Track F port would be the first exerciser of OUTPUT-DMABUF on hantro for H.264.

Rockchip platform coverage (driver split per SoC)

SoC	H.264 decode driver	Notes
RK3399 (PineBook Pro, RockPro64)	`rkvdec` (staging)	hantro VPU on this SoC has H.264 explicitly disabled; H.264 routes through rkvdec
RK3568	hantro vpu (`rockchip,rk3568-vpu`)	This is what the campaign's hantro fork targets via DT
RK3566 (PineTab2 — actual silicon)	should be `rkvdec2`/`vdpu346`	No mainline driver yet. Christian Hewitt patch series LKML 2025/12/26/206, not merged as of campaign closure date
RK3588	`rkvdec2` (merged Feb 2026)	Hantro on this SoC handles encode only

Important campaign-documentation finding: the campaign's docs have referred to PineTab2 as RK3568 throughout. PineTab2 is actually RK3566. The hantro rk3568-vpu DT compatible apparently works because the silicon is close enough — but the campaign's iter1..iter7 evidence is on RK3566 silicon running the rk3568 driver path. This has not been a problem, but it's a load-bearing detail to record.

Kernel-side OUTPUT-DMABUF state for hantro / rkvdec

Both drivers declare VB2_DMABUF in io_modes for the OUTPUT queue. The vb2 import path (vb2_dma_contig_memops with attach_dmabuf/map_dmabuf) would handle the DMA attachment.

Wrinkle: the hantro OUTPUT queue is configured with:

src_vq->dma_attrs = DMA_ATTR_ALLOC_SINGLE_PAGES | DMA_ATTR_NO_KERNEL_MAPPING;

DMA_ATTR_NO_KERNEL_MAPPING applies to the allocator path (MMAP), not the importer path (DMABUF). DMABUF import is not blocked by this flag.

No kernel mailing list discussion of "hantro OUTPUT-DMABUF for H.264" was found — neither working examples nor breakage reports. This is honestly an untested path.

Cost/benefit synthesis

What Track F would buy us

Original justification (cap_pool race): closed organically by iter5/iter6/iter7. No residual motivation.
Theoretical zero-copy from an upstream compressed-bitstream producer: doesn't apply. Firefox demuxes from network/disk; mpv demuxes from file. Neither allocates the compressed bitstream via dma-heap and exports it as dma-buf. The canonical DMABUF zero-copy story is for raw video frames on the CAPTURE side (already DMABUF-exported via VIDIOC_EXPBUF), not compressed bitstream on the OUTPUT side.

Cost

New alloc path (dma-heap or dmabuf-heap allocator in userspace).
New QBUF/DQBUF lifecycle with fd passing instead of buffer-index-only.
New kernel path through vb2_dma_contig importer — first exerciser on hantro for H.264.
Complete replacement of request_pool.c MMAP-based slot management.

Risk

Moderate to high. Untested kernel path. No precedent to reference.

Verdict: DROP

Track F is dropped from the campaign roadmap.

The candidate was created in iter2 as a structural fix for the cap_pool race. That race has been closed by other means (iter5 sweep + iter6 REINIT discipline + iter7 OUTPUT-pool teardown). The candidate's original purpose no longer exists. The alternative benefit case (zero-copy from upstream producer) has no realistic source in the campaign's pipeline. Every production V4L2 stateless H.264 consumer uses MMAP on OUTPUT. The kernel-side DMABUF support is advertised but untested.

Drop. Move on.

What would reopen this

A future pipeline stage where compressed bitstream arrives from another hardware component (DMA engine, network offload, hardware demux) that allocates and exports the bitstream as a dma-buf fd before libva sees it. That is not a scenario on any current or chartered Rockchip SoC embedded target.

If the campaign ever expands to hardware where this is the case (TI TDA4VM-class with hardware demux, secure-content paths on Qualcomm-class, etc.), reconsider. Until then: removed from the roadmap.

Operator action

Update phase0_findings_iter6.md and phase0_findings_iter7.md candidate F entries to reflect dropped status; this document is the canonical reference. No iter8 work on this candidate.

The PineTab2-is-RK3566-not-RK3568 finding is recorded above and will be picked up by future docs as needed; not a campaign correctness issue, just nomenclature accuracy.

5.7 KiB Raw Permalink Blame History