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 at gmail.com> wrote: > On Fri, Apr 29, 2016 at 3:48 AM, Daniel Stone <daniel at fooishbar.org> > wrote: > > Hi, > > > > On 28 April 2016 at 23:28, Rob Clark <robdclark at gmail.com> wrote: > >> On Wed, Apr 27, 2016 at 2:39 AM, Daniel Vetter <daniel at 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 at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160712/7f2b8cbe/attachment.html>
