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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Wed, Jun 12, 2024 at 04:09:53PM -0400, Nicolas Dufresne wrote:
> 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,

I think we all agree on this. There's an extensive amount of work
required in this area.

> and no one is actively working on it.

That may change though, I've heard that some of the people involved in a
previous attempt are considering resuming the work. It of course doesn't
provide a guarantee of success.

> 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 think the selection of an allocator (in a nutshell, what DMA heap to
use) and the selection of buffer parameters (size, format, stride,
modifiers, ...) are two related but distinct problems. We need to design
a solution that will address both, but keep them distinct so that one
can still use the future generic allocator API without having to
delegate all the allocation parameters decisions to a third-party
component.

> 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.

-- 
Regards,

Laurent Pinchart