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@xxxxxxxxxxxxxxxxxx> > > > Cc: Ben Widawsky <benjamin.widawsky@xxxxxxxxx> > > > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > > > /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@xxxxxxxxxxxxxxxxxx> > > 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. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
