Re: [RFC v2 5/8] drm/fence: add in-fences support

From: Daniel Stone <daniel@fooishbar.org>
To: Rob Clark <robdclark@gmail.com>
Cc: "Greg Hackmann" <ghackmann@google.com>,
	"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"Gustavo Padovan" <gustavo.padovan@collabora.co.uk>,
	"Gustavo Padovan" <gustavo@padovan.org>,
	"Daniel Stone" <daniels@collabora.com>,
	"Riley Andrews" <riandrews@android.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Arve Hjønnevåg" <arve@android.com>,
	"John Harrison" <John.C.Harrison@intel.com>
Subject: Re: [RFC v2 5/8] drm/fence: add in-fences support
Date: Fri, 29 Apr 2016 09:48:07 +0200	[thread overview]
Message-ID: <CAPj87rM_DzvvtATgdyG968OEDQnjqeSK-BK-c7+hNpE17xP21A@mail.gmail.com> (raw)
In-Reply-To: <CAF6AEGsNyamM8xZkqvawbwbfhNQFsfRV-Kkcs6=R8FayyjGCdQ@mail.gmail.com>

Hi,

On 28 April 2016 at 23:28, Rob Clark <robdclark@gmail.com> wrote:
> On Wed, Apr 27, 2016 at 2:39 AM, Daniel Vetter <daniel@ffwll.ch> 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.

Cheers,
Daniel