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@xxxxxxxxx>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
