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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox