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

Groups > linux.kernel > #1363609 > unrolled thread

[RFC 0/6] drm/fences: add in-fences to DRM

Back to article view | Back to linux.kernel

Contents

  [RFC 0/6] drm/fences: add in-fences to DRM Gustavo Padovan <gustavo@padovan.org> - 2016-03-23 19:50 +0100
    [RFC 6/6] drm/fence: support fence_collection on atomic commit Gustavo Padovan <gustavo@padovan.org> - 2016-03-23 19:50 +0100
    [RFC 5/6] dma-buf/fence: add fence_collection_wait() Gustavo Padovan <gustavo@padovan.org> - 2016-03-23 19:50 +0100
    [RFC 4/6] dma-buf/fence: add fence_collection_put() Gustavo Padovan <gustavo@padovan.org> - 2016-03-23 19:50 +0100
    [RFC 3/6] dma-buf/sync_file: add sync_file_fences_get() Gustavo Padovan <gustavo@padovan.org> - 2016-03-23 19:50 +0100
    [RFC 1/6] drm/fence: add FENCE_FD property to planes Gustavo Padovan <gustavo@padovan.org> - 2016-03-23 19:50 +0100
    Re: [RFC 0/6] drm/fences: add in-fences to DRM Maarten Lankhorst <maarten.lankhorst@linux.intel.com> - 2016-03-24 08:30 +0100
      Re: [RFC 0/6] drm/fences: add in-fences to DRM Gustavo Padovan <gustavo@padovan.org> - 2016-03-24 15:40 +0100
    Re: [RFC 0/6] drm/fences: add in-fences to DRM Inki Dae <inki.dae@samsung.com> - 2016-03-24 09:20 +0100
      Re: [RFC 0/6] drm/fences: add in-fences to DRM Gustavo Padovan <gustavo@padovan.org> - 2016-03-24 15:50 +0100
        Re: [RFC 0/6] drm/fences: add in-fences to DRM Inki Dae <inki.dae@samsung.com> - 2016-03-25 00:10 +0100
      Re: [RFC 0/6] drm/fences: add in-fences to DRM Rob Clark <robdclark@gmail.com> - 2016-03-24 16:50 +0100
        Re: [RFC 0/6] drm/fences: add in-fences to DRM Inki Dae <inki.dae@samsung.com> - 2016-03-25 00:50 +0100
          Re: [RFC 0/6] drm/fences: add in-fences to DRM Rob Clark <robdclark@gmail.com> - 2016-03-25 13:00 +0100
            Re: [RFC 0/6] drm/fences: add in-fences to DRM Daniel Stone <daniel@fooishbar.org> - 2016-03-25 13:20 +0100
              Re: [RFC 0/6] drm/fences: add in-fences to DRM Inki Dae <inki.dae@samsung.com> - 2016-03-28 03:30 +0200
                Re: [RFC 0/6] drm/fences: add in-fences to DRM Daniel Stone <daniel@fooishbar.org> - 2016-03-28 15:30 +0200
                  Re: [RFC 0/6] drm/fences: add in-fences to DRM Inki Dae <inki.dae@samsung.com> - 2016-03-29 04:20 +0200
                    Re: [RFC 0/6] drm/fences: add in-fences to DRM Rob Clark <robdclark@gmail.com> - 2016-03-29 15:30 +0200
                      Re: [RFC 0/6] drm/fences: add in-fences to DRM Inki Dae <inki.dae@samsung.com> - 2016-03-31 09:50 +0200
                        Re: [RFC 0/6] drm/fences: add in-fences to DRM Daniel Stone <daniel@fooishbar.org> - 2016-03-31 11:40 +0200
                          Re: [RFC 0/6] drm/fences: add in-fences to DRM Inki Dae <inki.dae@samsung.com> - 2016-03-31 12:10 +0200
                            Re: [RFC 0/6] drm/fences: add in-fences to DRM Daniel Stone <daniel@fooishbar.org> - 2016-03-31 13:00 +0200
                              Re: [RFC 0/6] drm/fences: add in-fences to DRM Inki Dae <daeinki@gmail.com> - 2016-03-31 13:30 +0200
                                Re: [RFC 0/6] drm/fences: add in-fences to DRM Daniel Stone <daniel@fooishbar.org> - 2016-03-31 13:50 +0200
                                Re: [RFC 0/6] drm/fences: add in-fences to DRM Rob Clark <robdclark@gmail.com> - 2016-03-31 16:20 +0200
                          Re: [RFC 0/6] drm/fences: add in-fences to DRM Daniel Vetter <daniel@ffwll.ch> - 2016-03-31 12:10 +0200
                            Re: [RFC 0/6] drm/fences: add in-fences to DRM Inki Dae <daeinki@gmail.com> - 2016-03-31 13:50 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1368105

