All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 03/11] drm/i915/execlists: Pull submit after dequeue under timeline lock
Date: Fri, 1 Jun 2018 15:02:38 +0100	[thread overview]
Message-ID: <8ed79b89-38ec-2bd3-6ea4-9f97eec43625@linux.intel.com> (raw)
In-Reply-To: <20180531185204.19520-4-chris@chris-wilson.co.uk>


On 31/05/2018 19:51, Chris Wilson wrote:
> In the next patch, we will begin processing the CSB from inside the
> interrupt handler. This means that updating the execlists->port[] will

The message that we will be processing CSB from irq handler, here and in 
following patch 5/11, doesn't seem to be true. So why is this needed? 
Why not just drop some patches from the series?

Regards,

Tvrtko

> no longer be locked by the tasklet but by the engine->timeline.lock
> instead. Pull dequeue and submit under the same lock for protection.
> (An alternative, future, plan is to keep the in/out arrays separate for
> concurrent processing and reduced lock coverage.)
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> ---
>   drivers/gpu/drm/i915/intel_lrc.c | 32 ++++++++++++--------------------
>   1 file changed, 12 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
> index e5cf049c18f8..d207a1bf9dc9 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -562,7 +562,7 @@ static void complete_preempt_context(struct intel_engine_execlists *execlists)
>   	execlists_clear_active(execlists, EXECLISTS_ACTIVE_PREEMPT);
>   }
>   
> -static bool __execlists_dequeue(struct intel_engine_cs *engine)
> +static void __execlists_dequeue(struct intel_engine_cs *engine)
>   {
>   	struct intel_engine_execlists * const execlists = &engine->execlists;
>   	struct execlist_port *port = execlists->port;
> @@ -617,11 +617,11 @@ static bool __execlists_dequeue(struct intel_engine_cs *engine)
>   		 * the HW to indicate that it has had a chance to respond.
>   		 */
>   		if (!execlists_is_active(execlists, EXECLISTS_ACTIVE_HWACK))
> -			return false;
> +			return;
>   
>   		if (need_preempt(engine, last, execlists->queue_priority)) {
>   			inject_preempt_context(engine);
> -			return false;
> +			return;
>   		}
>   
>   		/*
> @@ -646,7 +646,7 @@ static bool __execlists_dequeue(struct intel_engine_cs *engine)
>   		 * priorities of the ports haven't been switch.
>   		 */
>   		if (port_count(&port[1]))
> -			return false;
> +			return;
>   
>   		/*
>   		 * WaIdleLiteRestore:bdw,skl
> @@ -746,8 +746,10 @@ static bool __execlists_dequeue(struct intel_engine_cs *engine)
>   		port != execlists->port ? rq_prio(last) : INT_MIN;
>   
>   	execlists->first = rb;
> -	if (submit)
> +	if (submit) {
>   		port_assign(port, last);
> +		execlists_submit_ports(engine);
> +	}
>   
>   	/* We must always keep the beast fed if we have work piled up */
>   	GEM_BUG_ON(execlists->first && !port_isset(execlists->port));
> @@ -756,24 +758,19 @@ static bool __execlists_dequeue(struct intel_engine_cs *engine)
>   	if (last)
>   		execlists_user_begin(execlists, execlists->port);
>   
> -	return submit;
> +	/* If the engine is now idle, so should be the flag; and vice versa. */
> +	GEM_BUG_ON(execlists_is_active(&engine->execlists,
> +				       EXECLISTS_ACTIVE_USER) ==
> +		   !port_isset(engine->execlists.port));
>   }
>   
>   static void execlists_dequeue(struct intel_engine_cs *engine)
>   {
> -	struct intel_engine_execlists * const execlists = &engine->execlists;
>   	unsigned long flags;
> -	bool submit;
>   
>   	spin_lock_irqsave(&engine->timeline.lock, flags);
> -	submit = __execlists_dequeue(engine);
> +	__execlists_dequeue(engine);
>   	spin_unlock_irqrestore(&engine->timeline.lock, flags);
> -
> -	if (submit)
> -		execlists_submit_ports(engine);
> -
> -	GEM_BUG_ON(port_isset(execlists->port) &&
> -		   !execlists_is_active(execlists, EXECLISTS_ACTIVE_USER));
>   }
>   
>   void
> @@ -1156,11 +1153,6 @@ static void execlists_submission_tasklet(unsigned long data)
>   
>   	if (!execlists_is_active(&engine->execlists, EXECLISTS_ACTIVE_PREEMPT))
>   		execlists_dequeue(engine);
> -
> -	/* If the engine is now idle, so should be the flag; and vice versa. */
> -	GEM_BUG_ON(execlists_is_active(&engine->execlists,
> -				       EXECLISTS_ACTIVE_USER) ==
> -		   !port_isset(engine->execlists.port));
>   }
>   
>   static void queue_request(struct intel_engine_cs *engine,
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-06-01 14:02 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-31 18:51 ksoftirqd avoidance Chris Wilson
2018-05-31 18:51 ` [PATCH 01/11] drm/i915: Be irqsafe inside reset Chris Wilson
2018-06-01 13:44   ` Tvrtko Ursulin
2018-05-31 18:51 ` [PATCH 02/11] drm/i915/execlists: Reset the CSB head tracking on reset/sanitization Chris Wilson
2018-06-01 13:54   ` Tvrtko Ursulin
2018-05-31 18:51 ` [PATCH 03/11] drm/i915/execlists: Pull submit after dequeue under timeline lock Chris Wilson
2018-06-01 14:02   ` Tvrtko Ursulin [this message]
2018-06-01 14:07     ` Chris Wilson
2018-06-04  9:25       ` Tvrtko Ursulin
2018-06-04 10:12         ` Chris Wilson
2018-06-04 10:58           ` Tvrtko Ursulin
2018-06-04 11:15             ` Chris Wilson
2018-06-04 14:19   ` Tvrtko Ursulin
2018-05-31 18:51 ` [PATCH 04/11] drm/i915/execlists: Pull CSB reset under the timeline.lock Chris Wilson
2018-06-04 14:25   ` Tvrtko Ursulin
2018-06-04 15:29     ` Chris Wilson
2018-06-05  8:25       ` Tvrtko Ursulin
2018-05-31 18:51 ` [PATCH 05/11] drm/i915/execlists: Process one CSB interrupt at a time Chris Wilson
2018-06-04 14:27   ` Tvrtko Ursulin
2018-06-04 15:32     ` Chris Wilson
2018-06-05  8:30       ` Tvrtko Ursulin
2018-05-31 18:51 ` [PATCH 06/11] drm/i915/execlists: Unify CSB access pointers Chris Wilson
2018-06-04 14:53   ` Tvrtko Ursulin
2018-06-04 16:58     ` Daniele Ceraolo Spurio
2018-06-05  8:38       ` Tvrtko Ursulin
2018-05-31 18:52 ` [PATCH 07/11] drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd) Chris Wilson
2018-05-31 19:57   ` [PATCH] " Chris Wilson
2018-05-31 18:52 ` [PATCH 08/11] drm/i915: Move rate-limiting request retire to after submission Chris Wilson
2018-05-31 18:52 ` [PATCH 09/11] drm/i915: Wait for engines to idle before retiring Chris Wilson
2018-05-31 18:52 ` [PATCH 10/11] drm/i915: Move engine request retirement to intel_engine_cs Chris Wilson
2018-05-31 18:52 ` [PATCH 11/11] drm/i915: Hold request reference for submission until retirement Chris Wilson
2018-05-31 20:21   ` [PATCH] " Chris Wilson
2018-05-31 19:30 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/11] drm/i915: Be irqsafe inside reset Patchwork
2018-05-31 19:48 ` ✗ Fi.CI.BAT: failure " Patchwork
2018-05-31 20:14 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/11] drm/i915: Be irqsafe inside reset (rev2) Patchwork
2018-05-31 20:33 ` ✓ Fi.CI.BAT: success " Patchwork
2018-05-31 20:37 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/11] drm/i915: Be irqsafe inside reset (rev3) Patchwork
2018-05-31 20:54 ` ✓ Fi.CI.BAT: success " Patchwork
2018-05-31 21:54 ` ✗ Fi.CI.IGT: failure " Patchwork

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=8ed79b89-38ec-2bd3-6ea4-9f97eec43625@linux.intel.com \
    --to=tvrtko.ursulin@linux.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.