Le mardi 31 juillet 2012 17:03:52 Rob Clark, vous avez écrit :
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?
Basically, yes.
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.
It might work albeit with a higher system calls count overhead.
But what about libv4l2 transparent format conversion? Emulated USERBUF, with MMAP in the back-end would provide by far the least overhead. I don't see how DMABUF would work there.