[PATCHv2 3/9] v4l: add buffer exporting via dmabuf

[Rémi Denis-Courmont]

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 at 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.

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis