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

Open Source and information security mailing list archives

Date:	Thu, 28 Apr 2016 17:28:09 -0400
From:	Rob Clark <robdclark@...il.com>
To:	Greg Hackmann <ghackmann@...gle.com>,
	Ville Syrjälä <ville.syrjala@...ux.intel.com>,
	Gustavo Padovan <gustavo.padovan@...labora.co.uk>,
	Gustavo Padovan <gustavo@...ovan.org>,
	Daniel Stone <daniels@...labora.com>,
	Riley Andrews <riandrews@...roid.com>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Arve Hjønnevåg <arve@...roid.com>,
	John Harrison <John.C.Harrison@...el.com>
Subject: Re: [RFC v2 5/8] drm/fence: add in-fences support

On Wed, Apr 27, 2016 at 2:39 AM, Daniel Vetter <daniel@...ll.ch> 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@...ts.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives