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

[Inki Dae]

Hi Daniel,

2016ë 03ì 28ì 22:26ì Daniel Stone ì(ê) ì ê:
> Hi Inki,
> 
> On 28 March 2016 at 02:26, Inki Dae <inki.dae@xxxxxxxxxxx> 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?

Just for consistency. As you know, implicit sync hangs DMA fence up on dmabuf object through reservation object so dmabuf independent explicit sync looked strange to me.
As you mentioned above, the suballocation would be why explicit sync should be indepenent of DMABUF.

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? 

Thanks,
Inki Dae

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