From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH] drm/i915: Fix secure dispatch with full
	ppgtt
Date: Mon, 11 Aug 2014 13:51:30 +0200
Message-ID: <20140811115130.GQ8727@phenom.ffwll.local>
References: <1407751557-5167-1-git-send-email-daniel.vetter@ffwll.ch>
 <1407751738-19895-1-git-send-email-daniel.vetter@ffwll.ch>
 <20140811101740.GF6666@nuc-i3427.alporthouse.com>
 <20140811112219.GJ8727@phenom.ffwll.local>
 <20140811113542.GI6666@nuc-i3427.alporthouse.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces@lists.freedesktop.org>
Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com
 [209.85.212.174])
 by gabe.freedesktop.org (Postfix) with ESMTP id 2E7E76E3C5
 for <intel-gfx@lists.freedesktop.org>; Mon, 11 Aug 2014 04:51:19 -0700 (PDT)
Received: by mail-wi0-f174.google.com with SMTP id d1so4088670wiv.1
 for <intel-gfx@lists.freedesktop.org>; Mon, 11 Aug 2014 04:51:18 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <20140811113542.GI6666@nuc-i3427.alporthouse.com>
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>
Errors-To: intel-gfx-bounces@lists.freedesktop.org
Sender: "Intel-gfx" <intel-gfx-bounces@lists.freedesktop.org>
To: Chris Wilson <chris@chris-wilson.co.uk>, Daniel Vetter <daniel@ffwll.ch>, Daniel Vetter <daniel.vetter@ffwll.ch>, Intel Graphics Development <intel-gfx@lists.freedesktop.org>, Ben Widawsky <benjamin.widawsky@intel.com>
List-Id: intel-gfx@lists.freedesktop.org

On Mon, Aug 11, 2014 at 12:35:42PM +0100, Chris Wilson wrote:
> On Mon, Aug 11, 2014 at 01:22:19PM +0200, Daniel Vetter wrote:
> > On Mon, Aug 11, 2014 at 11:17:40AM +0100, Chris Wilson wrote:
> > > On Mon, Aug 11, 2014 at 12:08:58PM +0200, Daniel Vetter wrote:
> > > > Based upon a hunk from a patch from Chris Wilson, but augmented to:
> > > > - Process the batch in the full ppgtt vm so that self-relocations
> > > >   match again with userspace's expectations..
> > > > - Add a comment why plain pin for the global gtt binding is safe at
> > > >   that point.
> > > > 
> > > > v2: Drop local bind_vm variable (Chris).
> > > > 
> > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > Cc: Ben Widawsky <benjamin.widawsky@intel.com>
> > > > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > 
> > > /me jaw drops
> > > 
> > > Oh nice, yes you are right that does fix the issue with the relocations
> > > being in one address space whilst the exec needs to be done from gGTT.
> > > 
> > > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> > 
> > Actually it's not that simple - with this patch we don't add the ggtt vma
> > for the batch to the active list, which we probably should. So needs to be
> > revised a bit more I think ...
> 
> The only thing that comes unstuck is eviction, and even there that we
> keep them all in order of last GTT access, should prevent most random
> stalls. As the batch object itself is still being tracked for gpu
> busyness, it is only a level of finese required rather than being
> outright broken wrt to serialisation.
> 
> It is still a massive leap forward in our understanding of the
> potential solution, and not one step back.

Yeah, you're right. Added a FIXME comment as discussed on irc and pulled
it in. I guess in the end we should still smash the ggtt batch vma onto
the eb list somehow, to make sure that it goes through all the proper
move_to_active processing _before_ we call add_request.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch