[Intel-gfx] [PATCH 07/27] drm/i915/guc: Don't call switch_to_kernel_context with GuC submission
John Harrison
john.c.harrison at intel.com
Thu Sep 9 22:51:27 UTC 2021
On 8/20/2021 15:44, Matthew Brost wrote:
> Calling switch_to_kernel_context isn't needed if the engine PM reference
> is taken while all contexts are pinned. By not calling
> switch_to_kernel_context we save on issuing a request to the engine.
I thought the intention of the switch_to_kernel was to ensure that the
GPU is not touching any user context and is basically idle. That is not
a valid assumption with an external scheduler such as GuC. So why is the
description above only mentioning PM references? What is the connection
between the PM ref and the switch_to_kernel?
Also, the comment in the code does not mention anything about PM
references, it just says 'not necessary with GuC' but no explanation at all.
> v2:
> (Daniel Vetter)
> - Add FIXME comment about pushing switch_to_kernel_context to backend
>
> Signed-off-by: Matthew Brost <matthew.brost at intel.com>
> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> ---
> drivers/gpu/drm/i915/gt/intel_engine_pm.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> index 1f07ac4e0672..11fee66daf60 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> @@ -162,6 +162,15 @@ static bool switch_to_kernel_context(struct intel_engine_cs *engine)
> unsigned long flags;
> bool result = true;
>
> + /*
> + * No need to switch_to_kernel_context if GuC submission
> + *
> + * FIXME: This execlists specific backend behavior in generic code, this
"This execlists" -> "This is execlist"
"this should be" -> "it should be"
John.
> + * should be pushed to the 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