[Intel-gfx] [PATCH v10] drm/i915: Extend LRC pinning to cover GPU context writeback
Chris Wilson
chris at chris-wilson.co.uk
Mon Jan 18 08:53:00 PST 2016
On Mon, Jan 18, 2016 at 03:02:25PM +0000, Tvrtko Ursulin wrote:
> - while (!list_empty(&ring->request_list)) {
> - struct drm_i915_gem_request *request;
> -
> - request = list_first_entry(&ring->request_list,
> - struct drm_i915_gem_request,
> - list);
> -
> - if (!i915_gem_request_completed(request, true))
> + list_for_each_entry_safe(req, next, &ring->request_list, list) {
> + if (!i915_gem_request_completed(req, true))
> break;
>
> - i915_gem_request_retire(request);
> + if (!i915.enable_execlists || !i915.enable_guc_submission) {
> + i915_gem_request_retire(req);
> + } else {
> + prev_req = list_prev_entry(req, list);
> + if (prev_req)
> + i915_gem_request_retire(prev_req);
> + }
> }
>
> To explain, this attempts to ensure that in GuC mode requests are only
> unreferenced if there is a *following* *completed* request.
>
> This way, regardless of whether they are using the same or different
> contexts, we can be sure that the GPU has either completed the
> context writing, or that the unreference will not cause the final
> unpin of the context.
This is the first bogus step. contexts have to be unreferenced from
request retire, not request free. As it stands today, this forces us to
hold the struct_mutex for the free (causing many foul ups along the
line). The only reason why it is like that is because of execlists not
decoupling its context pinning inside request cancel.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list