From mboxrd@z Thu Jan 1 00:00:00 1970 From: Inki Dae Subject: Re: [RFC 0/6] drm/fences: add in-fences to DRM Date: Thu, 31 Mar 2016 19:05:46 +0900 Message-ID: <56FCF67A.8090109@samsung.com> References: <1458758847-21170-1-git-send-email-gustavo@padovan.org> <56F3A2DC.8080507@samsung.com> <56F47D01.7040508@samsung.com> <56F88828.5050304@samsung.com> <56F9E613.1030902@samsung.com> <56FCD5A3.4040700@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by gabe.freedesktop.org (Postfix) with ESMTPS id BF5246E9F8 for ; Thu, 31 Mar 2016 10:05:49 +0000 (UTC) Received: from epcpsbgr1.samsung.com (u141.gpu120.samsung.co.kr [203.254.230.141]) by mailout1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0O4W02HNQEPMXW30@mailout1.samsung.com> for dri-devel@lists.freedesktop.org; Thu, 31 Mar 2016 19:05:46 +0900 (KST) In-reply-to: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Daniel Stone Cc: Daniel Vetter , "dri-devel@lists.freedesktop.org" , Linux Kernel Mailing List , Riley Andrews , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , Gustavo Padovan , John Harrison List-Id: dri-devel@lists.freedesktop.org SGkgRGFuaWVsLAoKMjAxNuuFhCAwM+yblCAzMeydvCAxODozNeyXkCBEYW5pZWwgU3RvbmUg7J20 KOqwgCkg7JO0IOq4gDoKPiBIaSBJbmtpLAo+IAo+IE9uIDMxIE1hcmNoIDIwMTYgYXQgMDg6NDUs IElua2kgRGFlIDxpbmtpLmRhZUBzYW1zdW5nLmNvbT4gd3JvdGU6Cj4+IDIwMTbrhYQgMDPsm5Qg MjnsnbwgMjI6MjPsl5AgUm9iIENsYXJrIOydtCjqsIApIOyTtCDquIA6Cj4+PiBPbiBNb24sIE1h ciAyOCwgMjAxNiBhdCAxMDoxOCBQTSwgSW5raSBEYWUgPGlua2kuZGFlQHNhbXN1bmcuY29tPiB3 cm90ZToKPj4+PiBJbiBhZGRpdGlvbiwgSSB3b25kZXIgaG93IGV4cGxpY2l0IGFuZCBpbXBsaWNp dCBmZW5jZXMgY291bGQgY29leGlzdCB0b2dldGhlci4KPj4+PiBSb2Igc2FpZCwKPj4+PiAiSW1w bGljaXQgc3luYyBvZmMgcmVtYWlucyB0aGUgZGVmYXVsdCwgYnV0IHVzZXJzcGFjZSBjb3VsZCBv cHQtaW4gdG8gZXhwbGljaXQgc3luYyBpbnN0ZWFkIgo+Pj4+Cj4+Pj4gVGhpcyB3b3VsZCBtZWFu IHRoYXQgaWYgd2UgdXNlIGV4cGxpY2l0IHN5bmMgZm9yIHVzZXItc3BhY2UgdGhlbiBpdCBjb2V4 aXN0cyB3aXRoIGltcGxpY2l0IHN5bmMuIEhvd2V2ZXIsIHRoZXNlIHR3byBzeW5jIGZlbmNlcyBj YW4ndCBzZWUgc2FtZSBETUEgYnVmZmVyIGJlY2F1c2UgZXhwbGljaXQgZmVuY2UgaGFzIGEgZGlm ZmVyZW50IGZpbGUgb2JqZWN0IGZyb20gaW1wbGljaXQgb25lLgo+Pj4+IFNvIGluIHRoaXMgY2Fz ZSwgSSB0aGluayBleHBsaWNpdCBmZW5jZSB3b3VsZCBuZWVkIHRvIGJlIGh1bmcgdXAgb24gdGhl IHJlc2VydmF0aW9uIG9iamVjdCBvZiBkbWFidWYgb2JqZWN0IHNvbWVob3cuIE90aGVyd2lzZSwg YWx0aG91Z2ggdGhleSBjb2V4aXN0IHRvZ2V0aGVyLCBhcmUgdGhlc2UgZmVuY2VzIC0gZXhwbGlj aXQgYW5kIGltcGxpY2l0IC0gdXNlZCBmb3IgZGlmZmVyZW5jdCBwdXJwb3NlIHNlcGFyYXRlbHk/ Cj4+Pj4KPj4+Cj4+PiBJJ20gbm90IGVudGlyZWx5IHN1cmUgYWJvdXQgY29leGlzdGFuY2UgYXQg dGhlIHNhbWUgdGltZS4gIEl0IG9mYwo+Pj4gc2hvdWxkbid0IGJlIGEgcHJvYmxlbSBmb3Igb25l IGtlcm5lbCB0byBzdXBwb3J0IGJvdGgga2luZHMgb2YKPj4+IHVzZXJzcGFjZSAocHVyZSBleHBs aWNpdCBhbmQgcHVyZSBpbXBsaWNpdCkuICBBbmQgaG93IHRoaXMgd291bGQgd29yawo+Pj4gb24g a21zIGF0b21pYyBpb2N0bCAoY29tcG9zaXRvci9jb25zdW1lcikgc2lkZSBzZWVtcyBjbGVhciBl bm91Z2guLgo+Pj4gaWUuIHNvbWUgc29ydCBvZiBmbGFnLCB3aGljaCBpZiBzZXQgdXNlciBwcm92 aWRlcyBhbiBleHBsaWNpdCBmZW5jZQo+Pj4gZmQsIGFuZCBpZiBub3Qgc2V0IHdlIGZhbGwgYmFj ayB0byBjdXJyZW50IGJlaGF2aW91ciAoaWUuIGdldCBmZW5jZXMKPj4+IGZyb20gcmVzdiBvYmpl Y3QpLgo+Pgo+PiBXaXRoIHRoaXMgcGF0Y2ggc2VyaWVzLCB1c2VycyBjYW4gcmVnaXN0ZXIgZXhw bGljaXQgZmVuY2UocykgdG8gYXRvbWljIGttcyhjb25zdW1lciBzaWRlKSB0aHJvdWdoIGttcyBw cm9wZXJ0eSBpbnRlcmZhY2UgZm9yIHRoZSBleHBsaWNpdCBzeW5jLgo+Pgo+PiBIb3dldmVyLCBu b3cgc2V2ZXJhbCBEUk0gZHJpdmVycyhhbHNvIGNvbnN1bWVyKSBhbHJlYWR5IGhhdmUgYmVlZW4g dXNpbmcgaW1wbGljaXQgZmVuY2UuIFNvIHdoaWxlIEdQVShwcm9kdWNlciBzaWRlKSBpcyBhY2Nl c3NpbmcgRE1BIGJ1ZmZlciBhZnRlciByZWdpc3RlcmluZyBpdHMgZXhwbGljaXQgZmVuY2UgdG8g YXRvbWljIGttcywgYW5kIGlmIGF0b21pYyBjb21taXQgaXMgcmVxdWVzdGVkIGJ5IHVzZXItc3Bh Y2UsIHRoZW4gYXRvbWljIGhlbHBlciBmcmFtZXdvcmsgd2lsbCB0cnkgdG8gc3luY2hyb25pemUg d2l0aCB0aGUgcHJvZHVjZXIgLSB3YWl0aW5nIGZvciB0aGUgc2lnbmFsIG9mIEdQVSBzaWRlKHBy b2R1Y2VyKSwgYW5kIGRldmljZSBzcGVjaWZpYyBwYWdlIGZsaXAgZnVuY3Rpb24gd2lsbCBhbHNv IHRyeSB0byBkbyBzYW1lIHRoaW5nLgo+IAo+IFdlbGwsIGl0IGhhcyB0byBiZSBvbmUgb3IgdGhl IG90aGVyOiBtaXhpbmcgZXhwbGljaXQgYW5kIGltcGxpY2l0LAo+IGRlZmVhdHMgdGhlIHB1cnBv c2Ugb2YgdXNpbmcgZXhwbGljaXQgZmVuY2luZy4gU28sIHdoZW4gZXhwbGljaXQKPiBmZW5jaW5n IGlzIGluIHVzZSwgaW1wbGljaXQgZmVuY2VzIG11c3QgYmUgaWdub3JlZC4KPiAKPj4gQXMgb2Yg bm93LCBpdCBzZWVtcyB0aGF0IHRoaXMgd291bGRuJ3QgYmUgb3B0aW9uYWwgYnV0IG1hbmRhdG9y eSBpZiBleHBsaWNpdCBmZW5jZSBzdXBwb3J0IGlzIGFkZGVkIHRvIHRoZSBhdG9taWMgaGVscGVy IGZyYW1ld29yay4gVGhpcyB3b3VsZCBkZWZpbml0ZWx5IGJlIGR1cGxpY2F0aW9uIGFuZCBpdCBz ZWVtcyBub3QgY2xlYXIgZW5vdWdoIGV2ZW4gaWYgb25lIG9mIHRoZW0gaXMganVzdCBza2lwcGVk IGluIHJ1bnRpbWUuCj4gCj4gRHJpdmVycyB3b3VsZCBoYXZlIHRvIG9wdCBpbiB0byBleHBsaWNp dCBmZW5jaW5nIHN1cHBvcnQsIGFuZCBwYXJ0IG9mCj4gdGhhdCB3b3VsZCBiZSBlbnN1cmluZyB0 aGF0IHRoZSBkcml2ZXIgZG9lcyBub3Qgd2FpdCBvbiBpbXBsaWNpdAo+IGZlbmNlcyB3aGVuIHRo ZSB1c2VyIGhhcyByZXF1ZXN0ZWQgZXhwbGljaXQgZmVuY2luZyBiZSB1c2VkLgo+IAoKVGhlbiwg ZXhpc3RpbmcgZHJpdmVycyB3b3VsZCBuZWVkIGFkZGl0aW9uYWwgd29ya3MgZm9yIGV4cGxpY2l0 IGZlbmNpbmcgc3VwcG9ydC4gVGhpcyB3b3VsZG4ndCBiZSByZWFsbHkgd2hhdCB0aGUgZHJpdmVy cyBoYXZlIHRvIGJ1dCBzaG91bGQgYmUgaGFuZGxlZCB3aXRoIHRoaXMgcGF0Y2ggc2VyaWVzIGJl Y2F1c2UgdGhpcyB3b3VsZCBhZmZlY3QgZXhpc2luZyBkZXZpY2UgZHJpdmVycyB3aGljaCB1c2Ug aW1wbGljaXQgZmVuY2luZy4KCgpUaGFua3MsCklua2kgRGFlCgo+IENoZWVycywKPiBEYW5pZWwK PiAKPiAKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJp LWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBz Oi8vbGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753512AbcCaKFv (ORCPT ); Thu, 31 Mar 2016 06:05:51 -0400 Received: from mailout1.samsung.com ([203.254.224.24]:50124 "EHLO mailout1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751607AbcCaKFs (ORCPT ); Thu, 31 Mar 2016 06:05:48 -0400 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 X-AuditID: cbfee68d-f79e86d0000012da-ed-56fcf67a0a94 Content-transfer-encoding: 8BIT Message-id: <56FCF67A.8090109@samsung.com> Date: Thu, 31 Mar 2016 19:05:46 +0900 From: Inki Dae User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 To: Daniel Stone Cc: Rob Clark , Linux Kernel Mailing List , "dri-devel@lists.freedesktop.org" , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , Daniel Vetter , Riley Andrews , Gustavo Padovan , John Harrison 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> <56F47D01.7040508@samsung.com> <56F88828.5050304@samsung.com> <56F9E613.1030902@samsung.com> <56FCD5A3.4040700@samsung.com> In-reply-to: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOIsWRmVeSWpSXmKPExsWyRsSkQLfq258wg54dehbv/95ns1j48C6z xZXW6awWV76+Z7P4tLqV3WLS0wdsFpd3zWGzeL3pL6PF84U/mB04Pbbt3sbq8ff5dRaPvd8W sHi8+LqN2WPnrLvsHov3vGTyuN99nMnj8ya5AI4oLpuU1JzMstQifbsEroyJz3cyFpwWr2j7 rNLAOFG4i5GDQ0LAROLTbZEuRk4gU0ziwr31bF2MXBxCAisYJZ5cXMwMU7PiHh9EfCmjxN27 z9lBGngFBCV+TL7HAlLDLCAvceRSNoSpLjFlSi5E+QNGiTuXtrFBlGtJtPWvYgSxWQRUJRZP OMwKYrMB2RNX3GcD6RUViJDoPlEJEhYBGrPgwTtGkDnMAlOYJbbt2wo2R1jAXKL3YScrxIJJ rBJXb84Au4dTIFhiw/enYB0SAj/ZJWbufccMsU1A4tvkQywQz8hKbDrADPGwpMTBFTdYJjCK zULyziyEd2YhvLOAkXkVo2hqQXJBcVJ6kaFecWJucWleul5yfu4mRmB8nv73rHcH4+0D1ocY BTgYlXh4NdL+hAmxJpYVV+YeYjQFumEis5Rocj4wCeSVxBsamxlZmJqYGhuZW5opifMqSv0M FhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cC4cVaFcf/eLUdvfa7i+NbgcPrpm6z8b7k/3qUw 6PRkPXW9JLA721lBWf5sbuqCHDPbBKZvCaeiBCZl8B4J+O9teSRJdtLly++WWUfysR1wWRfx qmGd7y41s9nHNPIj33AaW7C/tYjKbLq6/63dl+yn/+J0O7exMkouOXdxno6/6073BUUJ014q sRRnJBpqMRcVJwIAtOrTEMoCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42I5/e+xgG7Vtz9hBpuOaVi8/3ufzWLhw7vM Fldap7NaXPn6ns3i0+pWdotJTx+wWVzeNYfN4vWmv4wWzxf+YHbg9Ni2exurx9/n11k89n5b wOLx4us2Zo+ds+6yeyze85LJ4373cSaPz5vkAjiiGhhtMlITU1KLFFLzkvNTMvPSbZW8g+Od 403NDAx1DS0tzJUU8hJzU22VXHwCdN0yc4AOVFIoS8wpBQoFJBYXK+nbYZoQGuKmawHTGKHr GxIE12NkgAYS1jBmTHy+k7HgtHhF22eVBsaJwl2MHBwSAiYSK+7xdTFyApliEhfurWfrYuTi EBJYyihx9+5zdpAEr4CgxI/J91hA6pkF5CWOXMqGMNUlpkzJhSh/wChx59I2NohyLYm2/lWM IDaLgKrE4gmHWUFsNiB74or7bCC9ogIREt0nKkHCIkBjFjx4xwgyh1lgCrPEtn1bweYIC5hL 9D7sZIVYMIlV4urNGWD3cAoES2z4/pRxAqPALCTnzUI4bxbCeQsYmVcxSqQWJBcUJ6XnGuWl lusVJ+YWl+al6yXn525iBCeBZ9I7GA/vcj/EKMDBqMTDeyH5T5gQa2JZcWXuIUYJDmYlEV7m j0Ah3pTEyqrUovz4otKc1OJDjKZA/01klhJNzgcmqLySeENjEzMjSyNzQwsjY3Mlcd7H/9eF CQmkJ5akZqemFqQWwfQxcXBKNTBqS3F/rmu8n2545PKSP/291gHPHRZVPMxU/B20uTDdSWH5 Wd6fMx+a6LfM2VZt8pY/ToWNyXy2+q1D09cuauXrPxmVGe9fc+nN0p4Nr/ti6w7uD4h/K++v O2dr5eXnRsdOvysU+FbknKF0Jvt+2a6jbhfmf7jeoWTYpVigaf1aRd3y5smYlf+VWIozEg21 mIuKEwFqLTgGGAMAAA== DLP-Filter: Pass X-MTR: 20000000000000000@CPGS X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Daniel, 2016년 03월 31일 18:35에 Daniel Stone 이(가) 쓴 글: > Hi Inki, > > On 31 March 2016 at 08:45, Inki Dae wrote: >> 2016년 03월 29일 22:23에 Rob Clark 이(가) 쓴 글: >>> On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae 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 > >