Hi Inki,

On 31 March 2016 at 08:45, Inki Dae <inki.dae@samsung.com> wrote:
> 2016년 03월 29일 22:23에 Rob Clark 이(가) 쓴 글:
>> On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae <inki.dae@samsung.com> wrote:
>>> In addition, I wonder how explicit and implicit fences could coexist together.
>>> Rob said,
>>> "Implicit sync ofc remains the default, but userspace could opt-in to explicit sync instead"
>>>
>>> This would mean that if we use explicit sync for user-space then it coexists with implicit sync. However, these two sync fences can't see same DMA buffer because explicit fence has a different file object from implicit one.
>>> So in this case, I think explicit fence would need to be hung up on the reservation object of dmabuf object somehow. Otherwise, although they coexist together, are these fences - explicit and implicit - used for differenct purpose separately?
>>>
>>
>> I'm not entirely sure about coexistance at the same time.  It ofc
>> shouldn't be a problem for one kernel to support both kinds of
>> userspace (pure explicit and pure implicit).  And how this would work
>> on kms atomic ioctl (compositor/consumer) side seems clear enough..
>> ie. some sort of flag, which if set user provides an explicit fence
>> fd, and if not set we fall back to current behaviour (ie. get fences
>> from resv object).
>
> With this patch series, users can register explicit fence(s) to atomic kms(consumer side) through kms property interface for the explicit sync.
>
> However, now several DRM drivers(also consumer) already have beeen using implicit fence. So while GPU(producer side) is accessing DMA buffer after registering its explicit fence to atomic kms, and if atomic commit is requested by user-space, then atomic helper framework will try to synchronize with the producer - waiting for the signal of GPU side(producer), and device specific page flip function will also try to do same thing.

Well, it has to be one or the other: mixing explicit and implicit,
defeats the purpose of using explicit fencing. So, when explicit
fencing is in use, implicit fences must be ignored.

> As of now, it seems that this wouldn't be optional but mandatory if explicit fence support is added to the atomic helper framework. This would definitely be duplication and it seems not clear enough even if one of them is just skipped in runtime.

Drivers would have to opt in to explicit fencing support, and part of
that would be ensuring that the driver does not wait on implicit
fences when the user has requested explicit fencing be used.

Cheers,
Daniel

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

#1368134

Hi Daniel,

2016년 03월 31일 18:35에 Daniel Stone 이(가) 쓴 글:
> Hi Inki,
> 
> On 31 March 2016 at 08:45, Inki Dae <inki.dae@samsung.com> wrote:
>> 2016년 03월 29일 22:23에 Rob Clark 이(가) 쓴 글:
>>> On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae <inki.dae@samsung.com> wrote:
>>>> In addition, I wonder how explicit and implicit fences could coexist together.
>>>> Rob said,
>>>> "Implicit sync ofc remains the default, but userspace could opt-in to explicit sync instead"
>>>>
>>>> This would mean that if we use explicit sync for user-space then it coexists with implicit sync. However, these two sync fences can't see same DMA buffer because explicit fence has a different file object from implicit one.
>>>> So in this case, I think explicit fence would need to be hung up on the reservation object of dmabuf object somehow. Otherwise, although they coexist together, are these fences - explicit and implicit - used for differenct purpose separately?
>>>>
>>>
>>> I'm not entirely sure about coexistance at the same time.  It ofc
>>> shouldn't be a problem for one kernel to support both kinds of
>>> userspace (pure explicit and pure implicit).  And how this would work
>>> on kms atomic ioctl (compositor/consumer) side seems clear enough..
>>> ie. some sort of flag, which if set user provides an explicit fence
>>> fd, and if not set we fall back to current behaviour (ie. get fences
>>> from resv object).
>>
>> With this patch series, users can register explicit fence(s) to atomic kms(consumer side) through kms property interface for the explicit sync.
>>
>> However, now several DRM drivers(also consumer) already have beeen using implicit fence. So while GPU(producer side) is accessing DMA buffer after registering its explicit fence to atomic kms, and if atomic commit is requested by user-space, then atomic helper framework will try to synchronize with the producer - waiting for the signal of GPU side(producer), and device specific page flip function will also try to do same thing.
> 
> Well, it has to be one or the other: mixing explicit and implicit,
> defeats the purpose of using explicit fencing. So, when explicit
> fencing is in use, implicit fences must be ignored.
> 
>> As of now, it seems that this wouldn't be optional but mandatory if explicit fence support is added to the atomic helper framework. This would definitely be duplication and it seems not clear enough even if one of them is just skipped in runtime.
> 
> Drivers would have to opt in to explicit fencing support, and part of
> that would be ensuring that the driver does not wait on implicit
> fences when the user has requested explicit fencing be used.
> 

