All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2 3/7] drm/i915/execlists: Make submission tasklet hardirq safe
Date: Tue, 08 May 2018 12:05:24 +0100	[thread overview]
Message-ID: <152577752428.24602.11661711810951048338@mail.alporthouse.com> (raw)
In-Reply-To: <0062c239-8e41-b25d-e6e4-e0945eec9fa7@linux.intel.com>

Quoting Tvrtko Ursulin (2018-05-08 11:56:37)
> 
> On 08/05/2018 11:24, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-05-08 11:10:41)
> >> On 07/05/2018 14:57, Chris Wilson wrote:
> >>> @@ -744,13 +748,25 @@ static void execlists_dequeue(struct intel_engine_cs *engine)
> >>>        /* We must always keep the beast fed if we have work piled up */
> >>>        GEM_BUG_ON(execlists->first && !port_isset(execlists->port));
> >>>    
> >>> -unlock:
> >>> -     spin_unlock_irq(&engine->timeline.lock);
> >>> -
> >>> -     if (submit) {
> >>> +     /* Re-evaluate the executing context setup after each preemptive kick */
> >>> +     if (last)
> >>>                execlists_user_begin(execlists, execlists->port);
> >>
> >> Last can be non-null and submit false, so this is not equivalent.
> >>
> >> By the looks of it makes no difference since it is OK to set the
> >> execlists user active bit multiple times. Even though the helper is
> >> called execlists_set_active_once. But the return value is not looked at.
> >>
> >> Still, why not keep doing this when submit is true?
> > 
> > It's a subtle difference, in that we want the context reevaluated every
> > time we kick the queue as we may have changed state that we want to
> > reload, and not just ELSP. Sometimes we need inheritance of more than
> > just priority...
> 
> What do you mean by context re-evaluated?
> 
> ACTIVE_USER is set from first to last request, no? I don't understand 
> what would change if you would set it multiple times while it is already 
> set.

It's not about ACTIVE_USER. This is a hook to indicate a change in
context state being executed on the GPU. It's to be hooked into by the
cpufreq/pstate code, gpufreq code, etc. Later realisation is that they
need to be notified for all context changes here.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-05-08 11:05 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-07 13:57 [PATCH v2 1/7] drm/i915: Flush submission tasklet after bumping priority Chris Wilson
2018-05-07 13:57 ` [PATCH v2 2/7] drm/i915: Disable tasklet scheduling across initial scheduling Chris Wilson
2018-05-08 10:02   ` Tvrtko Ursulin
2018-05-08 10:31     ` Chris Wilson
2018-05-07 13:57 ` [PATCH v2 3/7] drm/i915/execlists: Make submission tasklet hardirq safe Chris Wilson
2018-05-08 10:10   ` Tvrtko Ursulin
2018-05-08 10:24     ` Chris Wilson
2018-05-08 10:56       ` Tvrtko Ursulin
2018-05-08 11:05         ` Chris Wilson [this message]
2018-05-08 11:38           ` Tvrtko Ursulin
2018-05-08 11:43             ` Chris Wilson
2018-05-08 17:38   ` Tvrtko Ursulin
2018-05-08 17:45   ` Tvrtko Ursulin
2018-05-08 20:59     ` Chris Wilson
2018-05-09  9:23       ` Chris Wilson
2018-05-07 13:57 ` [PATCH v2 4/7] drm/i915/guc: " Chris Wilson
2018-05-08 17:43   ` Tvrtko Ursulin
2018-05-07 13:57 ` [PATCH v2 5/7] drm/i915/execlists: Direct submit onto idle engines Chris Wilson
2018-05-08 10:23   ` Tvrtko Ursulin
2018-05-08 10:40     ` Chris Wilson
2018-05-08 11:00       ` Tvrtko Ursulin
2018-05-07 13:57 ` [PATCH v2 6/7] drm/i915/execlists: Direct submission from irq handler Chris Wilson
2018-05-08 10:54   ` Tvrtko Ursulin
2018-05-08 11:10     ` Chris Wilson
2018-05-08 11:53       ` Tvrtko Ursulin
2018-05-08 12:17   ` [PATCH] " Chris Wilson
2018-05-07 13:57 ` [PATCH v2 7/7] drm/i915: Speed up idle detection by kicking the tasklets Chris Wilson
2018-05-07 15:31 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/7] drm/i915: Flush submission tasklet after bumping priority Patchwork
2018-05-07 15:32 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-05-07 15:46 ` ✓ Fi.CI.BAT: success " Patchwork
2018-05-07 17:56 ` ✓ Fi.CI.IGT: " Patchwork
2018-05-08  9:40 ` [PATCH v2 1/7] " Tvrtko Ursulin
2018-05-08  9:45   ` Chris Wilson
2018-05-08  9:57     ` Tvrtko Ursulin
2018-05-08 14:11 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/7] drm/i915: Flush submission tasklet after bumping priority (rev2) Patchwork
2018-05-08 14:13 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-05-08 14:28 ` ✓ Fi.CI.BAT: success " Patchwork
2018-05-08 16:27 ` ✓ Fi.CI.IGT: " 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=152577752428.24602.11661711810951048338@mail.alporthouse.com \
    --to=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=tvrtko.ursulin@linux.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.