Dear all, Here are the notes we took during the BoF.
I believe the meeting was super interesting. Although it felt a bit short for the topic, we left with a few interesting ideas. Thanks everyone! Ezequiel --- LPC 2020 BoF: Negotiating DMA-BUF Heaps Attendees: * Brian Starkey * Daniel Stone * Ezequiel Garcia * James Jones * John Reitan * Laura Abbott * Laurent Pinchart * Sumit Semwal * Robert Beckett # Replacing subsystem memory allocators with dma-buf heaps * Laurent: we should not have subsystem implement their own allocator. Using heaps could be a good idea. * Laura: Wary to add too much support to heaps, from the ION experience. * Laurent: V4L2: most drivers use videobuf2, which is a fairly complex piece of code. Three constraints, sg, contig, and vmalloc: these are fairly generic and not video-specific, why can't these just use heaps? * Brian: In-kernel API will most likely just care of dma-buf not necessarily FDs. This was discussed recently, see "Role of DMA Heaps vs GEM in allocation",https://www.spinics.net/lists/dri-devel/msg268103.html * Do we expect to get a non-file descriptor identifier for a dma-buf? No. * Laurent proposes a two steps API (similar to existing GEM API), where we have one interface to allocate a buffer, with an identifier local to a process, and then another interface to wrap the buffer on a dma-buf (fd). * If devices are not meant to be shared, then we might want to avoid the DMA-BUF design entirely. As Sumit mentioned, the fundamental idea behind DMA-BUF is that they are expected to be shared. OTOH, it was mentioned that sometimes we don't know if a buffer will be shared or not, so that's why the ability to wrap a buffer over dma-buf is useful. * New subsytems would possibly want to avoid implementing its own allocator interface. But unfortunately, we don't want to produce a fd per buffer, so that will mean a new subsystem will eventually require its own API (GEM-like). If a subsystem doesn't need many buffers, and the FD semantic is fine, then it would be acceptable to avoid a subsystem-specific API. * It would be interesting to experiment replacing videobuf2-dma-contig with just dma-buf heap usage, and see what kind of code save we'd save. * John Stultz has ideas around providing in-kernel accessors for the heaps - the idea is for drivers to not have to implement full exporter functionality for an already existing dma-buf heap type. * Drawback to this idea of reusing dma-buf heaps to allocate buffers, is that it means marking every buffer that gets exported as shareable. * The benefits in having a centralized implementation would be in unifying the semantics, reusable concepts that can be used to build future APIs around, rather than trying to created unified APIs around disparate kernel allocation APIs at only the userspace level. * Robert: Is there an in-kernel user for the in-kernel dma-buf request? A possible answer would be for scratch buffers. The idea would be to avoid getting details wrong. However, doing this would allow every buffer to be exportable. Also, it sounds like this means re-implementing DMA-API? * DMA-BUF are designed to be shared, not necessarily an allocator. * Want something to expose device-local memory to rest of kernel. Could be a dma-buf heap? _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
