On Tue, Jul 31, 2012 at 8:39 AM, Rémi Denis-Courmont remi@remlab.net 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