From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [RFC v2 5/8] drm/fence: add in-fences support Date: Thu, 28 Apr 2016 16:38:51 +0200 Message-ID: <20160428143851.GC5784@phenom.ffwll.local> References: <20160426143635.GW8291@phenom.ffwll.local> <20160426162621.GU4329@intel.com> <20160426172049.GB2558@phenom.ffwll.local> <20160426174045.GC4329@intel.com> <20160426182346.GC2558@phenom.ffwll.local> <20160426185506.GH4329@intel.com> <20160426200505.GD2558@phenom.ffwll.local> <571FD402.6050407@google.com> <20160428143644.GA3496@joana> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3D6B56ED41 for ; Thu, 28 Apr 2016 14:38:56 +0000 (UTC) Received: by mail-wm0-x22d.google.com with SMTP id a17so69063279wme.0 for ; Thu, 28 Apr 2016 07:38:56 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20160428143644.GA3496@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 , Daniel Stone , Greg Hackmann , Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , Gustavo Padovan , Daniel Stone , Riley Andrews , dri-devel , Linux Kernel Mailing List , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , John Harrison List-Id: dri-devel@lists.freedesktop.org T24gVGh1LCBBcHIgMjgsIDIwMTYgYXQgMTE6MzY6NDRBTSAtMDMwMCwgR3VzdGF2byBQYWRvdmFu IHdyb3RlOgo+IDIwMTYtMDQtMjcgRGFuaWVsIFN0b25lIDxkYW5pZWxAZm9vaXNoYmFyLm9yZz46 Cj4gCj4gPiBIaSwKPiA+IAo+ID4gT24gMjYgQXByaWwgMjAxNiBhdCAyMTo0OCwgR3JlZyBIYWNr bWFubiA8Z2hhY2ttYW5uQGdvb2dsZS5jb20+IHdyb3RlOgo+ID4gPiBPbiAwNC8yNi8yMDE2IDAx OjA1IFBNLCBEYW5pZWwgVmV0dGVyIHdyb3RlOgo+ID4gPj4gT24gVHVlLCBBcHIgMjYsIDIwMTYg YXQgMDk6NTU6MDZQTSArMDMwMCwgVmlsbGUgU3lyasOkbMOkIHdyb3RlOgo+ID4gPj4+IFdoYXQg YXJlIHRoZXkgZG9pbmcgdGhhdCBjYW4ndCBzdHVmZiB0aGUgZmVuY2VzIGludG8gYW4gYXJyYXkK PiA+ID4+PiBpbnN0ZWFkIG9mIHByb3BzPwo+ID4gPj4KPiA+ID4+IFRoZSBodyBjb21wb3NlciBp bnRlcmZhY2UgaXMgb25lIGluLWZlbmNlIHBlciBwbGFuZS4gVGhhdCdzIHJlYWxseSB0aGUKPiA+ ID4+IG1ham9yIHJlYXNvbiB3aHkgdGhlIGtlcm5lbCBpbnRlcmZhY2UgaXMgYnVpbHQgdG8gbWF0 Y2guIEFuZCBJIHJlYWxseQo+ID4gPj4gZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIGRpdmVyZ2UganVz dCBiZWNhdXNlIHdlIGhhdmUgYSBzbGlnaHQgZGlmZmVyZW50Cj4gPiA+PiBjb2xvciBwcmVmZXJl bmNlIDstKQo+ID4gPgo+ID4gPiBUaGUgcmVsYXRpb25zaGlwIGJldHdlZW4gbGF5ZXJzIGFuZCBm ZW5jZXMgaXMgb25seSBmdXp6eSBhbmQgaW5kaXJlY3QKPiA+ID4gdGhvdWdoLiAgVGhlIHJlbGF0 aW9uc2hpcCBpcyByZWFsbHkgYmV0d2VlbiB0aGUgYnVmZmVyIHlvdSdyZSBkaXNwbGF5aW5nIG9u Cj4gPiA+IHRoYXQgbGF5ZXIsIGFuZCB0aGUgZmVuY2UgcmVwcmVzZW50aW5nIHRoZSB3b3JrIGRv bmUgdG8gcmVuZGVyIGludG8gdGhhdAo+ID4gPiBidWZmZXIuICBTdXJmYWNlRmxpbmdlciBqdXN0 IGhhcHBlbnMgdG8gYnVuZGxlIHRoZW0gdG9nZXRoZXIgaW5zaWRlIHRoZSBzYW1lCj4gPiA+IHN0 cnVjdCBod2NfbGF5ZXJfMSBhcyBhbiBBUEkgY29udmVuaWVuY2UuCj4gPiAKPiA+IFJpZ2h0LCBh bmQgd2hlbiB1c2luZyBpbXBsaWNpdCBmZW5jaW5nLCB0aGlzIGNvbWVzIGFzIGEgcGxhbmUKPiA+ IHByb3BlcnR5LCBieSB2aXJ0dWUgb2YgcGxhbmUgLT4gZmIgLT4gYnVmZmVyIC0+IGZlbmNlLgo+ ID4gCj4gPiA+IFdoaWNoIGlzIGtpbmQgb2Ygc3BsaXR0aW5nIGhhaXJzIGFzIGxvbmcgYXMgeW91 IGhhdmUgYSAxLXRvLTEgcmVsYXRpb25zaGlwCj4gPiA+IGJldHdlZW4gbGF5ZXJzIGFuZCBEUk0g cGxhbmVzLiAgQnV0IHRoYXQncyBub3QgYWx3YXlzIHRoZSBjYXNlLgo+ID4gCj4gPiBDYW4geW91 IHBsZWFzZSBlbGFib3JhdGU/Cj4gPiAKPiA+ID4gQSAocGVyLUNSVEM/KSBhcnJheSBvZiBmZW5j ZXMgd291bGQgYmUgbW9yZSBmbGV4aWJsZS4gIEFuZCBldmVuIGluIHRoZSBjYXNlcwo+ID4gPiB3 aGVyZSB5b3UgY291bGQgbWFrZSBhIDEtdG8tMSBtYXBwaW5nIGJldHdlZW4gcGxhbmVzIGFuZCBm ZW5jZXMsIGl0J3Mgbm90Cj4gPiA+IHRoYXQgbXVjaCBtb3JlIHdvcmsgZm9yIHVzZXJzcGFjZSB0 byBhc3NlbWJsZSB0aG9zZSBmZW5jZXMgaW50byBhbiBhcnJheQo+ID4gPiBhbnl3YXkuCj4gPiAK PiA+IEFzIFZpbGxlIHNheXMsIEkgZG9uJ3Qgd2FudCB0byBnbyBkb3duIHRoZSBwYXRoIG9mIHNj aGVkdWxpbmcgQ1JUQwo+ID4gdXBkYXRlcyBzZXBhcmF0ZWx5LCBiZWNhdXNlIHRoYXQgYnJlYWtz IE1TVCBwcmV0dHkgYmFkbHkuIElmIHlvdSBkb24ndAo+ID4gd2FudCB5b3VyIHVwZGF0ZXMgdG8g ZGlzcGxheSBhdG9taWNhbGx5LCB0aGVuIGRvbid0IHNjaGVkdWxlIHRoZW0KPiA+IGF0b21pY2Fs bHkgLi4uID8gVGhhdCdzIHRoZSBvbmx5IHJlYXNvbiBJIGNhbiBzZWUgZm9yIG1ha2luZyBmZW5j aW5nCj4gPiBwZXItQ1JUQywgcmF0aGVyIHRoYW4ganVzdCBhIHBpbGUgb2YgdW5hc3NvY2lhdGVk IGZlbmNlcyBhcHBlbmRlZCB0bwo+ID4gdGhlIHJlcXVlc3QuIFBlci1DUlRDIGZlbmNlcyBhbHNv IGZvcmNlcyB1c2Vyc3BhY2UgdG8gbWVyZ2UgZmVuY2VzCj4gPiBiZWZvcmUgc3VibWlzc2lvbiB3 aGVuIHVzaW5nIG11bHRpcGxlIHBsYW5lcyBwZXIgQ1JUQywgd2hpY2ggaXMgcHJldHR5Cj4gPiBw dW5pdGl2ZS4KPiA+IAo+ID4gSSB0aGluayBoYXZpbmcgaXQgc2VtYW50aWNhbGx5IGF0dGFjaGVk IHRvIHRoZSBwbGFuZSBpcyBhIGxpdHRsZSBiaXQKPiA+IG5pY2VyIGZvciB0cmFjaW5nICh3aHkg d2FzIHRoaXMgcmVxdWVzdCBkZWxheWVkPyAtPiBhIGZlbmNlIC0+IHdoaWNoCj4gPiBidWZmZXIg d2FzIHRoYXQgZmVuY2UgZm9yPykgYXQgYSBnbGFuY2UuIEFsc28gdGhlICdwaWxlIG9mIGFwcGVu ZGVkCj4gPiBmZW5jZXMnIG1vZGVsIGlzIGEgYml0IGF3a3dhcmQgZm9yIG1vcmUgZ2VuZXJpYyB1 c2Vyc3BhY2UsIHdoaWNoCj4gPiBjcmVhdGVzIGEgbGliZHJtIHJlcXVlc3QgYW5kIGJ1aWxkcyBp dCAoYWRkIGEgcGxhbmUsIHRyeSBpdCBvdXQsIHdpbmQKPiA+IGJhY2spIGluY3JlbWVudGFsbHku IFVzaW5nIHByb3BlcnRpZXMgbWFrZXMgdGhhdCByZWFsbHkgZWFzeSwgYnV0Cj4gPiB3aXRob3V0 IHByb3BlcnRpZXMsIHdlJ2QgaGF2ZSB0byBhZGQgc2VwYXJhdGUgY29kZXBhdGhzIC0gYW5kIHRo dXMKPiA+IHNlcGFyYXRlIEFCSSwgd2hpY2ggY29tcGxpY2F0ZXMgZGlzdHJpYnV0aW9uIC0gdG8g bGliZHJtIHRvIGFjY291bnQKPiA+IGZvciBhIHNlcGFyYXRlIHBsYW5lIGFycmF5IHdoaWNoIHNo YXJlcyBhIGN1cnNvciB3aXRoIHRoZSBwcm9wZXJ0aWVzLgo+ID4gU28gZm9yIHRoYXQgcmVhc29u IGlmIG5vbmUgb3RoZXIsIEknZCByZWFsbHkgcHJlZmVyIG5vdCB0byBnbyBkb3duCj4gPiB0aGF0 IHJvdXRlLgo+IAo+IEkgYWxzbyBhZ3JlZSB0byBoYXZlIGl0IGFzIEZFTkNFX0ZEIHByb3Agb24g dGhlIHBsYW5lLiBTdW1tYXJpemluZyB0aGUKPiBhcmd1bWVudHMgb24gdGhpcyB0aHJlYWQsIHRo ZXkgYXJlOgo+IAo+ICAtIGltcGxpY2l0IGZlbmNlcyBhbHNvIG5lZWRzIG9uZSBmZW5jZSBwZXIg cGxhbmUvZmIsIHNvIGl0IHdpbGwgYmUgZ29vZCB0byAgICAgCj4gICAgbWF0Y2ggd2l0aCB0aGF0 LiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKPiAgLSByZXF1aXJlcyB1c2Vyc3BhY2UgdG8gYWx3YXlzIG1lcmdlIGZlbmNlcyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAoKImRvZXMgbm90IHJlcXVpcmUiIEkgcHJl c3VtZT8KCj4gIC0gY2FuIHVzZSBzdGFuZGFyZCBwbGFuZSBwcm9wZXJ0aWVzLCBtYWtpbmcga2Vy bmVsIGFuZCB1c2Vyc3BhY2UgbGlmZSBlYXNpZXIsICAKPiAgICBhbiBhcnJheSBicmluZ3MgbW9y ZSB3b3JrIHRvIGJ1aWxkIHRoZSBhdG9taWMgcmVxdWVzdCBwbHVzIGV4dHJhIGNoZWNraW5ncyAg IAo+ICAgIG9uIHRoZSBrZXJuZWwuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCj4gIC0gZG8gbm90IG5lZWQgdG8gY2hhbmdlcyB0 byBkcml2ZXJzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKPiAg LSBiZXR0ZXIgZm9yIHRyYWNpbmcsIGNhbiBpZGVudGlmeSB0aGUgYnVmZmVyL2ZlbmNlIHByb21w dGx5CgotIEZpdHMgaW4gd2VsbCB3aXRoIHRoZSBsaWJkcm0gYXRvbWljIHJvbGxiYWNrIHN1cHBv cnQgLSBubyBuZWVkIHRvIG1hbmFnZQogIGZlbmNlcyBzZXBhcmF0ZWx5IHdoZW4gaW5jcmVtZW50 YWxseSBidWlsZGluZyBhbiBhdG9taWMgY29tbWl0LgogCj4gCj4gCUd1c3Rhdm8KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IGRyaS1kZXZlbCBtYWls aW5nIGxpc3QKPiBkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCj4gaHR0cHM6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwKCi0tIApEYW5pZWwg VmV0dGVyClNvZnR3YXJlIEVuZ2luZWVyLCBJbnRlbCBDb3Jwb3JhdGlvbgpodHRwOi8vYmxvZy5m ZndsbC5jaApfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpk cmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0 cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753051AbcD1Oi7 (ORCPT ); Thu, 28 Apr 2016 10:38:59 -0400 Received: from mail-wm0-f46.google.com ([74.125.82.46]:37917 "EHLO mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752818AbcD1Oi4 (ORCPT ); Thu, 28 Apr 2016 10:38:56 -0400 Date: Thu, 28 Apr 2016 16:38:51 +0200 From: Daniel Vetter To: Gustavo Padovan , Daniel Stone , Greg Hackmann , Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , Gustavo Padovan , Daniel Stone , Riley Andrews , dri-devel , Linux Kernel Mailing List , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , John Harrison Subject: Re: [RFC v2 5/8] drm/fence: add in-fences support Message-ID: <20160428143851.GC5784@phenom.ffwll.local> Mail-Followup-To: Gustavo Padovan , Daniel Stone , Greg Hackmann , Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , Gustavo Padovan , Daniel Stone , Riley Andrews , dri-devel , Linux Kernel Mailing List , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , John Harrison References: <20160426143635.GW8291@phenom.ffwll.local> <20160426162621.GU4329@intel.com> <20160426172049.GB2558@phenom.ffwll.local> <20160426174045.GC4329@intel.com> <20160426182346.GC2558@phenom.ffwll.local> <20160426185506.GH4329@intel.com> <20160426200505.GD2558@phenom.ffwll.local> <571FD402.6050407@google.com> <20160428143644.GA3496@joana> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160428143644.GA3496@joana> X-Operating-System: Linux phenom 4.6.0-rc5+ User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 28, 2016 at 11:36:44AM -0300, Gustavo Padovan wrote: > 2016-04-27 Daniel Stone : > > > Hi, > > > > On 26 April 2016 at 21:48, Greg Hackmann wrote: > > > On 04/26/2016 01:05 PM, Daniel Vetter wrote: > > >> On Tue, Apr 26, 2016 at 09:55:06PM +0300, Ville Syrjälä wrote: > > >>> What are they doing that can't stuff the fences into an array > > >>> instead of props? > > >> > > >> The hw composer interface is one in-fence per plane. That's really the > > >> major reason why the kernel interface is built to match. And I really > > >> don't think we should diverge just because we have a slight different > > >> color preference ;-) > > > > > > The relationship between layers and fences is only fuzzy and indirect > > > though. The relationship is really between the buffer you're displaying on > > > that layer, and the fence representing the work done to render into that > > > buffer. SurfaceFlinger just happens to bundle them together inside the same > > > struct hwc_layer_1 as an API convenience. > > > > Right, and when using implicit fencing, this comes as a plane > > property, by virtue of plane -> fb -> buffer -> fence. > > > > > Which is kind of splitting hairs as long as you have a 1-to-1 relationship > > > between layers and DRM planes. But that's not always the case. > > > > Can you please elaborate? > > > > > A (per-CRTC?) array of fences would be more flexible. And even in the cases > > > where you could make a 1-to-1 mapping between planes and fences, it's not > > > that much more work for userspace to assemble those fences into an array > > > anyway. > > > > As Ville says, I don't want to go down the path of scheduling CRTC > > updates separately, because that breaks MST pretty badly. If you don't > > want your updates to display atomically, then don't schedule them > > atomically ... ? That's the only reason I can see for making fencing > > per-CRTC, rather than just a pile of unassociated fences appended to > > the request. Per-CRTC fences also forces userspace to merge fences > > before submission when using multiple planes per CRTC, which is pretty > > punitive. > > > > I think having it semantically attached to the plane is a little bit > > nicer for tracing (why was this request delayed? -> a fence -> which > > buffer was that fence for?) at a glance. Also the 'pile of appended > > fences' model is a bit awkward for more generic userspace, which > > creates a libdrm request and builds it (add a plane, try it out, wind > > back) incrementally. Using properties makes that really easy, but > > without properties, we'd have to add separate codepaths - and thus > > separate ABI, which complicates distribution - to libdrm to account > > for a separate plane array which shares a cursor with the properties. > > So for that reason if none other, I'd really prefer not to go down > > that route. > > I also agree to have it as FENCE_FD prop on the plane. Summarizing the > arguments on this thread, they are: > > - implicit fences also needs one fence per plane/fb, so it will be good to > match with that. > - requires userspace to always merge fences "does not require" I presume? > - can use standard plane properties, making kernel and userspace life easier, > an array brings more work to build the atomic request plus extra checkings > on the kernel. > - do not need to changes to drivers > - better for tracing, can identify the buffer/fence promptly - Fits in well with the libdrm atomic rollback support - no need to manage fences separately when incrementally building an atomic commit. > > Gustavo > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch