On Tue, Apr 05, 2016 at 02:42:16PM +0100, Tvrtko Ursulin wrote: > >>@@ -587,9 +587,6 @@ static int execlists_context_queue(struct > >>drm_i915_gem_request *request) > >> struct drm_i915_gem_request *cursor; > >> int num_elements = 0; > >> > >>- if (request->ctx != ring->default_context) > >>- intel_lr_context_pin(request); > >>- > > > >Since you remove LRC pin from queue, the lifetime is now either: > > > >1. From request create to cancel. > >2. From request create to execlist retirement. > > > >Would it be more logical to leave the LRC pin in queue, but remove it > >from request creation instead? That would make the LRC pin lifetime only > >a single possibility, from queue to execlist retire. Well what we actually need in request allocation is pinning the ringbuffer. At the moment we do that by pinning the request. We also need to pin the VM in order to manipulate it. We could leave pinning the logical context object til actual submission. > I felt was so close in getting rid of execlist_retired_req_queue, > using this patch as a starting point, when I realised this patch > does not play nicely with the GuC. Back to the drawing board. :( If you mean what happens if the GuC executes requests out-of-order - it can't in the current model since we only have a single timeline and that would break it badly - then nothing changes. We are only moving the release in time, not decoupling it from any serialisation. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
