Re: [PATCH i-g-t 4/7] tests/gem_mmap_gtt: Make the small-bo tiling tests work on old platforms

From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH i-g-t 4/7] tests/gem_mmap_gtt: Make the small-bo tiling tests work on old platforms
Date: Tue, 15 Dec 2015 13:29:59 +0200	[thread overview]
Message-ID: <20151215112959.GB4437@intel.com> (raw)
In-Reply-To: <20151215111652.GS24300@nuc-i3427.alporthouse.com>

On Tue, Dec 15, 2015 at 11:16:52AM +0000, Chris Wilson wrote:
> On Tue, Dec 15, 2015 at 12:57:15PM +0200, Ville Syrjälä wrote:
> > On Tue, Dec 15, 2015 at 09:57:22AM +0000, Chris Wilson wrote:
> > > On Tue, Dec 15, 2015 at 11:41:44AM +0200, Ville Syrjälä wrote:
> > > > On Mon, Dec 14, 2015 at 08:54:35PM +0000, Chris Wilson wrote:
> > > > > On Mon, Dec 14, 2015 at 08:49:38PM +0000, Chris Wilson wrote:
> > > > > > On Mon, Dec 14, 2015 at 10:15:53PM +0200, ville.syrjala@linux.intel.com wrote:
> > > > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > > > 
> > > > > > > Several factors conspire against us when trying to execute
> > > > > > > the tiled small-bo tests:
> > > > > > > - pre-gen4 require power of two fences, with natural alignment
> > > > > > > - the entire gtt may be mappable
> > > > > > > - we put a guard page at the end of gtt
> > > > > > > 
> > > > > > > What all that means is that when we try to use a tiled object half
> > > > > > > the size of the mappable area, we can only fit it in the first half
> > > > > > > of the gtt. That leads to a SIGBUS when we try to fault in the
> > > > > > > object when there's already something (eg. fbdev) occupying the
> > > > > > > first half of gtt.
> > > > > > > 
> > > > > > > So in order to make the tests run on old machines, let's further
> > > > > > > halve the object size when things look too tight.
> > > > > > 
> > > > > > That defeats the point of the test. The idea is to have the two objects
> > > > > > that just don't fit, but only just.
> > > > > 
> > > > > i.e. the test is meant to show that the kernel heuristics for using
> > > > > partial vma do not prevent the page-fault-of-doom.
> > > > 
> > > > So just skip then?
> > > 
> > > The kernel has a bug that partial vma was supposed to address.
> > 
> > I'm not sure partial vma has any benefit in this case. Sure, you could
> > them mmap the thing but unless we teach the GPU to also use partial
> > mappings it won't do any good since we just can't fit the thing into
> > the gtt.
> 
> For gen2, not being able to fit into mappable is an issue for the GPU as
> well, sure. But for userspace being oblivious and *always* being able to
> use mmaping of a bo, it is a big deal. (Being oblivious helps with
> robustness in the stack, X/display-server-de-jour should not die just
> because of a resource conflict - now X should catch the fault and handle
> it, give or take bugs, avoiding that error path entirely is even better.)

Yeah, I suppose it would be nice not to SIGBUS even if userspace is
trying something a bit crazy. It would just get an error later from
execbuf when trying to use the bo with the GPU. So I guess the right
fix would be to fall back to partial vma if we fail to bind the full
vma.

> 
> Using "sparse" resources so that we can arbitrary sized objects is
> something I'd like. But we have so much "whole-object-at-once" baked
> into the code, it will be a challenge.
> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx