All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rémi Denis-Courmont" <remi@remlab.net>
To: Tomasz Stanislawski <t.stanislaws@samsung.com>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	<linux-media@vger.kernel.org>, <dri-devel@lists.freedesktop.org>,
	<airlied@redhat.com>, <m.szyprowski@samsung.com>,
	<kyungmin.park@samsung.com>, <sumit.semwal@ti.com>,
	<daeinki@gmail.com>, <daniel.vetter@ffwll.ch>,
	<robdclark@gmail.com>, <pawel@osciak.com>,
	<linaro-mm-sig@lists.linaro.org>, <hverkuil@xs4all.nl>,
	<subashrp@gmail.com>
Subject: Re: [PATCH v4 02/14] Documentation: media: description of DMABUF importing in V4L2
Date: Fri, 20 Apr 2012 12:56:53 +0200	[thread overview]
Message-ID: <d24e8c6e35352ed5800161713f728591@chewa.net> (raw)
In-Reply-To: <4F912141.8060200@samsung.com>

On Fri, 20 Apr 2012 10:41:37 +0200, Tomasz Stanislawski

<t.stanislaws@samsung.com> wrote:

>> Am I understanding wrong or are you saying that you want to drop

userptr

>> from V4L2 API in long-term? If so, why?

> 

> Dropping userptr is just some brainstorming idea.

> It was found out that userptr is not a good mean

> for buffer exchange between to two devices.



I can believe that. But I am also inclined to believe that DMABUF is

targetted at device-to-device transfer, while USERPTR is targetted at

device-to-user (or user-to-device) transfers. Are you saying applications

should use DMABUF and memory map the buffers? Or would you care to explain

how DMABUF addresses the problem space of USERPTR?



> The USERPTR simplifies userspace code but introduce

> a lot of complexity problems for the kernel drivers

> and frameworks.



It is not only a simplification. In some cases, USERPTR is the only I/O

method that supports zero copy in pretty much any circumstance. When the

user cannot reliably predict the maximum number of required buffers,

predicts a value larger than the device will negotiate, or needs buffers to

outlive STREAMOFF (?), MMAP requires memory copying. USERPTR does not.



Now, I do realize that some devices cannot support USERPTR efficiently,

then they should not support USERPTR. But for those devices that can, it

seems quite a nice performance enhancement.



-- 

Rémi Denis-Courmont

Sent from my collocated server

WARNING: multiple messages have this Message-ID (diff)
From: "Rémi Denis-Courmont" <remi@remlab.net>
To: Tomasz Stanislawski <t.stanislaws@samsung.com>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
	airlied@redhat.com, m.szyprowski@samsung.com,
	kyungmin.park@samsung.com, sumit.semwal@ti.com,
	daeinki@gmail.com, daniel.vetter@ffwll.ch, robdclark@gmail.com,
	pawel@osciak.com, linaro-mm-sig@lists.linaro.org,
	hverkuil@xs4all.nl, subashrp@gmail.com
Subject: Re: [PATCH v4 02/14] Documentation: media: description of DMABUF importing in V4L2
Date: Fri, 20 Apr 2012 12:56:53 +0200	[thread overview]
Message-ID: <d24e8c6e35352ed5800161713f728591@chewa.net> (raw)
In-Reply-To: <4F912141.8060200@samsung.com>

On Fri, 20 Apr 2012 10:41:37 +0200, Tomasz Stanislawski
<t.stanislaws@samsung.com> wrote:
>> Am I understanding wrong or are you saying that you want to drop
userptr
>> from V4L2 API in long-term? If so, why?
> 
> Dropping userptr is just some brainstorming idea.
> It was found out that userptr is not a good mean
> for buffer exchange between to two devices.

I can believe that. But I am also inclined to believe that DMABUF is
targetted at device-to-device transfer, while USERPTR is targetted at
device-to-user (or user-to-device) transfers. Are you saying applications
should use DMABUF and memory map the buffers? Or would you care to explain
how DMABUF addresses the problem space of USERPTR?

> The USERPTR simplifies userspace code but introduce
> a lot of complexity problems for the kernel drivers
> and frameworks.

It is not only a simplification. In some cases, USERPTR is the only I/O
method that supports zero copy in pretty much any circumstance. When the
user cannot reliably predict the maximum number of required buffers,
predicts a value larger than the device will negotiate, or needs buffers to
outlive STREAMOFF (?), MMAP requires memory copying. USERPTR does not.

Now, I do realize that some devices cannot support USERPTR efficiently,
then they should not support USERPTR. But for those devices that can, it
seems quite a nice performance enhancement.

