| Message ID | 20171115171057.17340-4-gustavo@padovan.org (mailing list archive) |
|---|---|
| State | RFC, archived |
| Headers |
Received: from vger.kernel.org ([209.132.180.67]) by www.linuxtv.org with esmtp (Exim 4.84_2) (envelope-from <linux-media-owner@vger.kernel.org>) id 1eF1Dx-0006no-Hg; Wed, 15 Nov 2017 17:11:41 +0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933308AbdKORLh (ORCPT <rfc822;mkrufky@linuxtv.org> + 1 other); Wed, 15 Nov 2017 12:11:37 -0500 Received: from mail-qt0-f194.google.com ([209.85.216.194]:45845 "EHLO mail-qt0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933277AbdKORLT (ORCPT <rfc822;linux-media@vger.kernel.org>); Wed, 15 Nov 2017 12:11:19 -0500 Received: by mail-qt0-f194.google.com with SMTP id n32so19829274qtb.2; Wed, 15 Nov 2017 09:11:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=PBN4ZokPmMOV0MGqZ6LAu1ll6C0oLRHnFLFPX+ntdSY=; b=M9kpP8LcWMD6dcwlicOqhX8nr2tRr5rkGXOEqRO3lUDUyVJ6qWeCOcQyZJq/5lUNkP e1NN/LCFyS1b9l31P8ebMkxpWrgtP8wGuP0r5X7BPJpss7j1Xa1+bNT5nf0SzT/dEvTC a+WHIP0DgJ3pp0j1KNWYbkXouxbd800YqE3r+uaXGs5Ag/Z/rIpvYVx+K/98dxplYEHT SvPahBMNu7LbGrFuFsngpJl2o1Kg35SV3jodF+hLHbB3lL3m3IYFEGYoEr33ao0g3j8P EgxaUE94CGQuQUh8Iu6eOmTNBSxwJSCVmI0VH1lgHdbYwOgBmukv/QJ0nuuQqO+PJJc6 /uAg== X-Gm-Message-State: AJaThX4LGN40e5z68gtcYq3ggsFVFpWvV3V7U1YlieI7eQVTyX56ULHj H3mrGX72aGRICJZKM6plC/nyRuY/ X-Google-Smtp-Source: AGs4zMa8w/u4jXny9gFOOHM+fX5arnJXJF0qBHyL7HCup9Ohu0ymUlqQJ1MoZrlxIhHmgXn4wr650w== X-Received: by 10.55.51.73 with SMTP id z70mr24441728qkz.338.1510765877740; Wed, 15 Nov 2017 09:11:17 -0800 (PST) Received: from localhost.localdomain ([179.110.36.75]) by smtp.gmail.com with ESMTPSA id p85sm15211633qkp.94.2017.11.15.09.11.14 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 15 Nov 2017 09:11:17 -0800 (PST) From: Gustavo Padovan <gustavo@padovan.org> To: linux-media@vger.kernel.org Cc: Hans Verkuil <hverkuil@xs4all.nl>, Mauro Carvalho Chehab <mchehab@osg.samsung.com>, Shuah Khan <shuahkh@osg.samsung.com>, Pawel Osciak <pawel@osciak.com>, Alexandre Courbot <acourbot@chromium.org>, 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: [RFC v5 03/11] [media] vb2: add 'ordered_in_driver' property to queues Date: Wed, 15 Nov 2017 15:10:49 -0200 Message-Id: <20171115171057.17340-4-gustavo@padovan.org> X-Mailer: git-send-email 2.13.6 In-Reply-To: <20171115171057.17340-1-gustavo@padovan.org> References: <20171115171057.17340-1-gustavo@padovan.org> Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org |
Commit Message
Gustavo F. Padovan
Nov. 15, 2017, 5:10 p.m. UTC
From: Gustavo Padovan <gustavo.padovan@collabora.com> We use ordered_in_driver property to optimize for the case where the driver can deliver the buffers in an ordered fashion. When it is ordered we can use the same fence context for all fences, but when it is not we need to a new context for each out-fence. So the ordered_in_driver flag will help us with identifying the queues that can be optimized and use the same fence context. v4: make the property a vector for optimization and not a mandatory thing that drivers need to set if they want to use explicit synchronization. v3: improve doc (Hans Verkuil) v2: rename property to 'ordered_in_driver' to avoid confusion Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com> --- include/media/videobuf2-core.h | 7 +++++++ 1 file changed, 7 insertions(+)
Comments
On Thursday, November 16, 2017 2:10:49 AM JST, Gustavo Padovan wrote: > From: Gustavo Padovan <gustavo.padovan@collabora.com> > > We use ordered_in_driver property to optimize for the case where > the driver can deliver the buffers in an ordered fashion. When it > is ordered we can use the same fence context for all fences, but > when it is not we need to a new context for each out-fence. "we need to a new context" looks like it is missing a word.
2017-11-17 Alexandre Courbot <acourbot@chromium.org>: > On Thursday, November 16, 2017 2:10:49 AM JST, Gustavo Padovan wrote: > > From: Gustavo Padovan <gustavo.padovan@collabora.com> > > > > We use ordered_in_driver property to optimize for the case where > > the driver can deliver the buffers in an ordered fashion. When it > > is ordered we can use the same fence context for all fences, but > > when it is not we need to a new context for each out-fence. > > "we need to a new context" looks like it is missing a word. oh "we need to create a new context" Thanks for reviewing the patches! Gustavo
Em Wed, 15 Nov 2017 15:10:49 -0200 Gustavo Padovan <gustavo@padovan.org> escreveu: > From: Gustavo Padovan <gustavo.padovan@collabora.com> > > We use ordered_in_driver property to optimize for the case where > the driver can deliver the buffers in an ordered fashion. When it > is ordered we can use the same fence context for all fences, but > when it is not we need to a new context for each out-fence. > > So the ordered_in_driver flag will help us with identifying the queues > that can be optimized and use the same fence context. > > v4: make the property a vector for optimization and not a mandatory thing > that drivers need to set if they want to use explicit synchronization. > > v3: improve doc (Hans Verkuil) > > v2: rename property to 'ordered_in_driver' to avoid confusion > > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com> > --- > include/media/videobuf2-core.h | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h > index ef9b64398c8c..38b9c8dd42c6 100644 > --- a/include/media/videobuf2-core.h > +++ b/include/media/videobuf2-core.h > @@ -440,6 +440,12 @@ struct vb2_buf_ops { > * @fileio_read_once: report EOF after reading the first buffer > * @fileio_write_immediately: queue buffer after each write() call > * @allow_zero_bytesused: allow bytesused == 0 to be passed to the driver > + * @ordered_in_driver: if the driver can guarantee that the queue will be > + * ordered or not, i.e., the buffers are dequeued from the driver > + * in the same order they are queued to the driver. The default > + * is not ordered unless the driver sets this flag. Setting it > + * when ordering can be guaranted helps to optimize explicit > + * fences. > * @quirk_poll_must_check_waiting_for_buffers: Return POLLERR at poll when QBUF > * has not been called. This is a vb1 idiom that has been adopted > * also by vb2. > @@ -510,6 +516,7 @@ struct vb2_queue { > unsigned fileio_read_once:1; > unsigned fileio_write_immediately:1; > unsigned allow_zero_bytesused:1; > + unsigned ordered_in_driver:1; As this may depend on the format, it is probably a good idea to set this flag either via a function argument or by a function that would be meant to update it, as video format changes. > unsigned quirk_poll_must_check_waiting_for_buffers:1; > > struct mutex *lock;
Hi Mauro, 2017-11-17 Mauro Carvalho Chehab <mchehab@osg.samsung.com>: > Em Wed, 15 Nov 2017 15:10:49 -0200 > Gustavo Padovan <gustavo@padovan.org> escreveu: > > > From: Gustavo Padovan <gustavo.padovan@collabora.com> > > > > We use ordered_in_driver property to optimize for the case where > > the driver can deliver the buffers in an ordered fashion. When it > > is ordered we can use the same fence context for all fences, but > > when it is not we need to a new context for each out-fence. > > > > So the ordered_in_driver flag will help us with identifying the queues > > that can be optimized and use the same fence context. > > > > v4: make the property a vector for optimization and not a mandatory thing > > that drivers need to set if they want to use explicit synchronization. > > > > v3: improve doc (Hans Verkuil) > > > > v2: rename property to 'ordered_in_driver' to avoid confusion > > > > Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com> > > --- > > include/media/videobuf2-core.h | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h > > index ef9b64398c8c..38b9c8dd42c6 100644 > > --- a/include/media/videobuf2-core.h > > +++ b/include/media/videobuf2-core.h > > @@ -440,6 +440,12 @@ struct vb2_buf_ops { > > * @fileio_read_once: report EOF after reading the first buffer > > * @fileio_write_immediately: queue buffer after each write() call > > * @allow_zero_bytesused: allow bytesused == 0 to be passed to the driver > > + * @ordered_in_driver: if the driver can guarantee that the queue will be > > + * ordered or not, i.e., the buffers are dequeued from the driver > > + * in the same order they are queued to the driver. The default > > + * is not ordered unless the driver sets this flag. Setting it > > + * when ordering can be guaranted helps to optimize explicit > > + * fences. > > * @quirk_poll_must_check_waiting_for_buffers: Return POLLERR at poll when QBUF > > * has not been called. This is a vb1 idiom that has been adopted > > * also by vb2. > > @@ -510,6 +516,7 @@ struct vb2_queue { > > unsigned fileio_read_once:1; > > unsigned fileio_write_immediately:1; > > unsigned allow_zero_bytesused:1; > > + unsigned ordered_in_driver:1; > > As this may depend on the format, it is probably a good idea to set > this flag either via a function argument or by a function that > would be meant to update it, as video format changes. Right, and maybe I can find a way to store this in only one place, istead of what I did here (having to set explicitely both the ordered_in_driver and the flag separatedly) Gustavo
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h index ef9b64398c8c..38b9c8dd42c6 100644 --- a/include/media/videobuf2-core.h +++ b/include/media/videobuf2-core.h @@ -440,6 +440,12 @@ struct vb2_buf_ops { * @fileio_read_once: report EOF after reading the first buffer * @fileio_write_immediately: queue buffer after each write() call * @allow_zero_bytesused: allow bytesused == 0 to be passed to the driver + * @ordered_in_driver: if the driver can guarantee that the queue will be + * ordered or not, i.e., the buffers are dequeued from the driver + * in the same order they are queued to the driver. The default + * is not ordered unless the driver sets this flag. Setting it + * when ordering can be guaranted helps to optimize explicit + * fences. * @quirk_poll_must_check_waiting_for_buffers: Return POLLERR at poll when QBUF * has not been called. This is a vb1 idiom that has been adopted * also by vb2. @@ -510,6 +516,7 @@ struct vb2_queue { unsigned fileio_read_once:1; unsigned fileio_write_immediately:1; unsigned allow_zero_bytesused:1; + unsigned ordered_in_driver:1; unsigned quirk_poll_must_check_waiting_for_buffers:1; struct mutex *lock;