From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [RFC v2 5/8] drm/fence: add in-fences support Date: Thu, 28 Apr 2016 19:56:19 +0300 Message-ID: <20160428165619.GD4329@intel.com> 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 mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTP id A98A16ED97 for ; Thu, 28 Apr 2016 16:56:24 +0000 (UTC) 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 , 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 ZXkgYXJlOgoKWW91ciAic3VtbWFyeSIgZm9yZ290IHRvIGluY2x1ZGUgYW55IGNvdW50ZXIgYXJn dW1lbnRzLgoKPiAKPiAgLSBpbXBsaWNpdCBmZW5jZXMgYWxzbyBuZWVkcyBvbmUgZmVuY2UgcGVy IHBsYW5lL2ZiLCBzbyBpdCB3aWxsIGJlIGdvb2QgdG8gICAgIAo+ICAgIG1hdGNoIHdpdGggdGhh dC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCgpXZSB3b3VsZCBhY3R1YWxseSBuZWVkIGEgZmVuY2UgcGVyIG9iamVjdCByYXRoZXIg dGhhbiBwZXIgZmIuCgo+ICAtIHJlcXVpcmVzIHVzZXJzcGFjZSB0byBhbHdheXMgbWVyZ2UgZmVu Y2VzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCgoiZG9lc24ndD8iIGJ1dCB0 aGF0J3Mgbm90IHRydWUgaWYgaXQncyBhbiBhcnJheS4gSXQgd291bGQgYmUgdHJ1ZSBpZgp5b3Ug aGFkIGp1c3Qgb25lIGZlbmNlIGZvciB0aGUgd2hvbGUgdGhpbmcsIG9yIG9uZSBwZXIgY3J0Yy4K Cj4gIC0gY2FuIHVzZSBzdGFuZGFyZCBwbGFuZSBwcm9wZXJ0aWVzLCBtYWtpbmcga2VybmVsIGFu ZCB1c2Vyc3BhY2UgbGlmZSBlYXNpZXIsICAKPiAgICBhbiBhcnJheSBicmluZ3MgbW9yZSB3b3Jr IHRvIGJ1aWxkIHRoZSBhdG9taWMgcmVxdWVzdCBwbHVzIGV4dHJhIGNoZWNraW5ncyAgIAo+ICAg IG9uIHRoZSBrZXJuZWwuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCgpJIGRvbid0IHJlYWxseSBnZXQgdGhpcyBvbmUuIFRoZSBv YmplY3RzIGFuZCBwcm9wcyBhcmUgYXJyYXlzIHRvby4gV2h5IGlzCmFub3RoZXIgYXJyYXkgc28g cHJvYmxlbWF0aWM/Cgo+ICAtIGRvIG5vdCBuZWVkIHRvIGNoYW5nZXMgdG8gZHJpdmVycyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCj4gIC0gYmV0dGVyIGZvciB0 cmFjaW5nLCBjYW4gaWRlbnRpZnkgdGhlIGJ1ZmZlci9mZW5jZSBwcm9tcHRseQoKQ2FuIGZlbmNl cyBiZSByZXVzZWQgc29tZWhvdyB3aGlsZSBzdGlsbCBhdHRhY2hlZCB0byBhIHBsYW5lLCBvciBl dmVyPwpUaGF0IG1pZ2h0IGNhdXNlIHNvbWUgb2RkbmVzcyBpZiB5b3UsIHNheSwgbGVhdmUgYSBm ZW5jZSBhdHRhY2hlZCB0byBvbmUKcGxhbmUgYW5kIHRoZW4gZG8gYSBtb2Rlc2V0IG9uIGFub3Ro ZXIgY3J0YyBwZXJoYXBzIHdoaWNoIG5lZWRzIHRvIHR1cm4KdGhlIGZpcnN0IGNydGMgb2ZmK29u IHRvIHJlY29uZmlndXJlIHNvbWV0aGluZy4KCi0tIApWaWxsZSBTeXJqw6Rsw6QKSW50ZWwgT1RD Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZl bCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xp c3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753198AbcD1Q42 (ORCPT ); Thu, 28 Apr 2016 12:56:28 -0400 Received: from mga02.intel.com ([134.134.136.20]:5028 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752067AbcD1Q40 (ORCPT ); Thu, 28 Apr 2016 12:56:26 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,547,1455004800"; d="scan'208";a="954933383" Date: Thu, 28 Apr 2016 19:56:19 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Gustavo Padovan , Daniel Stone , Greg Hackmann , 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: <20160428165619.GD4329@intel.com> 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> 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: Your "summary" forgot to include any counter arguments. > > - implicit fences also needs one fence per plane/fb, so it will be good to > match with that. We would actually need a fence per object rather than per fb. > - requires userspace to always merge fences "doesn't?" but that's not true if it's an array. It would be true if you had just one fence for the whole thing, or one per crtc. > - 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. I don't really get this one. The objects and props are arrays too. Why is another array so problematic? > - do not need to changes to drivers > - better for tracing, can identify the buffer/fence promptly Can fences be reused somehow while still attached to a plane, or ever? That might cause some oddness if you, say, leave a fence attached to one plane and then do a modeset on another crtc perhaps which needs to turn the first crtc off+on to reconfigure something. -- Ville Syrjälä Intel OTC