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 21:17:29 +0300 Message-ID: <20160428181729.GH4329@intel.com> References: <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> <20160428165619.GD4329@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTP id 116EF6E3DE for ; Thu, 28 Apr 2016 18:17:34 +0000 (UTC) Content-Disposition: inline In-Reply-To: <20160428165619.GD4329@intel.com> 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 T24gVGh1LCBBcHIgMjgsIDIwMTYgYXQgMDc6NTY6MTlQTSArMDMwMCwgVmlsbGUgU3lyasOkbMOk IHdyb3RlOgo+IE9uIFRodSwgQXByIDI4LCAyMDE2IGF0IDExOjM2OjQ0QU0gLTAzMDAsIEd1c3Rh dm8gUGFkb3ZhbiB3cm90ZToKPiA+IDIwMTYtMDQtMjcgRGFuaWVsIFN0b25lIDxkYW5pZWxAZm9v aXNoYmFyLm9yZz46Cj4gPiAKPiA+ID4gSGksCj4gPiA+IAo+ID4gPiBPbiAyNiBBcHJpbCAyMDE2 IGF0IDIxOjQ4LCBHcmVnIEhhY2ttYW5uIDxnaGFja21hbm5AZ29vZ2xlLmNvbT4gd3JvdGU6Cj4g PiA+ID4gT24gMDQvMjYvMjAxNiAwMTowNSBQTSwgRGFuaWVsIFZldHRlciB3cm90ZToKPiA+ID4g Pj4gT24gVHVlLCBBcHIgMjYsIDIwMTYgYXQgMDk6NTU6MDZQTSArMDMwMCwgVmlsbGUgU3lyasOk bMOkIHdyb3RlOgo+ID4gPiA+Pj4gV2hhdCBhcmUgdGhleSBkb2luZyB0aGF0IGNhbid0IHN0dWZm IHRoZSBmZW5jZXMgaW50byBhbiBhcnJheQo+ID4gPiA+Pj4gaW5zdGVhZCBvZiBwcm9wcz8KPiA+ ID4gPj4KPiA+ID4gPj4gVGhlIGh3IGNvbXBvc2VyIGludGVyZmFjZSBpcyBvbmUgaW4tZmVuY2Ug cGVyIHBsYW5lLiBUaGF0J3MgcmVhbGx5IHRoZQo+ID4gPiA+PiBtYWpvciByZWFzb24gd2h5IHRo ZSBrZXJuZWwgaW50ZXJmYWNlIGlzIGJ1aWx0IHRvIG1hdGNoLiBBbmQgSSByZWFsbHkKPiA+ID4g Pj4gZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIGRpdmVyZ2UganVzdCBiZWNhdXNlIHdlIGhhdmUgYSBz bGlnaHQgZGlmZmVyZW50Cj4gPiA+ID4+IGNvbG9yIHByZWZlcmVuY2UgOy0pCj4gPiA+ID4KPiA+ ID4gPiBUaGUgcmVsYXRpb25zaGlwIGJldHdlZW4gbGF5ZXJzIGFuZCBmZW5jZXMgaXMgb25seSBm dXp6eSBhbmQgaW5kaXJlY3QKPiA+ID4gPiB0aG91Z2guICBUaGUgcmVsYXRpb25zaGlwIGlzIHJl YWxseSBiZXR3ZWVuIHRoZSBidWZmZXIgeW91J3JlIGRpc3BsYXlpbmcgb24KPiA+ID4gPiB0aGF0 IGxheWVyLCBhbmQgdGhlIGZlbmNlIHJlcHJlc2VudGluZyB0aGUgd29yayBkb25lIHRvIHJlbmRl ciBpbnRvIHRoYXQKPiA+ID4gPiBidWZmZXIuICBTdXJmYWNlRmxpbmdlciBqdXN0IGhhcHBlbnMg dG8gYnVuZGxlIHRoZW0gdG9nZXRoZXIgaW5zaWRlIHRoZSBzYW1lCj4gPiA+ID4gc3RydWN0IGh3 Y19sYXllcl8xIGFzIGFuIEFQSSBjb252ZW5pZW5jZS4KPiA+ID4gCj4gPiA+IFJpZ2h0LCBhbmQg d2hlbiB1c2luZyBpbXBsaWNpdCBmZW5jaW5nLCB0aGlzIGNvbWVzIGFzIGEgcGxhbmUKPiA+ID4g cHJvcGVydHksIGJ5IHZpcnR1ZSBvZiBwbGFuZSAtPiBmYiAtPiBidWZmZXIgLT4gZmVuY2UuCj4g PiA+IAo+ID4gPiA+IFdoaWNoIGlzIGtpbmQgb2Ygc3BsaXR0aW5nIGhhaXJzIGFzIGxvbmcgYXMg eW91IGhhdmUgYSAxLXRvLTEgcmVsYXRpb25zaGlwCj4gPiA+ID4gYmV0d2VlbiBsYXllcnMgYW5k IERSTSBwbGFuZXMuICBCdXQgdGhhdCdzIG5vdCBhbHdheXMgdGhlIGNhc2UuCj4gPiA+IAo+ID4g PiBDYW4geW91IHBsZWFzZSBlbGFib3JhdGU/Cj4gPiA+IAo+ID4gPiA+IEEgKHBlci1DUlRDPykg YXJyYXkgb2YgZmVuY2VzIHdvdWxkIGJlIG1vcmUgZmxleGlibGUuICBBbmQgZXZlbiBpbiB0aGUg Y2FzZXMKPiA+ID4gPiB3aGVyZSB5b3UgY291bGQgbWFrZSBhIDEtdG8tMSBtYXBwaW5nIGJldHdl ZW4gcGxhbmVzIGFuZCBmZW5jZXMsIGl0J3Mgbm90Cj4gPiA+ID4gdGhhdCBtdWNoIG1vcmUgd29y ayBmb3IgdXNlcnNwYWNlIHRvIGFzc2VtYmxlIHRob3NlIGZlbmNlcyBpbnRvIGFuIGFycmF5Cj4g PiA+ID4gYW55d2F5Lgo+ID4gPiAKPiA+ID4gQXMgVmlsbGUgc2F5cywgSSBkb24ndCB3YW50IHRv IGdvIGRvd24gdGhlIHBhdGggb2Ygc2NoZWR1bGluZyBDUlRDCj4gPiA+IHVwZGF0ZXMgc2VwYXJh dGVseSwgYmVjYXVzZSB0aGF0IGJyZWFrcyBNU1QgcHJldHR5IGJhZGx5LiBJZiB5b3UgZG9uJ3QK PiA+ID4gd2FudCB5b3VyIHVwZGF0ZXMgdG8gZGlzcGxheSBhdG9taWNhbGx5LCB0aGVuIGRvbid0 IHNjaGVkdWxlIHRoZW0KPiA+ID4gYXRvbWljYWxseSAuLi4gPyBUaGF0J3MgdGhlIG9ubHkgcmVh c29uIEkgY2FuIHNlZSBmb3IgbWFraW5nIGZlbmNpbmcKPiA+ID4gcGVyLUNSVEMsIHJhdGhlciB0 aGFuIGp1c3QgYSBwaWxlIG9mIHVuYXNzb2NpYXRlZCBmZW5jZXMgYXBwZW5kZWQgdG8KPiA+ID4g dGhlIHJlcXVlc3QuIFBlci1DUlRDIGZlbmNlcyBhbHNvIGZvcmNlcyB1c2Vyc3BhY2UgdG8gbWVy Z2UgZmVuY2VzCj4gPiA+IGJlZm9yZSBzdWJtaXNzaW9uIHdoZW4gdXNpbmcgbXVsdGlwbGUgcGxh bmVzIHBlciBDUlRDLCB3aGljaCBpcyBwcmV0dHkKPiA+ID4gcHVuaXRpdmUuCj4gPiA+IAo+ID4g PiBJIHRoaW5rIGhhdmluZyBpdCBzZW1hbnRpY2FsbHkgYXR0YWNoZWQgdG8gdGhlIHBsYW5lIGlz IGEgbGl0dGxlIGJpdAo+ID4gPiBuaWNlciBmb3IgdHJhY2luZyAod2h5IHdhcyB0aGlzIHJlcXVl c3QgZGVsYXllZD8gLT4gYSBmZW5jZSAtPiB3aGljaAo+ID4gPiBidWZmZXIgd2FzIHRoYXQgZmVu Y2UgZm9yPykgYXQgYSBnbGFuY2UuIEFsc28gdGhlICdwaWxlIG9mIGFwcGVuZGVkCj4gPiA+IGZl bmNlcycgbW9kZWwgaXMgYSBiaXQgYXdrd2FyZCBmb3IgbW9yZSBnZW5lcmljIHVzZXJzcGFjZSwg d2hpY2gKPiA+ID4gY3JlYXRlcyBhIGxpYmRybSByZXF1ZXN0IGFuZCBidWlsZHMgaXQgKGFkZCBh IHBsYW5lLCB0cnkgaXQgb3V0LCB3aW5kCj4gPiA+IGJhY2spIGluY3JlbWVudGFsbHkuIFVzaW5n IHByb3BlcnRpZXMgbWFrZXMgdGhhdCByZWFsbHkgZWFzeSwgYnV0Cj4gPiA+IHdpdGhvdXQgcHJv cGVydGllcywgd2UnZCBoYXZlIHRvIGFkZCBzZXBhcmF0ZSBjb2RlcGF0aHMgLSBhbmQgdGh1cwo+ ID4gPiBzZXBhcmF0ZSBBQkksIHdoaWNoIGNvbXBsaWNhdGVzIGRpc3RyaWJ1dGlvbiAtIHRvIGxp YmRybSB0byBhY2NvdW50Cj4gPiA+IGZvciBhIHNlcGFyYXRlIHBsYW5lIGFycmF5IHdoaWNoIHNo YXJlcyBhIGN1cnNvciB3aXRoIHRoZSBwcm9wZXJ0aWVzLgo+ID4gPiBTbyBmb3IgdGhhdCByZWFz b24gaWYgbm9uZSBvdGhlciwgSSdkIHJlYWxseSBwcmVmZXIgbm90IHRvIGdvIGRvd24KPiA+ID4g dGhhdCByb3V0ZS4KPiA+IAo+ID4gSSBhbHNvIGFncmVlIHRvIGhhdmUgaXQgYXMgRkVOQ0VfRkQg cHJvcCBvbiB0aGUgcGxhbmUuIFN1bW1hcml6aW5nIHRoZQo+ID4gYXJndW1lbnRzIG9uIHRoaXMg dGhyZWFkLCB0aGV5IGFyZToKPiAKPiBZb3VyICJzdW1tYXJ5IiBmb3Jnb3QgdG8gaW5jbHVkZSBh bnkgY291bnRlciBhcmd1bWVudHMuCj4gCj4gPiAKPiA+ICAtIGltcGxpY2l0IGZlbmNlcyBhbHNv IG5lZWRzIG9uZSBmZW5jZSBwZXIgcGxhbmUvZmIsIHNvIGl0IHdpbGwgYmUgZ29vZCB0byAgICAg Cj4gPiAgICBtYXRjaCB3aXRoIHRoYXQuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAo+IAo+IFdlIHdvdWxkIGFjdHVhbGx5IG5lZWQg YSBmZW5jZSBwZXIgb2JqZWN0IHJhdGhlciB0aGFuIHBlciBmYi4KCkkgZ3Vlc3MgeW91IGNvdWxk IG92ZXJjb21lIHRoaXMgYnkgYXV0b21hZ2ljYWxseSBjcmVhdGluZyBhIG1lcmdlZCBmZW5jZQpm b3IgYSBtdWx0aS1vYmogZmI/CgotLSAKVmlsbGUgU3lyasOkbMOkCkludGVsIE9UQwpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGlu ZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVl ZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752666AbcD1SRy (ORCPT ); Thu, 28 Apr 2016 14:17:54 -0400 Received: from mga11.intel.com ([192.55.52.93]:39905 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752593AbcD1SRx (ORCPT ); Thu, 28 Apr 2016 14:17:53 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,547,1455004800"; d="scan'208";a="968603297" Date: Thu, 28 Apr 2016 21:17:29 +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: <20160428181729.GH4329@intel.com> References: <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> <20160428165619.GD4329@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160428165619.GD4329@intel.com> 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 07:56:19PM +0300, Ville Syrjälä wrote: > 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. I guess you could overcome this by automagically creating a merged fence for a multi-obj fb? -- Ville Syrjälä Intel OTC