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: Tue, 29 Mar 2016 11:18:59 +0900 Message-ID: <56F9E613.1030902@samsung.com> References: <1458758847-21170-1-git-send-email-gustavo@padovan.org> <56F3A2DC.8080507@samsung.com> <56F47D01.7040508@samsung.com> <56F88828.5050304@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) by gabe.freedesktop.org (Postfix) with ESMTPS id 89F4789B70 for ; Tue, 29 Mar 2016 02:19:03 +0000 (UTC) Received: from epcpsbgr2.samsung.com (u142.gpu120.samsung.co.kr [203.254.230.142]) by mailout3.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0O4S00HTK3RN2JB0@mailout3.samsung.com> for dri-devel@lists.freedesktop.org; Tue, 29 Mar 2016 11:18:59 +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+yblCAyOOydvCAyMjoyNuyXkCBEYW5pZWwgU3RvbmUg7J20 KOqwgCkg7JO0IOq4gDoKPiBIaSBJbmtpLAo+IAo+IE9uIDI4IE1hcmNoIDIwMTYgYXQgMDI6MjYs IElua2kgRGFlIDxpbmtpLmRhZUBzYW1zdW5nLmNvbT4gd3JvdGU6Cj4+IDIwMTbrhYQgMDPsm5Qg MjXsnbwgMjE6MTDsl5AgRGFuaWVsIFN0b25lIOydtCjqsIApIOyTtCDquIA6Cj4+PiBTZWNvbmQs IHJlYWxseS4gVnVsa2FuIGF2b2lkcyBpbXBsaWNpdCBzeW5jIGVudGlyZWx5LCBhbmQgZXhwb3Nl cwo+Pj4gZmVuY2UtbGlrZSBwcmltaXRpdmVzIHRocm91Z2hvdXQgaXRzIHdob2xlIEFQSS4gVGhl c2UgaW5jbHVkZSBiZWluZwo+Pj4gYWJsZSB0byBwYXNzIHByZXJlcXVpc2l0ZSBmZW5jZXMgZm9y IGRpc3BsYXkgKHdoYXQgR3VzdGF2byBpcyBhZGRpbmcKPj4+IGhlcmU6IHNvbWV0aGluZyB0byBi bG9jayBvbiBiZWZvcmUgZGlzcGxheSksIGFuZCBhbHNvIHdoZW4gdGhlIHVzZXIKPj4+IGFjcXVp cmVzIGEgYnVmZmVyIGFzIGEgcmVuZGVyIHRhcmdldCwgaXQgaXMgZ2l2ZW4gYW5vdGhlciBwcmVy ZXF1aXNpdGUKPj4+IGZlbmNlICh0aGUgb3RoZXIgc2lkZSBvZiB3aGF0IEd1c3Rhdm8gaXMgc3Vn Z2VzdGluZywgaS5lLiB0aGUgZmVuY2UKPj4+IHRyaWdnZXJzIHdoZW4gdGhlIGJ1ZmZlciBpcyBu byBsb25nZXIgZGlzcGxheWVkIGFuZCBiZWNvbWVzIGF2YWlsYWJsZQo+Pj4gZm9yIHJlbmRlcmlu ZykuCj4+Pgo+Pj4gSW4gb3JkZXIgdG8gaW1wbGVtZW50IHRoaXMgY29ycmVjdGx5LCBhbmQgYXZv aWQgcGVyZm9ybWFuY2UgYnViYmxlcywKPj4+IHdlIG5lZWQgYSBwcmltaXRpdmUgbGlrZSB0aGlz IGV4cG9zZWQgdGhyb3VnaCB0aGUgS01TIEFQSSwgZnJvbSBib3RoCj4+PiBzaWRlcy4gVGhpcyBp cyBlc3BlY2lhbGx5IGltcG9ydGFudCB3aGVuIHlvdSB0YWtlIHRoZSBjYXNlIG9mCj4+PiB1c2Vy c3BhY2Ugc3ViYWxsb2NhdGlvbiwgd2hlcmUgdXNlcnNwYWNlIGFsbG9jYXRlcyBsYXJnZXIgYmxv Y2tzIGFuZAo+Pj4gZGl2aWRlcyB0aGUgYWxsb2NhdGlvbiBpbnRlcm5hbGx5IGZvciBkaWZmZXJl bnQgdXNlcy4gSW1wbGljaXQgc3luYwo+Pj4gZG9lcyBub3Qgd29yayBhdCBhbGwgZm9yIHRoYXQg Y2FzZS4KPj4KPj4gQ2FuIHlvdSBnaXZlIG1lIG1vcmUgZGV0YWlscyB3aHkgaW1wbGljaXQgc3lu YyBjYW5ub3QgdGFrZSBjYXJlIG9mIHRoZSBjYXNlIG9mIHVzZXJzcGFjZSBzdWJhbGxvY2F0aW9u Pwo+IAo+IEltcGxpY2l0IHN5bmMgZG9lcyBub3Qga25vdyBhYm91dCBzdWJhbGxvY2F0aW9uLCBz byBpbXBsaWNpdCB3aWxsCj4gb3BlcmF0ZSBmb3IgZXZlcnkgcmFuZ2UgaW4gdGhlIGJ1ZmZlciwg bm90IGp1c3QgdGhlIG9uZSB5b3Ugd2FudC4KPiAKPiBTYXkgeW91IGhhdmUgb25lIGtlcm5lbCBi dWZmZXIsIHdoaWNoIHVzZXJzcGFjZSBzdWJkaXZpZGVzIGludG8gZm91cgo+IGluZGVwZW5kZW50 IGJ1ZmZlcnMuIEl0IGNhbiBwZXJmb3JtIG9wZXJhdGlvbnMgb24gdGhlc2UgYnVmZmVycyB3aGlj aAo+IGFyZSBjb21wbGV0ZWx5IGluZGVwZW5kZW50IG9mIGVhY2ggb3RoZXIsIGFuZCBhbiBleHBs aWNpdCBzeW5jIG1vZGVsCj4gYWxsb3dzIHRoaXMgaW5kZXBlbmRlbmNlIHRvIGJlIGtlcHQuIElt cGxpY2l0IHN5bmMgdGllcyB0aGVtIHRvZ2V0aGVyLAo+IHNvIHRoYXQgeW91IGNhbm5vdCBkbyBh bnkgb3BlcmF0aW9ucyBvbiBidWZmZXIgMSB1bnRpbCBhbGwgb3BlcmF0aW9ucwo+IG9uIGJ1ZmZl ciAyIGhhdmUgY29tcGxldGVkLgo+IAo+PiBBbmQgaXMgdGhlcmUgYW55IHJlYXNvbiB0aGF0IGZl bmNlIGZkIHNob3VsZG4ndCBkZXBlbmRlbnQgb2YgRE1BQlVGIC0gbm93IGZlbmNlIGZkIGlzIGEg bmV3IGZpbGUsIG5vdCBETUFCVUYgZmQ/Cj4gCj4gQmVjYXVzZSBkbWFidWYgaXMgZm9yIGJ1ZmZl ciBzaGFyaW5nLCBhbmQgZmVuY2VzIGFyZW4ndCBidWZmZXJzICh0aGV5Cj4gd2lsbCBuZXZlciBl eHBvcnQgcGFnZSByYW5nZXMpLiBJcyB0aGVyZSBhbnkgcGFydGljdWxhciBiZW5lZml0IHlvdQo+ IHRoaW5rIHlvdSB3b3VsZCBnZXQgZnJvbSBkb2luZyB0aGlzPwoKSnVzdCBmb3IgY29uc2lzdGVu Y3kuIEFzIHlvdSBrbm93LCBpbXBsaWNpdCBzeW5jIGhhbmdzIERNQSBmZW5jZSB1cCBvbiBkbWFi dWYgb2JqZWN0IHRocm91Z2ggcmVzZXJ2YXRpb24gb2JqZWN0IHNvIGRtYWJ1ZiBpbmRlcGVuZGVu dCBleHBsaWNpdCBzeW5jIGxvb2tlZCBzdHJhbmdlIHRvIG1lLgpBcyB5b3UgbWVudGlvbmVkIGFi b3ZlLCB0aGUgc3ViYWxsb2NhdGlvbiB3b3VsZCBiZSB3aHkgZXhwbGljaXQgc3luYyBzaG91bGQg YmUgaW5kZXBlbmVudCBvZiBETUFCVUYuCgpJbiBhZGRpdGlvbiwgSSB3b25kZXIgaG93IGV4cGxp Y2l0IGFuZCBpbXBsaWNpdCBmZW5jZXMgY291bGQgY29leGlzdCB0b2dldGhlci4KUm9iIHNhaWQs CiJJbXBsaWNpdCBzeW5jIG9mYyByZW1haW5zIHRoZSBkZWZhdWx0LCBidXQgdXNlcnNwYWNlIGNv dWxkIG9wdC1pbiB0byBleHBsaWNpdCBzeW5jIGluc3RlYWQiCgpUaGlzIHdvdWxkIG1lYW4gdGhh dCBpZiB3ZSB1c2UgZXhwbGljaXQgc3luYyBmb3IgdXNlci1zcGFjZSB0aGVuIGl0IGNvZXhpc3Rz IHdpdGggaW1wbGljaXQgc3luYy4gSG93ZXZlciwgdGhlc2UgdHdvIHN5bmMgZmVuY2VzIGNhbid0 IHNlZSBzYW1lIERNQSBidWZmZXIgYmVjYXVzZSBleHBsaWNpdCBmZW5jZSBoYXMgYSBkaWZmZXJl bnQgZmlsZSBvYmplY3QgZnJvbSBpbXBsaWNpdCBvbmUuClNvIGluIHRoaXMgY2FzZSwgSSB0aGlu ayBleHBsaWNpdCBmZW5jZSB3b3VsZCBuZWVkIHRvIGJlIGh1bmcgdXAgb24gdGhlIHJlc2VydmF0 aW9uIG9iamVjdCBvZiBkbWFidWYgb2JqZWN0IHNvbWVob3cuIE90aGVyd2lzZSwgYWx0aG91Z2gg dGhleSBjb2V4aXN0IHRvZ2V0aGVyLCBhcmUgdGhlc2UgZmVuY2VzIC0gZXhwbGljaXQgYW5kIGlt cGxpY2l0IC0gdXNlZCBmb3IgZGlmZmVyZW5jdCBwdXJwb3NlIHNlcGFyYXRlbHk/IAoKVGhhbmtz LApJbmtpIERhZQoKPiAKPj4+IGdvb2QgdGhpbmcuIFRoaXMgaXMgYWxzbyB0aGUgbW9kZWwgdGhh dCBDaHJvbWVPUyBpcyBtb3ZpbmcgdG93YXJkcywgc28KPj4+IGl0IGJlY29tZXMgbW9yZSBpbXBv cnRhbnQgZnJvbSB0aGF0IHBvaW50IG9mIHZpZXcgYXMgd2VsbC4KPj4KPj4gSSB0aGluayBHdXN0 YXZvIHNob3VsZCBoYWQgZXhwbGFuZWQgdGhpcyBwYXRoIHNlcmllcyBlbm91Z2ggdG8gb3RoZXIg cGVvcGxlIHdoZW4gcG9zdGluZyB0aGVtIC0gaWUsIHdoYXQgcmVsYXRpb25zaGlwIGV4cGxpY3Qg YW5kIGltcGxpY2l0IGZlbmNlcyBoYXZlLCBhbmQgd2h5IGltcGxpY2l0IGZlbmNlIC0gd2hpY2gg aXMgaW5kZXBlbmRlbnQgb2YgRE1BQlVGIC0gaXMgcmVxdWlyZWQsIGFuZCB3aGF0IHVzZSBjYXNl cyB0aGVyZSBhcmUgaW4gcmVhbCB1c2VycywgYW5kIGV0Yy4KPiAKPiBGYWlyIGVub3VnaCwgdGhl IHN1bW1hcnkgY291bGQgcGVyaGFwcyBjb250YWluIHNvbWV0aGluZyBsaWtlIHRoaXMuCj4gCj4g Q2hlZXJzLAo+IERhbmllbAo+IAo+IApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVl ZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5m by9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755168AbcC2CTG (ORCPT ); Mon, 28 Mar 2016 22:19:06 -0400 Received: from mailout3.samsung.com ([203.254.224.33]:36527 "EHLO mailout3.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751697AbcC2CTD (ORCPT ); Mon, 28 Mar 2016 22:19:03 -0400 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 X-AuditID: cbfee68e-f79d96d0000012b1-d4-56f9e613f2ef Content-transfer-encoding: 8BIT Message-id: <56F9E613.1030902@samsung.com> Date: Tue, 29 Mar 2016 11:18:59 +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> In-reply-to: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFIsWRmVeSWpSXmKPExsWyRsSkRFf42c8wg+3TDS3e/73PZrHw4V1m iyut01ktrnx9z2bxaXUru8Wkpw/YLC7vmsNm8XrTX0aL5wt/MDtwemzbvY3V4+/z6ywee78t YPF48XUbs8fOWXfZPRbvecnkcb/7OJPH501yARxRXDYpqTmZZalF+nYJXBkPvneyFiyXqVj7 aTlLA+NnsS5GTg4JAROJRZPPMEHYYhIX7q1n62Lk4hASWMEocX7jeVaYoq8vuqASsxglrl3b zgKS4BUQlPgx+R6QzcHBLCAvceRSNoSpLjFlSi5E+QNGiQOnvjBDlGtJLLrXDraMRUBV4mjn d3YQmw3InrjiPhtIr6hAhET3iUqQsAjQmAUP3jGCzGEWmMIssW3fVjaQhLCAuUTvw05WiAWH mCVefekAO5RTIFiid9ohJpCEhMBPdokd++axQWwTkPg2+RDYoRICshKbDjBDPCYpcXDFDZYJ jGKzkLwzC+GdWQjvLGBkXsUomlqQXFCclF5kpFecmFtcmpeul5yfu4kRGKWn/z3r28F484D1 IUYBDkYlHl6GBT/DhFgTy4orcw8xmgLdMJFZSjQ5H5gK8kriDY3NjCxMTUyNjcwtzZTEeROk fgYLCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYLQ37TA6d2f+xvo/r+aGutqo7Nr3Qins/Ub9 rysnTGSyeie1tTFzxvqXthpifCuTi/3ttgbtr0y5ciYjdtOikC5l7Unnct9/2s/hvaK5yyL0 l+KJAy/X9m8TYtnMYL1L3enlrSMPD+s4mjk5MW5ZyuVoP7s9gaPlwWX7w90OBoc2fM61tndQ +qDEUpyRaKjFXFScCADpNoJhzQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnleLIzCtJLcpLzFFi42I5/e+xoK7ws59hBqenaFq8/3ufzWLhw7vM Fldap7NaXPn6ns3i0+pWdotJTx+wWVzeNYfN4vWmv4wWzxf+YHbg9Ni2exurx9/n11k89n5b wOLx4us2Zo+ds+6yeyze85LJ4373cSaPz5vkAjiiGhhtMlITU1KLFFLzkvNTMvPSbZW8g+Od 403NDAx1DS0tzJUU8hJzU22VXHwCdN0yc4AOVFIoS8wpBQoFJBYXK+nbYZoQGuKmawHTGKHr GxIE12NkgAYS1jBmPPjeyVqwXKZi7aflLA2Mn8W6GDk5JARMJL6+6GKDsMUkLtxbD2RzcQgJ zGKUuHZtOwtIgldAUOLH5HtANgcHs4C8xJFL2RCmusSUKbkQ5Q8YJQ6c+sIMUa4lseheOxOI zSKgKnG08zs7iM0GZE9ccZ8NpFdUIEKi+0QlSFgEaMyCB+8YQeYwC0xhlti2byvYPcIC5hK9 DztZIRYcYpZ49aWDFSTBKRAs0TvtENMERqArEc6bhXDeLITzFjAyr2KUSC1ILihOSs81ykst 1ytOzC0uzUvXS87P3cQITgTPpHcwHt7lfohRgINRiYeXYcHPMCHWxLLiytxDjBIczEoivE5P gUK8KYmVValF+fFFpTmpxYcYTYH+m8gsJZqcD0xSeSXxhsYmZkaWRuaGFkbG5krivI//rwsT EkhPLEnNTk0tSC2C6WPi4JRqYJyTtP+eWeTF7Z/Wh26cPu/876KZEavnH9OvSDpmHzj/hua5 T/JurN8jayfULgmcEmGesqd2sY10ZETSwdNL/VYeWmOsvbvgZM1X37Msy/SyqrZ0G/BeWXSp 9JT3Wq4WjXVB8/llLjxImG+q6F57T86ZZYHUrsMWGhNcl+2/OP9s3tVfKcy7VJuUWIozEg21 mIuKEwFJlzv1GgMAAA== 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월 28일 22:26에 Daniel Stone 이(가) 쓴 글: > Hi Inki, > > On 28 March 2016 at 02:26, Inki Dae wrote: >> 2016년 03월 25일 21:10에 Daniel Stone 이(가) 쓴 글: >>> 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? > > Implicit sync does not know about suballocation, so implicit will > operate for every range in the buffer, not just the one you want. > > Say you have one kernel buffer, which userspace subdivides into four > independent buffers. It can perform operations on these buffers which > are completely independent of each other, and an explicit sync model > allows this independence to be kept. Implicit sync ties them together, > so that you cannot do any operations on buffer 1 until all operations > on buffer 2 have completed. > >> And is there any reason that fence fd shouldn't dependent of DMABUF - now fence fd is a new file, not DMABUF fd? > > Because dmabuf is for buffer sharing, and fences aren't buffers (they > will never export page ranges). Is there any particular benefit you > think you would get from doing this? Just for consistency. As you know, implicit sync hangs DMA fence up on dmabuf object through reservation object so dmabuf independent explicit sync looked strange to me. As you mentioned above, the suballocation would be why explicit sync should be indepenent of DMABUF. 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? Thanks, Inki Dae > >>> 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. > > Fair enough, the summary could perhaps contain something like this. > > Cheers, > Daniel > >