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