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

Groups > linux.kernel > #1365485

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

Show all headers | View raw

Hi Inki,

On 28 March 2016 at 02:26, Inki Dae <inki.dae@samsung.com> wrote:
> 2016년 03월 25일 21:10에 Daniel Stone 이(가) 쓴 글:
>> Second, really. Vulkan avoids implicit sync entirely, and exposes
>> fence-like primitives throughout its whole API. These include being
>> able to pass prerequisite fences for display (what Gustavo is adding
>> here: something to block on before display), and also when the user
>> acquires a buffer as a render target, it is given another prerequisite
>> fence (the other side of what Gustavo is suggesting, i.e. the fence
>> triggers when the buffer is no longer displayed and becomes available
>> for rendering).
>>
>> In order to implement this correctly, and avoid performance bubbles,
>> we need a primitive like this exposed through the KMS API, from both
>> sides. This is especially important when you take the case of
>> userspace suballocation, where userspace allocates larger blocks and
>> divides the allocation internally for different uses. Implicit sync
>> does not work at all for that case.
>
> Can you give me more details why implicit sync cannot take care of the case of userspace suballocation?

Implicit sync does not know about suballocation, so implicit will
operate for every range in the buffer, not just the one you want.

Say you have one kernel buffer, which userspace subdivides into four
independent buffers. It can perform operations on these buffers which
are completely independent of each other, and an explicit sync model
allows this independence to be kept. Implicit sync ties them together,
so that you cannot do any operations on buffer 1 until all operations
on buffer 2 have completed.

> And is there any reason that fence fd shouldn't dependent of DMABUF - now fence fd is a new file, not DMABUF fd?

Because dmabuf is for buffer sharing, and fences aren't buffers (they
will never export page ranges). Is there any particular benefit you
think you would get from doing this?

>> good thing. This is also the model that ChromeOS is moving towards, so
>> it becomes more important from that point of view as well.
>
> I think Gustavo should had explaned this path series enough to other people when posting them - ie, what relationship explict and implicit fences have, and why implicit fence - which is independent of DMABUF - is required, and what use cases there are in real users, and etc.

Fair enough, the summary could perhaps contain something like this.

Cheers,
Daniel

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[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

csiph-web