On Thu, 4 Dec 2014 12:21:01 +0100 Daniel Vetter <daniel@xxxxxxxx> wrote: > On Wed, Dec 03, 2014 at 11:49:06AM -0800, Jesse Barnes wrote: > > Expose an ioctl to create Android fences based on the Android sync point > > infrastructure (which in turn is based on DMA-buf fences). Just a > > sketch at this point, no testing has been done. > > > > There are a couple of goals here: > > 1) allow applications and libraries to create fences without an > > associated buffer > > 2) re-use a common API so userspace doesn't have to impedance mismatch > > between different driver implementations too much > > 3) allow applications and libraries to use explicit synchronization if > > they choose by exposing fences directly > > > > v2: use struct fence directly using Maarten's new interface > > v3: use new i915 request structure (Jesse) > > make i915 fences a compile time option since Android support is still > > in staging (Jesse) > > check for request complete after arming IRQs (Chris) > > add timeline id to ioctl (Tvrtko) > > > > Signed-off-by: Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> > > Same high-level comment as before: > > I still don't see the point in a separate get_fence ioctl when we want > both in&out fences for execbuf (and later on atomic flips) for android. > This separate ioctl here looks incomplete and just means you have to do 2 > ioctls at least to actually get at the fence for an execbuf. Yeah I'm working on converting over to putting the creation calls into execbuf instead; that also makes per-ring/context handling easier, and also the display stuff easier, since we won't have to worry about enumerating crtcs and planes as separate timelines. > And android sync stuff still needs to be de-staged. On that: The function > names to wrap a struct fence into a syncpt file and then insert the file > into an fd slot need a bit of name bikeshedding since it's not clear that > it's just a userspace interface wrapper now. I don't think we'll be able to de-stage without a user, but I can add a patch to do that as part of the series. -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
