From: Rob Clark <robdclark@gmail.com>
To: Daniel Stone <daniel@fooishbar.org>
Cc: "Greg Hackmann" <ghackmann@google.com>,
"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"Gustavo Padovan" <gustavo.padovan@collabora.co.uk>,
"Gustavo Padovan" <gustavo@padovan.org>,
"Daniel Stone" <daniels@collabora.com>,
"Riley Andrews" <riandrews@android.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Arve Hjønnevåg" <arve@android.com>,
"John Harrison" <John.C.Harrison@intel.com>
Subject: Re: [RFC v2 5/8] drm/fence: add in-fences support
Date: Fri, 29 Apr 2016 18:23:42 -0400 [thread overview]
Message-ID: <CAF6AEGvWK_jeCR8aLP3xkaEa7O8UN6oFruSM=rDF=_9Wt_YGAA@mail.gmail.com> (raw)
In-Reply-To: <CAPj87rM_DzvvtATgdyG968OEDQnjqeSK-BK-c7+hNpE17xP21A@mail.gmail.com>
On Fri, Apr 29, 2016 at 3:48 AM, Daniel Stone <daniel@fooishbar.org> wrote:
> Hi,
>
> On 28 April 2016 at 23:28, Rob Clark <robdclark@gmail.com> wrote:
>> On Wed, Apr 27, 2016 at 2:39 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
>>> On Tue, Apr 26, 2016 at 01:48:02PM -0700, Greg Hackmann wrote:
>>>> A (per-CRTC?) array of fences would be more flexible. And even in the cases
>>>> where you could make a 1-to-1 mapping between planes and fences, it's not
>>>> that much more work for userspace to assemble those fences into an array
>>>> anyway.
>>>
>>> I'm ok with an array too if that's what you folks prefer (it's meant to be
>>> used by you after all). I just don't want just 1 fence for the entire op,
>>> forcing userspace to first merge them all together. That seems silly.
>>
>> I was kinda more a fan of array too, if for no other reason that to be
>> consistent w/ how out-fences work. (And using property just for
>> in-fence seemed slightly weird/abusive to me)
>
> I don't think it's really useful to look for much consistency between
> the two, beyond the name. I'm more concerned with consistency between
> in-fences and the implicit fences on buffers/FBs, and between
> out-fences and the page_flip_events.
>
>>> One side-effect of that is that we'd also have to rework all the internal
>>> bits and move fences around in atomic. Which means change a pile of
>>> drivers. Not sure that's worth it, but I'd be ok either way really.
>>
>> hmm, well we could keep the array per-plane (and if one layer is using
>> multiple planes, just list the same fd multiple times).. then it
>> mostly comes down to changes in the ioctl fxn itself.
>
> ... and new API in libdrm, which is going to be a serious #ifdef and
> distribution pain. The core property API has been available since
> 2.4.62 last June, but for this we'd have to write the code, wait for
> the kernel code, wait for HWC, get everything together, and then merge
> and release. That gives minimum one year of libdrm releases which have
> had atomic but not in-fence API support, if we're adding a new array.
> And I just don't really see what it buys us, apart from the need for
> the core atomic_get_property helper to statically return -1 when
> requesting FENCE_FD.
don't we have the same issue for out-fences anyway?
ofc, I suspect we could handle making fences look like properties in
userspace in libdrm (at least if there was a sane way that libdrm
could track and eventually close() old out-fence fd's). I'm not
entirely sure this matters, I mean how do we make implicit vs explicit
fencing transparent to the compositor and the proto between
compositor<->app?
Admittedly I haven't given *too* much thought yet about the
implications to libdrm and it's users, but it seems like we need to
make a v2 API rev anyway for out-fences, and the compositor is going
to need different codepaths for explicit vs implicit (if it supports
both). So I don't think in-fences as something other than property
really costs us anything additional?
(Unless there is some sane reason to have an intermediate state w/
in-fences but pageflip events instead of out-fences? But that seems
odd..)
BR,
-R
> Cheers,
> Daniel
next prev parent reply other threads:[~2016-04-29 22:23 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-25 22:33 [RFC v2 0/8] drm: explicit fencing support Gustavo Padovan
2016-04-25 22:33 ` [RFC v2 1/8] dma-buf/fence: add fence_collection fences Gustavo Padovan
2016-04-26 14:41 ` Daniel Vetter
2016-04-26 15:02 ` Gustavo Padovan
2016-04-27 6:36 ` Daniel Vetter
2016-04-26 15:09 ` Chris Wilson
2016-04-28 14:47 ` Gustavo Padovan
2016-04-25 22:33 ` [RFC v2 2/8] Documentation: add fence-collection to kernel DocBook Gustavo Padovan
2016-04-25 22:33 ` [RFC v2 3/8] dma-buf/sync_file: add sync_file_fences_get() Gustavo Padovan
2016-04-25 22:33 ` [RFC v2 4/8] drm/fence: allow fence waiting to be interrupted by userspace Gustavo Padovan
2016-04-25 22:33 ` [RFC v2 5/8] drm/fence: add in-fences support Gustavo Padovan
2016-04-26 10:10 ` Ville Syrjälä
2016-04-26 14:14 ` Gustavo Padovan
2016-04-26 14:36 ` Daniel Vetter
2016-04-26 16:26 ` Ville Syrjälä
2016-04-26 17:20 ` Daniel Vetter
2016-04-26 17:40 ` Ville Syrjälä
2016-04-26 18:23 ` Daniel Vetter
2016-04-26 18:55 ` Ville Syrjälä
2016-04-26 20:05 ` Daniel Vetter
2016-04-26 20:48 ` Greg Hackmann
2016-04-27 6:39 ` Daniel Vetter
2016-04-28 21:28 ` Rob Clark
2016-04-29 7:48 ` Daniel Stone
2016-04-29 22:23 ` Rob Clark [this message]
2016-04-29 21:14 ` Greg Hackmann
2016-04-27 6:57 ` Daniel Stone
2016-04-28 14:36 ` Gustavo Padovan
2016-04-28 14:38 ` Daniel Vetter
2016-04-28 16:56 ` Ville Syrjälä
2016-04-28 17:43 ` Daniel Vetter
2016-04-28 17:51 ` Ville Syrjälä
2016-04-28 17:55 ` Gustavo Padovan
2016-04-28 18:02 ` Daniel Vetter
2016-04-28 18:17 ` Ville Syrjälä
2016-04-28 20:40 ` Daniel Vetter
2016-04-26 16:25 ` Ville Syrjälä
2016-04-25 22:33 ` [RFC v2 6/8] drm/fence: add fence to drm_pending_event Gustavo Padovan
2016-04-25 22:33 ` [RFC v2 7/8] drm/fence: add fence timeline to drm_crtc Gustavo Padovan
2016-04-26 10:12 ` Ville Syrjälä
2016-04-26 14:23 ` Gustavo Padovan
2016-04-26 16:34 ` Ville Syrjälä
2016-04-27 8:23 ` Daniel Stone
2016-04-25 22:33 ` [RFC v2 8/8] drm/fence: add out-fences support Gustavo Padovan
2016-04-26 14:53 ` Daniel Vetter
2016-04-28 15:23 ` Gustavo Padovan
[not found] ` <CAHbf0-HVNM=akFaE54U6B=51eegwumFmH=dUv+HHbnGOgGD=nw@mail.gmail.com>
2016-04-26 6:30 ` [RFC v2 0/8] drm: explicit fencing support Daniel Vetter
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='CAF6AEGvWK_jeCR8aLP3xkaEa7O8UN6oFruSM=rDF=_9Wt_YGAA@mail.gmail.com' \
--to=robdclark@gmail.com \
--cc=John.C.Harrison@intel.com \
--cc=arve@android.com \
--cc=daniel@fooishbar.org \
--cc=daniels@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=ghackmann@google.com \
--cc=gustavo.padovan@collabora.co.uk \
--cc=gustavo@padovan.org \
--cc=linux-kernel@vger.kernel.org \
--cc=riandrews@android.com \
--cc=ville.syrjala@linux.intel.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;
as well as URLs for NNTP newsgroup(s).