[Intel-gfx] [PATCH 2/3] drm/i915: Android sync points for i915 v3

[Daniel Vetter]

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 at virtuousgeek.org>

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