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. 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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
