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: Fri, 25 Mar 2016 08:03:57 +0900 Message-ID: <56F4725D.6040501@samsung.com> References: <1458758847-21170-1-git-send-email-gustavo@padovan.org> <56F3A2DC.8080507@samsung.com> <20160324143913.GB4781@joana> 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 22DD16E182 for ; Thu, 24 Mar 2016 23:04:00 +0000 (UTC) Received: from epcpsbgr3.samsung.com (u143.gpu120.samsung.co.kr [203.254.230.143]) by mailout1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0O4K02DDUG2MSB80@mailout1.samsung.com> for dri-devel@lists.freedesktop.org; Fri, 25 Mar 2016 08:03:58 +0900 (KST) In-reply-to: <20160324143913.GB4781@joana> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Gustavo Padovan , dri-devel@lists.freedesktop.org, Daniel Stone , Daniel Vetter , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , linux-kernel@vger.kernel.org, Riley Andrews , Gustavo Padovan , John Harrison List-Id: dri-devel@lists.freedesktop.org SGkgR3Vlc3Rhdm8sCgoyMDE264WEIDAz7JuUIDI07J28IDIzOjM57JeQIEd1c3Rhdm8gUGFkb3Zh biDsnbQo6rCAKSDsk7Qg6riAOgo+IEhpIElua2ksCj4gCj4gMjAxNi0wMy0yNCBJbmtpIERhZSA8 aW5raS5kYWVAc2Ftc3VuZy5jb20+Ogo+IAo+PiBIaSwKPj4KPj4gMjAxNuuFhCAwM+yblCAyNOyd vCAwMzo0N+yXkCBHdXN0YXZvIFBhZG92YW4g7J20KOqwgCkg7JO0IOq4gDoKPj4+IEZyb206IEd1 c3Rhdm8gUGFkb3ZhbiA8Z3VzdGF2by5wYWRvdmFuQGNvbGxhYm9yYS5jby51az4KPj4+Cj4+PiBI aSwKPj4+Cj4+PiBUaGlzIGlzIGEgZmlyc3QgcHJvcG9zYWwgdG8gZGlzY3VzcyB0aGUgYWRkaXRp b24gb2YgaW4tZmVuY2VzIHN1cHBvcnQKPj4+IHRvIERSTS4gSXQgYWRkcyBhIG5ldyBzdHJ1Y3Qg dG8gZmVuY2UuYyB0byBhYnN0cmFjdCB0aGUgdXNlIG9mIHN5bmNfZmlsZQo+Pj4gaW4gRFJNIGRy aXZlcnMuIFRoZSBuZXcgc3RydWN0IGZlbmNlX2NvbGxlY3Rpb24gY29udGFpbnMgYSBhcnJheSB3 aXRoIGFsbAo+Pj4gZmVuY2VzIHRoYXQgYSBhdG9taWMgY29tbWl0IG5lZWRzIHRvIHdhaXQgb24K Pj4KPj4gQXMgSSBtZW50aW9uZWQgYWxyZWFkeSBsaWtlIGJlbG93LAo+PiBodHRwOi8vd3d3LnNw aW5pY3MubmV0L2xpc3RzL2RyaS1kZXZlbC9tc2cxMDMyMjUuaHRtbAo+Pgo+PiBJIGRvbid0IHNl ZSB3aHkgQW5kcm9pZCBzcGVjaWZpYyB0aGluZyBpcyB0cmllZCB0byBwcm9wYWdhdGUgdG8gTGlu dXggRFJNLiBJbiBMaW51eCBtYWlubGluZSwgaXQgaGFzIGFscmVhZHkgaW1wbGljaXQgc3luYyBp bnRlcmZhY2VzIGZvciBETUEgZGV2aWNlcyBjYWxsZWQgZG1hIGZlbmNlIHdoaWNoIGZvcmNlcyBy ZWdpc3RlcmluZyBhIGZlbmNlIG9iZWpjdCB0byBETUFCVUYgdGhyb3VnaCBhIHJlc2VydmF0aW9u IG9iZWpjdCB3aGVuIGEgZG1hYnVmIG9iamVjdCBpcyBjcmVhdGVkLiBIb3dldmVyLCBBbmRyb2lk IHN5bmMgZHJpdmVyIGNyZWF0ZXMgYSBuZXcgZmlsZSBmb3IgYSBzeW5jIG9iamVjdCBhbmQgdGhp cyB3b3VsZCBoYXZlIGRpZmZlcmVudCBwb2ludCBvZiB2aWV3Lgo+Pgo+PiBJcyB0aGVyZSBhbnlv bmUgd2hvIGNhbiBleHBsYW4gd2h5IEFuZHJvaWQgc3BlY2lmaWMgdGhpbmcgaXMgdHJpZWQgdG8g c3ByZWFkIGludG8gTGludXggRFJNPyBXYXMgdGhlcmUgYW55IGNvbnNlbnN1cyB0byB1c2UgQW5k cm9pZCBzeW5jIGRyaXZlciAtIHdoaWNoIHVzZXMgZXhwbGljaXQgc3luYyBpbnRlcmZhY2VzIC0g YXMgTGludXggc3RhbmRhcmQ/Cj4gCj4gQmVjYXVzZSB3ZSB3YW50IGV4cGxpY2l0IGZlbmNpbmcg YXMgdGhlIExpbnV4IHN0YW5kYXJkIGluIHRoZSBmdXR1cmUgdG8KPiBiZSBhYmxlIHRvIGRvIHNt YXJ0IHNjaGVkdWxpbmcsIGUuZy4sIHNlbmQgYXN5bmMgam9icyB0byB0aGUgZ3B1IGFuZCBhdAo+ IHRoZSBzYW1lIHRpbWUgc2VuZCBhc3luYyBhdG9taWMgY29tbWl0cyB3aXRoIHN5bmNfZmlsZSBm ZCBhdHRhY2hlZCBzbwo+IHRoZXkgY2FuIHdhaXQgdGhlIEdQVSB0byBmaW5pc2ggYW5kIHdlIGRv bid0IGJsb2NrIGluIHVzZXJzcGFjZSBhbnltb3JlLAo+IHF1aXRlIHNpbWlsYXIgdG8gd2hhdCBB bmRyb2lkIGRvZXMuCgpHUFUgaXMgYWxzbyBETUEgZGV2aWNlIHNvIEkgdGhpbmsgdGhlIHN5bmNo b25pemF0aW9uIHNob3VsZCBiZSBoYW5kbGVkIHRyYW5zcGFyZW50IHRvIHVzZXItc3BhY2UuCkFu ZCBJIGtub3cgdGhhdCBDaHJvbWl1bSBndXkgYWxyZWFkeSBkaWQgc2ltaWxhciB0aGluZyB3aXRo IG5vbi1hdG9taWMgY29tbWl0IG9ubHkgdXNpbmcgaW1wbGljaXQgc3luYywKaHR0cHM6Ly9jaHJv bWl1bS5nb29nbGVzb3VyY2UuY29tL2Nocm9taXVtb3MvdGhpcmRfcGFydHkva2VybmVsCmJyYW5j aCBuYW1lIDogY2hyb21lb3MtMy4xNAoKT2YgY291cnNlLCB0aGlzIGFwcHJvYWNoIHVzZXMgYSBu ZXcgaGVscGVyIGZyYW1ld29yayBwbGFjZWQgaW4gZHJtIGRpcmVjdG9yeSBzbyBJIHRoaW5rIGlm IHRoaXMgZnJhbWV3b3JrIGNhbiBiZSBtb3ZlZCBpbnRvIGRtYS1idWYgZGlyZWN0b3J5IGFmdGVy IHNvbWUgY2xlYW51cCBhbmQgcmVmYWN0b3JpbmcgdGhlbSBpZiBuZWNlc3NhcnkuCkFueXdheSwg SSdtIG5vdCBzdXJlIEkgdW5kZXJzdG9vZCB0aGUgc21hcnQgc2NoZWR1bGluZyB5b3UgbWVudGlv bmVkIGJ1dCBJIHRoaW5rIHdlIGNvdWxkIGRvIHdoYXQgeW91IHRyeSB0byBkbyB3aXRob3V0IHRo ZSBleHBsaWNpdCBmZW5jZS4KCj4gCj4gVGhpcyB3b3VsZCBzdGlsbCB1c2UgZG1hLWJ1ZiBmZW5j ZXMgaW4gdGhlIGRyaXZlciBsZXZlbCwgYnV0IGl0IGhhcyBhCj4gbG90IG1vcmUgYWR2YW50YWdl cyB0aGFuIGltcGxpY2l0IGZlbmNpbmcuCgpZb3UgbWVhbnMgdGhpbmdzIGZvciByZW5kZXJpbmcg cGlwZWxpbmUgZGVidWdnaW5nIGFuZCBtZXJnaW5nIHN5bmMgZmVuY2VzPwoKVGhhbmtzLApJbmtp IERhZQoKPiAKPiAJR3VzdGF2bwo+IAo+IApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5m cmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0 aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751499AbcCXXEE (ORCPT ); Thu, 24 Mar 2016 19:04:04 -0400 Received: from mailout1.samsung.com ([203.254.224.24]:35171 "EHLO mailout1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750870AbcCXXEC (ORCPT ); Thu, 24 Mar 2016 19:04:02 -0400 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 X-AuditID: cbfee68f-f793a6d000001364-85-56f4725e7269 Content-transfer-encoding: 8BIT Message-id: <56F4725D.6040501@samsung.com> Date: Fri, 25 Mar 2016 08:03:57 +0900 From: Inki Dae User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 To: Gustavo Padovan , dri-devel@lists.freedesktop.org, Daniel Stone , Daniel Vetter , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , linux-kernel@vger.kernel.org, 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> <20160324143913.GB4781@joana> In-reply-to: <20160324143913.GB4781@joana> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsWyRsSkWDeu6EuYwa5uNov3f++zWSx8eJfZ YlP/VnaLK1/fs1l8Wt3KbrHzwS52i0lPH7BZXN41h83i9aa/jA6cHtt2b2P1+Pv8OovHjrtL GD32flvA4rF4z0smj/vdx5k8dk7ay+TxeZNcAEcUl01Kak5mWWqRvl0CV0b7tT3MBY+EK5Z+ m8LawPiXv4uRk0NCwETixuzbTBC2mMSFe+vZuhi5OIQEVjBKzNl0gaWLkQOs6GGXCkR8FqPE tk0tzCANvAKCEj8m3wOrYRaQlzhyKRvCVJeYMiUXpEJI4AGjRNeXOohqLYlzzz6zg9gsAqoS D7bcZQWx2YDsiSvus4G0igpESHSfqATZJCLwj0ni5crjLCA1wgLmEr0PO1khTmhilNjzaT1Y ghNo6OzNf1lAEhICb9klHq5ZxASxQUDi2+RDUPfLSmw6wAzxo6TEwRU3WCYwis5C8sEshA9m IXywgJF5FaNoakFyQXFSepGxXnFibnFpXrpecn7uJkZgJJ7+96x/B+PdA9aHGAU4GJV4eB3c v4QJsSaWFVfmHmI0BbphIrOUaHI+MN7zSuINjc2MLExNTI2NzC3NlMR5F0r9DBYSSE8sSc1O TS1ILYovKs1JLT7EyMTBKdXAKL9rHvtHh1l+x0sM9379PaUr+v3jdik2NuPHEz2/Vm4Pnn3A YvERz8vJz/MVq/1UFs8qVpqzeKJf5tsHZz3FVI+L/Z1d9nVV2+zPU55WL/KV+JD5zipvy+Tv 3BsYrknJzKuW/9c9v/vRFc0Gsw2CeUVXxbaelp/2MfkGk2Xny/lZynq/N3S9W6rEUpyRaKjF XFScCAABrG6yvwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsVy+t9jQd24oi9hBjP1LN7/vc9msfDhXWaL Tf1b2S2ufH3PZvFpdSu7xc4Hu9gtJj19wGZxedccNovXm/4yOnB6bNu9jdXj7/PrLB477i5h 9Nj7bQGLx+I9L5k87ncfZ/LYOWkvk8fnTXIBHFENjDYZqYkpqUUKqXnJ+SmZeem2St7B8c7x pmYGhrqGlhbmSgp5ibmptkouPgG6bpk5QPcpKZQl5pQChQISi4uV9O0wTQgNcdO1gGmM0PUN CYLrMTJAAwlrGDPar+1hLngkXLH02xTWBsa//F2MHBwSAiYSD7tUuhg5gUwxiQv31rN1MXJx CAnMYpTYtqmFGSTBKyAo8WPyPRaQemYBeYkjl7IhTHWJKVNyQSqEBB4wSnR9qYOo1pI49+wz O4jNIqAq8WDLXVYQmw3InrjiPhtIq6hAhET3iUqQTSIC/5gkXq48zgJSIyxgLtH7sJMV4oQm Rok9n9aDJTiBhs7e/JdlAiP/LCQXzUK4aBbCRQsYmVcxSqQWJBcUJ6XnGuWllusVJ+YWl+al 6yXn525iBMf6M+kdjId3uR9iFOBgVOLhfeHyJUyINbGsuDL3EKMEB7OSCK9WNFCINyWxsiq1 KD++qDQntfgQoynQTxOZpUST84FpKK8k3tDYxMzI0sjc0MLI2FxJnPfx/3VhQgLpiSWp2amp BalFMH1MHJxSDYwWCh2Xt4poF10Jf/flT8GVtLt/A44nmd7fG3SH75fPNbn1Ezj8J/Vmxu27 nfS7aHa+45kDNzb+7mZ/Oueq3W6u718eaf5IeZcsuEc1a/OkBUemCcSa+WdNsr63pbTmy6eb avNXbVz3d7PoM35l2fK0Nwu9fs4VZJDfJGrr1nuhxapti//9UNlnSizFGYmGWsxFxYkARgde KQsDAAA= 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 Guestavo, 2016년 03월 24일 23:39에 Gustavo Padovan 이(가) 쓴 글: > Hi Inki, > > 2016-03-24 Inki Dae : > >> Hi, >> >> 2016년 03월 24일 03:47에 Gustavo Padovan 이(가) 쓴 글: >>> From: Gustavo Padovan >>> >>> Hi, >>> >>> This is a first proposal to discuss the addition of in-fences support >>> to DRM. It adds a new struct to fence.c to abstract the use of sync_file >>> in DRM drivers. The new struct fence_collection contains a array with all >>> fences that a atomic commit needs to wait on >> >> As I mentioned already like below, >> http://www.spinics.net/lists/dri-devel/msg103225.html >> >> I don't see why Android specific thing is tried to propagate to Linux DRM. In Linux mainline, it has already implicit sync interfaces for DMA devices called dma fence which forces registering a fence obejct to DMABUF through a reservation obejct when a dmabuf object is created. However, Android sync driver creates a new file for a sync object and this would have different point of view. >> >> Is there anyone who can explan why Android specific thing is tried to spread into Linux DRM? Was there any consensus to use Android sync driver - which uses explicit sync interfaces - as Linux standard? > > Because we want explicit fencing as the Linux standard in the future to > be able to do smart scheduling, e.g., send async jobs to the gpu and at > the same time send async atomic commits with sync_file fd attached so > they can wait the GPU to finish and we don't block in userspace anymore, > quite similar to what Android does. GPU is also DMA device so I think the synchonization should be handled transparent to user-space. And I know that Chromium guy already did similar thing with non-atomic commit only using implicit sync, https://chromium.googlesource.com/chromiumos/third_party/kernel branch name : chromeos-3.14 Of course, this approach uses a new helper framework placed in drm directory so I think if this framework can be moved into dma-buf directory after some cleanup and refactoring them if necessary. Anyway, I'm not sure I understood the smart scheduling you mentioned but I think we could do what you try to do without the explicit fence. > > This would still use dma-buf fences in the driver level, but it has a > lot more advantages than implicit fencing. You means things for rendering pipeline debugging and merging sync fences? Thanks, Inki Dae > > Gustavo > >