Then, existing drivers would need additional works for explicit fencing support. This wouldn't be really what the drivers have to but should be handled with this patch series because this would affect exising device drivers which use implicit fencing.


Thanks,
Inki Dae

> Cheers,
> Daniel
> 
> 

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

#1368173

Hi Inki,

On 31 March 2016 at 11:05, Inki Dae <inki.dae@samsung.com> wrote:
> 2016년 03월 31일 18:35에 Daniel Stone 이(가) 쓴 글:
>> On 31 March 2016 at 08:45, Inki Dae <inki.dae@samsung.com> wrote:
>>> As of now, it seems that this wouldn't be optional but mandatory if explicit fence support is added to the atomic helper framework. This would definitely be duplication and it seems not clear enough even if one of them is just skipped in runtime.
>>
>> Drivers would have to opt in to explicit fencing support, and part of
>> that would be ensuring that the driver does not wait on implicit
>> fences when the user has requested explicit fencing be used.
>>
>
> Then, existing drivers would need additional works for explicit fencing support. This wouldn't be really what the drivers have to but should be handled with this patch series because this would affect exising device drivers which use implicit fencing.

Well, yes. Anyone implementing their own atomic commit would need to
ensure that the commit works properly for fences. The helpers could
also add it, but the helpers are not mandatory, and you are not
required to use every part of the helper to use one part of the
helper. There is no magic wand you can wave that instantly makes it
work for every driver.

Cheers,
Daniel

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

#1368191

Hi Daniel,

2016-03-31 19:56 GMT+09:00 Daniel Stone <daniel@fooishbar.org>:
> Hi Inki,
>
> On 31 March 2016 at 11:05, Inki Dae <inki.dae@samsung.com> wrote:
>> 2016년 03월 31일 18:35에 Daniel Stone 이(가) 쓴 글:
>>> On 31 March 2016 at 08:45, Inki Dae <inki.dae@samsung.com> wrote:
>>>> As of now, it seems that this wouldn't be optional but mandatory if explicit fence support is added to the atomic helper framework. This would definitely be duplication and it seems not clear enough even if one of them is just skipped in runtime.
>>>
>>> Drivers would have to opt in to explicit fencing support, and part of
>>> that would be ensuring that the driver does not wait on implicit
>>> fences when the user has requested explicit fencing be used.
>>>
>>
>> Then, existing drivers would need additional works for explicit fencing support. This wouldn't be really what the drivers have to but should be handled with this patch series because this would affect exising device drivers which use implicit fencing.
>
> Well, yes. Anyone implementing their own atomic commit would need to
> ensure that the commit works properly for fences. The helpers could
> also add it, but the helpers are not mandatory, and you are not
> required to use every part of the helper to use one part of the
> helper. There is no magic wand you can wave that instantly makes it
> work for every driver

I meant there are already several DRM drivers which work properly for
implicit fence. So if atomic helper framework of DRM core is
considered only for the explicit fence, then fencing operation would
affect the existing DRM drivers. So I hope this trying could consider
existing implicit fence users.

Thanks,
Inki Dae
.
>
> Cheers,
> Daniel
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

#1368224

Hi Inki,

On 31 March 2016 at 12:26, Inki Dae <daeinki@gmail.com> wrote:
> 2016-03-31 19:56 GMT+09:00 Daniel Stone <daniel@fooishbar.org>:
>> On 31 March 2016 at 11:05, Inki Dae <inki.dae@samsung.com> wrote:
>>> Then, existing drivers would need additional works for explicit fencing support. This wouldn't be really what the drivers have to but should be handled with this patch series because this would affect exising device drivers which use implicit fencing.
>>
>> Well, yes. Anyone implementing their own atomic commit would need to
>> ensure that the commit works properly for fences. The helpers could
>> also add it, but the helpers are not mandatory, and you are not
>> required to use every part of the helper to use one part of the
>> helper. There is no magic wand you can wave that instantly makes it
>> work for every driver
>
> I meant there are already several DRM drivers which work properly for
> implicit fence. So if atomic helper framework of DRM core is
> considered only for the explicit fence, then fencing operation would
> affect the existing DRM drivers. So I hope this trying could consider
> existing implicit fence users.

