From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ben Widawsky <widawsky@gmail.com>
Subject: Re: [RFC] drm/i915: context support unit test
Date: Thu, 30 Dec 2010 12:21:19 -0800
Message-ID: <20101230202118.GA4813@snipes.kumite>
References: <20101225225303.GA5311@snipes.kumite>
	<20101228223616.GB5596@viiv.ffwll.ch>
	<20101229040301.GA17502@snipes.kumite>
	<5df004b018c6d26ee6c55171892e3e84.squirrel@www.ffwll.ch>
	<b9dded$hh2bn6@orsmga002.jf.intel.com>
	<e422031f05cf8e51af8ab1f9153cc3d0.squirrel@www.ffwll.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org>
Received: from mail-iy0-f177.google.com (mail-iy0-f177.google.com
	[209.85.210.177])
	by gabe.freedesktop.org (Postfix) with ESMTP id 084439E746
	for <intel-gfx@lists.freedesktop.org>;
	Thu, 30 Dec 2010 12:21:25 -0800 (PST)
Received: by iyj21 with SMTP id 21so10922300iyj.36
	for <intel-gfx@lists.freedesktop.org>;
	Thu, 30 Dec 2010 12:21:25 -0800 (PST)
Content-Disposition: inline
In-Reply-To: <e422031f05cf8e51af8ab1f9153cc3d0.squirrel@www.ffwll.ch>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=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: Daniel Vetter <daniel@ffwll.ch>
Cc: benjamin.widawsky@linux.intel.com, intel-gfx@lists.freedesktop.org
List-Id: intel-gfx@lists.freedesktop.org

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.
> 
> And wrt restoring the gtt offset: I think to guarantee this, we need
> ppGTT. In the GGTT we might get unlucky and a scanout buffer sits at
> the desired spot. So at least for bring-up (until ppGTT works) we need
> to be able to bail out in the kernel and politely ask userspace to fix up
> the mess ;)
I agree with this. Depending on what the HW does when it loads state, it
might also require allowing the client to have a way to prevent
restoring context on the next submission. I think it would be good to
add this to the API even if HW doesn't require it. 
Either way, I think this gets messy if we allow sharing contexts amongst
clients. I hope nobody has a good use case for sharing contexts :-).
> 
> Cheers, Daniel
> 
Ben