From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gustavo Padovan Subject: Re: [PATCH v5 4/4] drm/fence: add out-fences support Date: Fri, 21 Oct 2016 11:07:32 -0200 Message-ID: <20161021130732.GD2734@joana> References: <1476975005-30441-1-git-send-email-gustavo@padovan.org> <1476975005-30441-5-git-send-email-gustavo@padovan.org> <20161020153518.GX4329@intel.com> <20161020155538.GA10205@joana> <20161020163444.GY4329@intel.com> <20161020191520.GZ4329@intel.com> <20161021125730.GF20761@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mail-vk0-f66.google.com (mail-vk0-f66.google.com [209.85.213.66]) by gabe.freedesktop.org (Postfix) with ESMTPS id 186946ED08 for ; Fri, 21 Oct 2016 13:07:46 +0000 (UTC) Received: by mail-vk0-f66.google.com with SMTP id 2so4814644vkb.1 for ; Fri, 21 Oct 2016 06:07:46 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20161021125730.GF20761@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: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , Gustavo Padovan , marcheu@google.com, Daniel Stone , seanpaul@google.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, laurent.pinchart@ideasonboard.com, Gustavo Padovan , John Harrison , m.chehab@samsung.com List-Id: dri-devel@lists.freedesktop.org MjAxNi0xMC0yMSBEYW5pZWwgVmV0dGVyIDxkYW5pZWxAZmZ3bGwuY2g+OgoKPiBPbiBUaHUsIE9j dCAyMCwgMjAxNiBhdCAxMDoxNToyMFBNICswMzAwLCBWaWxsZSBTeXJqw6Rsw6Qgd3JvdGU6Cj4g PiBPbiBUaHUsIE9jdCAyMCwgMjAxNiBhdCAwNzozNDo0NFBNICswMzAwLCBWaWxsZSBTeXJqw6Rs w6Qgd3JvdGU6Cj4gPiA+IE9uIFRodSwgT2N0IDIwLCAyMDE2IGF0IDAxOjU1OjM4UE0gLTAyMDAs IEd1c3Rhdm8gUGFkb3ZhbiB3cm90ZToKPiA+ID4gPiAyMDE2LTEwLTIwIFZpbGxlIFN5cmrDpGzD pCA8dmlsbGUuc3lyamFsYUBsaW51eC5pbnRlbC5jb20+Ogo+ID4gPiA+IAo+ID4gPiA+ID4gT24g VGh1LCBPY3QgMjAsIDIwMTYgYXQgMTI6NTA6MDVQTSAtMDIwMCwgR3VzdGF2byBQYWRvdmFuIHdy b3RlOgo+ID4gPiA+ID4gPiBGcm9tOiBHdXN0YXZvIFBhZG92YW4gPGd1c3Rhdm8ucGFkb3ZhbkBj b2xsYWJvcmEuY28udWs+Cj4gPiA+ID4gPiA+IAo+ID4gPiA+ID4gPiBTdXBwb3J0IERSTSBvdXQt ZmVuY2VzIGJ5IGNyZWF0aW5nIGEgc3luY19maWxlIHdpdGggYSBmZW5jZSBmb3IgZWFjaCBDUlRD Cj4gPiA+ID4gPiA+IHRoYXQgc2V0cyB0aGUgT1VUX0ZFTkNFX1BUUiBwcm9wZXJ0eS4KPiA+ID4g PiA+IAo+ID4gPiA+ID4gSSBzdGlsbCBtYWludGFpbiB0aGUgb3V0IGZlbmNlIHNob3VsZCBhbHNv IGJlIHBlciBmYiAod2VsbCwgcGVyIHBsYW5lCj4gPiA+ID4gPiBzaW5jZSB3ZSBjYW4ndCBhZGQg aXQgdG8gZmJzKS4gT3RoZXJ3aXNlIGl0J3Mgbm90IGdvaW5nIHRvIGJlIGF0IGFsbAo+ID4gPiA+ ID4gdXNlZnVsIGlmIHlvdSBkbyBmcHM+dnJlZnJlc2ggYW5kIGRvbid0IGluY2x1ZGUgdGhlIHNh bWUgc2V0IG9mIHBsYW5lcwo+ID4gPiA+ID4gaW4gZXZlcnkgYXRvbWljIGlvY3RsLCBlZy4gaWYg eW91IG9ubHkgZXZlciBpbmNsdWRlIG9uZXMgdGhhdCBhcmUKPiA+ID4gPiA+IHNvbWVob3cgZGly dHkuCj4gPiA+ID4gCj4gPiA+ID4gSG93IHdvdWxkIHRoZSBrZXJuZWwgc2lnbmFsIHRoZXNlIGRp cnR5IHBsYW5lcyB0aGVuPyBSaWdodCBub3cgd2Ugc2lnbmFsCj4gPiA+ID4gYXQgdGhlIHZibGFu ay4KPiA+ID4gCj4gPiA+IFNvIGlmIEkgdGhpbmsgYWJvdXQgaXQgaW4gdGVybXMgb2YgdGhlIHBy ZXZpb3VzIGZicyBzb21ldGhpbmcgbGlrZSB0aGlzCj4gPiA+IGNvbWVzIHRvIG1pbmQ6Cj4gPiA+ IAo+ID4gPiAgc3RhcnRpbmcgcG9pbnQ6Cj4gPiA+ICBwbGFuZSBhLCBmYiAwCj4gPiA+ICBwbGFu ZSBiLCBmYiAxCj4gPiA+IAo+ID4gPiAgaW9jdGw6Cj4gPiA+ICBwbGFuZSBhLCBmYiAyLCBmZW5j ZSBBCj4gPiA+ICBwbGFuZSBiLCBmYiAzLCBmZW5jZSBCCj4gPiA+IAo+ID4gPiAgaW9jdGw6Cj4g PiA+ICBwbGFuZSBhLCBmYiA0LCBmZW5jZSBDCj4gPiA+ICAtPiBmYiAyIGNhbiBiZSByZXVzZWQs IHNvIGZlbmNlIEMgc2hvdWxkIHNpZ25hbCBpbW1lZGlhdGVseT8KPiA+ID4gCj4gPiA+ICB2Ymxh bms6Cj4gPiA+ICAtPiBmYiAwLDEgY2FuIGJlIHJldXNlZCwgc28gZmVuY2UgQSxCIHNpZ25hbD8K PiA+ID4gCj4gPiA+IEl0IGZlZWxzIGEgYml0IHdvbmt5IHNpbmNlIHRoZSBmZW5jZSBpcyBlZmZl Y3RpdmVseSBhc3NvY2lhdGVkIHdpdGggdGhlCj4gPiA+IHByZXZpb3VzIGZiIGFmdGVyIHRoZSBw cmV2aW91cyBmYiB3YXMgYWxyZWFkeSBzdWJtaXR0ZWQgdG8gdGhlIGtlcm5lbC4KPiA+ID4gT25l IG1pZ2h0IGFzc3VtZSBmZW5jZSBBIHRvIGJlIHRoZSBvbmUgc2lnbmFsbGVkIGVhcmx5LCBidXQg dGhhdCB3b3VsZAo+ID4gPiBnaXZlIHRoZSBpbXByZXNzaW9uIHRoYXQgZmIgMCB3b3VsZCBiZSBm cmVlIGZvciByZXVzZSB3aGVuIGl0J3Mgbm90Lgo+ID4gCj4gPiBPSywgc28gYWZ0ZXIgaGFzaGlu ZyB0aGlzIG91dCBvbiBpcmMgd2l0aCBHdXN0YXZvIGFuZCBCcmlhbiwgd2UgY2FtZQo+ID4gdG8g dGhlIGNvbmNsdXNpb24gdGhhdCB0aGUgcGVyLWNydGMgb3V0IGZlbmNlIHNob3VsZCBiZSBzdWZm aWNpZW50Cj4gPiBhZnRlciBhbGwuCj4gPiAKPiA+IFRoZSB3YXkgaXQgY2FuIHdvcmsgaXMgdGhh dCB0aGUgZmlyc3QgaW9jdGwgd2lsbCByZXR1cm4gdGhlIGZlbmNlLAo+ID4gZG9lc24ndCByZWFs bHkgbWF0dGVyIGhvdyBtYW55IG9mIHRoZSBwbGFuZXMgYXJlIGludm9sdmVkIGluIHRoaXMKPiA+ IGlvY3RsLiBTdWJzZXF1ZW50IGlvY3RscyB0aGF0IG1hbmFnZSB0byBnZXQgaW4gYmVmb3JlIHRo ZSBuZXh0Cj4gPiB2Ymxhbmsgd2lsbCBnZXQgYmFjayBhIC0xIGFzIHRoZSBmZW5jZSwgZXZlbiBp ZiB0aGUgc2V0IGlmIHBsYW5lcwo+ID4gaW52b2x2ZWQgaXMgbm90IHRoZSBzYW1lIGFzIGluIHRo ZSBmaXJzdCBpb2N0bC4gRnJvbSB0aGUgLTEKPiA+IHVzZXJzcGFjZSBjYW4gdGVsbCB3aGF0IGhh cHBlbmVkLCBhbmQgY2FuIHRoZW4gY29uc3VsdCBpdHMgb3duCj4gPiByZWNvcmRzIHRvIHNlZSB3 aGljaCBzdGlsbCBwZW5kaW5nIGZsaXBzIHdlcmUgb3ZlcndyaXR0ZW4sIGFuZAo+ID4gdGh1cyBr bm93cyB3aGljaCBidWZmZXJzIGNhbiBiZSByZXVzZWQgaW1tZWRpYXRlbHkuCj4gPiAKPiA+IElm IHVzZXJzcGFjZSBwbGFucyBvbiBzZW5kaW5nIG91dCB0aGUgbm93IGZyZWUgYnVmZmVycyB0byBz b21lb25lCj4gPiBlbHNlIGFjY29tcGFuaWVkIGJ5IGEgZmVuY2UsIGl0IGNhbiBqdXN0IGNyZWF0 ZSBhbiBhbHJlYWR5IHNpZ25hbGxlZAo+ID4gZmVuY2UgdG8gc2VuZCBpbnN0ZWFkIG9mIHNlbmRp bmcgdGhlIGZlbmNlIGl0IGdvdCBiYWNrIGZyb20gdGhlCj4gPiBhdG9taWMgaW9jdGwgc2luY2Ug dGhhdCBvbmUgaXMgc3RpbGwgYXNzb2NpYXRlZCB3aXRoIHRoZSBvcmlnaW5hbAo+ID4gc2Nhbm91 dCBidWZmZXJzLgo+ID4gCj4gPiBUaGUgZmVuY2UgcmV0dXJuZWQgYnkgdGhlIGF0b21pYyBpb2N0 bCB3aWxsIG9ubHkgc2lnbmFsIGFmdGVyIHRoZQo+ID4gdmJsYW5rLCBhdCB3aGljaCBwb2ludCB1 c2Vyc3BhY2Ugd2lsbCBvYnZpb3VzbHkga25vdyB0aGF0IHRoZQo+ID4gb3JnaW5hbCBzY2Fub3V0 IGJ1ZmZlcnMgYXJlIG5vdyBhbHNvIHJlYWR5IGZvciByZXVzZSwgYW5kIHRoYXQKPiA+IHRoZSBs YXN0IGJ1ZmZlciBzdWJtaXR0ZWQgZm9yIGVhY2ggcGxhbmUgaXMgbm93IGJlaW5nIGFjdGl2ZWx5 Cj4gPiBzY2FubmVkIG91dC4gU28gaWYgdXNlcnNwYWNlIHdhbnRzIHRvIHNlbmQgb3V0IHNvbWUg b2YgdGhlCj4gPiBvcmlnaW5hbCBidWZmZXJzIHRvIHNvbWVvbmUgZWxzZSwgaXQgY2FuIHNlbmQg YWxvbmcgdGhlIGZlbmNlCj4gPiByZXR1cm5lZCBmcm9tIHRoZSBhdG9taWMgaW9jdGwuCj4gPiAK PiA+IFNvIHJlcXVpcmVzIGEgYml0IG1vcmUgd29yayBmcm9tIHVzZXJzcGFjZSBwZXJoYXBzLiBC dXQgb2J2aW91c2x5Cj4gPiBpdCBvbmx5IGhhcyB0byBkbyB0aGlzIGlmIGl0IHBsYW5zIG9uIHN1 Ym1pdHRpbmcgbXVsdGlwbGUgb3BlcmF0aW9ucwo+ID4gcGVyIGZyYW1lLgo+ID4gCj4gPiBTbyBh IHNsaWdodGx5IGV4cGFuZGVkIHZlcnNpb24gb2YgbXkgcHJldmlvdXMgZXhhbXBsZSBtaWdodCBs b29rIGxpa2U6Cj4gPiBzdGFydGluZyBwb2ludDoKPiA+ICBwbGFuZSBhLCBmYiAwCj4gPiAgcGxh bmUgYiwgZmIgMQo+ID4gCj4gPiBpb2N0bDoKPiA+ICBjcnRjOiBmZW5jZSBBCj4gPiAgcGxhbmUg YSwgZmIgMgo+ID4gIHBsYW5lIGIsIGZiIDMKPiA+IAo+ID4gaW9jdGw6Cj4gPiAgY3J0YzogZmVu Y2UgLTEKPiA+ICBwbGFuZSBhLCBmYiA0Cj4gPiAgLT4gdGhlIHByZXZpb3VzbHkgc3VibWl0dGVk IGZiIGZvciBwbGFuZSBhIChmYiAyKSBjYW4gYmUgcmV1c2VkCj4gPiAKPiA+IGlvY3RsOgo+ID4g IGNydGM6IGZlbmNlIC0xCj4gPiAgcGxhbmUgYSwgZmIgNQo+ID4gIC0+IHRoZSBwcmV2aW91c2x5 IHN1Ym1pdHRlZCBmYiBmb3IgcGxhbmUgYSAoZmIgNCkgY2FuIGJlIHJldXNlZAo+ID4gCj4gPiB2 Ymxhbms6Cj4gPiAgLT4gZmVuY2UgQSBzaWduYWxzLCBmYiAwLDEgY2FuIGJlIHJldXNlZAo+ID4g ICAgIGZiIDMgYW5kIDUgYmVpbmcgc2Nhbm5lZCBvdXQgbm93Cj4gPiAKPiA+IAo+ID4gV2UgYWxz byBoYWQgYSBxdWljayBzaWRlIHRyYWNrIHcuci50LiB2YXJpYWJsZSByZWZyZXNoIHJhdGUgZGlz cGxheXMsCj4gPiBhbmQgSSB0aGluayB0aGUgY29uY2x1c2lvbiB3YXMgdGhhdCB0aGVyZSB0aGUg dmJsYW5rIG1heSBqdXN0IGhhcHBlbgo+ID4gc29vbmVyIG9yIGxhdGVyLiBOb3RoaW5nIGVsc2Ug c2hvdWxkIGNoYW5nZS4gV2hhdCdzIHVuY2xlYXIgaXMgaG93Cj4gPiB0aGUgcmVmcmVzaCByYXRl IHdvdWxkIGJlIGNvbnRyb2xsZWQuIFRoZSB0d28gb2J2aW91cyBvcHRpb25zIGFyZQo+ID4gZXhw bGljaXQgY29udHJvbCwgYW5kIGF1dG9tYWdpYyBiYXNlZCBvbiB0aGUgc3VibWl0IHJhdGUuIEJ1 dCB0aGF0J3MKPiA+IGEgc2VwYXJhdGUgdG9waWMgZW50aXJlbHkuCj4gCj4gVGhhbmtzIGEgbG90 IGZvciBkb2luZyB0aGlzIGRpc2N1c3Npb24gYW5kIHRoZSBkZXRhaWxlZCB3cml0ZS11cC4gSW1v IHdlCj4gc2hvdWxkIGJha2UgdGhpcyBpbnRvIHRoZSBrZXJuZWxkb2MsIGFzIHVhYmkgZG9jdW1l bnRhdGlvbiBleGFtcGxlcy4KPiBHdXN0YXZvLCBjYW4geW91IHBscyBpbmNsdWRlIHRoaXM/IEkn ZCBwdXQgaXQgaW50byB0aGUga2VybmVsZG9jIGZvcgo+IEBvdXRfZmVuY2UsIHdpdGggaW5saW5l IHN0cnVjdCBjb21tZW50cyB3ZSBjYW4gYmUgcmF0aGVyIGV4Y2Vzc2l2ZSBpbgo+IHRoZWlyIGxl bmdodCA7LSkKClN1cmUsIEknbGwgd29yayBvbiBrZXJuZWwgZG9jIGZvciB0aGlzLgoKR3VzdGF2 bwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2 ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9s aXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932997AbcJUNHm convert rfc822-to-8bit (ORCPT ); Fri, 21 Oct 2016 09:07:42 -0400 Received: from mail-vk0-f68.google.com ([209.85.213.68]:36589 "EHLO mail-vk0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754584AbcJUNHi (ORCPT ); Fri, 21 Oct 2016 09:07:38 -0400 Date: Fri, 21 Oct 2016 11:07:32 -0200 From: Gustavo Padovan To: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , Gustavo Padovan , marcheu@google.com, Daniel Stone , seanpaul@google.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, laurent.pinchart@ideasonboard.com, Gustavo Padovan , John Harrison , m.chehab@samsung.com Subject: Re: [PATCH v5 4/4] drm/fence: add out-fences support Message-ID: <20161021130732.GD2734@joana> Mail-Followup-To: Gustavo Padovan , Ville =?iso-8859-1?Q?Syrj=E4l=E4?= , Gustavo Padovan , marcheu@google.com, Daniel Stone , seanpaul@google.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, laurent.pinchart@ideasonboard.com, Gustavo Padovan , John Harrison , m.chehab@samsung.com References: <1476975005-30441-1-git-send-email-gustavo@padovan.org> <1476975005-30441-5-git-send-email-gustavo@padovan.org> <20161020153518.GX4329@intel.com> <20161020155538.GA10205@joana> <20161020163444.GY4329@intel.com> <20161020191520.GZ4329@intel.com> <20161021125730.GF20761@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: <20161021125730.GF20761@phenom.ffwll.local> User-Agent: Mutt/1.7.0 (2016-08-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 2016-10-21 Daniel Vetter : > On Thu, Oct 20, 2016 at 10:15:20PM +0300, Ville Syrjälä wrote: > > On Thu, Oct 20, 2016 at 07:34:44PM +0300, Ville Syrjälä wrote: > > > On Thu, Oct 20, 2016 at 01:55:38PM -0200, Gustavo Padovan wrote: > > > > 2016-10-20 Ville Syrjälä : > > > > > > > > > On Thu, Oct 20, 2016 at 12:50:05PM -0200, Gustavo Padovan wrote: > > > > > > From: Gustavo Padovan > > > > > > > > > > > > Support DRM out-fences by creating a sync_file with a fence for each CRTC > > > > > > that sets the OUT_FENCE_PTR property. > > > > > > > > > > I still maintain the out fence should also be per fb (well, per plane > > > > > since we can't add it to fbs). Otherwise it's not going to be at all > > > > > useful if you do fps>vrefresh and don't include the same set of planes > > > > > in every atomic ioctl, eg. if you only ever include ones that are > > > > > somehow dirty. > > > > > > > > How would the kernel signal these dirty planes then? Right now we signal > > > > at the vblank. > > > > > > So if I think about it in terms of the previous fbs something like this > > > comes to mind: > > > > > > starting point: > > > plane a, fb 0 > > > plane b, fb 1 > > > > > > ioctl: > > > plane a, fb 2, fence A > > > plane b, fb 3, fence B > > > > > > ioctl: > > > plane a, fb 4, fence C > > > -> fb 2 can be reused, so fence C should signal immediately? > > > > > > vblank: > > > -> fb 0,1 can be reused, so fence A,B signal? > > > > > > It feels a bit wonky since the fence is effectively associated with the > > > previous fb after the previous fb was already submitted to the kernel. > > > One might assume fence A to be the one signalled early, but that would > > > give the impression that fb 0 would be free for reuse when it's not. > > > > OK, so after hashing this out on irc with Gustavo and Brian, we came > > to the conclusion that the per-crtc out fence should be sufficient > > after all. > > > > The way it can work is that the first ioctl will return the fence, > > doesn't really matter how many of the planes are involved in this > > ioctl. Subsequent ioctls that manage to get in before the next > > vblank will get back a -1 as the fence, even if the set if planes > > involved is not the same as in the first ioctl. From the -1 > > userspace can tell what happened, and can then consult its own > > records to see which still pending flips were overwritten, and > > thus knows which buffers can be reused immediately. > > > > If userspace plans on sending out the now free buffers to someone > > else accompanied by a fence, it can just create an already signalled > > fence to send instead of sending the fence it got back from the > > atomic ioctl since that one is still associated with the original > > scanout buffers. > > > > The fence returned by the atomic ioctl will only signal after the > > vblank, at which point userspace will obviously know that the > > orginal scanout buffers are now also ready for reuse, and that > > the last buffer submitted for each plane is now being actively > > scanned out. So if userspace wants to send out some of the > > original buffers to someone else, it can send along the fence > > returned from the atomic ioctl. > > > > So requires a bit more work from userspace perhaps. But obviously > > it only has to do this if it plans on submitting multiple operations > > per frame. > > > > So a slightly expanded version of my previous example might look like: > > starting point: > > plane a, fb 0 > > plane b, fb 1 > > > > ioctl: > > crtc: fence A > > plane a, fb 2 > > plane b, fb 3 > > > > ioctl: > > crtc: fence -1 > > plane a, fb 4 > > -> the previously submitted fb for plane a (fb 2) can be reused > > > > ioctl: > > crtc: fence -1 > > plane a, fb 5 > > -> the previously submitted fb for plane a (fb 4) can be reused > > > > vblank: > > -> fence A signals, fb 0,1 can be reused > > fb 3 and 5 being scanned out now > > > > > > We also had a quick side track w.r.t. variable refresh rate displays, > > and I think the conclusion was that there the vblank may just happen > > sooner or later. Nothing else should change. What's unclear is how > > the refresh rate would be controlled. The two obvious options are > > explicit control, and automagic based on the submit rate. But that's > > a separate topic entirely. > > Thanks a lot for doing this discussion and the detailed write-up. Imo we > should bake this into the kerneldoc, as uabi documentation examples. > Gustavo, can you pls include this? I'd put it into the kerneldoc for > @out_fence, with inline struct comments we can be rather excessive in > their lenght ;-) Sure, I'll work on kernel doc for this. Gustavo