MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8BIT
Message-id: <56FCF67A.8090109@samsung.com>
Date: Thu, 31 Mar 2016 19:05:46 +0900
From: Inki Dae <inki.dae@samsung.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
 Thunderbird/31.6.0
To: Daniel Stone <daniel@fooishbar.org>
Cc: Rob Clark <robdclark@gmail.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>,
        =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= <arve@android.com>,
        Daniel Vetter <daniel.vetter@ffwll.ch>,
        Riley Andrews <riandrews@android.com>,
        Gustavo Padovan <gustavo.padovan@collabora.co.uk>,
        John Harrison <John.C.Harrison@intel.com>
Subject: Re: [RFC 0/6] drm/fences: add in-fences to DRM
References: <1458758847-21170-1-git-send-email-gustavo@padovan.org>
 <56F3A2DC.8080507@samsung.com>
 <CAF6AEGu13bahQWK5yBDnsUoKdmLxJT=fj=S-VNWKjjNqLG2gEg@mail.gmail.com>
 <56F47D01.7040508@samsung.com>
 <CAF6AEGtesj5hDQtBQgTAJFnMi0euY+Xm+wbUupMc660VPVtmvg@mail.gmail.com>
 <CAPj87rMpNOwbvv1+jfKfE=Bte7S3wpH6WpZUpHv6uvKQ5DeY=Q@mail.gmail.com>
 <56F88828.5050304@samsung.com>
 <CAPj87rPJj0E_WvKCfGbANoXT9w6ns2k3mnNWvo5LZFfqtN1RGQ@mail.gmail.com>
 <56F9E613.1030902@samsung.com>
 <CAF6AEGt3OOfvtSVtueNKdVFo5Pnm=mL8K+dPPJZ8BjYXSi+0ww@mail.gmail.com>
 <56FCD5A3.4040700@samsung.com>
 <CAPj87rPjoBiF_TuBERM4sqL6sb_73CMirRav+JCYFiWzpp+FHw@mail.gmail.com>
In-reply-to: <CAPj87rPjoBiF_TuBERM4sqL6sb_73CMirRav+JCYFiWzpp+FHw@mail.gmail.com>
DLP-Filter: Pass
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2970
Lines: 49

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