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@xxxxxxxxxxxxxxx wrote: > > > > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > > > > > > > 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.) 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
