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: Mon, 28 Mar 2016 10:26:00 +0900 Message-ID: <56F88828.5050304@samsung.com> References: <1458758847-21170-1-git-send-email-gustavo@padovan.org> <56F3A2DC.8080507@samsung.com> <56F47D01.7040508@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mailout4.samsung.com (mailout4.samsung.com [203.254.224.34]) by gabe.freedesktop.org (Postfix) with ESMTPS id 006D36E370 for ; Mon, 28 Mar 2016 01:26:03 +0000 (UTC) Received: from epcpsbgr1.samsung.com (u141.gpu120.samsung.co.kr [203.254.230.141]) by mailout4.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0O4Q01EXX6NC7260@mailout4.samsung.com> for dri-devel@lists.freedesktop.org; Mon, 28 Mar 2016 10:26:00 +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 , 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 SGkgUm9iIGFuZCBEYW5pZWwsCgoyMDE264WEIDAz7JuUIDI17J28IDIxOjEw7JeQIERhbmllbCBT dG9uZSDsnbQo6rCAKSDsk7Qg6riAOgo+IEhpIGFsbCwKPiAKPiBPbiAyNSBNYXJjaCAyMDE2IGF0 IDExOjU4LCBSb2IgQ2xhcmsgPHJvYmRjbGFya0BnbWFpbC5jb20+IHdyb3RlOgo+PiBPbiBUaHUs IE1hciAyNCwgMjAxNiBhdCA3OjQ5IFBNLCBJbmtpIERhZSA8aW5raS5kYWVAc2Ftc3VuZy5jb20+ IHdyb3RlOgo+Pj4gSXQncyBkZWZpbml0ZWx5IGRpZmZlcmVudCBjYXNlLiBUaGlzIHRyaWVzIHRv IGFkZCBuZXcgdXNlci1zcGFjZSBpbnRlcmZhY2VzIHRvIGV4cG9zZSBmZW5jZXMgdG8gdXNlci1z cGFjZS4gQXQgbGVhc3QsIGltcGxpY2l0IGludGVyZmFjZXMgYXJlIGVtYmVkZGVkIGludG8gZHJp dmVycy4KPj4+IFNvIEknZCBsaWtlIHRvIGdpdmUgeW91IGEgcXVlc3Rpb24uIFdoeSBleHBvc2lu ZyBmZW5jZXMgdG8gdXNlci1zcGFjZSBpcyByZXF1aXJlZD8gVG8gcHJvdmlkZSBlYXN5LXRvLWRl YnVnIHNvbHV0aW9uIHRvIHJlbmRlcmluZyBwaXBsZWxpbmU/IFRvIHByb3ZpZGUgbWVyZ2UgZmVu Y2UgZmVhdHVyZT8KPj4KPj4gV2VsbCwgaW1wbGljaXQgc3luYyBhbmQgZXhwbGljaXQgc3luYyBh cmUgdHdvIGRpZmZlcmVudCBjYXNlcy4KPj4gSW1wbGljaXQgc3luYyBvZmMgcmVtYWlucyB0aGUg ZGVmYXVsdCwgYnV0IHVzZXJzcGFjZSBjb3VsZCBvcHQtaW4gdG8KPj4gZXhwbGljaXQgc3luYyBp bnN0ZWFkLiAgRm9yIGV4YW1wbGUsIG9uIHRoZSBncHUgc2lkZSBvZiB0aGluZ3MsCj4+IGRlcGVu ZGluZyBvbiBmbGFncyB1c2Vyc3BhY2UgcGFzc2VzIGluIHRvIHRoZSBzdWJtaXQgaW9jdGwgd2Ug d291bGQKPj4gZWl0aGVyIGF0dGFjaCB0aGUgZmVuY2UgdG8gYWxsIHRoZSB3cml0dGVuIGJ1ZmZl cnMgKGltcGxpY2l0KSBvcgo+PiByZXR1cm4gaXQgYXMgYSBmZW5jZSBmZCB0byB1c2Vyc3BhY2Ug KGV4cGxpY2l0KSwgd2hpY2ggdXNlcnNwYWNlIGNvdWxkCj4+IHRoZW4gcGFzcyBpbiB0byBhdG9t aWMgaW9jdGwgdG8gc3luY2hyb25pemUgcGFnZWZsaXAuCj4+Cj4+IEFuZCB2aXNhLXZlcnNhLCB3 ZSBjYW4gcGFzcyB0aGUgcGFnZWZsaXAgKGF0b21pYykgY29tcGxldGlvbiBmZW5jZQo+PiBiYWNr IGluIHRvIGdwdSBzbyBpdCBkb2Vzbid0IHN0YXJ0IHJlbmRlcmluZyB0aGUgbmV4dCBmcmFtZSB1 bnRpbCB0aGUKPj4gYnVmZmVyIGlzIG9mZiBzY3JlZW4uCj4+Cj4+IGZ3aXcsIGN1cnJlbnRseSBh bmRyb2lkIGlzIHRoZSBmaXJzdCB1c2VyIG9mIGV4cGxpY2l0IHN5bmMgKGFsdGhvdWdoIEkKPj4g ZXhwZWN0IHdheWxhbmQvd2VzdG9uIHRvIGZvbGxvdyBzdWl0KS4KPiAKPiBTZWNvbmQsIHJlYWxs eS4gVnVsa2FuIGF2b2lkcyBpbXBsaWNpdCBzeW5jIGVudGlyZWx5LCBhbmQgZXhwb3Nlcwo+IGZl bmNlLWxpa2UgcHJpbWl0aXZlcyB0aHJvdWdob3V0IGl0cyB3aG9sZSBBUEkuIFRoZXNlIGluY2x1 ZGUgYmVpbmcKPiBhYmxlIHRvIHBhc3MgcHJlcmVxdWlzaXRlIGZlbmNlcyBmb3IgZGlzcGxheSAo d2hhdCBHdXN0YXZvIGlzIGFkZGluZwo+IGhlcmU6IHNvbWV0aGluZyB0byBibG9jayBvbiBiZWZv cmUgZGlzcGxheSksIGFuZCBhbHNvIHdoZW4gdGhlIHVzZXIKPiBhY3F1aXJlcyBhIGJ1ZmZlciBh cyBhIHJlbmRlciB0YXJnZXQsIGl0IGlzIGdpdmVuIGFub3RoZXIgcHJlcmVxdWlzaXRlCj4gZmVu Y2UgKHRoZSBvdGhlciBzaWRlIG9mIHdoYXQgR3VzdGF2byBpcyBzdWdnZXN0aW5nLCBpLmUuIHRo ZSBmZW5jZQo+IHRyaWdnZXJzIHdoZW4gdGhlIGJ1ZmZlciBpcyBubyBsb25nZXIgZGlzcGxheWVk IGFuZCBiZWNvbWVzIGF2YWlsYWJsZQo+IGZvciByZW5kZXJpbmcpLgo+IAo+IEluIG9yZGVyIHRv IGltcGxlbWVudCB0aGlzIGNvcnJlY3RseSwgYW5kIGF2b2lkIHBlcmZvcm1hbmNlIGJ1YmJsZXMs Cj4gd2UgbmVlZCBhIHByaW1pdGl2ZSBsaWtlIHRoaXMgZXhwb3NlZCB0aHJvdWdoIHRoZSBLTVMg QVBJLCBmcm9tIGJvdGgKPiBzaWRlcy4gVGhpcyBpcyBlc3BlY2lhbGx5IGltcG9ydGFudCB3aGVu IHlvdSB0YWtlIHRoZSBjYXNlIG9mCj4gdXNlcnNwYWNlIHN1YmFsbG9jYXRpb24sIHdoZXJlIHVz ZXJzcGFjZSBhbGxvY2F0ZXMgbGFyZ2VyIGJsb2NrcyBhbmQKPiBkaXZpZGVzIHRoZSBhbGxvY2F0 aW9uIGludGVybmFsbHkgZm9yIGRpZmZlcmVudCB1c2VzLiBJbXBsaWNpdCBzeW5jCj4gZG9lcyBu b3Qgd29yayBhdCBhbGwgZm9yIHRoYXQgY2FzZS4KCkNhbiB5b3UgZ2l2ZSBtZSBtb3JlIGRldGFp bHMgd2h5IGltcGxpY2l0IHN5bmMgY2Fubm90IHRha2UgY2FyZSBvZiB0aGUgY2FzZSBvZiB1c2Vy c3BhY2Ugc3ViYWxsb2NhdGlvbj8KQW5kIGlzIHRoZXJlIGFueSByZWFzb24gdGhhdCBmZW5jZSBm ZCBzaG91bGRuJ3QgZGVwZW5kZW50IG9mIERNQUJVRiAtIG5vdyBmZW5jZSBmZCBpcyBhIG5ldyBm aWxlLCBub3QgRE1BQlVGIGZkPwoKPiAKPiBBcyBzdGF0ZWQgYmVmb3JlLCB0aGVyZSBhcmUgb3Ro ZXIgYmVuZWZpdHMsIGluY2x1ZGluZyBtdWNoIGJldHRlcgo+IHRyYWNlYWJpbGl0eS4gSSB3b3Vs ZCBleHBlY3QgV2F5bGFuZC9XZXN0b24gdG8gYWxzbyBzdGFydCBwdXNoaW5nCj4gc3VwcG9ydCBm b3IgdGhpcyBBUEkgcmVsYXRpdmVseSBzb29uLgo+IAo+PiBBIGNvdXBsZSBsaW5hcm8gZm9sa3Mg aGF2ZQo+PiBhbmRyb2lkIHJ1bm5pbmcgd2l0aCBhbiB1cHN0cmVhbSBrZXJuZWwgKyBtZXNhICsg YXRvbWljL2ttcyBod2Mgb24gYQo+PiBjb3VwbGUgZGV2aWNlcyAobmV4dXM3IGFuZCBkYjQxMGMg d2l0aCBmcmVlZHJlbm8sIGFuZCBxZW11IHdpdGgKPj4gdmlyZ2wpLiAgQnV0IHRoZXJlIGFyZSBz b21lIGxpbWl0YXRpb25zIGR1ZSB0byBtaXNzaW5nIHRoZQo+PiBFR0xfQU5EUk9JRF9uYXRpdmVf ZmVuY2Vfc3luYyBleHRlbnNpb24gaW4gbWVzYS4gIEkgcGxhbiB0byBpbXBsZW1lbnQKPj4gdGhh dCwgYnV0IEkgb2ZjIG5lZWQgdGhlIGZlbmNlIGZkIHN0dWZmIGluIG9yZGVyIHRvIGRvIHNvIDst KQo+IAo+IFllcywgaGF2aW5nIHRoYXQgd291bGQgYmUgYSBnb2RzZW5kIGZvciBhIGxvdCBvZiBw ZW9wbGUuCj4gCj4+PiBBbmQgaWYgd2UgbmVlZCByZWFsbHkgdG8gZXhwb3NlIGZlbmNlcyB0byB1 c2VyLXNwYWNlIGFuZCB0aGVyZSBpcyByZWFsbHkgcmVhbCB1c2VyLCB0aGVuIHdlIGhhdmUgYWxy ZWFkeSBnb29kIGNhbmRpZGF0ZXMsIERNQS1CVUYtSU9DVEwtU1lOQyBvciBtYXliZSBmY250bCBz eXN0ZW0gY2FsbCBiZWNhdXNlIHdlIHNoYXJlIGFscmVhZHkgRE1BIGJ1ZmZlciBiZXR3ZWVuIENQ VSA8LT4gRE1BIGFuZCBETUEgPC0+IERNQSB1c2luZyBETUFCVUYuCj4+PiBGb3IgRE1BLUJVRi1J T0NUTC1TWU5DLCBJIHRoaW5rIHlvdSByZW1lbWJlciB0aGF0IHdhcyB3aGF0IEkgdHJpZWQgbG9u ZyB0aW1lIGFnbyBiZWNhdXNlIHlvdSB3YXMgdGhlcmUuIFNldmVyYWwgeWVhcnMgYWdvLCBJIHRy aWVkIHRvIGNvdXBsZSBleHBvc2luZyB0aGUgZmVuY2VzIHRvIHVzZXItc3BhY2Ugd2l0aCBjYWNo ZSBvcGVyYXRpb24gYWx0aG91Z2ggYXQgdGhhdCB0aW1lLCBJIHJlYWxseSBtaXNsZWFkZWQgdGhl IGZlbmNlIG1hY2huaXNtLiBNeSB0cnlpbmcgd2FzIGFsc28gZm9yIHRoZSBwb3RlbnRpYWwgdXNl cnMuCj4+Cj4+IE5vdGUgdGhhdCB0aGlzIGlzIG5vdCAoanVzdCkgYWJvdXQgc3cgc3luYywgYnV0 IGFsc28gc3luYyBiZXR3ZWVuCj4+IG11bHRpcGxlIGh3IGRldmljZXMuCj4gCj4gU3luYyBpc24n dCBxdWl0ZSBnb29kIGVub3VnaCwgYmVjYXVzZSBpdCdzIGEgbWFuZGF0b3J5IGJsb2NraW5nIHBv aW50Cj4gZm9yIHVzZXJzcGFjZS4gV2Ugd2FudCB0byBwdXNoIHRoZSBleHBsaWNpdCBmZW5jZXMg ZnVydGhlciBkb3duIHRoZQo+IGxpbmUsIHNvIHVzZXJzcGFjZSBjYW4gcGFyYWxsZWxpc2UgaXRz IHdvcmsuCj4gCj4gRXZlbiBpZiBub25lIG9mIHRoZSBhYm92ZSByZXF1aXJlbWVudHMgaGVsZCB0 cnVlLCBJIGRvbid0IHRoaW5rIGJlaW5nCj4gYWJsZSB0byBzdXBwb3J0IEFuZHJvaWQgaXMgYSBi YWQgdGhpbmcuIEl0J3MgY29tcGxldGVseSByaWdodCB0byBiZQo+IHdvcnJpZWQgYWJvdXQgcHVz aGluZyBpbiBBbmRyb2lkIHdvcmsgYW5kIEFQSXMgZm9yIHRoZSBzYWtlIG9mIGl0IC0KPiBoZW5j ZSB3aHkgd2UgZGlkbid0IHRha2UgQURGISAtIGJ1dCBpbiB0aGlzIGNhc2UgaXQncyBkZWZpbml0 ZWx5IGEKCkFzIGxlYXN0IEdvb2dsZSdzIEFERiBib29zdGVkIHVwIGF0b21pYyBLTVMuIDopIAoK PiBnb29kIHRoaW5nLiBUaGlzIGlzIGFsc28gdGhlIG1vZGVsIHRoYXQgQ2hyb21lT1MgaXMgbW92 aW5nIHRvd2FyZHMsIHNvCj4gaXQgYmVjb21lcyBtb3JlIGltcG9ydGFudCBmcm9tIHRoYXQgcG9p bnQgb2YgdmlldyBhcyB3ZWxsLgoKSSB0aGluayBHdXN0YXZvIHNob3VsZCBoYWQgZXhwbGFuZWQg dGhpcyBwYXRoIHNlcmllcyBlbm91Z2ggdG8gb3RoZXIgcGVvcGxlIHdoZW4gcG9zdGluZyB0aGVt IC0gaWUsIHdoYXQgcmVsYXRpb25zaGlwIGV4cGxpY3QgYW5kIGltcGxpY2l0IGZlbmNlcyBoYXZl LCBhbmQgd2h5IGltcGxpY2l0IGZlbmNlIC0gd2hpY2ggaXMgaW5kZXBlbmRlbnQgb2YgRE1BQlVG IC0gaXMgcmVxdWlyZWQsIGFuZCB3aGF0IHVzZSBjYXNlcyB0aGVyZSBhcmUgaW4gcmVhbCB1c2Vy cywgYW5kIGV0Yy4KCgpUaGFua3MsCklua2kgRGFlCgo+IAo+IENoZWVycywKPiBEYW5pZWwKPiAK PiAKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRl dmVsIG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8v bGlzdHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753119AbcC1B0G (ORCPT ); Sun, 27 Mar 2016 21:26:06 -0400 Received: from mailout4.samsung.com ([203.254.224.34]:36607 "EHLO mailout4.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752516AbcC1B0E (ORCPT ); Sun, 27 Mar 2016 21:26:04 -0400 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 X-AuditID: cbfee68d-f79e86d0000012da-70-56f888280447 Content-transfer-encoding: 8BIT Message-id: <56F88828.5050304@samsung.com> Date: Mon, 28 Mar 2016 10:26:00 +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 , Rob Clark Cc: 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> In-reply-to: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBIsWRmVeSWpSXmKPExsWyRsSkSFej40eYQd8BOYv3f++zWSx8eJfZ 4krrdFaLK1/fs1l8Wt3KbjHp6QM2i8u75rBZvN70l9Hi+cIfzA6cHtt2b2P1+Pv8OovH3m8L WDxefN3G7LFz1l12j8V7XjJ53O8+zuTxeZNcAEcUl01Kak5mWWqRvl0CV8bcswuYCq6rVjT9 P87cwDhProuRk0NCwETiZPN5ZghbTOLCvfVsILaQwApGiRW/UrsYOcBq7s+Q6GLkAgovZZQ4 NG8HC0gNr4CgxI/J91hAapgF5CWOXMqGMNUlpkzJhSh/wChx70w/G0S5lsSjzn9MIDaLgKrE h20PwdayAdkTV9xnA+kVFYiQ6D5RCRIWEfCQeHGzkQlkDrPARyaJRzdfg/UKC5hL9D7sZIVY cItJ4urqK+wgCU6BYIm7bW/BOiQE/rJLzP9ymAVim4DEt8mHWCCekZXYdADqX0mJgytusExg FJuF5J1ZCO/MQnhnASPzKkbR1ILkguKk9CJDveLE3OLSvHS95PzcTYzACD3971nvDsbbB6wP MQpwMCrx8GZY/ggTYk0sK67MPcRoCnTDRGYp0eR8YBrIK4k3NDYzsjA1MTU2Mrc0UxLnVZT6 GSwkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsSjJ8ZRR7dNC0as2PVqFOrk1ZwWm36lvuF25 kk+2R/kBw4dzz54fjJ6+Q+/N9YmzsvhPX9if+/ul/QL29F6b+rLDGfmmfLylsn0/G3qzGFOm f837ujaTM7Zb1Xp1nqLZAi4Rdfnk9ccs9deHrzLl8GdhygoIfTYvpfjm7D1fMnjmfKkMuJej xFKckWioxVxUnAgAwgLQeMsCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42I5/e+xgK5Gx48wg23bJCze/73PZrHw4V1m iyut01ktrnx9z2bxaXUru8Wkpw/YLC7vmsNm8XrTX0aL5wt/MDtwemzbvY3V4+/z6ywee78t YPF48XUbs8fOWXfZPRbvecnkcb/7OJPH501yARxRDYw2GamJKalFCql5yfkpmXnptkrewfHO 8aZmBoa6hpYW5koKeYm5qbZKLj4Bum6ZOUAHKimUJeaUAoUCEouLlfTtME0IDXHTtYBpjND1 DQmC6zEyQAMJaxgz5p5dwFRwXbWi6f9x5gbGeXJdjBwcEgImEvdnSHQxcgKZYhIX7q1n62Lk 4hASWMoocWjeDhaQBK+AoMSPyfdYQOqZBeQljlzKhjDVJaZMyYUof8Aoce9MPxtEuZbEo85/ TCA2i4CqxIdtD5lBbDYge+KK+2wgvaICERLdJypBwiICHhIvbjYygcxhFvjIJPHo5muwXmEB c4neh52sEAtuMUlcXX2FHSTBKRAscbftLdMERoFZSM6bhXDeLITzFjAyr2KUSC1ILihOSs81 zEst1ytOzC0uzUvXS87P3cQITgPPpHYwHtzlfohRgINRiYc3w/JHmBBrYllxZe4hRgkOZiUR 3rVNQCHelMTKqtSi/Pii0pzU4kOMpkD/TWSWEk3OB6aovJJ4Q2MTMyNLI3NDCyNjcyVx3sf/ 14UJCaQnlqRmp6YWpBbB9DFxcEo1MHLMDlfaaaUi5imd57NUplRY4/vc2xxbP+SVb5m8guHk nZofs6K5KpRfcbpenypeOH+p7dQl172YfyzqnCUhMJH95aLpp5PrLOYLPegzFHh+YndO9c1v k45Lbun8xsBi/OBGT9YNbvZm89QDN3qlmiwvur39o9n1qpixvsta10U8KWHRjC0X7ymxFGck GmoxFxUnAgABbLE+GQMAAA== 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 Rob and Daniel, 2016년 03월 25일 21:10에 Daniel Stone 이(가) 쓴 글: > Hi all, > > On 25 March 2016 at 11:58, Rob Clark wrote: >> On Thu, Mar 24, 2016 at 7:49 PM, Inki Dae wrote: >>> It's definitely different case. This tries to add new user-space interfaces to expose fences to user-space. At least, implicit interfaces are embedded into drivers. >>> So I'd like to give you a question. Why exposing fences to user-space is required? To provide easy-to-debug solution to rendering pipleline? To provide merge fence feature? >> >> Well, implicit sync and explicit sync are two different cases. >> Implicit sync ofc remains the default, but userspace could opt-in to >> explicit sync instead. For example, on the gpu side of things, >> depending on flags userspace passes in to the submit ioctl we would >> either attach the fence to all the written buffers (implicit) or >> return it as a fence fd to userspace (explicit), which userspace could >> then pass in to atomic ioctl to synchronize pageflip. >> >> And visa-versa, we can pass the pageflip (atomic) completion fence >> back in to gpu so it doesn't start rendering the next frame until the >> buffer is off screen. >> >> fwiw, currently android is the first user of explicit sync (although I >> expect wayland/weston to follow suit). > > 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? And is there any reason that fence fd shouldn't dependent of DMABUF - now fence fd is a new file, not DMABUF fd? > > As stated before, there are other benefits, including much better > traceability. I would expect Wayland/Weston to also start pushing > support for this API relatively soon. > >> A couple linaro folks have >> android running with an upstream kernel + mesa + atomic/kms hwc on a >> couple devices (nexus7 and db410c with freedreno, and qemu with >> virgl). But there are some limitations due to missing the >> EGL_ANDROID_native_fence_sync extension in mesa. I plan to implement >> that, but I ofc need the fence fd stuff in order to do so ;-) > > Yes, having that would be a godsend for a lot of people. > >>> And if we need really to expose fences to user-space and there is really real user, then we have already good candidates, DMA-BUF-IOCTL-SYNC or maybe fcntl system call because we share already DMA buffer between CPU <-> DMA and DMA <-> DMA using DMABUF. >>> For DMA-BUF-IOCTL-SYNC, I think you remember that was what I tried long time ago because you was there. Several years ago, I tried to couple exposing the fences to user-space with cache operation although at that time, I really misleaded the fence machnism. My trying was also for the potential users. >> >> Note that this is not (just) about sw sync, but also sync between >> multiple hw devices. > > Sync isn't quite good enough, because it's a mandatory blocking point > for userspace. We want to push the explicit fences further down the > line, so userspace can parallelise its work. > > Even if none of the above requirements held true, I don't think being > able to support Android is a bad thing. It's completely right to be > worried about pushing in Android work and APIs for the sake of it - > hence why we didn't take ADF! - but in this case it's definitely a As least Google's ADF boosted up atomic KMS. :) > 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. Thanks, Inki Dae > > Cheers, > Daniel > >