[Intel-gfx] [RFC] drm/i915: context support unit test

[Chris Wilson]

On Thu, 30 Dec 2010 16:48:31 -0800, Ben Widawsky <widawsky at gmail.com> 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