[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <373924ea-a35c-78f5-dd0c-e5f36623cb84@xs4all.nl>
Date: Mon, 15 Jan 2018 13:14:28 +0100
From: Hans Verkuil <hverkuil@...all.nl>
To: Gustavo Padovan <gustavo@...ovan.org>,
Alexandre Courbot <acourbot@...omium.org>
Cc: Linux Media Mailing List <linux-media@...r.kernel.org>,
Mauro Carvalho Chehab <mchehab@....samsung.com>,
Shuah Khan <shuahkh@....samsung.com>,
Pawel Osciak <pawel@...iak.com>,
Sakari Ailus <sakari.ailus@....fi>,
Brian Starkey <brian.starkey@....com>,
Thierry Escande <thierry.escande@...labora.com>,
linux-kernel@...r.kernel.org,
Gustavo Padovan <gustavo.padovan@...labora.com>
Subject: Re: [PATCH v7 1/6] [media] vb2: add is_unordered callback for drivers
On 01/15/2018 01:01 PM, Gustavo Padovan wrote:
> 2018-01-15 Alexandre Courbot <acourbot@...omium.org>:
>
>> On Thu, Jan 11, 2018 at 1:07 AM, Gustavo Padovan <gustavo@...ovan.org> wrote:
>>> From: Gustavo Padovan <gustavo.padovan@...labora.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.
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.
Regards,
Hans
Powered by blists - more mailing lists