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@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.) 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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
