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. Dave Gordon (6): drm/i915/guc: doorbell reset should avoid used doorbells drm/i915/guc: refactor guc_init_doorbell_hw() drm/i915/guc: use a separate GuC client for each engine drm/i915/guc: add engine mask to GuC client & pass to GuC drm/i915/guc: use for_each_engine_id() where appropriate drm/i915/guc: re-optimise i915_guc_client layout drivers/gpu/drm/i915/i915_debugfs.c | 43 +++++++---- drivers/gpu/drm/i915/i915_guc_submission.c | 118 ++++++++++++++++++----------- drivers/gpu/drm/i915/intel_guc.h | 11 ++- 3 files changed, 107 insertions(+), 65 deletions(-) -- 1.9.1 -- _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
