From: Dave Gordon <david.s.gordon@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v2 3/6] drm/i915/guc: use a separate GuC client for each engine
Date: Fri, 22 Jul 2016 11:23:11 +0100 [thread overview]
Message-ID: <5791F40F.4070301@intel.com> (raw)
In-Reply-To: <20160721183048.GG10317@nuc-i3427.alporthouse.com>
On 21/07/16 19:30, Chris Wilson wrote:
> On Thu, Jul 21, 2016 at 07:15:39PM +0100, Dave Gordon wrote:
>> When using a single GuC client for multiple engines, the i915 driver has
>> to merge all work items into a single work queue, which the GuC firmware
>> then demultiplexes into separate submission queues per engine. In
>> theory, this could lead to the single queue becoming a bottleneck in
>> which an excess of outstanding work for one or more engines might
>> prevent work for an idle engine reaching the hardware.
>>
>> To reduce this risk, we can create one GuC client per engine. Each will
>> have its own workqueue, to be used only for work targeting a single
>> engine, so there will be no cross-engine contention for workqueue slots.
>>
>> Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
>> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>
> Does guc_context_desc.engines_used have any effect?
> -Chris
Yes, some of the firmware code uses it to optimise which queues it scans
at certain times. If it knows that a certain queue *doesn't* contain
work for a given engine, it can skip scanning that queue entirely.
Does this patchset change the results in the parallel-submission nop test?
.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-07-22 10:23 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-21 18:15 [PATCH v2 0/6] drm/i915/guc: use one GuC client per GPU engine Dave Gordon
2016-07-21 18:15 ` [PATCH v2 1/6] drm/i915/guc: doorbell reset should avoid used doorbells Dave Gordon
2016-07-22 10:00 ` Tvrtko Ursulin
2016-07-21 18:15 ` [PATCH v2 2/6] drm/i915/guc: refactor guc_init_doorbell_hw() Dave Gordon
2016-07-22 10:01 ` Tvrtko Ursulin
2016-07-21 18:15 ` [PATCH v2 3/6] drm/i915/guc: use a separate GuC client for each engine Dave Gordon
2016-07-21 18:30 ` Chris Wilson
2016-07-22 10:23 ` Dave Gordon [this message]
2016-07-22 21:57 ` Chris Wilson
2016-07-21 18:15 ` [PATCH v2 4/6] drm/i915/guc: add engine mask to GuC client & pass to GuC Dave Gordon
2016-07-21 18:15 ` [PATCH v2 5/6] drm/i915/guc: use for_each_engine_id() where appropriate Dave Gordon
2016-07-22 10:04 ` Tvrtko Ursulin
2016-07-22 10:45 ` Dave Gordon
2016-07-21 18:15 ` [PATCH v2 6/6] drm/i915/guc: re-optimise i915_guc_client layout Dave Gordon
2016-07-22 10:05 ` Tvrtko Ursulin
2016-07-22 6:02 ` ✓ Ro.CI.BAT: success for drm/i915/guc: use one GuC client per GPU engine Patchwork
2016-07-22 10:06 ` Tvrtko Ursulin
2016-07-22 15:17 ` Dave Gordon
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=5791F40F.4070301@intel.com \
--to=david.s.gordon@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.