| Message ID | 1465312727-2211-10-git-send-email-zhi.a.wang@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Jun 07, 2016 at 11:18:45AM -0400, Zhi Wang wrote: > This patch introduces an approach to track the execlist context status > change. > > GVT-g uses GVT context as the "shadow context". The content inside GVT > context will be copied back to guest after the context is idle. And GVT-g > has to know the status of the execlist context. > > This function is configurable when creating a new GEM context. Currently, > Only GVT-g will create the "status-change-notification" enabled GEM > context. > > v7: > > - Remove per-engine ctx status notifiers. Use one status notifier for all > engines. (Joonas) > - Add prefix "INTEL_" for related definitions. (Joonas) > - Refine the comments in execlists_context_status_change(). (Joonas) > > v6: > > - When !CONFIG_DRM_I915_GVT, make GVT code as dead code then compiler > could automatically eliminate them for us. (Chris) > - Always initialize the notifier header, so it could be switched on/off > at runtime. (Chris) > > v5: > > - Only compile this feature when CONFIG_DRM_I915_GVT is enabled.(Tvrtko) > > Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> > --- > +static inline void execlists_context_status_change( > + struct drm_i915_gem_request *rq, > + unsigned long status) > +{ > + /* > + * Only used when GVT-g is enabled now. When GVT-g is disabled, > + * The compiler should eliminate this function as dead-code. > + */ > + if (!IS_ENABLED(CONFIG_DRM_I915_GVT)) > + return; > + > + if (!rq->ctx->enable_lrc_status_change_notification) > + return; Was there any other justification for the boolean? (i.e. does it get used elsewhere) I thought we mentioned this as probably premature optimisation and should favour speeding up a no-op call_chain() if required. So can we have callbacks in the notifier but need to disable notification? If so, that is never explained. > + > + atomic_notifier_call_chain(&rq->ctx->status_notifier, status, rq); > +}
On ti, 2016-06-07 at 23:01 +0100, Chris Wilson wrote: > On Tue, Jun 07, 2016 at 11:18:45AM -0400, Zhi Wang wrote: > > > > This patch introduces an approach to track the execlist context status > > change. > > > > GVT-g uses GVT context as the "shadow context". The content inside GVT > > context will be copied back to guest after the context is idle. And GVT-g > > has to know the status of the execlist context. > > > > This function is configurable when creating a new GEM context. Currently, > > Only GVT-g will create the "status-change-notification" enabled GEM > > context. > > > > v7: > > > > - Remove per-engine ctx status notifiers. Use one status notifier for all > > engines. (Joonas) > > - Add prefix "INTEL_" for related definitions. (Joonas) > > - Refine the comments in execlists_context_status_change(). (Joonas) > > > > v6: > > > > - When !CONFIG_DRM_I915_GVT, make GVT code as dead code then compiler > > could automatically eliminate them for us. (Chris) > > - Always initialize the notifier header, so it could be switched on/off > > at runtime. (Chris) > > > > v5: > > > > - Only compile this feature when CONFIG_DRM_I915_GVT is enabled.(Tvrtko) > > > > Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> > > --- > > +static inline void execlists_context_status_change( > > + struct drm_i915_gem_request *rq, > > + unsigned long status) > > +{ > > + /* > > + * Only used when GVT-g is enabled now. When GVT-g is disabled, > > + * The compiler should eliminate this function as dead-code. > > + */ > > + if (!IS_ENABLED(CONFIG_DRM_I915_GVT)) > > + return; > > + > > + if (!rq->ctx->enable_lrc_status_change_notification) > > + return; > Was there any other justification for the boolean? (i.e. does it get > used elsewhere) I thought we mentioned this as probably premature > optimisation and should favour speeding up a no-op call_chain() if > required. So can we have callbacks in the notifier but need to disable > notification? If so, that is never explained. > By my original comments, after removing this boolean, you can add my; Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> > > > > + > > + atomic_notifier_call_chain(&rq->ctx->status_notifier, status, rq); > > +}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index a3ef3eb..4ab4cf7 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -880,6 +880,8 @@ struct i915_gem_context { } engine[I915_NUM_ENGINES]; u32 lrc_ring_buffer_size; u32 lrc_addressing_mode_bits; + struct atomic_notifier_head status_notifier; + bool enable_lrc_status_change_notification; struct list_head link; diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index d9d7779..b0e82a1 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -298,6 +298,7 @@ __create_hw_context(struct drm_device *dev, ctx->lrc_ring_buffer_size = 4 * PAGE_SIZE; ctx->lrc_addressing_mode_bits = GEN8_CTX_ADDRESSING_MODE(dev_priv) << GEN8_CTX_ADDRESSING_MODE_SHIFT; + ATOMIC_INIT_NOTIFIER_HEAD(&ctx->status_notifier); return ctx; diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index ffb436c..956585d 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -404,6 +404,23 @@ static void execlists_submit_requests(struct drm_i915_gem_request *rq0, spin_unlock_irq(&dev_priv->uncore.lock); } +static inline void execlists_context_status_change( + struct drm_i915_gem_request *rq, + unsigned long status) +{ + /* + * Only used when GVT-g is enabled now. When GVT-g is disabled, + * The compiler should eliminate this function as dead-code. + */ + if (!IS_ENABLED(CONFIG_DRM_I915_GVT)) + return; + + if (!rq->ctx->enable_lrc_status_change_notification) + return; + + atomic_notifier_call_chain(&rq->ctx->status_notifier, status, rq); +} + static void execlists_context_unqueue(struct intel_engine_cs *engine) { struct drm_i915_gem_request *req0 = NULL, *req1 = NULL; @@ -439,6 +456,12 @@ static void execlists_context_unqueue(struct intel_engine_cs *engine) if (unlikely(!req0)) return; + execlists_context_status_change(req0, INTEL_CONTEXT_SCHEDULE_IN); + + if (req1) + execlists_context_status_change(req1, + INTEL_CONTEXT_SCHEDULE_IN); + if (req0->elsp_submitted & engine->idle_lite_restore_wa) { /* * WaIdleLiteRestore: make sure we never cause a lite restore @@ -477,6 +500,8 @@ execlists_check_remove_request(struct intel_engine_cs *engine, u32 ctx_id) if (--head_req->elsp_submitted > 0) return 0; + execlists_context_status_change(head_req, INTEL_CONTEXT_SCHEDULE_OUT); + list_del(&head_req->execlist_link); i915_gem_request_unreference(head_req); diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h index a8db42a..2b8255c 100644 --- a/drivers/gpu/drm/i915/intel_lrc.h +++ b/drivers/gpu/drm/i915/intel_lrc.h @@ -57,6 +57,11 @@ #define GEN8_CSB_READ_PTR(csb_status) \ (((csb_status) & GEN8_CSB_READ_PTR_MASK) >> 8) +enum { + INTEL_CONTEXT_SCHEDULE_IN = 0, + INTEL_CONTEXT_SCHEDULE_OUT, +}; + /* Logical Rings */ int intel_logical_ring_alloc_request_extras(struct drm_i915_gem_request *request); int intel_logical_ring_reserve_space(struct drm_i915_gem_request *request);
This patch introduces an approach to track the execlist context status change. GVT-g uses GVT context as the "shadow context". The content inside GVT context will be copied back to guest after the context is idle. And GVT-g has to know the status of the execlist context. This function is configurable when creating a new GEM context. Currently, Only GVT-g will create the "status-change-notification" enabled GEM context. v7: - Remove per-engine ctx status notifiers. Use one status notifier for all engines. (Joonas) - Add prefix "INTEL_" for related definitions. (Joonas) - Refine the comments in execlists_context_status_change(). (Joonas) v6: - When !CONFIG_DRM_I915_GVT, make GVT code as dead code then compiler could automatically eliminate them for us. (Chris) - Always initialize the notifier header, so it could be switched on/off at runtime. (Chris) v5: - Only compile this feature when CONFIG_DRM_I915_GVT is enabled.(Tvrtko) Signed-off-by: Zhi Wang <zhi.a.wang@intel.com> --- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/i915_gem_context.c | 1 + drivers/gpu/drm/i915/intel_lrc.c | 25 +++++++++++++++++++++++++ drivers/gpu/drm/i915/intel_lrc.h | 5 +++++ 4 files changed, 33 insertions(+)