[PATCH 04/26] drm/i915/guc: Don't call switch_to_kernel_context with GuC submission

John Harrison john.c.harrison at intel.com
Thu Oct 7 03:49:05 UTC 2021


On 10/4/2021 15:06, Matthew Brost wrote:
> Calling switch_to_kernel_context isn't needed if the engine PM reference
> is taken while all user contexts are pinned as if don't have PM ref that
> guarantees that all user contexts scheduling is disabled. By not calling
> switch_to_kernel_context we save on issuing a request to the engine.
>
> v2:
>   (Daniel Vetter)
>    - Add FIXME comment about pushing switch_to_kernel_context to backend
> v3:
>   (John Harrison)
>    - Update commit message
>    - Fix workding comment
>
> Signed-off-by: Matthew Brost <matthew.brost at intel.com>
> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
Reviewed-by: John Harrison <John.C.Harrison at Intel.com>

> ---
>   drivers/gpu/drm/i915/gt/intel_engine_pm.c | 13 +++++++++++++
>   1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> index dacd62773735..a1334b48dde7 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> @@ -162,6 +162,19 @@ static bool switch_to_kernel_context(struct intel_engine_cs *engine)
>   	unsigned long flags;
>   	bool result = true;
>   
> +	/*
> +	 * This is execlist specific behaviour intended to ensure the GPU is
> +	 * idle by switching to a known 'safe' context. With GuC submission, the
> +	 * same idle guarantee is achieved by other means (disabling
> +	 * scheduling). Further, switching to a 'safe' context has no effect
> +	 * with GuC submission as the scheduler can just switch back again.
> +	 *
> +	 * FIXME: Move this backend scheduler specific behaviour into the
> +	 * scheduler backend.
> +	 */
> +	if (intel_engine_uses_guc(engine))
> +		return true;
> +
>   	/* GPU is pointing to the void, as good as in the kernel context. */
>   	if (intel_gt_is_wedged(engine->gt))
>   		return true;



More information about the dri-devel mailing list