[RFC v2 5/8] drm/fence: add in-fences support

[Dominik Behr]

Gustavo, you added fence_put()
in __drm_atomic_helper_plane_destroy_state(), shouldn't we also add a
corresponding fence_get() in __drm_atomic_helper_plane_duplicate_state() ?

On Fri, Apr 29, 2016 at 3:23 PM, Rob Clark <robdclark at gmail.com> wrote:

> On Fri, Apr 29, 2016 at 3:48 AM, Daniel Stone <daniel at fooishbar.org>
> wrote:
> > Hi,
> >
> > On 28 April 2016 at 23:28, Rob Clark <robdclark at gmail.com> wrote:
> >> On Wed, Apr 27, 2016 at 2:39 AM, Daniel Vetter <daniel at 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
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160712/7f2b8cbe/attachment.html>