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: Wed, 27 Apr 2016 08:39:04 +0200 Message-ID: <20160427063904.GH2558@phenom.ffwll.local> References: <20160426101050.GN4329@intel.com> <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-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) by gabe.freedesktop.org (Postfix) with ESMTPS id 737DC6E9CC for ; Wed, 27 Apr 2016 06:39:09 +0000 (UTC) Received: by mail-wm0-x22f.google.com with SMTP id n129so12514398wmn.1 for ; Tue, 26 Apr 2016 23:39:09 -0700 (PDT) Content-Disposition: inline In-Reply-To: <571FD402.6050407@google.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Greg Hackmann Cc: Daniel Stone , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Riley Andrews , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Gustavo Padovan , John Harrison List-Id: dri-devel@lists.freedesktop.org T24gVHVlLCBBcHIgMjYsIDIwMTYgYXQgMDE6NDg6MDJQTSAtMDcwMCwgR3JlZyBIYWNrbWFubiB3 cm90ZToKPiBPbiAwNC8yNi8yMDE2IDAxOjA1IFBNLCBEYW5pZWwgVmV0dGVyIHdyb3RlOgo+ID5P biBUdWUsIEFwciAyNiwgMjAxNiBhdCAwOTo1NTowNlBNICswMzAwLCBWaWxsZSBTeXJqw6Rsw6Qg d3JvdGU6Cj4gPj5PbiBUdWUsIEFwciAyNiwgMjAxNiBhdCAwODoyMzo0NlBNICswMjAwLCBEYW5p ZWwgVmV0dGVyIHdyb3RlOgo+ID4+Pk9uIFR1ZSwgQXByIDI2LCAyMDE2IGF0IDA4OjQwOjQ1UE0g KzAzMDAsIFZpbGxlIFN5cmrDpGzDpCB3cm90ZToKPiA+Pj5CdXQgcmVhbGx5IHRoZSByZWFzb24g Zm9yIHBlci1wbGFuZSBpcyBodyBjb21wb3NlciBmcm9tCj4gPj4+QW5kcm9pZC4gSSBkb24ndCBz ZWUgYW55IHBvaW50IGluIGRlc2lnbmluZyBhbiBhcGkgdGhhdCdzIG5lZWRsZXNzbHkKPiA+Pj5k aWZmZXJlbnQgZnJvbSB3aGF0IHRoZSBtYWluIHVzZXIgZXhwZWN0cyAoZXZlbiBpZiBpdCBtYXkg YmUgc2lsbHkpLgo+ID4+Cj4gPj5XaGF0IGFyZSB0aGV5IGRvaW5nIHRoYXQgY2FuJ3Qgc3R1ZmYg dGhlIGZlbmNlcyBpbnRvIGFuIGFycmF5Cj4gPj5pbnN0ZWFkIG9mIHByb3BzPwo+ID4KPiA+VGhl IGh3IGNvbXBvc2VyIGludGVyZmFjZSBpcyBvbmUgaW4tZmVuY2UgcGVyIHBsYW5lLiBUaGF0J3Mg cmVhbGx5IHRoZQo+ID5tYWpvciByZWFzb24gd2h5IHRoZSBrZXJuZWwgaW50ZXJmYWNlIGlzIGJ1 aWx0IHRvIG1hdGNoLiBBbmQgSSByZWFsbHkKPiA+ZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIGRpdmVy Z2UganVzdCBiZWNhdXNlIHdlIGhhdmUgYSBzbGlnaHQgZGlmZmVyZW50Cj4gPmNvbG9yIHByZWZl cmVuY2UgOy0pCj4gPgo+ID5BcyBsb25nIGFzIHlvdSBlbmQgdXAgd2l0aCBhIHBpbGUgb2YgZmVu Y2VzIHNvbWVob3cgaXQnbGwgd29yay4KPiA+LURhbmllbAo+ID4KPiAKPiBUaGUgcmVsYXRpb25z aGlwIGJldHdlZW4gbGF5ZXJzIGFuZCBmZW5jZXMgaXMgb25seSBmdXp6eSBhbmQgaW5kaXJlY3QK PiB0aG91Z2guICBUaGUgcmVsYXRpb25zaGlwIGlzIHJlYWxseSBiZXR3ZWVuIHRoZSBidWZmZXIg eW91J3JlIGRpc3BsYXlpbmcgb24KPiB0aGF0IGxheWVyLCBhbmQgdGhlIGZlbmNlIHJlcHJlc2Vu dGluZyB0aGUgd29yayBkb25lIHRvIHJlbmRlciBpbnRvIHRoYXQKPiBidWZmZXIuICBTdXJmYWNl RmxpbmdlciBqdXN0IGhhcHBlbnMgdG8gYnVuZGxlIHRoZW0gdG9nZXRoZXIgaW5zaWRlIHRoZSBz YW1lCj4gc3RydWN0IGh3Y19sYXllcl8xIGFzIGFuIEFQSSBjb252ZW5pZW5jZS4KPiAKPiBXaGlj aCBpcyBraW5kIG9mIHNwbGl0dGluZyBoYWlycyBhcyBsb25nIGFzIHlvdSBoYXZlIGEgMS10by0x IHJlbGF0aW9uc2hpcAo+IGJldHdlZW4gbGF5ZXJzIGFuZCBEUk0gcGxhbmVzLiAgQnV0IHRoYXQn cyBub3QgYWx3YXlzIHRoZSBjYXNlLgo+IAo+IEEgKHBlci1DUlRDPykgYXJyYXkgb2YgZmVuY2Vz IHdvdWxkIGJlIG1vcmUgZmxleGlibGUuICBBbmQgZXZlbiBpbiB0aGUgY2FzZXMKPiB3aGVyZSB5 b3UgY291bGQgbWFrZSBhIDEtdG8tMSBtYXBwaW5nIGJldHdlZW4gcGxhbmVzIGFuZCBmZW5jZXMs IGl0J3Mgbm90Cj4gdGhhdCBtdWNoIG1vcmUgd29yayBmb3IgdXNlcnNwYWNlIHRvIGFzc2VtYmxl IHRob3NlIGZlbmNlcyBpbnRvIGFuIGFycmF5Cj4gYW55d2F5LgoKSSdtIG9rIHdpdGggYW4gYXJy YXkgdG9vIGlmIHRoYXQncyB3aGF0IHlvdSBmb2xrcyBwcmVmZXIgKGl0J3MgbWVhbnQgdG8gYmUK dXNlZCBieSB5b3UgYWZ0ZXIgYWxsKS4gSSBqdXN0IGRvbid0IHdhbnQganVzdCAxIGZlbmNlIGZv ciB0aGUgZW50aXJlIG9wLApmb3JjaW5nIHVzZXJzcGFjZSB0byBmaXJzdCBtZXJnZSB0aGVtIGFs bCB0b2dldGhlci4gVGhhdCBzZWVtcyBzaWxseS4KCk9uZSBzaWRlLWVmZmVjdCBvZiB0aGF0IGlz IHRoYXQgd2UnZCBhbHNvIGhhdmUgdG8gcmV3b3JrIGFsbCB0aGUgaW50ZXJuYWwKYml0cyBhbmQg bW92ZSBmZW5jZXMgYXJvdW5kIGluIGF0b21pYy4gV2hpY2ggbWVhbnMgY2hhbmdlIGEgcGlsZSBv Zgpkcml2ZXJzLiBOb3Qgc3VyZSB0aGF0J3Mgd29ydGggaXQsIGJ1dCBJJ2QgYmUgb2sgZWl0aGVy IHdheSByZWFsbHkuCi1EYW5pZWwKLS0gCkRhbmllbCBWZXR0ZXIKU29mdHdhcmUgRW5naW5lZXIs IEludGVsIENvcnBvcmF0aW9uCmh0dHA6Ly9ibG9nLmZmd2xsLmNoCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJp LWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753088AbcD0GjL (ORCPT ); Wed, 27 Apr 2016 02:39:11 -0400 Received: from mail-wm0-f42.google.com ([74.125.82.42]:37515 "EHLO mail-wm0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752147AbcD0GjJ (ORCPT ); Wed, 27 Apr 2016 02:39:09 -0400 Date: Wed, 27 Apr 2016 08:39:04 +0200 From: Daniel Vetter To: Greg Hackmann Cc: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , Gustavo Padovan , Gustavo Padovan , Daniel Stone , Riley Andrews , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Arve =?iso-8859-1?B?SGr4bm5lduVn?= , John Harrison Subject: Re: [RFC v2 5/8] drm/fence: add in-fences support Message-ID: <20160427063904.GH2558@phenom.ffwll.local> Mail-Followup-To: Greg Hackmann , Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , Gustavo Padovan , Gustavo Padovan , Daniel Stone , Riley Andrews , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Arve =?iso-8859-1?B?SGr4bm5lduVn?= , John Harrison References: <20160426101050.GN4329@intel.com> <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: <571FD402.6050407@google.com> 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 Tue, Apr 26, 2016 at 01:48:02PM -0700, 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: > >>On Tue, Apr 26, 2016 at 08:23:46PM +0200, Daniel Vetter wrote: > >>>On Tue, Apr 26, 2016 at 08:40:45PM +0300, Ville Syrjälä wrote: > >>>But really the reason for per-plane is hw composer from > >>>Android. I don't see any point in designing an api that's needlessly > >>>different from what the main user expects (even if it may be silly). > >> > >>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 ;-) > > > >As long as you end up with a pile of fences somehow it'll work. > >-Daniel > > > > 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. > > 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. > > 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. I'm ok with an array too if that's what you folks prefer (it's meant to be used by you after all). I just don't want just 1 fence for the entire op, forcing userspace to first merge them all together. That seems silly. One side-effect of that is that we'd also have to rework all the internal bits and move fences around in atomic. Which means change a pile of drivers. Not sure that's worth it, but I'd be ok either way really. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch