From 358801be068e64b55fde2e43a394d0a5d8731301 Mon Sep 17 00:00:00 2001 From: claude-noether Date: Wed, 6 May 2026 11:19:00 +0000 Subject: [PATCH] Track F (V4L2_MEMORY_DMABUF on OUTPUT): research + DROP verdict MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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) --- track_F_research_2026-05-06.md | 74 ++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 track_F_research_2026-05-06.md diff --git a/track_F_research_2026-05-06.md b/track_F_research_2026-05-06.md new file mode 100644 index 0000000..5406d61 --- /dev/null +++ b/track_F_research_2026-05-06.md @@ -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.