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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
