From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752783AbcD2WXo (ORCPT ); Fri, 29 Apr 2016 18:23:44 -0400 Received: from mail-yw0-f172.google.com ([209.85.161.172]:34063 "EHLO mail-yw0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751980AbcD2WXn (ORCPT ); Fri, 29 Apr 2016 18:23:43 -0400 MIME-Version: 1.0 In-Reply-To: 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> <20160427063904.GH2558@phenom.ffwll.local> Date: Fri, 29 Apr 2016 18:23:42 -0400 Message-ID: Subject: Re: [RFC v2 5/8] drm/fence: add in-fences support From: Rob Clark To: Daniel Stone Cc: Greg Hackmann , =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= , Gustavo Padovan , Gustavo Padovan , Daniel Stone , Riley Andrews , "dri-devel@lists.freedesktop.org" , Linux Kernel Mailing List , =?UTF-8?B?QXJ2ZSBIasO4bm5ldsOlZw==?= , John Harrison Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 29, 2016 at 3:48 AM, Daniel Stone wrote: > Hi, > > On 28 April 2016 at 23:28, Rob Clark wrote: >> On Wed, Apr 27, 2016 at 2:39 AM, Daniel Vetter wrote: >>> On Tue, Apr 26, 2016 at 01:48:02PM -0700, Greg Hackmann wrote: >>>> 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. >> >> I was kinda more a fan of array too, if for no other reason that to be >> consistent w/ how out-fences work. (And using property just for >> in-fence seemed slightly weird/abusive to me) > > I don't think it's really useful to look for much consistency between > the two, beyond the name. I'm more concerned with consistency between > in-fences and the implicit fences on buffers/FBs, and between > out-fences and the page_flip_events. > >>> 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. >> >> hmm, well we could keep the array per-plane (and if one layer is using >> multiple planes, just list the same fd multiple times).. then it >> mostly comes down to changes in the ioctl fxn itself. > > ... and new API in libdrm, which is going to be a serious #ifdef and > distribution pain. The core property API has been available since > 2.4.62 last June, but for this we'd have to write the code, wait for > the kernel code, wait for HWC, get everything together, and then merge > and release. That gives minimum one year of libdrm releases which have > had atomic but not in-fence API support, if we're adding a new array. > And I just don't really see what it buys us, apart from the need for > the core atomic_get_property helper to statically return -1 when > requesting FENCE_FD. don't we have the same issue for out-fences anyway? ofc, I suspect we could handle making fences look like properties in userspace in libdrm (at least if there was a sane way that libdrm could track and eventually close() old out-fence fd's). I'm not entirely sure this matters, I mean how do we make implicit vs explicit fencing transparent to the compositor and the proto between compositor<->app? Admittedly I haven't given *too* much thought yet about the implications to libdrm and it's users, but it seems like we need to make a v2 API rev anyway for out-fences, and the compositor is going to need different codepaths for explicit vs implicit (if it supports both). So I don't think in-fences as something other than property really costs us anything additional? (Unless there is some sane reason to have an intermediate state w/ in-fences but pageflip events instead of out-fences? But that seems odd..) BR, -R > Cheers, > Daniel