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 16:45:39 +0900 Message-ID: <56FCD5A3.4040700@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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by gabe.freedesktop.org (Postfix) with ESMTPS id 946636E9B7 for ; Thu, 31 Mar 2016 07:45:50 +0000 (UTC) Received: from epcpsbgr4.samsung.com (u144.gpu120.samsung.co.kr [203.254.230.144]) by mailout2.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0O4W00HFO883FY30@mailout2.samsung.com> for dri-devel@lists.freedesktop.org; Thu, 31 Mar 2016 16:45:39 +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: Rob Clark Cc: Daniel Vetter , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , "dri-devel@lists.freedesktop.org" , Linux Kernel Mailing List , Riley Andrews , Gustavo Padovan , John Harrison List-Id: dri-devel@lists.freedesktop.org CgoyMDE264WEIDAz7JuUIDI57J28IDIyOjIz7JeQIFJvYiBDbGFyayDsnbQo6rCAKSDsk7Qg6riA Ogo+IE9uIE1vbiwgTWFyIDI4LCAyMDE2IGF0IDEwOjE4IFBNLCBJbmtpIERhZSA8aW5raS5kYWVA c2Ftc3VuZy5jb20+IHdyb3RlOgo+Pgo+PiBJbiBhZGRpdGlvbiwgSSB3b25kZXIgaG93IGV4cGxp Y2l0IGFuZCBpbXBsaWNpdCBmZW5jZXMgY291bGQgY29leGlzdCB0b2dldGhlci4KPj4gUm9iIHNh aWQsCj4+ICJJbXBsaWNpdCBzeW5jIG9mYyByZW1haW5zIHRoZSBkZWZhdWx0LCBidXQgdXNlcnNw YWNlIGNvdWxkIG9wdC1pbiB0byBleHBsaWNpdCBzeW5jIGluc3RlYWQiCj4+Cj4+IFRoaXMgd291 bGQgbWVhbiB0aGF0IGlmIHdlIHVzZSBleHBsaWNpdCBzeW5jIGZvciB1c2VyLXNwYWNlIHRoZW4g aXQgY29leGlzdHMgd2l0aCBpbXBsaWNpdCBzeW5jLiBIb3dldmVyLCB0aGVzZSB0d28gc3luYyBm ZW5jZXMgY2FuJ3Qgc2VlIHNhbWUgRE1BIGJ1ZmZlciBiZWNhdXNlIGV4cGxpY2l0IGZlbmNlIGhh cyBhIGRpZmZlcmVudCBmaWxlIG9iamVjdCBmcm9tIGltcGxpY2l0IG9uZS4KPj4gU28gaW4gdGhp cyBjYXNlLCBJIHRoaW5rIGV4cGxpY2l0IGZlbmNlIHdvdWxkIG5lZWQgdG8gYmUgaHVuZyB1cCBv biB0aGUgcmVzZXJ2YXRpb24gb2JqZWN0IG9mIGRtYWJ1ZiBvYmplY3Qgc29tZWhvdy4gT3RoZXJ3 aXNlLCBhbHRob3VnaCB0aGV5IGNvZXhpc3QgdG9nZXRoZXIsIGFyZSB0aGVzZSBmZW5jZXMgLSBl eHBsaWNpdCBhbmQgaW1wbGljaXQgLSB1c2VkIGZvciBkaWZmZXJlbmN0IHB1cnBvc2Ugc2VwYXJh dGVseT8KPj4KPiAKPiBJJ20gbm90IGVudGlyZWx5IHN1cmUgYWJvdXQgY29leGlzdGFuY2UgYXQg dGhlIHNhbWUgdGltZS4gIEl0IG9mYwo+IHNob3VsZG4ndCBiZSBhIHByb2JsZW0gZm9yIG9uZSBr ZXJuZWwgdG8gc3VwcG9ydCBib3RoIGtpbmRzIG9mCj4gdXNlcnNwYWNlIChwdXJlIGV4cGxpY2l0 IGFuZCBwdXJlIGltcGxpY2l0KS4gIEFuZCBob3cgdGhpcyB3b3VsZCB3b3JrCj4gb24ga21zIGF0 b21pYyBpb2N0bCAoY29tcG9zaXRvci9jb25zdW1lcikgc2lkZSBzZWVtcyBjbGVhciBlbm91Z2gu Lgo+IGllLiBzb21lIHNvcnQgb2YgZmxhZywgd2hpY2ggaWYgc2V0IHVzZXIgcHJvdmlkZXMgYW4g ZXhwbGljaXQgZmVuY2UKPiBmZCwgYW5kIGlmIG5vdCBzZXQgd2UgZmFsbCBiYWNrIHRvIGN1cnJl bnQgYmVoYXZpb3VyIChpZS4gZ2V0IGZlbmNlcwo+IGZyb20gcmVzdiBvYmplY3QpLgoKV2l0aCB0 aGlzIHBhdGNoIHNlcmllcywgdXNlcnMgY2FuIHJlZ2lzdGVyIGV4cGxpY2l0IGZlbmNlKHMpIHRv IGF0b21pYyBrbXMoY29uc3VtZXIgc2lkZSkgdGhyb3VnaCBrbXMgcHJvcGVydHkgaW50ZXJmYWNl IGZvciB0aGUgZXhwbGljaXQgc3luYy4KCkhvd2V2ZXIsIG5vdyBzZXZlcmFsIERSTSBkcml2ZXJz KGFsc28gY29uc3VtZXIpIGFscmVhZHkgaGF2ZSBiZWVlbiB1c2luZyBpbXBsaWNpdCBmZW5jZS4g U28gd2hpbGUgR1BVKHByb2R1Y2VyIHNpZGUpIGlzIGFjY2Vzc2luZyBETUEgYnVmZmVyIGFmdGVy IHJlZ2lzdGVyaW5nIGl0cyBleHBsaWNpdCBmZW5jZSB0byBhdG9taWMga21zLCBhbmQgaWYgYXRv bWljIGNvbW1pdCBpcyByZXF1ZXN0ZWQgYnkgdXNlci1zcGFjZSwgdGhlbiBhdG9taWMgaGVscGVy IGZyYW1ld29yayB3aWxsIHRyeSB0byBzeW5jaHJvbml6ZSB3aXRoIHRoZSBwcm9kdWNlciAtIHdh aXRpbmcgZm9yIHRoZSBzaWduYWwgb2YgR1BVIHNpZGUocHJvZHVjZXIpLCBhbmQgZGV2aWNlIHNw ZWNpZmljIHBhZ2UgZmxpcCBmdW5jdGlvbiB3aWxsIGFsc28gdHJ5IHRvIGRvIHNhbWUgdGhpbmcu CgpBcyBvZiBub3csIGl0IHNlZW1zIHRoYXQgdGhpcyB3b3VsZG4ndCBiZSBvcHRpb25hbCBidXQg bWFuZGF0b3J5IGlmIGV4cGxpY2l0IGZlbmNlIHN1cHBvcnQgaXMgYWRkZWQgdG8gdGhlIGF0b21p YyBoZWxwZXIgZnJhbWV3b3JrLiBUaGlzIHdvdWxkIGRlZmluaXRlbHkgYmUgZHVwbGljYXRpb24g YW5kIGl0IHNlZW1zIG5vdCBjbGVhciBlbm91Z2ggZXZlbiBpZiBvbmUgb2YgdGhlbSBpcyBqdXN0 IHNraXBwZWQgaW4gcnVudGltZS4KCj4gCj4gT24gdGhlIGdwdS9wcm9kdWNlciBzaWRlLCBJIHRo aW5rIHdoYXQgbWFrZXMgc2Vuc2UgaXMgdG8gYm90aCBhdHRhY2gKPiB0aGUgZmVuY2UgdG8gdGhl IHJlc3Ygb2JqZWN0cyBhbmQgKG9wdGlvbmFsbHksIHNwZWNpZmllZCBieSBhbiBzdWJtaXQKPiBp b2N0bCBmbGFnKSByZXR1cm4gYSBmZW5jZSBmZC4gIFRoZSBvdGhlciBvcHRpb24gaXMgdG8gYWRk IGEgbmV3IGlvY3RsCj4gdG8gY29udmVydCBhbiBpbnRlcm5hbCBwZXItcmluZyBmZW5jZS9zZXFu byAodGhhdCBpcyBhbHJlYWR5IHJldHVybmVkCj4gYnkgc3VibWl0IGlvY3RsKSB0byBhIGZlbmNl IGZkLi4gYnV0IEkgdGhpbmsgdGhhdCB3b3VsZCBlbmQgdXAgd2l0aAo+IGR1cGxpY2F0ZSAnc3Ry dWN0IGZlbmNlJyBvYmplY3RzIG9uIHRoZSBrZXJuZWwgc2lkZSAobm90IHN1cmUgaWYgdGhhdAoK SSB0aGluayB0aGUgcHJvYmxlbSBpcyBub3QgdGhhdCBrZXJuZWwganVzdCBrZWVwcyBkdXBsaWNh dGUgZmVuY2Ugb2JqZWN0cyBzZXBhcmF0ZWx5IGJ1dCBpcyB0aGF0IHRoZXNlIGZlbmNlcyBjYW4g YmUgcGVyZm9ybWVkIHNlcGFyYXRlbHkgZm9yIHNhbWUgcHVycG9zZS4KCj4gd291bGQgY2F1c2Ug aXNzdWVzIHNvbWVob3cpLCBhbmQgbWlnaHQgYmUgdW5uZWVkZWQgc2luY2Ugd2l0aAo+IEVHTF9B TkRST0lEX25hdGl2ZV9mZW5jZV9zeW5jIHNpbmNlIHdlIHNob3VsZCBrbm93IGJlZm9yZSBnbEZs dXNoKCkgaXMKPiBjYWxsZWQgd2hldGhlciB3ZSB3YW50IGFuIGZkIG9yIG5vdC4gIEJ1dCBtYWlu IHRoaW5nIEknbSBwb25kZXJpbmcKClNvIEkgdGhpbmsgdGhpcyBpcyBub3QgdXNlci1zcGFjZSBp c3N1ZS4gQWxsIHVzZXJzIGRvbid0IGhhdmUgdG8ga25vdyB3aGV0aGVyIERNQSBkcml2ZXJzIHN1 cHBvcnQgaW1wbGljaXQgZmVuY2Ugb3Igbm90IHNvIGFzIHNvb24gYXMgdXNlciB1c2VzIGV4cGxp Y2l0IGZlbmNlLCB0aGUgZHVwbGljYXRpb24gd291bGQgaGFwcGVuLgoKVGhlcmUgbWF5IGJlIHNv bWV0aGluZyBJIG1pc3NlZCBzbyB5b3VyIGNvbW1lbnQgd291bGQgYmUgaGVscGZ1bCBpbiB1bmRl cnN0YW5kaW5nIGl0LgoKClRoYW5rcywKSW5raSBEYWUKCj4gaGVyZSBpcyBob3cgdG8gc2FuZWx5 IHN1cHBvcnQgdGhlIG9sZCB3YXkgb2YgdXNlcnNwYWNlIGdsIGRyaXZlcgo+IGludGVybmFsIHN5 bmNocm9uaXphdGlvbiB3aXRoIG5ldyB1c2Vyc3BhY2Ugb24gb2xkIGtlcm5lbCwgYnV0IGFsc28K PiBjb25kaXRpb25hbGx5IHN1cHBvcnQgRUdMX0FORFJPSURfbmF0aXZlX2ZlbmNlX3N5bmMgaWYg eW91IGhhdmUgYSBuZXcKPiBlbm91Z2gga2VybmVsLgo+IAo+IEJSLAo+IC1SCj4gCj4gCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWls aW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZy ZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753847AbcCaHpu (ORCPT ); Thu, 31 Mar 2016 03:45:50 -0400 Received: from mailout2.samsung.com ([203.254.224.25]:39050 "EHLO mailout2.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751418AbcCaHps (ORCPT ); Thu, 31 Mar 2016 03:45:48 -0400 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 X-AuditID: cbfee690-f79e56d0000012c4-bd-56fcd5a348ce Content-transfer-encoding: 8BIT Message-id: <56FCD5A3.4040700@samsung.com> Date: Thu, 31 Mar 2016 16:45:39 +0900 From: Inki Dae User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 To: Rob Clark Cc: Daniel Stone , 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> In-reply-to: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBIsWRmVeSWpSXmKPExsWyRsSkSHfx1T9hBu+e6li8/3ufzWLhw7vM Fldap7NaXPn6ns3i0+pWdotJTx+wWVzeNYfN4vWmv4wWzxf+YHbg9Ni2exurx9/n11k89n5b wOLx4us2Zo+ds+6yeyze85LJ4373cSaPz5vkAjiiuGxSUnMyy1KL9O0SuDIabrQyFvRKV2yY +oOlgfGTaBcjB4eEgInE7geRXYycQKaYxIV769m6GLk4hARWMEp83fCeCSJhIrFtw28miMQs RomHP5tYQBK8AoISPybfYwEZxCwgL3HkUjaEqS4xZUouSIWQwANGidV3+CGqtSS+LdjEDGKz CKhKvHnTzwhiswHZE1fcZwNpFRWIkOg+UQkSFhFQlli1dT8LyFZmgRnMEsvnngI7R1jAXKL3 YScrxDmrWCRmTb7ACpLgFAiWmLG7DewBCYG/7BItU/6yQmwTkPg2+RALxMOyEpsOMEP8JSlx cMUNlgmMYrOQfDML4ZtZCN8sYGRexSiaWpBcUJyUXmSiV5yYW1yal66XnJ+7iREYoaf/PZuw g/HeAetDjAIcjEo8vBppf8KEWBPLiitzDzGaAt0wkVlKNDkfmAbySuINjc2MLExNTI2NzC3N lMR5X0v9DBYSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAWHqFre3uxpWfZwv+T17E9vImq+5y sQxtcdlbjHeKWln/fNX7nR/8aE2/ysZbt9691leZwRm1ZnuJnW7yud3vnZqPlaUmbTlReKEz dvbJe6fk5VwLvkbYzXt9yzTYu+vjf5Nvj2Wss2zk8nKei1/Y3ShQrptUvfqxqh7zg90dX6Qb tlXGxGX8UGIpzkg01GIuKk4EACsYRGLLAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42I5/e+xoO7iq3/CDJomq1u8/3ufzWLhw7vM Fldap7NaXPn6ns3i0+pWdotJTx+wWVzeNYfN4vWmv4wWzxf+YHbg9Ni2exurx9/n11k89n5b wOLx4us2Zo+ds+6yeyze85LJ4373cSaPz5vkAjiiGhhtMlITU1KLFFLzkvNTMvPSbZW8g+Od 403NDAx1DS0tzJUU8hJzU22VXHwCdN0yc4AOVFIoS8wpBQoFJBYXK+nbYZoQGuKmawHTGKHr GxIE12NkgAYS1jBmNNxoZSzola7YMPUHSwPjJ9EuRk4OCQETiW0bfjNB2GISF+6tZ+ti5OIQ EpjFKPHwZxMLSIJXQFDix+R7QDYHB7OAvMSRS9kQprrElCm5IBVCAg8YJVbf4Yeo1pL4tmAT M4jNIqAq8eZNPyOIzQZkT1xxnw2kVVQgQqL7RCVIWERAWWLV1v0sIFuZBWYwSyyfewrsHGEB c4neh52sEOesYpGYNfkCK0iCUyBYYsbuNrYJjEBHIlw3C+G6WQjXLWBkXsUokVqQXFCclJ5r lJdarlecmFtcmpeul5yfu4kRnAaeSe9gPLzL/RCjAAejEg/vheQ/YUKsiWXFlbmHGCU4mJVE eNuvAIV4UxIrq1KL8uOLSnNSiw8xmgL9N5FZSjQ5H5ii8kriDY1NzIwsjcwNLYyMzZXEeR// XxcmJJCeWJKanZpakFoE08fEwSnVwKijb/Al9unfypyqWx7ORibrr+/dKrc1cfOBX3KeSnsm ORlUHXudwPLz9+wZL6ctk9u+a8vR8ATvZ/cuMN+WszPa1O95XSjAIFymk/Xa2xunt0938egw 3+ay54Iu581mVZYZlqlKiZ3VybJlb9ttNVjNNYT71r3YYfn0Qa9kedLuP0bsq1eFciixFGck GmoxFxUnAgDIoIyaGQMAAA== 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 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. 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. > > On the gpu/producer side, I think what makes sense is to both attach > the fence to the resv objects and (optionally, specified by an submit > ioctl flag) return a fence fd. The other option is to add a new ioctl > to convert an internal per-ring fence/seqno (that is already returned > by submit ioctl) to a fence fd.. but I think that would end up with > duplicate 'struct fence' objects on the kernel side (not sure if that I think the problem is not that kernel just keeps duplicate fence objects separately but is that these fences can be performed separately for same purpose. > would cause issues somehow), and might be unneeded since with > EGL_ANDROID_native_fence_sync since we should know before glFlush() is > called whether we want an fd or not. But main thing I'm pondering So I think this is not user-space issue. All users don't have to know whether DMA drivers support implicit fence or not so as soon as user uses explicit fence, the duplication would happen. There may be something I missed so your comment would be helpful in understanding it. Thanks, Inki Dae > here is how to sanely support the old way of userspace gl driver > internal synchronization with new userspace on old kernel, but also > conditionally support EGL_ANDROID_native_fence_sync if you have a new > enough kernel. > > BR, > -R > >