From: Matthew Brost <matthew.brost@intel.com>
To: John Harrison <john.c.harrison@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
daniele.ceraolospurio@intel.com
Subject: Re: [Intel-gfx] [PATCH 07/26] drm/i915/guc: Introduce context parent-child relationship
Date: Fri, 8 Oct 2021 11:33:30 -0700 [thread overview]
Message-ID: <20211008183330.GA2672@jons-linux-dev-box> (raw)
In-Reply-To: <624cb924-dadc-89f8-6f52-c56366f15eb1@intel.com>
On Thu, Oct 07, 2021 at 12:35:08PM -0700, John Harrison wrote:
> On 10/4/2021 15:06, Matthew Brost wrote:
> > Introduce context parent-child relationship. Once this relationship is
> > created all pinning / unpinning operations are directed to the parent
> > context. The parent context is responsible for pinning all of its'
> No need for an apostrophe.
>
Fixed.
> > children and itself.
> >
> > This is a precursor to the full GuC multi-lrc implementation but aligns
> > to how GuC mutli-lrc interface is defined - a single H2G is used
> > register / deregister all of the contexts simultaneously.
> >
> > Subsequent patches in the series will implement the pinning / unpinning
> > operations for parent / child contexts.
> >
> > v2:
> > (Daniel Vetter)
> > - Add kernel doc, add wrapper to access parent to ensure safety
> > v3:
> > (John Harrison)
> > - Fix comment explaing GEM_BUG_ON in to_parent()
> > - Make variable names generic (non-GuC specific)
> >
> > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > ---
> > drivers/gpu/drm/i915/gt/intel_context.c | 29 +++++++++++++
> > drivers/gpu/drm/i915/gt/intel_context.h | 41 +++++++++++++++++++
> > drivers/gpu/drm/i915/gt/intel_context_types.h | 21 ++++++++++
> > 3 files changed, 91 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c b/drivers/gpu/drm/i915/gt/intel_context.c
> > index f601323b939f..c5bb7ccfb3f8 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > @@ -403,6 +403,8 @@ intel_context_init(struct intel_context *ce, struct intel_engine_cs *engine)
> > INIT_LIST_HEAD(&ce->destroyed_link);
> > + INIT_LIST_HEAD(&ce->parallel.child_list);
> > +
> > /*
> > * Initialize fence to be complete as this is expected to be complete
> > * unless there is a pending schedule disable outstanding.
> > @@ -417,10 +419,17 @@ intel_context_init(struct intel_context *ce, struct intel_engine_cs *engine)
> > void intel_context_fini(struct intel_context *ce)
> > {
> > + struct intel_context *child, *next;
> > +
> > if (ce->timeline)
> > intel_timeline_put(ce->timeline);
> > i915_vm_put(ce->vm);
> > + /* Need to put the creation ref for the children */
> > + if (intel_context_is_parent(ce))
> > + for_each_child_safe(ce, child, next)
> > + intel_context_put(child);
> > +
> > mutex_destroy(&ce->pin_mutex);
> > i915_active_fini(&ce->active);
> > i915_sw_fence_fini(&ce->guc_state.blocked);
> > @@ -537,6 +546,26 @@ struct i915_request *intel_context_find_active_request(struct intel_context *ce)
> > return active;
> > }
> > +void intel_context_bind_parent_child(struct intel_context *parent,
> > + struct intel_context *child)
> > +{
> > + /*
> > + * Callers responsibility to validate that this function is used
> > + * correctly but we use GEM_BUG_ON here ensure that they do.
> > + */
> > + GEM_BUG_ON(!intel_engine_uses_guc(parent->engine));
> > + GEM_BUG_ON(intel_context_is_pinned(parent));
> > + GEM_BUG_ON(intel_context_is_child(parent));
> > + GEM_BUG_ON(intel_context_is_pinned(child));
> > + GEM_BUG_ON(intel_context_is_child(child));
> > + GEM_BUG_ON(intel_context_is_parent(child));
> > +
> > + parent->parallel.number_children++;
> > + list_add_tail(&child->parallel.child_link,
> > + &parent->parallel.child_list);
> > + child->parallel.parent = parent;
> > +}
> > +
> > #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> > #include "selftest_context.c"
> > #endif
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.h b/drivers/gpu/drm/i915/gt/intel_context.h
> > index c41098950746..b63c10a144af 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> > @@ -44,6 +44,47 @@ void intel_context_free(struct intel_context *ce);
> > int intel_context_reconfigure_sseu(struct intel_context *ce,
> > const struct intel_sseu sseu);
> > +static inline bool intel_context_is_child(struct intel_context *ce)
> > +{
> > + return !!ce->parallel.parent;
> > +}
> > +
> > +static inline bool intel_context_is_parent(struct intel_context *ce)
> > +{
> > + return !!ce->parallel.number_children;
> > +}
> > +
> > +static inline bool intel_context_is_pinned(struct intel_context *ce);
> > +
> > +static inline struct intel_context *
> > +intel_context_to_parent(struct intel_context *ce)
> > +{
> > + if (intel_context_is_child(ce)) {
> > + /*
> > + * The parent holds ref count to the child so it is always safe
> > + * for the parent to access the child, but the child has a
> > + * pointer to the parent without a ref. To ensure this is safe
> > + * the child should only access the parent pointer while the
> > + * parent is pinned.
> > + */
> > + GEM_BUG_ON(!intel_context_is_pinned(ce->parallel.parent));
> > +
> > + return ce->parallel.parent;
> > + } else {
> > + return ce;
> > + }
> > +}
> > +
> > +void intel_context_bind_parent_child(struct intel_context *parent,
> > + struct intel_context *child);
> > +
> > +#define for_each_child(parent, ce)\
> > + list_for_each_entry(ce, &(parent)->parallel.child_list,\
> > + parallel.child_link)
> > +#define for_each_child_safe(parent, ce, cn)\
> > + list_for_each_entry_safe(ce, cn, &(parent)->parallel.child_list,\
> > + parallel.child_link)
> > +
> > /**
> > * intel_context_lock_pinned - Stablises the 'pinned' status of the HW context
> > * @ce - the context
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > index 4613d027cbc3..76dfca57cb45 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > @@ -220,6 +220,27 @@ struct intel_context {
> > */
> > struct list_head destroyed_link;
> > + /** @parallel: sub-structure for parallel submission members */
> > + struct {
> > + union {
> > + /**
> > + * @child_list: parent's list of children
> > + * contexts, no protection as immutable after context
> > + * creation
> > + */
> > + struct list_head child_list;
> > + /**
> > + * @child_link: child's link into parent's list of
> > + * children
> > + */
> > + struct list_head child_link;
> > + };
> > + /** @parent: pointer to parent if child */
> > + struct intel_context *parent;
> > + /** @number_children: number of children if parent */
> > + u8 number_children;
> Is there any particular reason for using 'u8'? A simple 'int' can be much
> more efficient depending upon the host CPU architecture.
>
Several other fields in the struct are u8 as well, I guess it saves a
few bytes in the struct if they are packed together. Going to leave as
is, if we want to change to all natural sizes we can do in a simple
follow up patch.
Matt
> Not a blocker though. So with the typo above fixed:
> Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
>
> > + } parallel;
> > +
> > #ifdef CONFIG_DRM_I915_SELFTEST
> > /**
> > * @drop_schedule_enable: Force drop of schedule enable G2H for selftest
>
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Brost <matthew.brost@intel.com>
To: John Harrison <john.c.harrison@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
daniele.ceraolospurio@intel.com
Subject: Re: [PATCH 07/26] drm/i915/guc: Introduce context parent-child relationship
Date: Fri, 8 Oct 2021 11:33:30 -0700 [thread overview]
Message-ID: <20211008183330.GA2672@jons-linux-dev-box> (raw)
In-Reply-To: <624cb924-dadc-89f8-6f52-c56366f15eb1@intel.com>
On Thu, Oct 07, 2021 at 12:35:08PM -0700, John Harrison wrote:
> On 10/4/2021 15:06, Matthew Brost wrote:
> > Introduce context parent-child relationship. Once this relationship is
> > created all pinning / unpinning operations are directed to the parent
> > context. The parent context is responsible for pinning all of its'
> No need for an apostrophe.
>
Fixed.
> > children and itself.
> >
> > This is a precursor to the full GuC multi-lrc implementation but aligns
> > to how GuC mutli-lrc interface is defined - a single H2G is used
> > register / deregister all of the contexts simultaneously.
> >
> > Subsequent patches in the series will implement the pinning / unpinning
> > operations for parent / child contexts.
> >
> > v2:
> > (Daniel Vetter)
> > - Add kernel doc, add wrapper to access parent to ensure safety
> > v3:
> > (John Harrison)
> > - Fix comment explaing GEM_BUG_ON in to_parent()
> > - Make variable names generic (non-GuC specific)
> >
> > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > ---
> > drivers/gpu/drm/i915/gt/intel_context.c | 29 +++++++++++++
> > drivers/gpu/drm/i915/gt/intel_context.h | 41 +++++++++++++++++++
> > drivers/gpu/drm/i915/gt/intel_context_types.h | 21 ++++++++++
> > 3 files changed, 91 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c b/drivers/gpu/drm/i915/gt/intel_context.c
> > index f601323b939f..c5bb7ccfb3f8 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > @@ -403,6 +403,8 @@ intel_context_init(struct intel_context *ce, struct intel_engine_cs *engine)
> > INIT_LIST_HEAD(&ce->destroyed_link);
> > + INIT_LIST_HEAD(&ce->parallel.child_list);
> > +
> > /*
> > * Initialize fence to be complete as this is expected to be complete
> > * unless there is a pending schedule disable outstanding.
> > @@ -417,10 +419,17 @@ intel_context_init(struct intel_context *ce, struct intel_engine_cs *engine)
> > void intel_context_fini(struct intel_context *ce)
> > {
> > + struct intel_context *child, *next;
> > +
> > if (ce->timeline)
> > intel_timeline_put(ce->timeline);
> > i915_vm_put(ce->vm);
> > + /* Need to put the creation ref for the children */
> > + if (intel_context_is_parent(ce))
> > + for_each_child_safe(ce, child, next)
> > + intel_context_put(child);
> > +
> > mutex_destroy(&ce->pin_mutex);
> > i915_active_fini(&ce->active);
> > i915_sw_fence_fini(&ce->guc_state.blocked);
> > @@ -537,6 +546,26 @@ struct i915_request *intel_context_find_active_request(struct intel_context *ce)
> > return active;
> > }
> > +void intel_context_bind_parent_child(struct intel_context *parent,
> > + struct intel_context *child)
> > +{
> > + /*
> > + * Callers responsibility to validate that this function is used
> > + * correctly but we use GEM_BUG_ON here ensure that they do.
> > + */
> > + GEM_BUG_ON(!intel_engine_uses_guc(parent->engine));
> > + GEM_BUG_ON(intel_context_is_pinned(parent));
> > + GEM_BUG_ON(intel_context_is_child(parent));
> > + GEM_BUG_ON(intel_context_is_pinned(child));
> > + GEM_BUG_ON(intel_context_is_child(child));
> > + GEM_BUG_ON(intel_context_is_parent(child));
> > +
> > + parent->parallel.number_children++;
> > + list_add_tail(&child->parallel.child_link,
> > + &parent->parallel.child_list);
> > + child->parallel.parent = parent;
> > +}
> > +
> > #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> > #include "selftest_context.c"
> > #endif
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.h b/drivers/gpu/drm/i915/gt/intel_context.h
> > index c41098950746..b63c10a144af 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> > @@ -44,6 +44,47 @@ void intel_context_free(struct intel_context *ce);
> > int intel_context_reconfigure_sseu(struct intel_context *ce,
> > const struct intel_sseu sseu);
> > +static inline bool intel_context_is_child(struct intel_context *ce)
> > +{
> > + return !!ce->parallel.parent;
> > +}
> > +
> > +static inline bool intel_context_is_parent(struct intel_context *ce)
> > +{
> > + return !!ce->parallel.number_children;
> > +}
> > +
> > +static inline bool intel_context_is_pinned(struct intel_context *ce);
> > +
> > +static inline struct intel_context *
> > +intel_context_to_parent(struct intel_context *ce)
> > +{
> > + if (intel_context_is_child(ce)) {
> > + /*
> > + * The parent holds ref count to the child so it is always safe
> > + * for the parent to access the child, but the child has a
> > + * pointer to the parent without a ref. To ensure this is safe
> > + * the child should only access the parent pointer while the
> > + * parent is pinned.
> > + */
> > + GEM_BUG_ON(!intel_context_is_pinned(ce->parallel.parent));
> > +
> > + return ce->parallel.parent;
> > + } else {
> > + return ce;
> > + }
> > +}
> > +
> > +void intel_context_bind_parent_child(struct intel_context *parent,
> > + struct intel_context *child);
> > +
> > +#define for_each_child(parent, ce)\
> > + list_for_each_entry(ce, &(parent)->parallel.child_list,\
> > + parallel.child_link)
> > +#define for_each_child_safe(parent, ce, cn)\
> > + list_for_each_entry_safe(ce, cn, &(parent)->parallel.child_list,\
> > + parallel.child_link)
> > +
> > /**
> > * intel_context_lock_pinned - Stablises the 'pinned' status of the HW context
> > * @ce - the context
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > index 4613d027cbc3..76dfca57cb45 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > @@ -220,6 +220,27 @@ struct intel_context {
> > */
> > struct list_head destroyed_link;
> > + /** @parallel: sub-structure for parallel submission members */
> > + struct {
> > + union {
> > + /**
> > + * @child_list: parent's list of children
> > + * contexts, no protection as immutable after context
> > + * creation
> > + */
> > + struct list_head child_list;
> > + /**
> > + * @child_link: child's link into parent's list of
> > + * children
> > + */
> > + struct list_head child_link;
> > + };
> > + /** @parent: pointer to parent if child */
> > + struct intel_context *parent;
> > + /** @number_children: number of children if parent */
> > + u8 number_children;
> Is there any particular reason for using 'u8'? A simple 'int' can be much
> more efficient depending upon the host CPU architecture.
>
Several other fields in the struct are u8 as well, I guess it saves a
few bytes in the struct if they are packed together. Going to leave as
is, if we want to change to all natural sizes we can do in a simple
follow up patch.
Matt
> Not a blocker though. So with the typo above fixed:
> Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
>
> > + } parallel;
> > +
> > #ifdef CONFIG_DRM_I915_SELFTEST
> > /**
> > * @drop_schedule_enable: Force drop of schedule enable G2H for selftest
>
next prev parent reply other threads:[~2021-10-08 18:38 UTC|newest]
Thread overview: 165+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-04 22:06 [Intel-gfx] [PATCH 00/26] Parallel submission aka multi-bb execbuf Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-04 22:06 ` [Intel-gfx] [PATCH 01/26] drm/i915/guc: Move GuC guc_id allocation under submission state sub-struct Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-07 3:06 ` [Intel-gfx] " John Harrison
2021-10-07 3:06 ` John Harrison
2021-10-07 15:05 ` [Intel-gfx] " Matthew Brost
2021-10-07 15:05 ` Matthew Brost
2021-10-07 18:13 ` [Intel-gfx] " John Harrison
2021-10-07 18:13 ` John Harrison
2021-10-04 22:06 ` [Intel-gfx] [PATCH 02/26] drm/i915/guc: Take GT PM ref when deregistering context Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-07 3:37 ` [Intel-gfx] " John Harrison
2021-10-07 3:37 ` John Harrison
2021-10-08 1:28 ` [Intel-gfx] " Matthew Brost
2021-10-08 1:28 ` Matthew Brost
2021-10-08 18:23 ` [Intel-gfx] " Matthew Brost
2021-10-08 18:23 ` Matthew Brost
2021-10-04 22:06 ` [Intel-gfx] [PATCH 03/26] drm/i915/guc: Take engine PM when a context is pinned with GuC submission Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-07 3:45 ` [Intel-gfx] " John Harrison
2021-10-07 3:45 ` John Harrison
2021-10-07 15:19 ` [Intel-gfx] " Matthew Brost
2021-10-07 15:19 ` Matthew Brost
2021-10-07 18:15 ` [Intel-gfx] " John Harrison
2021-10-07 18:15 ` John Harrison
2021-10-08 1:23 ` [Intel-gfx] " Matthew Brost
2021-10-08 1:23 ` Matthew Brost
2021-10-04 22:06 ` [Intel-gfx] [PATCH 04/26] drm/i915/guc: Don't call switch_to_kernel_context " Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-07 3:49 ` [Intel-gfx] " John Harrison
2021-10-07 3:49 ` John Harrison
2021-10-04 22:06 ` [Intel-gfx] [PATCH 05/26] drm/i915: Add logical engine mapping Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-07 19:03 ` [Intel-gfx] " John Harrison
2021-10-07 19:03 ` John Harrison
2021-10-04 22:06 ` [Intel-gfx] [PATCH 06/26] drm/i915: Expose logical engine instance to user Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-04 22:06 ` [Intel-gfx] [PATCH 07/26] drm/i915/guc: Introduce context parent-child relationship Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-07 19:35 ` [Intel-gfx] " John Harrison
2021-10-07 19:35 ` John Harrison
2021-10-08 18:33 ` Matthew Brost [this message]
2021-10-08 18:33 ` Matthew Brost
2021-10-04 22:06 ` [Intel-gfx] [PATCH 08/26] drm/i915/guc: Add multi-lrc context registration Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-07 19:50 ` [Intel-gfx] " John Harrison
2021-10-07 19:50 ` John Harrison
2021-10-08 1:31 ` [Intel-gfx] " Matthew Brost
2021-10-08 1:31 ` Matthew Brost
2021-10-08 17:20 ` [Intel-gfx] " John Harrison
2021-10-08 17:29 ` Matthew Brost
2021-10-04 22:06 ` [Intel-gfx] [PATCH 09/26] drm/i915/guc: Ensure GuC schedule operations do not operate on child contexts Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-07 20:23 ` [Intel-gfx] " John Harrison
2021-10-07 20:23 ` John Harrison
2021-10-04 22:06 ` [Intel-gfx] [PATCH 10/26] drm/i915/guc: Assign contexts in parent-child relationship consecutive guc_ids Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-07 22:03 ` [Intel-gfx] " John Harrison
2021-10-07 22:03 ` John Harrison
2021-10-08 1:21 ` [Intel-gfx] " Matthew Brost
2021-10-08 1:21 ` Matthew Brost
2021-10-08 16:40 ` [Intel-gfx] " John Harrison
2021-10-08 16:40 ` John Harrison
2021-10-13 18:03 ` [Intel-gfx] " Matthew Brost
2021-10-13 18:03 ` Matthew Brost
2021-10-13 19:11 ` [Intel-gfx] " John Harrison
2021-10-13 19:11 ` John Harrison
2021-10-04 22:06 ` [Intel-gfx] [PATCH 11/26] drm/i915/guc: Implement parallel context pin / unpin functions Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-04 22:06 ` [Intel-gfx] [PATCH 12/26] drm/i915/guc: Implement multi-lrc submission Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-05 7:55 ` [Intel-gfx] " kernel test robot
2021-10-05 7:55 ` kernel test robot
2021-10-05 10:37 ` kernel test robot
2021-10-05 10:37 ` kernel test robot
2021-10-08 17:20 ` John Harrison
2021-10-08 17:20 ` John Harrison
2021-10-13 18:24 ` [Intel-gfx] " Matthew Brost
2021-10-13 18:24 ` Matthew Brost
2021-10-04 22:06 ` [Intel-gfx] [PATCH 13/26] drm/i915/guc: Insert submit fences between requests in parent-child relationship Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-04 22:06 ` [Intel-gfx] [PATCH 14/26] drm/i915/guc: Implement multi-lrc reset Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-08 17:39 ` [Intel-gfx] " John Harrison
2021-10-08 17:39 ` John Harrison
2021-10-08 17:56 ` [Intel-gfx] " Matthew Brost
2021-10-08 17:56 ` Matthew Brost
2021-10-04 22:06 ` [Intel-gfx] [PATCH 15/26] drm/i915/guc: Update debugfs for GuC multi-lrc Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-08 17:46 ` [Intel-gfx] " John Harrison
2021-10-08 17:46 ` John Harrison
2021-10-04 22:06 ` [Intel-gfx] [PATCH 16/26] drm/i915: Fix bug in user proto-context creation that leaked contexts Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-08 17:49 ` [Intel-gfx] " John Harrison
2021-10-08 17:49 ` John Harrison
2021-10-04 22:06 ` [Intel-gfx] [PATCH 17/26] drm/i915/guc: Connect UAPI to GuC multi-lrc interface Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-11 22:09 ` [Intel-gfx] " John Harrison
2021-10-11 22:09 ` John Harrison
2021-10-11 22:59 ` [Intel-gfx] " Matthew Brost
2021-10-11 22:59 ` Matthew Brost
2021-10-04 22:06 ` [Intel-gfx] [PATCH 18/26] drm/i915/doc: Update parallel submit doc to point to i915_drm.h Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-04 22:06 ` [Intel-gfx] [PATCH 19/26] drm/i915/guc: Add basic GuC multi-lrc selftest Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-04 22:06 ` [Intel-gfx] [PATCH 20/26] drm/i915/guc: Implement no mid batch preemption for multi-lrc Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-11 23:32 ` [Intel-gfx] " John Harrison
2021-10-11 23:32 ` John Harrison
2021-10-13 1:52 ` [Intel-gfx] " Matthew Brost
2021-10-13 1:52 ` Matthew Brost
2021-10-04 22:06 ` [Intel-gfx] [PATCH 21/26] drm/i915: Multi-BB execbuf Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-05 8:31 ` [Intel-gfx] " kernel test robot
2021-10-05 8:31 ` kernel test robot
2021-10-05 17:02 ` Matthew Brost
2021-10-06 20:46 ` Matthew Brost
2021-10-12 21:22 ` John Harrison
2021-10-12 21:22 ` John Harrison
2021-10-13 0:37 ` [Intel-gfx] " Matthew Brost
2021-10-13 0:37 ` Matthew Brost
2021-10-04 22:06 ` [Intel-gfx] [PATCH 22/26] drm/i915/guc: Handle errors in multi-lrc requests Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-12 21:56 ` [Intel-gfx] " John Harrison
2021-10-12 21:56 ` John Harrison
2021-10-13 0:18 ` [Intel-gfx] " Matthew Brost
2021-10-13 0:18 ` Matthew Brost
2021-10-04 22:06 ` [Intel-gfx] [PATCH 23/26] drm/i915: Make request conflict tracking understand parallel submits Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-12 22:08 ` [Intel-gfx] " John Harrison
2021-10-12 22:08 ` John Harrison
2021-10-13 0:32 ` [Intel-gfx] " Matthew Brost
2021-10-13 0:32 ` Matthew Brost
2021-10-13 19:35 ` [Intel-gfx] " John Harrison
2021-10-13 19:35 ` John Harrison
2021-10-13 17:51 ` [Intel-gfx] " Matthew Brost
2021-10-13 17:51 ` Matthew Brost
2021-10-13 19:25 ` [Intel-gfx] " John Harrison
2021-10-13 19:25 ` John Harrison
2021-10-04 22:06 ` [Intel-gfx] [PATCH 24/26] drm/i915: Update I915_GEM_BUSY IOCTL to understand composite fences Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-11 22:15 ` [Intel-gfx] " Daniele Ceraolo Spurio
2021-10-11 22:15 ` Daniele Ceraolo Spurio
2021-10-12 7:53 ` [Intel-gfx] " Tvrtko Ursulin
2021-10-12 18:31 ` Matthew Brost
2021-10-04 22:06 ` [Intel-gfx] [PATCH 25/26] drm/i915: Enable multi-bb execbuf Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-04 22:06 ` [Intel-gfx] [PATCH 26/26] drm/i915/execlists: Weak parallel submission support for execlists Matthew Brost
2021-10-04 22:06 ` Matthew Brost
2021-10-04 22:21 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Parallel submission aka multi-bb execbuf (rev4) Patchwork
2021-10-12 22:15 ` John Harrison
2021-10-13 0:15 ` Matthew Brost
2021-10-13 19:24 ` John Harrison
2021-10-04 22:23 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-10-04 22:26 ` [Intel-gfx] ✗ Fi.CI.DOCS: " Patchwork
2021-10-12 22:15 ` John Harrison
2021-10-13 0:12 ` Matthew Brost
2021-10-04 22:54 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2021-10-05 1:49 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Parallel submission aka multi-bb execbuf (rev5) Patchwork
2021-10-05 1:51 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-10-05 1:54 ` [Intel-gfx] ✗ Fi.CI.DOCS: " Patchwork
2021-10-05 2:21 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2021-10-12 18:11 ` [Intel-gfx] [PATCH 02/26] drm/i915/guc: Take GT PM ref when deregistering context Matthew Brost
2021-10-12 18:11 ` Matthew Brost
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211008183330.GA2672@jons-linux-dev-box \
--to=matthew.brost@intel.com \
--cc=daniele.ceraolospurio@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=john.c.harrison@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.