Re: [ANN] Request for Topics and registration for a Media Summit September 16th

[Nicolas Dufresne <nicolas.dufresne@collabora.com>]

Hi Tomasz,

Le mercredi 12 juin 2024 à 18:01 +0900, Tomasz Figa a écrit :
> >   I would like to
> > deprecate MMAP too and only focus on DMABUF. I believe Linux needs a
> > centralized buffer allocator, instead of having multiple allocation APIs
> > scattered in different places. There are design ideas in gralloc that we
> > could benefit from.
> > 
> 
> Given that we now have DMA-buf heaps in mainline, it sounds much more
> realistic. It would certainly help eliminate some issues in the vb2
> layer, such as vb2-dma-sg having its own open coded page allocation
> that can't handle DMA addressing limitations (which can be fixed with
> some additions to the DMA API, but eliminating the problem altogether
> is way better than any other solution.)
> 
> That said, as we already use a centralized DMA-buf allocator in
> ChromeOS and don't really care about the MMAP mode, I'm definitely
> biased here. We would need to hear from people working on userspace
> which still uses it (if there is any).

This aspect is what makes the V4L2 support in chromium really sad to non
ChromeOS users. ChromeOS makes arbitrary decisions like that codec video node
must be named video-dec0/enc0 (there is solutions to that using udev and
topologies btw), and decided that minigbm is the only way allocate memory for
these codecs on Linux. In practice, in every project where we need Chromium V4L2
codecs, we endup having to patch it to do MMAP/dmabuf export support and EGL
import support (the other way around).

I'm not bashing against ChromeOS, I just want to underline that this is far from
a solve problem, and no one is actively working on it. I don't see minigbm
becoming an acceptable goto library, since EOL (in Chromebook term) hardware get
removed and you need a CLA to contribute. I also strongly disagree that the
calculation of auxiliary buffer needed for codecs reference frame should be done
in a third party library. The driver must validate these sizes, and is the
logical place to have this logic, not a third party system allocator. On that
front though, its a bit like the video-decX dev node naming, there is a generic
solution, since the size is exposed through TRY/S_FMT calls already.

I'll repeat that as often as needed, there is a lot of gaps toward removing mmap
(dmabuf exportation) in CODEC drivers which ChromeOS only have hacks around and
no generic solution suitable for generic linux community. In FFMPEG and
GStreamer, we use mmap + dmabuf export because that is actually usable in a
generic manner today.

Nicolas