From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [RFC] drm/i915: context support unit test Date: Fri, 31 Dec 2010 09:31:23 +0000 Message-ID: <0d30dc$kk5sgj@orsmga001.jf.intel.com> References: <20101225225303.GA5311@snipes.kumite> <20101228223616.GB5596@viiv.ffwll.ch> <20101229040301.GA17502@snipes.kumite> <5df004b018c6d26ee6c55171892e3e84.squirrel@www.ffwll.ch> <20101230202118.GA4813@snipes.kumite> <20101231004831.GA14664@snipes.kumite> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTP id 1D6A99E756 for ; Fri, 31 Dec 2010 01:31:27 -0800 (PST) In-Reply-To: <20101231004831.GA14664@snipes.kumite> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Ben Widawsky , Daniel Vetter Cc: benjamin.widawsky@linux.intel.com, intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Thu, 30 Dec 2010 16:48:31 -0800, Ben Widawsky 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