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: Tue, 26 Apr 2016 20:23:46 +0200 Message-ID: <20160426182346.GC2558@phenom.ffwll.local> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7D07D6E186 for ; Tue, 26 Apr 2016 18:23:51 +0000 (UTC) Received: by mail-wm0-x22c.google.com with SMTP id u206so17557422wme.1 for ; Tue, 26 Apr 2016 11:23:51 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20160426174045.GC4329@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= 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 T24gVHVlLCBBcHIgMjYsIDIwMTYgYXQgMDg6NDA6NDVQTSArMDMwMCwgVmlsbGUgU3lyasOkbMOk IHdyb3RlOgo+IE9uIFR1ZSwgQXByIDI2LCAyMDE2IGF0IDA3OjIwOjQ5UE0gKzAyMDAsIERhbmll bCBWZXR0ZXIgd3JvdGU6Cj4gPiBPbiBUdWUsIEFwciAyNiwgMjAxNiBhdCAwNzoyNjoyMVBNICsw MzAwLCBWaWxsZSBTeXJqw6Rsw6Qgd3JvdGU6Cj4gPiA+IE9uIFR1ZSwgQXByIDI2LCAyMDE2IGF0 IDA0OjM2OjM2UE0gKzAyMDAsIERhbmllbCBWZXR0ZXIgd3JvdGU6Cj4gPiA+ID4gT24gVHVlLCBB cHIgMjYsIDIwMTYgYXQgMTE6MTQ6MjJBTSAtMDMwMCwgR3VzdGF2byBQYWRvdmFuIHdyb3RlOgo+ ID4gPiA+ID4gMjAxNi0wNC0yNiBWaWxsZSBTeXJqw6Rsw6QgPHZpbGxlLnN5cmphbGFAbGludXgu aW50ZWwuY29tPjoKPiA+ID4gPiA+IAo+ID4gPiA+ID4gPiBPbiBNb24sIEFwciAyNSwgMjAxNiBh dCAwNzozMzoyNVBNIC0wMzAwLCBHdXN0YXZvIFBhZG92YW4gd3JvdGU6Cj4gPiA+ID4gPiA+ID4g RnJvbTogR3VzdGF2byBQYWRvdmFuIDxndXN0YXZvLnBhZG92YW5AY29sbGFib3JhLmNvLnVrPgo+ ID4gPiA+ID4gPiA+IAo+ID4gPiA+ID4gPiA+IFRoZXJlIGlzIG5vdyBhIG5ldyBwcm9wZXJ0eSBj YWxsZWQgRkVOQ0VfRkQgYXR0YWNoZWQgdG8gZXZlcnkgcGxhbmUKPiA+ID4gPiA+ID4gPiBzdGF0 ZSB0aGF0IHJlY2VpdmVzIHRoZSBzeW5jX2ZpbGUgZmQgZnJvbSB1c2Vyc3BhY2UgdmlhIHRoZSBh dG9taWMgY29tbWl0Cj4gPiA+ID4gPiA+ID4gSU9DVEwuCj4gPiA+ID4gPiA+IAo+ID4gPiA+ID4g PiBJIHN0aWxsIGRvbid0IGxpa2UgdGhpcyBwcm9wZXJ0eSBhYnVzZS4gQWxzbyB3aXRoIGF0b21p YywgYWxsIHBhc3NlZAo+ID4gPiA+ID4gPiBmZW5jZXMgbXVzdCBiZSB3YWl0ZWQgdXBvbiBiZWZv cmUgYW55dGhpbmcgaXMgZG9uZSwgc28gYXR0YWNoaW5nIHRoZW0KPiA+ID4gPiA+ID4gdG8gcGxh bmVzIHNlZW1zIGxpa2UgaXQgbWlnaHQganVzdCBnaXZlIHBlb3BsZSB0aGUgd3JvbmcgaWRlYS4K PiA+ID4gPiA+IAo+ID4gPiA+ID4gSSdtIGFjdHVhbGx5IGZpbmUgd2l0aCB0aGlzIGFzIHByb3Bl cnR5LCBidXQgYW5vdGhlciBzb2x1dGlvbnMgaXMgdXNlCj4gPiA+ID4gPiBhbiBhcnJheSBvZiB7 cGxhbmUsIGZlbmNlX2ZkfSBhbmQgZXh0ZW5kIGRybV9hdG9taWNfaW9jdGwgYXJncyBqdXN0IGxp a2UKPiA+ID4gPiA+IHdlIGhhdmUgZG9uZSBmb3Igb3V0IGZlbmNlcy4gSG93ZXZlciB0aGUgRkVO Q0VfRkQgcHJvcGVydHkgaXMgZWFzaWVyIHRvCj4gPiA+ID4gPiBoYW5kbGUgaW4gdXNlcnNwYWNl IHRoYW4gdGhlIGFycmF5LiBBbnkgb3RoZXIgaWRlYT8KPiA+ID4gPiAKPiA+ID4gPiBJbW8gRkVO Q0VfRkQgaXMgcGVyZmVjdGx5IGZpbmUuIEJ1dCB3aGF0J3MgdGhlIGNvbmNlcm4gYXJvdW5kIGdp dmluZwo+ID4gPiA+IHBlb3BsZSB0aGUgd3JvbmcgaWRlYSB3aXRoIGF0dGFjaGluZyBmZW5jZXMg dG8gcGxhbmVzPyBGb3Igbm9uYmxvY2tpbmcKPiA+ID4gPiBjb21taXRzIHdlIG5lZWQgdG8gc3Rv cmUgdGhlbSBzb21ld2hlcmUgZm9yIHRoZSB3b3JrZXIsIGRybV9wbGFuZV9zdGF0ZQo+ID4gPiA+ IHNlZW1zIGxpa2UgYW4gYXMgZ29vZCBwbGFjZSBhcyBhbnkgb3RoZXIuCj4gPiA+IAo+ID4gPiBJ dCBnaXZlcyB0aGUgaW1wcmVzc2lvbiB0aGF0IGVhY2ggcGxhbmUgbWlnaHQgZmxpcCBhcyBzb29u IGFzIGl0cyBmZW5jZQo+ID4gPiBzaWduYWxzLgo+ID4gCj4gPiBUaGF0IHdvdWxkbid0IGJlIGF0 b21pYy4gTm90IHN1cmUgaG93IHNvbWVvbmUgY291bGQgY29tZSB1cCB3aXRoIHRoYXQKPiA+IGlk ZWEuCj4gCj4gV2hhdCBlbHNlIHdvdWxkIGl0IG1lYW4/IEl0J3MgYXR0YWNoZWQgdG8gYSBzcGVj aWZpYyBwbGFuZSwgc28gd2h5IHdvdWxkCj4gaXQgYWZmZWN0IG90aGVyIHBsYW5lcz8KPiAKPiA+ IEkgbWVhbiB3ZSBjb3VsZCBtb3ZlIEZFTkNFX0ZEIHRvIHRoZSBjcnRjIChmZW5jZSBmZHMgY2Fu IGJlIG1lcmdlZCksCj4gPiBidXQgdGhhdCdzIGp1c3QgYSBuZWVkbGVzcyBkaWZmZXJlbmNlIHRv IHdoYXQgaHdjIGV4cGVjdHMuIEkgdGhpbmsKPiA+IGFsaWduaW5nIHdpdGggdGhlIG9ubHkgcmVh bC13b3JsZCB1c2VycyBpbiB0aGlzIGNhc2UgaGVyZSBtYWtlcyBzZW5zZS4KPiAKPiBXZWxsIGl0 IGRvZXNuJ3QgYmVsb25nIG9uIHRoZSBjcnRjIGVpdGhlci4gSSB3b3VsZCBqdXN0IHN0aWNrIGlu IHRoZQo+IGlvY3RsIGFzIGEgc2VwYXJhdGUgdGhpbmcsIHRoZW4gaXQncyBjbGVhciBpdCdzIHJl bGF0ZWQgdG8gdGhlIHdob2xlCj4gb3BlcmF0aW9uIHJhdGhlciB0aGFuIGFueSBrbXMgb2JqZWN0 LgoKV2Ugd2FudCBpdCBwZXItY3J0YyBJJ2Qgc2F5LCBzbyB0aGF0IHlvdSBjb3VsZCBmbGlwIGVh Y2ggY3J0YwppbmRpdmlkdWFsbHkuIEJ1dCByZWFsbHkgdGhlIHJlYXNvbiBmb3IgcGVyLXBsYW5l IGlzIGh3IGNvbXBvc2VyIGZyb20KQW5kcm9pZC4gSSBkb24ndCBzZWUgYW55IHBvaW50IGluIGRl c2lnbmluZyBhbiBhcGkgdGhhdCdzIG5lZWRsZXNzbHkKZGlmZmVyZW50IGZyb20gd2hhdCB0aGUg bWFpbiB1c2VyIGV4cGVjdHMgKGV2ZW4gaWYgaXQgbWF5IGJlIHNpbGx5KS4KClRoZSBvdGhlciBi aXQgaXMgdGhhdCBmb3IgaW1wbGljaXQgc3luY2luZyB5b3UgbmVlZCBvbmUgZmVuY2UgcGVyIGZi L3BsYW5lCmFueXdheSwgc28gdGhpcyBhbHNvIGZpdHMgbmljZWx5IG9uIHRoZSBkcml2ZXIgc2lk ZSBJIHRoaW5rLgoKPiA+IFBsdXMgZG9jcyBpbiBjYXNlIHNvbWVvbmUgaGFzIGZ1bm55IGlkZWFz Lgo+IAo+IFdlcmVuJ3QgeW91IGp1c3QgcXVvdGluZyBydXN0eSdzIEFQSSBtYW5pZmVzdG8gcmVj ZW50bHk/IDspCgpJIHF1b3RlIGl0IGFsbCB0aGUgdGltZS4KCmh0dHA6Ly9zd2VuZy50aGUtZGF2 aWVzLm5ldC9Ib21lL3J1c3R5cy1hcGktZGVzaWduLW1hbmlmZXN0bwoKSSB0aGluayBjdXJyZW50 IGludGVyZmFjZSBpcyBzY29yaW5nIHByZXR0eSBoaWdoIHNpbmNlIGFzIHBhcnQgb2YKR3VzdGF2 bydzIHdvcmsgdGhlcmUncyBubyBhbHNvIGEgbmV3IGF0b21pYyBoZWxwZXIgd2hpY2ggd2lsbCBn ZXQgdGhlCndhaXRpbmcgcmlnaHQuIFRoZXJlJ3Mgc3RpbGwgdGhlIHByb2JsZW0gdGhhdCBuZWl0 aGVyIGZvciBkcm1fZXZlbnQgbm9yCnRoZSBmZW5jZSBkbyB3ZSBoYXZlIGFueXRoaW5nIGlkaW90 LXByb29mLiBTbyBmb3IgdGhhdCB0aGUgc29sdXRpb24gaXMKdGVzdGNhc2VzICh3aGljaCBhcmUg YWxzbyBoYXBwZW5pbmcpLgotRGFuaWVsCi0tIApEYW5pZWwgVmV0dGVyClNvZnR3YXJlIEVuZ2lu ZWVyLCBJbnRlbCBDb3Jwb3JhdGlvbgpodHRwOi8vYmxvZy5mZndsbC5jaApfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0 CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3Rv cC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753531AbcDZSXz (ORCPT ); Tue, 26 Apr 2016 14:23:55 -0400 Received: from mail-wm0-f51.google.com ([74.125.82.51]:37049 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753382AbcDZSXw (ORCPT ); Tue, 26 Apr 2016 14:23:52 -0400 Date: Tue, 26 Apr 2016 20:23:46 +0200 From: Daniel Vetter To: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Cc: 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: <20160426182346.GC2558@phenom.ffwll.local> Mail-Followup-To: 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: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160426174045.GC4329@intel.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 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. 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). 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