Gustavo, you added fence_put() in __drm_atomic_helper_plane_destroy_state(), shouldn't we also add a corresponding fence_get() in __drm_atomic_helper_plane_duplicate_state() ?
On Fri, Apr 29, 2016 at 3:23 PM, Rob Clark robdclark@gmail.com wrote:
On Fri, Apr 29, 2016 at 3:48 AM, Daniel Stone daniel@fooishbar.org wrote:
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.
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
dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel