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: Tue, 26 Apr 2016 21:55:06 +0300 Message-ID: <20160426185506.GH4329@intel.com> References: <1461623608-29538-1-git-send-email-gustavo@padovan.org> <1461623608-29538-6-git-send-email-gustavo@padovan.org> <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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by gabe.freedesktop.org (Postfix) with ESMTP id 231126E904 for ; Tue, 26 Apr 2016 18:55:12 +0000 (UTC) Content-Disposition: inline In-Reply-To: <20160426182346.GC2558@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: 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 List-Id: dri-devel@lists.freedesktop.org T24gVHVlLCBBcHIgMjYsIDIwMTYgYXQgMDg6MjM6NDZQTSArMDIwMCwgRGFuaWVsIFZldHRlciB3 cm90ZToKPiBPbiBUdWUsIEFwciAyNiwgMjAxNiBhdCAwODo0MDo0NVBNICswMzAwLCBWaWxsZSBT eXJqw6Rsw6Qgd3JvdGU6Cj4gPiBPbiBUdWUsIEFwciAyNiwgMjAxNiBhdCAwNzoyMDo0OVBNICsw MjAwLCBEYW5pZWwgVmV0dGVyIHdyb3RlOgo+ID4gPiBPbiBUdWUsIEFwciAyNiwgMjAxNiBhdCAw NzoyNjoyMVBNICswMzAwLCBWaWxsZSBTeXJqw6Rsw6Qgd3JvdGU6Cj4gPiA+ID4gT24gVHVlLCBB cHIgMjYsIDIwMTYgYXQgMDQ6MzY6MzZQTSArMDIwMCwgRGFuaWVsIFZldHRlciB3cm90ZToKPiA+ ID4gPiA+IE9uIFR1ZSwgQXByIDI2LCAyMDE2IGF0IDExOjE0OjIyQU0gLTAzMDAsIEd1c3Rhdm8g UGFkb3ZhbiB3cm90ZToKPiA+ID4gPiA+ID4gMjAxNi0wNC0yNiBWaWxsZSBTeXJqw6Rsw6QgPHZp bGxlLnN5cmphbGFAbGludXguaW50ZWwuY29tPjoKPiA+ID4gPiA+ID4gCj4gPiA+ID4gPiA+ID4g T24gTW9uLCBBcHIgMjUsIDIwMTYgYXQgMDc6MzM6MjVQTSAtMDMwMCwgR3VzdGF2byBQYWRvdmFu IHdyb3RlOgo+ID4gPiA+ID4gPiA+ID4gRnJvbTogR3VzdGF2byBQYWRvdmFuIDxndXN0YXZvLnBh ZG92YW5AY29sbGFib3JhLmNvLnVrPgo+ID4gPiA+ID4gPiA+ID4gCj4gPiA+ID4gPiA+ID4gPiBU aGVyZSBpcyBub3cgYSBuZXcgcHJvcGVydHkgY2FsbGVkIEZFTkNFX0ZEIGF0dGFjaGVkIHRvIGV2 ZXJ5IHBsYW5lCj4gPiA+ID4gPiA+ID4gPiBzdGF0ZSB0aGF0IHJlY2VpdmVzIHRoZSBzeW5jX2Zp bGUgZmQgZnJvbSB1c2Vyc3BhY2UgdmlhIHRoZSBhdG9taWMgY29tbWl0Cj4gPiA+ID4gPiA+ID4g PiBJT0NUTC4KPiA+ID4gPiA+ID4gPiAKPiA+ID4gPiA+ID4gPiBJIHN0aWxsIGRvbid0IGxpa2Ug dGhpcyBwcm9wZXJ0eSBhYnVzZS4gQWxzbyB3aXRoIGF0b21pYywgYWxsIHBhc3NlZAo+ID4gPiA+ ID4gPiA+IGZlbmNlcyBtdXN0IGJlIHdhaXRlZCB1cG9uIGJlZm9yZSBhbnl0aGluZyBpcyBkb25l LCBzbyBhdHRhY2hpbmcgdGhlbQo+ID4gPiA+ID4gPiA+IHRvIHBsYW5lcyBzZWVtcyBsaWtlIGl0 IG1pZ2h0IGp1c3QgZ2l2ZSBwZW9wbGUgdGhlIHdyb25nIGlkZWEuCj4gPiA+ID4gPiA+IAo+ID4g PiA+ID4gPiBJJ20gYWN0dWFsbHkgZmluZSB3aXRoIHRoaXMgYXMgcHJvcGVydHksIGJ1dCBhbm90 aGVyIHNvbHV0aW9ucyBpcyB1c2UKPiA+ID4gPiA+ID4gYW4gYXJyYXkgb2Yge3BsYW5lLCBmZW5j ZV9mZH0gYW5kIGV4dGVuZCBkcm1fYXRvbWljX2lvY3RsIGFyZ3MganVzdCBsaWtlCj4gPiA+ID4g PiA+IHdlIGhhdmUgZG9uZSBmb3Igb3V0IGZlbmNlcy4gSG93ZXZlciB0aGUgRkVOQ0VfRkQgcHJv cGVydHkgaXMgZWFzaWVyIHRvCj4gPiA+ID4gPiA+IGhhbmRsZSBpbiB1c2Vyc3BhY2UgdGhhbiB0 aGUgYXJyYXkuIEFueSBvdGhlciBpZGVhPwo+ID4gPiA+ID4gCj4gPiA+ID4gPiBJbW8gRkVOQ0Vf RkQgaXMgcGVyZmVjdGx5IGZpbmUuIEJ1dCB3aGF0J3MgdGhlIGNvbmNlcm4gYXJvdW5kIGdpdmlu Zwo+ID4gPiA+ID4gcGVvcGxlIHRoZSB3cm9uZyBpZGVhIHdpdGggYXR0YWNoaW5nIGZlbmNlcyB0 byBwbGFuZXM/IEZvciBub25ibG9ja2luZwo+ID4gPiA+ID4gY29tbWl0cyB3ZSBuZWVkIHRvIHN0 b3JlIHRoZW0gc29tZXdoZXJlIGZvciB0aGUgd29ya2VyLCBkcm1fcGxhbmVfc3RhdGUKPiA+ID4g PiA+IHNlZW1zIGxpa2UgYW4gYXMgZ29vZCBwbGFjZSBhcyBhbnkgb3RoZXIuCj4gPiA+ID4gCj4g PiA+ID4gSXQgZ2l2ZXMgdGhlIGltcHJlc3Npb24gdGhhdCBlYWNoIHBsYW5lIG1pZ2h0IGZsaXAg YXMgc29vbiBhcyBpdHMgZmVuY2UKPiA+ID4gPiBzaWduYWxzLgo+ID4gPiAKPiA+ID4gVGhhdCB3 b3VsZG4ndCBiZSBhdG9taWMuIE5vdCBzdXJlIGhvdyBzb21lb25lIGNvdWxkIGNvbWUgdXAgd2l0 aCB0aGF0Cj4gPiA+IGlkZWEuCj4gPiAKPiA+IFdoYXQgZWxzZSB3b3VsZCBpdCBtZWFuPyBJdCdz IGF0dGFjaGVkIHRvIGEgc3BlY2lmaWMgcGxhbmUsIHNvIHdoeSB3b3VsZAo+ID4gaXQgYWZmZWN0 IG90aGVyIHBsYW5lcz8KPiA+IAo+ID4gPiBJIG1lYW4gd2UgY291bGQgbW92ZSBGRU5DRV9GRCB0 byB0aGUgY3J0YyAoZmVuY2UgZmRzIGNhbiBiZSBtZXJnZWQpLAo+ID4gPiBidXQgdGhhdCdzIGp1 c3QgYSBuZWVkbGVzcyBkaWZmZXJlbmNlIHRvIHdoYXQgaHdjIGV4cGVjdHMuIEkgdGhpbmsKPiA+ ID4gYWxpZ25pbmcgd2l0aCB0aGUgb25seSByZWFsLXdvcmxkIHVzZXJzIGluIHRoaXMgY2FzZSBo ZXJlIG1ha2VzIHNlbnNlLgo+ID4gCj4gPiBXZWxsIGl0IGRvZXNuJ3QgYmVsb25nIG9uIHRoZSBj cnRjIGVpdGhlci4gSSB3b3VsZCBqdXN0IHN0aWNrIGluIHRoZQo+ID4gaW9jdGwgYXMgYSBzZXBh cmF0ZSB0aGluZywgdGhlbiBpdCdzIGNsZWFyIGl0J3MgcmVsYXRlZCB0byB0aGUgd2hvbGUKPiA+ IG9wZXJhdGlvbiByYXRoZXIgdGhhbiBhbnkga21zIG9iamVjdC4KPiAKPiBXZSB3YW50IGl0IHBl ci1jcnRjIEknZCBzYXksIHNvIHRoYXQgeW91IGNvdWxkIGZsaXAgZWFjaCBjcnRjCj4gaW5kaXZp ZHVhbGx5LgoKVGhlbiB5b3UgY291bGQganVzdCBpc3N1ZSBtdWx0aXBsZSBpb2N0bHMuIEZvciBl Zy4gdGhvc2UgbmFzdHkgNGsgTVNUCmRpc3BsYXkgKG9yIGp1c3Qgb3RoZXJ3aXNlIG5lYXRseSBz eW5jZWQgZGlzcGxheWVzKSB5b3Ugd2FudCB0byB3YWl0IGZvcgphbGwgdGhlIGZlbmNlcyB1cGZy b250IGFuZCB0aGUgZmxpcCBldmVyeXRoaW5nIGF0IG9uY2UsIG90aGVyd2lzZSB5b3UnbGwKZ2V0 IG5hc3R5IHRlYXJzIGF0IHRoZSBzZWFtcy4KCj4gQnV0IHJlYWxseSB0aGUgcmVhc29uIGZvciBw ZXItcGxhbmUgaXMgaHcgY29tcG9zZXIgZnJvbQo+IEFuZHJvaWQuIEkgZG9uJ3Qgc2VlIGFueSBw b2ludCBpbiBkZXNpZ25pbmcgYW4gYXBpIHRoYXQncyBuZWVkbGVzc2x5Cj4gZGlmZmVyZW50IGZy b20gd2hhdCB0aGUgbWFpbiB1c2VyIGV4cGVjdHMgKGV2ZW4gaWYgaXQgbWF5IGJlIHNpbGx5KS4K CldoYXQgYXJlIHRoZXkgZG9pbmcgdGhhdCBjYW4ndCBzdHVmZiB0aGUgZmVuY2VzIGludG8gYW4g YXJyYXkKaW5zdGVhZCBvZiBwcm9wcz8KCj4gCj4gVGhlIG90aGVyIGJpdCBpcyB0aGF0IGZvciBp bXBsaWNpdCBzeW5jaW5nIHlvdSBuZWVkIG9uZSBmZW5jZSBwZXIgZmIvcGxhbmUKPiBhbnl3YXks IHNvIHRoaXMgYWxzbyBmaXRzIG5pY2VseSBvbiB0aGUgZHJpdmVyIHNpZGUgSSB0aGluay4KPiAK PiA+ID4gUGx1cyBkb2NzIGluIGNhc2Ugc29tZW9uZSBoYXMgZnVubnkgaWRlYXMuCj4gPiAKPiA+ IFdlcmVuJ3QgeW91IGp1c3QgcXVvdGluZyBydXN0eSdzIEFQSSBtYW5pZmVzdG8gcmVjZW50bHk/ IDspCj4gCj4gSSBxdW90ZSBpdCBhbGwgdGhlIHRpbWUuCj4gCj4gaHR0cDovL3N3ZW5nLnRoZS1k YXZpZXMubmV0L0hvbWUvcnVzdHlzLWFwaS1kZXNpZ24tbWFuaWZlc3RvCj4gCj4gSSB0aGluayBj dXJyZW50IGludGVyZmFjZSBpcyBzY29yaW5nIHByZXR0eSBoaWdoIHNpbmNlIGFzIHBhcnQgb2YK PiBHdXN0YXZvJ3Mgd29yayB0aGVyZSdzIG5vIGFsc28gYSBuZXcgYXRvbWljIGhlbHBlciB3aGlj aCB3aWxsIGdldCB0aGUKPiB3YWl0aW5nIHJpZ2h0LiBUaGVyZSdzIHN0aWxsIHRoZSBwcm9ibGVt IHRoYXQgbmVpdGhlciBmb3IgZHJtX2V2ZW50IG5vcgo+IHRoZSBmZW5jZSBkbyB3ZSBoYXZlIGFu eXRoaW5nIGlkaW90LXByb29mLiBTbyBmb3IgdGhhdCB0aGUgc29sdXRpb24gaXMKPiB0ZXN0Y2Fz ZXMgKHdoaWNoIGFyZSBhbHNvIGhhcHBlbmluZykuCj4gLURhbmllbAo+IC0tIAo+IERhbmllbCBW ZXR0ZXIKPiBTb2Z0d2FyZSBFbmdpbmVlciwgSW50ZWwgQ29ycG9yYXRpb24KPiBodHRwOi8vYmxv Zy5mZndsbC5jaAoKLS0gClZpbGxlIFN5cmrDpGzDpApJbnRlbCBPVEMKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApk cmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlzdHMuZnJlZWRlc2t0b3Au b3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752455AbcDZSzO (ORCPT ); Tue, 26 Apr 2016 14:55:14 -0400 Received: from mga04.intel.com ([192.55.52.120]:61336 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752194AbcDZSzM (ORCPT ); Tue, 26 Apr 2016 14:55:12 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,537,1455004800"; d="scan'208";a="963230759" Date: Tue, 26 Apr 2016 21:55:06 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: 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: <20160426185506.GH4329@intel.com> References: <1461623608-29538-1-git-send-email-gustavo@padovan.org> <1461623608-29538-6-git-send-email-gustavo@padovan.org> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160426182346.GC2558@phenom.ffwll.local> 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 08:23:46PM +0200, Daniel Vetter wrote: > On Tue, Apr 26, 2016 at 08:40:45PM +0300, Ville Syrjälä wrote: > > On Tue, Apr 26, 2016 at 07:20:49PM +0200, Daniel Vetter wrote: > > > On Tue, Apr 26, 2016 at 07:26:21PM +0300, Ville Syrjälä wrote: > > > > On Tue, Apr 26, 2016 at 04:36:36PM +0200, Daniel Vetter wrote: > > > > > On Tue, Apr 26, 2016 at 11:14:22AM -0300, Gustavo Padovan wrote: > > > > > > 2016-04-26 Ville Syrjälä : > > > > > > > > > > > > > On Mon, Apr 25, 2016 at 07:33:25PM -0300, Gustavo Padovan wrote: > > > > > > > > From: Gustavo Padovan > > > > > > > > > > > > > > > > There is now a new property called FENCE_FD attached to every plane > > > > > > > > state that receives the sync_file fd from userspace via the atomic commit > > > > > > > > IOCTL. > > > > > > > > > > > > > > I still don't like this property abuse. Also with atomic, all passed > > > > > > > fences must be waited upon before anything is done, so attaching them > > > > > > > to planes seems like it might just give people the wrong idea. > > > > > > > > > > > > I'm actually fine with this as property, but another solutions is use > > > > > > an array of {plane, fence_fd} and extend drm_atomic_ioctl args just like > > > > > > we have done for out fences. However the FENCE_FD property is easier to > > > > > > handle in userspace than the array. Any other idea? > > > > > > > > > > Imo FENCE_FD is perfectly fine. But what's the concern around giving > > > > > people the wrong idea with attaching fences to planes? For nonblocking > > > > > commits we need to store them somewhere for the worker, drm_plane_state > > > > > seems like an as good place as any other. > > > > > > > > It gives the impression that each plane might flip as soon as its fence > > > > signals. > > > > > > That wouldn't be atomic. Not sure how someone could come up with that > > > idea. > > > > What else would it mean? It's attached to a specific plane, so why would > > it affect other planes? > > > > > I mean we could move FENCE_FD to the crtc (fence fds can be merged), > > > but that's just a needless difference to what hwc expects. I think > > > aligning with the only real-world users in this case here makes sense. > > > > Well it doesn't belong on the crtc either. I would just stick in the > > ioctl as a separate thing, then it's clear it's related to the whole > > operation rather than any kms object. > > We want it per-crtc I'd say, so that you could flip each crtc > individually. Then you could just issue multiple ioctls. For eg. those nasty 4k MST display (or just otherwise neatly synced displayes) you want to wait for all the fences upfront and the flip everything at once, otherwise you'll get nasty tears at the seams. > 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 other bit is that for implicit syncing you need one fence per fb/plane > anyway, so this also fits nicely on the driver side I think. > > > > Plus docs in case someone has funny ideas. > > > > Weren't you just quoting rusty's API manifesto recently? ;) > > I quote it all the time. > > http://sweng.the-davies.net/Home/rustys-api-design-manifesto > > I think current interface is scoring pretty high since as part of > Gustavo's work there's no also a new atomic helper which will get the > waiting right. There's still the problem that neither for drm_event nor > the fence do we have anything idiot-proof. So for that the solution is > testcases (which are also happening). > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Ville Syrjälä Intel OTC