-- 
Rémi Denis-Courmont
Sent from my collocated server

  reply	other threads:[~2012-04-20 10:57 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-13 15:47 [PATCH v4 00/14] Integration of videobuf2 with dmabuf Tomasz Stanislawski
2012-04-13 15:47 ` [PATCH v4 01/14] v4l: Add DMABUF as a memory type Tomasz Stanislawski
2012-04-17  0:57   ` Laurent Pinchart
2012-04-13 15:47 ` [PATCH v4 02/14] Documentation: media: description of DMABUF importing in V4L2 Tomasz Stanislawski
2012-04-16 23:25   ` Laurent Pinchart
2012-04-19 14:32     ` Tomasz Stanislawski
2012-04-19 20:36       ` Mauro Carvalho Chehab
2012-04-19 20:37       ` Mauro Carvalho Chehab
2012-04-20  8:41         ` Tomasz Stanislawski
2012-04-20 10:56           ` Rémi Denis-Courmont [this message]
2012-04-20 10:56             ` Rémi Denis-Courmont
2012-04-20 12:25             ` Tomasz Stanislawski
2012-04-20 13:03               ` Rémi Denis-Courmont
2012-04-20 13:03                 ` Rémi Denis-Courmont
2012-04-21 17:10                 ` Laurent Pinchart
2012-04-20 14:48               ` Mauro Carvalho Chehab
2012-04-20 13:36             ` Mauro Carvalho Chehab
2012-04-23  7:50               ` Marek Szyprowski
2012-04-23 14:00                 ` Mauro Carvalho Chehab
2012-04-13 15:47 ` [PATCH v4 03/14] v4l: vb2: add support for shared buffer (dma_buf) Tomasz Stanislawski
2012-04-17  0:57   ` Laurent Pinchart
2012-04-13 15:47 ` [PATCH v4 04/14] v4l: vb: remove warnings about MEMORY_DMABUF Tomasz Stanislawski
2012-04-17  0:57   ` Laurent Pinchart
2012-04-13 15:47 ` [PATCH v4 05/14] v4l: vb2-dma-contig: Shorten vb2_dma_contig prefix to vb2_dc Tomasz Stanislawski
2012-04-13 15:47 ` [PATCH v4 06/14] v4l: vb2-dma-contig: Remove unneeded allocation context structure Tomasz Stanislawski
2012-04-17  0:57   ` Laurent Pinchart
2012-04-13 15:47 ` [PATCH v4 07/14] v4l: vb2-dma-contig: Reorder functions Tomasz Stanislawski
2012-04-13 15:47 ` [PATCH v4 08/14] v4l: vb2-dma-contig: add support for scatterlist in userptr mode Tomasz Stanislawski
2012-04-17  0:43   ` Laurent Pinchart
2012-04-17  0:43     ` Laurent Pinchart
2012-04-20  8:52     ` Tomasz Stanislawski
2012-04-13 15:47 ` [PATCH v4 09/14] v4l: vb2: add prepare/finish callbacks to allocators Tomasz Stanislawski
2012-04-17  0:57   ` Laurent Pinchart
2012-04-13 15:47 ` [PATCH v4 10/14] v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator Tomasz Stanislawski
2012-04-13 15:47 ` [PATCH v4 11/14] v4l: vb2-dma-contig: add support for dma_buf importing Tomasz Stanislawski
2012-04-17  0:57   ` Laurent Pinchart
2012-04-17  0:57     ` Laurent Pinchart
2012-04-19 11:38     ` Tomasz Stanislawski
2012-04-13 15:47 ` [PATCH v4 12/14] v4l: vb2-dma-contig: change map/unmap behaviour for importers Tomasz Stanislawski
2012-04-17  1:03   ` Laurent Pinchart
2012-04-13 15:47 ` [PATCH v4 13/14] v4l: s5p-tv: mixer: support for dmabuf importing Tomasz Stanislawski
2012-04-13 15:47 ` [PATCH v4 14/14] v4l: fimc: " Tomasz Stanislawski
2012-04-20 12:56   ` Sylwester Nawrocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d24e8c6e35352ed5800161713f728591@chewa.net \
    --to=remi@remlab.net \
    --cc=airlied@redhat.com \
    --cc=daeinki@gmail.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hverkuil@xs4all.nl \
    --cc=kyungmin.park@samsung.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-media@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mchehab@redhat.com \
    --cc=pawel@osciak.com \
    --cc=robdclark@gmail.com \
    --cc=subashrp@gmail.com \
    --cc=sumit.semwal@ti.com \
    --cc=t.stanislaws@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.