[Intel-gfx] [RFC v2] drm/i915: Android native sync support

[Chris Wilson]

On Wed, Jan 28, 2015 at 10:50:18AM +0100, Daniel Vetter wrote:
> On Wed, Jan 28, 2015 at 09:23:46AM +0000, Chris Wilson wrote:
> > On Wed, Jan 28, 2015 at 10:22:15AM +0100, Daniel Vetter wrote:
> > > 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.
> > 
> > They won't be using execbuffer either. So what's your point?
> 
> Android very much will user execbuffer. And even the in-flight buffered
> svm stuff will keep on using execbuf (just without any relocs).

So still buffer-centric and would benefit from the more general and more
explict fencing rather than just execbuf. If you look at the throttling
in mesa, you can already see a place that would rather create a fence on
a buffer rather than its very approximate execbuf tracking.
 
> And once we indeed can make the case (plus have the hw) for direct
> userspace submission I think the kernel shouldn't be in the business of
> creating fence objects: The ring will be fully under control of
> userspace, and that's the only place we could insert a seqno into. So
> again the same trust issues.

No buffers, no requests, nothing for the kernel to do. No impact on
designing an API that is useful today.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre