From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753774AbcD1V22 (ORCPT ); Thu, 28 Apr 2016 17:28:28 -0400 Received: from mail-yw0-f174.google.com ([209.85.161.174]:32931 "EHLO mail-yw0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753070AbcD1V2K convert rfc822-to-8bit (ORCPT ); Thu, 28 Apr 2016 17:28:10 -0400 MIME-Version: 1.0 In-Reply-To: <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> <20160427063904.GH2558@phenom.ffwll.local> Date: Thu, 28 Apr 2016 17:28:09 -0400 Message-ID: Subject: Re: [RFC v2 5/8] drm/fence: add in-fences support From: Rob Clark To: 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 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: >> 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. 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) > 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. BR, -R > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel