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? -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