Yes, absolutely. Implicit fencing is already part of userspace ABI
that we can effectively never remove: it would break everyone's
desktops on Intel alone, as well as many others. So explicit will be
opt-in from the user and the driver both, and only when the
combination is fully supported will explicit fencing be used.

Cheers,
Daniel

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

#1368343

On Thu, Mar 31, 2016 at 7:26 AM, Inki Dae <daeinki@gmail.com> wrote:
> Hi Daniel,
>
> 2016-03-31 19:56 GMT+09:00 Daniel Stone <daniel@fooishbar.org>:
>> Hi Inki,
>>
>> On 31 March 2016 at 11:05, Inki Dae <inki.dae@samsung.com> wrote:
>>> 2016년 03월 31일 18:35에 Daniel Stone 이(가) 쓴 글:
>>>> On 31 March 2016 at 08:45, Inki Dae <inki.dae@samsung.com> wrote:
>>>>> As of now, it seems that this wouldn't be optional but mandatory if explicit fence support is added to the atomic helper framework. This would definitely be duplication and it seems not clear enough even if one of them is just skipped in runtime.
>>>>
>>>> Drivers would have to opt in to explicit fencing support, and part of
>>>> that would be ensuring that the driver does not wait on implicit
>>>> fences when the user has requested explicit fencing be used.
>>>>
>>>
>>> Then, existing drivers would need additional works for explicit fencing support. This wouldn't be really what the drivers have to but should be handled with this patch series because this would affect exising device drivers which use implicit fencing.
>>
>> Well, yes. Anyone implementing their own atomic commit would need to
>> ensure that the commit works properly for fences. The helpers could
>> also add it, but the helpers are not mandatory, and you are not
>> required to use every part of the helper to use one part of the
>> helper. There is no magic wand you can wave that instantly makes it
>> work for every driver
>
> I meant there are already several DRM drivers which work properly for
> implicit fence. So if atomic helper framework of DRM core is
> considered only for the explicit fence, then fencing operation would
> affect the existing DRM drivers. So I hope this trying could consider
> existing implicit fence users.
>

Note that there would be a new flag on the atomic ioctl to request
explicit fencing, and with an old kernel or a driver that does not
support it, the ioctl would be rejected and an error returned.  The
atomic/kms framework would of course continue to support implicit
fencing.   And an explicit-fencing userspace would require a
sufficiently new kernel and possibly some minor driver support (above
and beyond 'struct fence' conversion).

BR,
-R

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

#1368136

On Thu, Mar 31, 2016 at 10:35:11AM +0100, Daniel Stone wrote:
> Well, it has to be one or the other: mixing explicit and implicit,
> defeats the purpose of using explicit fencing. So, when explicit
> fencing is in use, implicit fences must be ignored.

You can mix it, if you're careful. CrOS wants that to better mesh android
with Ozone, and we'll be discussing what needs to be added to be able to
make it work implicit and explicit fencing work together, in both
directions. Of course this should only be used for shared buffers, e.g.
explicit syncing in an android client running on top of implicitly synced
ozone/kms.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

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

#1368219

2016-03-31 19:04 GMT+09:00 Daniel Vetter <daniel@ffwll.ch>:
> On Thu, Mar 31, 2016 at 10:35:11AM +0100, Daniel Stone wrote:
>> Well, it has to be one or the other: mixing explicit and implicit,
>> defeats the purpose of using explicit fencing. So, when explicit
>> fencing is in use, implicit fences must be ignored.
>
> You can mix it, if you're careful. CrOS wants that to better mesh android
> with Ozone, and we'll be discussing what needs to be added to be able to
> make it work implicit and explicit fencing work together, in both
> directions. Of course this should only be used for shared buffers, e.g.
> explicit syncing in an android client running on top of implicitly synced
> ozone/kms.

Good idea. I hope fence things of mainline would be more discussed so
could be considered for many cases.

Thanks,
Inki Dae

> -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] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web