From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gustavo Padovan Subject: Re: [RFC v2 5/8] drm/fence: add in-fences support Date: Thu, 28 Apr 2016 11:36:44 -0300 Message-ID: <20160428143644.GA3496@joana> References: <20160426141422.GG7857@joana> <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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-yw0-f195.google.com (mail-yw0-f195.google.com [209.85.161.195]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6446A6ECEB for ; Thu, 28 Apr 2016 14:36:50 +0000 (UTC) Received: by mail-yw0-f195.google.com with SMTP id u62so5329516ywe.3 for ; Thu, 28 Apr 2016 07:36:50 -0700 (PDT) Content-Disposition: inline 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 Stone , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Linux Kernel Mailing List , dri-devel , Riley Andrews , Gustavo Padovan , John Harrison List-Id: dri-devel@lists.freedesktop.org MjAxNi0wNC0yNyBEYW5pZWwgU3RvbmUgPGRhbmllbEBmb29pc2hiYXIub3JnPjoKCj4gSGksCj4g Cj4gT24gMjYgQXByaWwgMjAxNiBhdCAyMTo0OCwgR3JlZyBIYWNrbWFubiA8Z2hhY2ttYW5uQGdv b2dsZS5jb20+IHdyb3RlOgo+ID4gT24gMDQvMjYvMjAxNiAwMTowNSBQTSwgRGFuaWVsIFZldHRl ciB3cm90ZToKPiA+PiBPbiBUdWUsIEFwciAyNiwgMjAxNiBhdCAwOTo1NTowNlBNICswMzAwLCBW aWxsZSBTeXJqw6Rsw6Qgd3JvdGU6Cj4gPj4+IFdoYXQgYXJlIHRoZXkgZG9pbmcgdGhhdCBjYW4n dCBzdHVmZiB0aGUgZmVuY2VzIGludG8gYW4gYXJyYXkKPiA+Pj4gaW5zdGVhZCBvZiBwcm9wcz8K PiA+Pgo+ID4+IFRoZSBodyBjb21wb3NlciBpbnRlcmZhY2UgaXMgb25lIGluLWZlbmNlIHBlciBw bGFuZS4gVGhhdCdzIHJlYWxseSB0aGUKPiA+PiBtYWpvciByZWFzb24gd2h5IHRoZSBrZXJuZWwg aW50ZXJmYWNlIGlzIGJ1aWx0IHRvIG1hdGNoLiBBbmQgSSByZWFsbHkKPiA+PiBkb24ndCB0aGlu ayB3ZSBzaG91bGQgZGl2ZXJnZSBqdXN0IGJlY2F1c2Ugd2UgaGF2ZSBhIHNsaWdodCBkaWZmZXJl bnQKPiA+PiBjb2xvciBwcmVmZXJlbmNlIDstKQo+ID4KPiA+IFRoZSByZWxhdGlvbnNoaXAgYmV0 d2VlbiBsYXllcnMgYW5kIGZlbmNlcyBpcyBvbmx5IGZ1enp5IGFuZCBpbmRpcmVjdAo+ID4gdGhv dWdoLiAgVGhlIHJlbGF0aW9uc2hpcCBpcyByZWFsbHkgYmV0d2VlbiB0aGUgYnVmZmVyIHlvdSdy ZSBkaXNwbGF5aW5nIG9uCj4gPiB0aGF0IGxheWVyLCBhbmQgdGhlIGZlbmNlIHJlcHJlc2VudGlu ZyB0aGUgd29yayBkb25lIHRvIHJlbmRlciBpbnRvIHRoYXQKPiA+IGJ1ZmZlci4gIFN1cmZhY2VG bGluZ2VyIGp1c3QgaGFwcGVucyB0byBidW5kbGUgdGhlbSB0b2dldGhlciBpbnNpZGUgdGhlIHNh bWUKPiA+IHN0cnVjdCBod2NfbGF5ZXJfMSBhcyBhbiBBUEkgY29udmVuaWVuY2UuCj4gCj4gUmln aHQsIGFuZCB3aGVuIHVzaW5nIGltcGxpY2l0IGZlbmNpbmcsIHRoaXMgY29tZXMgYXMgYSBwbGFu ZQo+IHByb3BlcnR5LCBieSB2aXJ0dWUgb2YgcGxhbmUgLT4gZmIgLT4gYnVmZmVyIC0+IGZlbmNl Lgo+IAo+ID4gV2hpY2ggaXMga2luZCBvZiBzcGxpdHRpbmcgaGFpcnMgYXMgbG9uZyBhcyB5b3Ug aGF2ZSBhIDEtdG8tMSByZWxhdGlvbnNoaXAKPiA+IGJldHdlZW4gbGF5ZXJzIGFuZCBEUk0gcGxh bmVzLiAgQnV0IHRoYXQncyBub3QgYWx3YXlzIHRoZSBjYXNlLgo+IAo+IENhbiB5b3UgcGxlYXNl IGVsYWJvcmF0ZT8KPiAKPiA+IEEgKHBlci1DUlRDPykgYXJyYXkgb2YgZmVuY2VzIHdvdWxkIGJl IG1vcmUgZmxleGlibGUuICBBbmQgZXZlbiBpbiB0aGUgY2FzZXMKPiA+IHdoZXJlIHlvdSBjb3Vs ZCBtYWtlIGEgMS10by0xIG1hcHBpbmcgYmV0d2VlbiBwbGFuZXMgYW5kIGZlbmNlcywgaXQncyBu b3QKPiA+IHRoYXQgbXVjaCBtb3JlIHdvcmsgZm9yIHVzZXJzcGFjZSB0byBhc3NlbWJsZSB0aG9z ZSBmZW5jZXMgaW50byBhbiBhcnJheQo+ID4gYW55d2F5Lgo+IAo+IEFzIFZpbGxlIHNheXMsIEkg ZG9uJ3Qgd2FudCB0byBnbyBkb3duIHRoZSBwYXRoIG9mIHNjaGVkdWxpbmcgQ1JUQwo+IHVwZGF0 ZXMgc2VwYXJhdGVseSwgYmVjYXVzZSB0aGF0IGJyZWFrcyBNU1QgcHJldHR5IGJhZGx5LiBJZiB5 b3UgZG9uJ3QKPiB3YW50IHlvdXIgdXBkYXRlcyB0byBkaXNwbGF5IGF0b21pY2FsbHksIHRoZW4g ZG9uJ3Qgc2NoZWR1bGUgdGhlbQo+IGF0b21pY2FsbHkgLi4uID8gVGhhdCdzIHRoZSBvbmx5IHJl YXNvbiBJIGNhbiBzZWUgZm9yIG1ha2luZyBmZW5jaW5nCj4gcGVyLUNSVEMsIHJhdGhlciB0aGFu IGp1c3QgYSBwaWxlIG9mIHVuYXNzb2NpYXRlZCBmZW5jZXMgYXBwZW5kZWQgdG8KPiB0aGUgcmVx dWVzdC4gUGVyLUNSVEMgZmVuY2VzIGFsc28gZm9yY2VzIHVzZXJzcGFjZSB0byBtZXJnZSBmZW5j ZXMKPiBiZWZvcmUgc3VibWlzc2lvbiB3aGVuIHVzaW5nIG11bHRpcGxlIHBsYW5lcyBwZXIgQ1JU Qywgd2hpY2ggaXMgcHJldHR5Cj4gcHVuaXRpdmUuCj4gCj4gSSB0aGluayBoYXZpbmcgaXQgc2Vt YW50aWNhbGx5IGF0dGFjaGVkIHRvIHRoZSBwbGFuZSBpcyBhIGxpdHRsZSBiaXQKPiBuaWNlciBm b3IgdHJhY2luZyAod2h5IHdhcyB0aGlzIHJlcXVlc3QgZGVsYXllZD8gLT4gYSBmZW5jZSAtPiB3 aGljaAo+IGJ1ZmZlciB3YXMgdGhhdCBmZW5jZSBmb3I/KSBhdCBhIGdsYW5jZS4gQWxzbyB0aGUg J3BpbGUgb2YgYXBwZW5kZWQKPiBmZW5jZXMnIG1vZGVsIGlzIGEgYml0IGF3a3dhcmQgZm9yIG1v cmUgZ2VuZXJpYyB1c2Vyc3BhY2UsIHdoaWNoCj4gY3JlYXRlcyBhIGxpYmRybSByZXF1ZXN0IGFu ZCBidWlsZHMgaXQgKGFkZCBhIHBsYW5lLCB0cnkgaXQgb3V0LCB3aW5kCj4gYmFjaykgaW5jcmVt ZW50YWxseS4gVXNpbmcgcHJvcGVydGllcyBtYWtlcyB0aGF0IHJlYWxseSBlYXN5LCBidXQKPiB3 aXRob3V0IHByb3BlcnRpZXMsIHdlJ2QgaGF2ZSB0byBhZGQgc2VwYXJhdGUgY29kZXBhdGhzIC0g YW5kIHRodXMKPiBzZXBhcmF0ZSBBQkksIHdoaWNoIGNvbXBsaWNhdGVzIGRpc3RyaWJ1dGlvbiAt IHRvIGxpYmRybSB0byBhY2NvdW50Cj4gZm9yIGEgc2VwYXJhdGUgcGxhbmUgYXJyYXkgd2hpY2gg c2hhcmVzIGEgY3Vyc29yIHdpdGggdGhlIHByb3BlcnRpZXMuCj4gU28gZm9yIHRoYXQgcmVhc29u IGlmIG5vbmUgb3RoZXIsIEknZCByZWFsbHkgcHJlZmVyIG5vdCB0byBnbyBkb3duCj4gdGhhdCBy b3V0ZS4KCkkgYWxzbyBhZ3JlZSB0byBoYXZlIGl0IGFzIEZFTkNFX0ZEIHByb3Agb24gdGhlIHBs YW5lLiBTdW1tYXJpemluZyB0aGUKYXJndW1lbnRzIG9uIHRoaXMgdGhyZWFkLCB0aGV5IGFyZToK CiAtIGltcGxpY2l0IGZlbmNlcyBhbHNvIG5lZWRzIG9uZSBmZW5jZSBwZXIgcGxhbmUvZmIsIHNv IGl0IHdpbGwgYmUgZ29vZCB0byAgICAgCiAgIG1hdGNoIHdpdGggdGhhdC4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAtIHJlcXVp cmVzIHVzZXJzcGFjZSB0byBhbHdheXMgbWVyZ2UgZmVuY2VzICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAtIGNhbiB1c2Ugc3RhbmRhcmQgcGxhbmUgcHJvcGVydGllcywgbWFr aW5nIGtlcm5lbCBhbmQgdXNlcnNwYWNlIGxpZmUgZWFzaWVyLCAgCiAgIGFuIGFycmF5IGJyaW5n cyBtb3JlIHdvcmsgdG8gYnVpbGQgdGhlIGF0b21pYyByZXF1ZXN0IHBsdXMgZXh0cmEgY2hlY2tp bmdzICAgCiAgIG9uIHRoZSBrZXJuZWwuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAtIGRvIG5vdCBuZWVkIHRvIGNoYW5nZXMg dG8gZHJpdmVycyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAt IGJldHRlciBmb3IgdHJhY2luZywgY2FuIGlkZW50aWZ5IHRoZSBidWZmZXIvZmVuY2UgcHJvbXB0 bHkKCglHdXN0YXZvCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9y ZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZl bAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752845AbcD1Ogv (ORCPT ); Thu, 28 Apr 2016 10:36:51 -0400 Received: from mail-yw0-f196.google.com ([209.85.161.196]:35262 "EHLO mail-yw0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752195AbcD1Ogt convert rfc822-to-8bit (ORCPT ); Thu, 28 Apr 2016 10:36:49 -0400 Date: Thu, 28 Apr 2016 11:36:44 -0300 From: Gustavo Padovan To: Daniel Stone Cc: 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: <20160428143644.GA3496@joana> 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: <20160426141422.GG7857@joana> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8BIT In-Reply-To: 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 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 - 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 Gustavo