All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Hoath <nicholas.hoath@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 4/5] drm/i915: Subsume intel_ctx_submit_request in to drm_i915_gem_request
Date: Wed, 12 Nov 2014 12:13:03 +0000	[thread overview]
Message-ID: <54634ECF.4000407@intel.com> (raw)
In-Reply-To: <20141112112411.GO8220@nuc-i3427.alporthouse.com>

On 12/11/2014 11:24, Chris Wilson wrote:
> On Wed, Nov 12, 2014 at 10:53:26AM +0000, Nick Hoath wrote:
>    		seq_putc(m, '\n');
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
>> index afa9c35..0fe238c 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -2027,6 +2027,28 @@ struct drm_i915_gem_request {
>>   	struct list_head free_list;
>>
>>   	uint32_t uniq;
>> +
>> +	/**
>> +	 * The ELSP only accepts two elements at a time, so we queue context/tail
>> +	 * pairs on a given queue (ring->execlist_queue) until the hardware is
>> +	 * available. The queue serves a double purpose: we also use it to keep track
>> +	 * of the up to 2 contexts currently in the hardware (usually one in execution
>> +	 * and the other queued up by the GPU): We only remove elements from the head
>> +	 * of the queue when the hardware informs us that an element has been
>> +	 * completed.
>> +	 *
>> +	 * All accesses to the queue are mediated by a spinlock (ring->execlist_lock).
>> +	 */
>> +
>> +	/** Execlist link in the submission queue.*/
>> +	struct list_head execlist_link;
>
> This is redundant. The request should only be one of the pending or active
> lists at any time.
>
This is used by the pending execlist requests list owned by the 
intel_engine_cs. The request isn't in both the active and pending 
execlist engine lists.
>> +	/** Execlists workqueue for processing this request in a bottom half */
>> +	struct work_struct work;
>
> For what purpose? This is not needed.
This worker is currently used to free up execlist requests. This goes 
away when Thomas Daniel's patchset is merged.
I have spotted a bug in the cleanup handler with the merged 
requests/execlists cleanup though.
>
>> +	/** Execlists no. of times this request has been sent to the ELSP */
>> +	int elsp_submitted;
>
> A request can only be submitted exactly once at any time. This
> bookkeeping is not part of the request.
This is a refcount to preserve the request if it has been resubmitted 
due to preemption or TDR, due to a race condition between the HW 
finishing with the item and the cleanup/resubmission. Have a look at
e1fee72c2ea2e9c0c6e6743d32a6832f21337d6c which contains a much better
description of why this exists.
>
> Still not detangled I am afraid.
> -Chris
>

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2014-11-12 12:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-12 10:53 [PATCH 0/5] drm/i915: Untangle execlist tracking Nick Hoath
2014-11-12 10:53 ` [PATCH 1/5] drm/i915: execlist request keeps ptr/ref to gem_request Nick Hoath
2014-11-12 10:53 ` [PATCH 2/5] drm/i915: Removed duplicate members from submit_request Nick Hoath
2014-11-12 10:53 ` [PATCH 3/5] drm/i915: Remove FIXME_lrc_ctx backpointer Nick Hoath
2014-11-12 10:53 ` [PATCH 4/5] drm/i915: Subsume intel_ctx_submit_request in to drm_i915_gem_request Nick Hoath
2014-11-12 11:24   ` Chris Wilson
2014-11-12 12:13     ` Nick Hoath [this message]
2014-12-10 16:25       ` Daniel Vetter
2014-11-12 10:53 ` [PATCH 5/5] drm/i915: Change workaround execlist submission to use gem requests Nick Hoath
2014-12-10 16:28 ` [PATCH 0/5] drm/i915: Untangle execlist tracking Daniel Vetter

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=54634ECF.4000407@intel.com \
    --to=nicholas.hoath@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /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.