On Sun, Aug 16, 2020 at 10:23 AM Ezequiel Garcia <ezequiel@xxxxxxxxxxxxx> wrote: > > This heap is basically a wrapper around DMA-API dma_alloc_attrs, > which will allocate memory suitable for the given device. > > The implementation is mostly a port of the Contiguous Videobuf2 > memory allocator (see videobuf2/videobuf2-dma-contig.c) > over to the DMA-BUF Heap interface. > > The intention of this allocator is to provide applications > with a more system-agnostic API: the only thing the application > needs to know is which device to get the buffer for. > > Whether the buffer is backed by CMA, IOMMU or a DMA Pool > is unknown to the application. My hesitancy here is that the main reason we have DMA BUF Heaps, and ION before it, was to expose different types of memory allocations to userspace. The main premise that often these buffers are shared with multiple devices, which have differing constraints and it is userspace that best understands the path a buffer will take through a series of devices. So userspace is best positioned to determine what type of memory should be allocated to satisfy the various devices constraints (there were some design attempts to allow DMA BUFs to use multiple attach with deferred alloc at map time to handle this constraint solving in-kernel, but it was never adopted in practice). This however, requires some system specific policy - implemented in the Android userspace by gralloc which maps "usage" types (device pipeline flows) to heaps. I liken it to fstab, which helps map mount points to partitions - it's not going to be the same on every system. What you seem to be proposing seems a bit contrary to this premise - Userland doesn't know what type of memory it needs, but given a device can somehow find the heap it should allocate for? This seems to assume the buffer is only to be used with a single device? There was at some point a discussion where folks (maybe it was DanielV? I can't remember...) suggested having something like a sysfs device node link from a device to a dma-buf heap chardev. This seems like it would add a similar behavior as what you're proposing, however without adding possibly a ton of new device specific heaps to the /dev/dma_heap/ dir. However, we would potentially need any missing heap types added first. > I'm not really expecting this patch to be correct or even > a good idea, but just submitting it to start a discussion on DMA-BUF > heap discovery and negotiation. > > Given Plumbers is just a couple weeks from now, I've submitted > a BoF proposal to discuss this, as perhaps it would make > sense to discuss this live? I do think it's an interesting idea. I agree that having every driver implement a dmabuf exporter is a bit silly, but I also think Brian's point that maybe we need some drm helper functions that provide similar functionality along with a more standardized device ioctl for single device allocations might be better. thanks -john _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
