marfrit/libva-multiplanar
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Track F (V4L2_MEMORY_DMABUF on OUTPUT): research + DROP verdict

Browse Source 
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>
This commit is contained in:
Claude (noether)
2026-05-06 11:19:00 +00:00
parent b996794246
commit 358801be06
1 changed files with 74 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
track_F_research_2026-05-06.md
+74
View File
@@ -0,0 +1,74 @@
# 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:
```c
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.