[Bug 583890] v4l2: Implement V4L2_MEMORY_USERPTR support

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=583890
  GStreamer | gst-plugins-good | git

Nicolas Dufresne <nicolas.dufresne> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |ASSIGNED
         AssignedTo|gstreamer-bugs at lists.freede |nicolas.dufresne at collabora.
                   |sktop.org                   |co.uk

--- Comment #37 from Nicolas Dufresne <nicolas.dufresne at collabora.co.uk> 2013-11-25 17:17:00 UTC ---
(In reply to comment #36)
> This information can't be retrieved via V4L2 and is completely dependant on the
> hardware and driver AFAIK. Due to this I don't think it makes sense to
> generically implement USERPTR support as it will never work reliably in all
> situations.

It's true that V4L2 lacks some way to probe this. A driver that supports
USERPTR in some ways, will succeed REQBUF, that we can probe easily. We can
also try and queue malloc() buffer, the problem is that we cannot guaranty our
probing is not accidentally physically contiguous.

On the V4L2 side, there is currently 3 type of allocators being used.

The vmalloc allocator (used notably by the UVC driver and most devices using
serial line) is the most flexible for userspace, and will do userptr from
malloc().

The original dma allocator, this is used by the majority of the drivers since
it's the easiest fit for any uses cases. This allocated produce and consume
physically contiguous memory. Drivers that do support USERPTR and use that
allocator will only work if the passed buffer are contiguous (regardless of the
source, it will check each pages and make sure one is next to the other).

Finally, there is the rest, which are custom allocators, can be based on
framebuffer. It usually check the location of the blocks, contiguous or not, in
memory.

In the long term, the IOMMUs should remove this limitation, but meanwhile there
is no way to be 100% sure through probing what is being used. The solution we'd
like to bring here, is to be able to force this mode and let the user make that
decision (io-mode=userptr), this is already in the API. For the automatic mode,
we'd like to use white list for activating it.

For the vmalloc case, it quite simple, and it should benefit one of the most
used driver, which is UVC (if the is a format match, ovbiously). e.g.

gst-launch-1.0 v4l2src io-mode=userptr ! xvimagesink

It's useful now, but I'm aware that if DMABUF make it to XV, it would become
obsolete. On Wayland, dmabuf shall be used. Note that the code for dmabuf
handling will be very similar to USERPTR in the end.

For the dma case, we'd have another white list, and base on that we would set
the unused GST_MEMORY_FLAG_PHYSICALLY_CONTIGUOUS when producing mmap buffers.
It's a lot more work to handle this case, we will probably have a fallback to
dma (or r/w) in the likely case incoming buffer do not have this flags (I'm not
sure this flag can be negotiated really). We can try and avoid this fallback by
retaining two buffers in our userptr pool, though this assumed two first buffer
are right. the important part I think is that we don't fail because of us
attempting to optimize things.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.