On Thu, 30 Dec 2010 16:48:31 -0800, Ben Widawsky <[email protected]> wrote: > On Thu, Dec 30, 2010 at 12:21:19PM -0800, Ben Widawsky wrote: > > On Thu, Dec 30, 2010 at 01:48:36PM +0100, Daniel Vetter wrote: > > > This way userspace doesn't have to track a list of context bos and the > > > kernel gem stays in full control. And specifying the context relation of > > > a bo toghether with the relocation that actually uses it is probably the > > > clearest solution. > > I'll need to research this one more. > > It seems like you picked this slot based mechanism to get rid of needing > a disassociate IOCTL. At least if I followed you, the scheme allows you > to overwrite BOs associated with the context. The cost is userspace > would have to manage the slots. It'd be very easy to just have a flag to > associate a buffer with a context, and forget the slots. > > As you point out this hinges on the assumption that not many buffers are > needed, and the size doesn't grow. I'm not the right person to judge the > accuracy of that, but it seems like an undesirable trait. I do really > like doing away with the extra IOCTLs though. > > Chris, do you have an opinion? I'm leaning towards the two IOCTLs at > present.
I'm still leaning towards explicit associate/disassociate ioctls as I think that will lead to a simpler userspace API (or at least integrate conveniently with the existing libdrm). > The compromise would be to associate in the execbuffer, and disassociate > through an IOCTL. Using a flag in the execbuffer.object is one approach, but breaks the symmetry and thereby consistency. "Minimal, consistent and difficult to misuse." If you've never seen them before: http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html with the corollary http://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html is an enlightening read. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
