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
