Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1390549 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC v2 5/8] drm/fence: add in-fences support Rob Clark <robdclark@gmail.com> - 2016-04-28 23:30 +0200
    Re: [RFC v2 5/8] drm/fence: add in-fences support Daniel Stone <daniel@fooishbar.org> - 2016-04-29 09:50 +0200
      Re: [RFC v2 5/8] drm/fence: add in-fences support Rob Clark <robdclark@gmail.com> - 2016-04-30 00:30 +0200

#1390549 — Re: [RFC v2 5/8] drm/fence: add in-fences support

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:
>> On 04/26/2016 01:05 PM, Daniel Vetter wrote:
>> >On Tue, Apr 26, 2016 at 09:55:06PM +0300, Ville Syrjälä wrote:
>> >>On Tue, Apr 26, 2016 at 08:23:46PM +0200, Daniel Vetter wrote:
>> >>>On Tue, Apr 26, 2016 at 08:40:45PM +0300, Ville Syrjälä wrote:
>> >>>But really the reason for per-plane is hw composer from
>> >>>Android. I don't see any point in designing an api that's needlessly
>> >>>different from what the main user expects (even if it may be silly).
>> >>
>> >>What are they doing that can't stuff the fences into an array
>> >>instead of props?
>> >
>> >The hw composer interface is one in-fence per plane. That's really the
>> >major reason why the kernel interface is built to match. And I really
>> >don't think we should diverge just because we have a slight different
>> >color preference ;-)
>> >
>> >As long as you end up with a pile of fences somehow it'll work.
>> >-Daniel
>> >
>>
>> The relationship between layers and fences is only fuzzy and indirect
>> though.  The relationship is really between the buffer you're displaying on
>> that layer, and the fence representing the work done to render into that
>> buffer.  SurfaceFlinger just happens to bundle them together inside the same
>> struct hwc_layer_1 as an API convenience.
>>
>> Which is kind of splitting hairs as long as you have a 1-to-1 relationship
>> between layers and DRM planes.  But that's not always the case.
>>
>> 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)

> 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.

BR,
-R


> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

[toc] | [next] | [standalone]

#1390839

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.

Cheers,
Daniel

[toc] | [prev] | [next] | [standalone]

#1391498

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web