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
