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. The compromise would be to associate in the execbuffer, and disassociate through an IOCTL. Thanks. Ben _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
