From: Chris Wilson <[email protected]>
There may be a disconnect between the GT used by the engine and the GT
used for the VM, requiring us to hold a wakeref on both while the GPU is
active with this request.
Signed-off-by: Chris Wilson <[email protected]>
[ahajda: removed not-yet-upstremed wakeref tracking bits]
Signed-off-by: Andrzej Hajda <[email protected]>
---
drivers/gpu/drm/i915/gt/intel_context.h | 15 +++++++++++----
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 3 +++
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h b/drivers/gpu/drm/i915/gt/intel_context.h
index 0a8d553da3f439..48f888c3da083b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -14,6 +14,7 @@
#include "i915_drv.h"
#include "intel_context_types.h"
#include "intel_engine_types.h"
+#include "intel_gt_pm.h"
#include "intel_ring_types.h"
#include "intel_timeline_types.h"
#include "i915_trace.h"
@@ -207,8 +208,11 @@ void intel_context_exit_engine(struct intel_context *ce);
static inline void intel_context_enter(struct intel_context *ce)
{
lockdep_assert_held(&ce->timeline->mutex);
- if (!ce->active_count++)
- ce->ops->enter(ce);
+ if (ce->active_count++)
+ return;
+
+ ce->ops->enter(ce);
+ intel_gt_pm_get(ce->vm->gt);
}
static inline void intel_context_mark_active(struct intel_context *ce)
@@ -222,8 +226,11 @@ static inline void intel_context_exit(struct intel_context *ce)
{
lockdep_assert_held(&ce->timeline->mutex);
GEM_BUG_ON(!ce->active_count);
- if (!--ce->active_count)
- ce->ops->exit(ce);
+ if (--ce->active_count)
+ return;
+
+ intel_gt_pm_put_async(ce->vm->gt);
+ ce->ops->exit(ce);
}
static inline struct intel_context *intel_context_get(struct intel_context *ce)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index e971b153fda976..ac0566c5e99e17 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -114,6 +114,9 @@ __queue_and_release_pm(struct i915_request *rq,
ENGINE_TRACE(engine, "parking\n");
+ GEM_BUG_ON(rq->context->active_count != 1);
+ __intel_gt_pm_get(engine->gt);
+
/*
* We have to serialise all potential retirement paths with our
* submission, as we don't want to underflow either the
---
base-commit: 3385d6482cd60f2a0bbb0fa97b70ae7dbba4f95c
change-id: 20230330-hold_wakeref_for_active_vm-7f013a449ef3
Best regards,
--
Andrzej Hajda <[email protected]>
On Thu, Mar 30, 2023 at 04:35:39PM +0200, Andrzej Hajda wrote:
> From: Chris Wilson <[email protected]>
>
> There may be a disconnect between the GT used by the engine and the GT
> used for the VM, requiring us to hold a wakeref on both while the GPU is
> active with this request.
>
> Signed-off-by: Chris Wilson <[email protected]>
> [ahajda: removed not-yet-upstremed wakeref tracking bits]
> Signed-off-by: Andrzej Hajda <[email protected]>
> ---
> drivers/gpu/drm/i915/gt/intel_context.h | 15 +++++++++++----
> drivers/gpu/drm/i915/gt/intel_engine_pm.c | 3 +++
> 2 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.h b/drivers/gpu/drm/i915/gt/intel_context.h
> index 0a8d553da3f439..48f888c3da083b 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.h
> +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> @@ -14,6 +14,7 @@
> #include "i915_drv.h"
> #include "intel_context_types.h"
> #include "intel_engine_types.h"
> +#include "intel_gt_pm.h"
> #include "intel_ring_types.h"
> #include "intel_timeline_types.h"
> #include "i915_trace.h"
> @@ -207,8 +208,11 @@ void intel_context_exit_engine(struct intel_context *ce);
> static inline void intel_context_enter(struct intel_context *ce)
> {
> lockdep_assert_held(&ce->timeline->mutex);
> - if (!ce->active_count++)
> - ce->ops->enter(ce);
> + if (ce->active_count++)
> + return;
> +
> + ce->ops->enter(ce);
> + intel_gt_pm_get(ce->vm->gt);
> }
>
> static inline void intel_context_mark_active(struct intel_context *ce)
> @@ -222,8 +226,11 @@ static inline void intel_context_exit(struct intel_context *ce)
> {
> lockdep_assert_held(&ce->timeline->mutex);
> GEM_BUG_ON(!ce->active_count);
> - if (!--ce->active_count)
> - ce->ops->exit(ce);
> + if (--ce->active_count)
> + return;
> +
> + intel_gt_pm_put_async(ce->vm->gt);
> + ce->ops->exit(ce);
so far so good. this all matches the commit msg and seems a good move.
> }
>
> static inline struct intel_context *intel_context_get(struct intel_context *ce)
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> index e971b153fda976..ac0566c5e99e17 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> @@ -114,6 +114,9 @@ __queue_and_release_pm(struct i915_request *rq,
>
> ENGINE_TRACE(engine, "parking\n");
>
> + GEM_BUG_ON(rq->context->active_count != 1);
why do you need this here? should it be a separated patch with
separated explanation?
> + __intel_gt_pm_get(engine->gt);
why? I mean, why the get in the release pm?
and where's the put for this get?
should it be a separated patch as well?
> +
> /*
> * We have to serialise all potential retirement paths with our
> * submission, as we don't want to underflow either the
>
> ---
> base-commit: 3385d6482cd60f2a0bbb0fa97b70ae7dbba4f95c
> change-id: 20230330-hold_wakeref_for_active_vm-7f013a449ef3
>
> Best regards,
> --
> Andrzej Hajda <[email protected]>
On 30/03/2023 15:35, Andrzej Hajda wrote:
> From: Chris Wilson <[email protected]>
>
> There may be a disconnect between the GT used by the engine and the GT
> used for the VM, requiring us to hold a wakeref on both while the GPU is
> active with this request.
Presumably this is for MTL? "drm/i1915/mtl: ..." ?
> Signed-off-by: Chris Wilson <[email protected]>
> [ahajda: removed not-yet-upstremed wakeref tracking bits]
> Signed-off-by: Andrzej Hajda <[email protected]>
> ---
> drivers/gpu/drm/i915/gt/intel_context.h | 15 +++++++++++----
> drivers/gpu/drm/i915/gt/intel_engine_pm.c | 3 +++
> 2 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_context.h b/drivers/gpu/drm/i915/gt/intel_context.h
> index 0a8d553da3f439..48f888c3da083b 100644
> --- a/drivers/gpu/drm/i915/gt/intel_context.h
> +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> @@ -14,6 +14,7 @@
> #include "i915_drv.h"
> #include "intel_context_types.h"
> #include "intel_engine_types.h"
> +#include "intel_gt_pm.h"
> #include "intel_ring_types.h"
> #include "intel_timeline_types.h"
> #include "i915_trace.h"
> @@ -207,8 +208,11 @@ void intel_context_exit_engine(struct intel_context *ce);
> static inline void intel_context_enter(struct intel_context *ce)
> {
> lockdep_assert_held(&ce->timeline->mutex);
> - if (!ce->active_count++)
> - ce->ops->enter(ce);
> + if (ce->active_count++)
> + return;
> +
> + ce->ops->enter(ce);
> + intel_gt_pm_get(ce->vm->gt);
> }
>
> static inline void intel_context_mark_active(struct intel_context *ce)
> @@ -222,8 +226,11 @@ static inline void intel_context_exit(struct intel_context *ce)
> {
> lockdep_assert_held(&ce->timeline->mutex);
> GEM_BUG_ON(!ce->active_count);
> - if (!--ce->active_count)
> - ce->ops->exit(ce);
> + if (--ce->active_count)
> + return;
> +
> + intel_gt_pm_put_async(ce->vm->gt);
> + ce->ops->exit(ce);
Above too are balance and plausible - media tile engine vs root tile VM,
although at the moment it escapes me what exactly would go bad, like
what gets powered down which is then access by the executing request and
fails how?
> }
>
> static inline struct intel_context *intel_context_get(struct intel_context *ce)
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> index e971b153fda976..ac0566c5e99e17 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> @@ -114,6 +114,9 @@ __queue_and_release_pm(struct i915_request *rq,
>
> ENGINE_TRACE(engine, "parking\n");
>
> + GEM_BUG_ON(rq->context->active_count != 1);
> + __intel_gt_pm_get(engine->gt);
> +
But this one I don't immediately get. Above we have get and put which is
balanced - fine, but where is this extra get coming from, who will put
it and where?
Regards,
Tvrtko
> /*
> * We have to serialise all potential retirement paths with our
> * submission, as we don't want to underflow either the
>
> ---
> base-commit: 3385d6482cd60f2a0bbb0fa97b70ae7dbba4f95c
> change-id: 20230330-hold_wakeref_for_active_vm-7f013a449ef3
>
> Best regards,