From: Gustavo Padovan <gustavo@padovan.org>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Alexandre Courbot <acourbot@chromium.org>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
Shuah Khan <shuahkh@osg.samsung.com>,
Pawel Osciak <pawel@osciak.com>,
Sakari Ailus <sakari.ailus@iki.fi>,
Brian Starkey <brian.starkey@arm.com>,
Thierry Escande <thierry.escande@collabora.com>,
linux-kernel@vger.kernel.org,
Gustavo Padovan <gustavo.padovan@collabora.com>
Subject: Re: [PATCH v7 1/6] [media] vb2: add is_unordered callback for drivers
Date: Mon, 15 Jan 2018 15:55:54 -0200 [thread overview]
Message-ID: <20180115175554.GB9598@jade> (raw)
In-Reply-To: <373924ea-a35c-78f5-dd0c-e5f36623cb84@xs4all.nl>
2018-01-15 Hans Verkuil <hverkuil@xs4all.nl>:
> On 01/15/2018 01:01 PM, Gustavo Padovan wrote:
> > 2018-01-15 Alexandre Courbot <acourbot@chromium.org>:
> >
> >> On Thu, Jan 11, 2018 at 1:07 AM, Gustavo Padovan <gustavo@padovan.org> wrote:
> >>> From: Gustavo Padovan <gustavo.padovan@collabora.com>
> >>>
> >>> Explicit synchronization benefits a lot from ordered queues, they fit
> >>> better in a pipeline with DRM for example so create a opt-in way for
> >>> drivers notify videobuf2 that the queue is unordered.
> >>>
> >>> Drivers don't need implement it if the queue is ordered.
> >>
> >> This is going to make user-space believe that *all* vb2 drivers use
> >> ordered queues by default, at least until non-ordered drivers catch up
> >> with this change. Wouldn't it be less dangerous to do the opposite
> >> (make queues non-ordered by default)?
> >
> > The rational behind this decision was because most formats/drivers are
> > ordered so only a small amount of drivers need to changed. I think this
> > was proposed by Hans on the Media Summit.
> >
> > I understand your concern. My question is how dangerous will it be. If
> > you are building a product you will make the changes in the driver if
> > they are not there yet, or if it is a distribution you'd never know
> > which driver/format you are using so you should be prepared for
> > everything.
> >
> > AFAIK all Capture drivers are ordered and that is where I think fences
> > is most useful.
>
> Right. What could be done is to mark all codec drivers as unordered initially
> ask the driver authors to verify this. All capture drivers using vb2 and not
> using REQUEUE are ordered.
That is a good way out.
>
> One thing we haven't looked at is what to do with drivers that do not use vb2.
> Those won't support fences, but how will userspace know that fences are not
> supported? I'm not sure what the best method is for that.
>
> I am leaning towards a new capability since this has to be advertised clearly.
The capability flag makes sense to me, I'll incorporate it as part of my
next patchset.
Gustavo
next prev parent reply other threads:[~2018-01-15 17:56 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-10 16:07 [PATCH v7 0/6] V4L2 Explicit Synchronization Gustavo Padovan
2018-01-10 16:07 ` [PATCH v7 1/6] [media] vb2: add is_unordered callback for drivers Gustavo Padovan
2018-01-12 11:57 ` Hans Verkuil
2018-01-15 7:11 ` Alexandre Courbot
2018-01-15 12:01 ` Gustavo Padovan
2018-01-15 12:14 ` Hans Verkuil
2018-01-15 17:55 ` Gustavo Padovan [this message]
2018-01-16 2:35 ` Alexandre Courbot
2018-01-10 16:07 ` [PATCH v7 2/6] [media] v4l: add 'unordered' flag to format description ioctl Gustavo Padovan
2018-01-12 12:05 ` Hans Verkuil
2018-01-10 16:07 ` [PATCH v7 3/6] [media] vb2: add explicit fence user API Gustavo Padovan
2018-01-12 12:15 ` Hans Verkuil
2018-01-12 12:20 ` Hans Verkuil
2018-01-10 16:07 ` [PATCH v7 4/6] [media] vb2: add in-fence support to QBUF Gustavo Padovan
2018-01-12 13:46 ` Hans Verkuil
2018-01-18 17:38 ` Gustavo Padovan
2018-01-10 16:07 ` [PATCH v7 5/6] [media] vb2: add out-fence " Gustavo Padovan
2018-01-12 14:05 ` Hans Verkuil
2018-01-19 13:12 ` Gustavo Padovan
2018-01-15 7:12 ` Alexandre Courbot
2018-01-19 13:43 ` Gustavo Padovan
2018-01-10 16:07 ` [PATCH v7 6/6] [media] v4l: Document explicit synchronization behavior Gustavo Padovan
2018-01-12 14:48 ` Hans Verkuil
2018-01-10 16:44 ` [PATCH v7 0/6] V4L2 Explicit Synchronization Nicolas Dufresne
2018-01-10 17:11 ` Gustavo Padovan
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=20180115175554.GB9598@jade \
--to=gustavo@padovan.org \
--cc=acourbot@chromium.org \
--cc=brian.starkey@arm.com \
--cc=gustavo.padovan@collabora.com \
--cc=hverkuil@xs4all.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@osg.samsung.com \
--cc=pawel@osciak.com \
--cc=sakari.ailus@iki.fi \
--cc=shuahkh@osg.samsung.com \
--cc=thierry.escande@collabora.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox