Re: [PATCH 2/3] drm/i915: Android sync points for i915 v3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux