From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
Nick Hoath <nicholas.hoath@intel.com>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH v10] drm/i915: Extend LRC pinning to cover GPU context writeback
Date: Mon, 18 Jan 2016 17:14:26 +0000 [thread overview]
Message-ID: <569D1D72.2010804@linux.intel.com> (raw)
In-Reply-To: <20160118165300.GC26573@nuc-i3427.alporthouse.com>
On 18/01/16 16:53, Chris Wilson wrote:
> 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.
What is the first bogus step? My idea of how to fix the GuC issue, or
the mention of final unreference in relation to GPU completing the
submission?
Also I don't understand how would you decouple context and request lifetime?
Maybe we can ignore execlist mode for the moment and just consider the
GuC which, as much as I understand it, has a simpler and fully aligned
request/context/lrc lifetime of:
* reference and pin and request creation
* unpin and unreference at retire
Where retire is decoupled from actual GPU activity, or maybe better say
indirectly driven.
Execlists bolt on a parallel another instance reference and pin on top,
with different lifetime rules so maybe ignore that for the GuC
discussion. Just to figure out what you have in mind.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-01-18 17:14 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-13 16:19 [PATCH v10] drm/i915: Extend LRC pinning to cover GPU context writeback Nick Hoath
2016-01-13 19:28 ` Yu Dai
2016-01-14 7:20 ` ✗ failure: Fi.CI.BAT Patchwork
2016-01-14 11:31 ` Nick Hoath
2016-01-19 9:08 ` Daniel Vetter
2016-01-14 11:36 ` [PATCH v10] drm/i915: Extend LRC pinning to cover GPU context writeback Chris Wilson
2016-01-14 11:56 ` Nick Hoath
2016-01-14 12:31 ` Chris Wilson
2016-01-14 12:37 ` Nick Hoath
2016-01-15 10:59 ` Nick Hoath
2016-01-18 15:02 ` Tvrtko Ursulin
2016-01-18 16:53 ` Chris Wilson
2016-01-18 17:14 ` Tvrtko Ursulin [this message]
2016-01-18 20:47 ` Chris Wilson
2016-01-19 10:24 ` Tvrtko Ursulin
2016-01-19 17:18 ` Tvrtko Ursulin
2016-01-19 17:31 ` Tvrtko Ursulin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=569D1D72.2010804@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=nicholas.hoath@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.