Re: [RFC v2] drm/i915: Android native sync support

[Daniel Vetter <daniel@ffwll.ch>]

On Mon, Jan 26, 2015 at 09:08:03AM +0000, Chris Wilson wrote:
> On Mon, Jan 26, 2015 at 08:52:39AM +0100, Daniel Vetter wrote:
> > I think the problem will be platforms that want full explicit fence (like
> > android) but allow delayed creation of the fence fd from a gl sync object
> > (like the android egl extension allows).
> > 
> > I'm not sure yet how to best expose that really since just creating a
> > fence from the implicit request attached to the batch might upset the
> > interface purists with the mix in implicit and explicit fencing ;-) Hence
> > why I think for now we should just do the eager fd creation at execbuf
> > until ppl scream (well maybe not merge this patch until ppl scream ...).
> 
> Everything we do is buffer centric. Even in the future with random bits
> of memory, we will still use buffers behind the scenes. From an
> interface perspective, it is clearer to me if we say "give me a fence for
> this buffer". Exactly the same way as we say "is this buffer busy" or
> "wait on this buffer". The change is that we now hand back an fd to slot
> into an event loop. That, to me, is a much smaller evolutionary step of
> the existing API, and yet more versatile than just attaching one to the
> execbuf.

The problem is that big parts of the world do not subscribe to that buffer
centric view of gfx. Imo since those parts will be the primary users of
this interface we should try to fit their ideas as much as feasible. Later
on (if we need it) we can add some glue to tie in the buffer-centric
implicit model with the explicit model.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx