Fence, timeline and android sync points
daniel at ffwll.ch
Thu Aug 14 11:47:16 PDT 2014
On Thu, Aug 14, 2014 at 8:18 PM, Jerome Glisse <j.glisse at gmail.com> wrote:
> Sucks because you can not do weird synchronization like one i depicted in another
> mail in this thread and for as long as cmdbuf_ioctl do not give you fence|syncpt
> you can not such thing cleanly in non hackish way.
Actually i915 can soon will do that that.
> Sucks because you have a fence object per buffer object and thus overhead grow
> with the number of objects. Not even mentioning fence lifetime issue.
> Sucks because sub-buffer allocation is just one of many tricks that can not be
> achieved properly and cleanly with implicit sync.
Well I heard all those reasons and I'm well of aware of them. The
problem is that with current hardware the kernel needs to know for
each buffer how long it needs to be kept around since hw just can't do
page faulting. Yeah you can pin them but for an uma design that
doesn't go down well with folks.
The other problem is that the Linux Desktop I don't seem to care about
any more kinda relies on implicit syncing right now, so we better keep
that working fairly well. Of course we could dream up a shiny new
world where all of the Linux desktop does explicit syncing, but that
world doesn't exist right now. I mean really if you want to right away
throw implicit syncing overboard that doesn't bode well for the
current linux desktop.
So I don't understand all the implicit syncing bashing. It's here, and
it'll stay for a while longer whether you like it or not ...
Of course that doesn't mean we (intel here) won't support explicit
syncing too, and I really don't see a conflict here when mixing and
matching these two approaches.
> Having code that work around or alieviate some of this, is in no way a testimony
> that it's the best solution. I do believe explicit sync to be superior in use
> case it allows way more freedom while the only drawback i see is that you have to
> put some trust into userspace.
> So yes implicit sync sucks and it does map to i915 reality as well.
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
More information about the dri-devel