On Tue, Jul 31, 2012 at 8:39 AM, Rémi Denis-Courmont <remi@xxxxxxxxxx> wrote: > Le mardi 31 juillet 2012 14:56:14 Laurent Pinchart, vous avez écrit : >> > For that matter, wouldn't it be useful to support exporting a userptr >> > buffer at some point in the future? >> >> Shouldn't USERPTR usage be discouraged once we get dma-buf support ? > > USERPTR, where available, is currently the only way to perform zero-copy from > kernel to userspace. READWRITE does not support zero-copy at all. MMAP only > supports zero-copy if userspace knows a boundary on the number of concurrent > buffers *and* the device can deal with that number of buffers; in general, > MMAP requires memory copying. hmm, this sounds like the problem is device pre-allocating buffers? Anyways, last time I looked, the vb2 core supported changing dmabuf fd each time you QBUF, in a similar way to what you can do w/ userptr. So that seems to get you the advantages you miss w/ mmap without the pitfalls of userptr. > I am not sure DMABUF even supports transmitting data efficiently to userspace. > In my understanding, it's meant for transmitting data between DSP's bypassing > userspace entirely, in other words the exact opposite of what USERBUF does. well, dmabuf's can be mmap'd.. so it is more a matter of where the buffer gets allocated, malloc() or from some driver (v4l2 or other). There are a *ton* of ways userspace allocated memory can go badly, esp. if the hw has special requirements about memory (GFP_DMA32 in a system w/ PAE/LPAE, certain ranges of memory, certain alignment of memory, etc). BR, -R > -- > Rémi Denis-Courmont > http://www.remlab.net/ > http://fi.linkedin.com/in/remidenis _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
