All of lore.kernel.org
 help / color / mirror / Atom feed
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 10/26] drm/i915/guc: Assign contexts in parent-child relationship consecutive guc_ids
Date: Wed, 13 Oct 2021 11:03:31 -0700	[thread overview]
Message-ID: <20211013180331.GA13066@jons-linux-dev-box> (raw)
In-Reply-To: <e58f0cb8-0261-1e8d-5b56-5dd69bf070e3@intel.com>

On Fri, Oct 08, 2021 at 09:40:43AM -0700, John Harrison wrote:
> On 10/7/2021 18:21, Matthew Brost wrote:
> > On Thu, Oct 07, 2021 at 03:03:04PM -0700, John Harrison wrote:
> > > On 10/4/2021 15:06, Matthew Brost wrote:
> > > > Assign contexts in parent-child relationship consecutive guc_ids. This
> > > > is accomplished by partitioning guc_id space between ones that need to
> > > > be consecutive (1/16 available guc_ids) and ones that do not (15/16 of
> > > > available guc_ids). The consecutive search is implemented via the bitmap
> > > > API.
> > > > 
> > > > This is a precursor to the full GuC multi-lrc implementation but aligns
> > > > to how GuC mutli-lrc interface is defined - guc_ids must be consecutive
> > > > when using the GuC multi-lrc interface.
> > > > 
> > > > v2:
> > > >    (Daniel Vetter)
> > > >     - Explicitly state why we assign consecutive guc_ids
> > > > v3:
> > > >    (John Harrison)
> > > >     - Bring back in spin lock
> > > > 
> > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > > > ---
> > > >    drivers/gpu/drm/i915/gt/uc/intel_guc.h        |   6 +-
> > > >    .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 104 ++++++++++++++----
> > > >    2 files changed, 86 insertions(+), 24 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > index 25a598e2b6e8..a9f4ec972bfb 100644
> > > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > @@ -76,9 +76,13 @@ struct intel_guc {
> > > >    		 */
> > > >    		spinlock_t lock;
> > > >    		/**
> > > > -		 * @guc_ids: used to allocate new guc_ids
> > > > +		 * @guc_ids: used to allocate new guc_ids, single-lrc
> > > >    		 */
> > > >    		struct ida guc_ids;
> > > > +		/**
> > > > +		 * @guc_ids_bitmap: used to allocate new guc_ids, multi-lrc
> > > > +		 */
> > > > +		unsigned long *guc_ids_bitmap;
> > > >    		/**
> > > >    		 * @guc_id_list: list of intel_context with valid guc_ids but no
> > > >    		 * refs
> > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > index 1f2809187513..79e7732e83b2 100644
> > > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > @@ -128,6 +128,16 @@ guc_create_virtual(struct intel_engine_cs **siblings, unsigned int count);
> > > >    #define GUC_REQUEST_SIZE 64 /* bytes */
> > > > +/*
> > > > + * We reserve 1/16 of the guc_ids for multi-lrc as these need to be contiguous
> > > > + * per the GuC submission interface. A different allocation algorithm is used
> > > > + * (bitmap vs. ida) between multi-lrc and single-lrc hence the reason to
> > > > + * partition the guc_id space. We believe the number of multi-lrc contexts in
> > > > + * use should be low and 1/16 should be sufficient. Minimum of 32 guc_ids for
> > > > + * multi-lrc.
> > > > + */
> > > > +#define NUMBER_MULTI_LRC_GUC_ID		(GUC_MAX_LRC_DESCRIPTORS / 16)
> > > > +
> > > >    /*
> > > >     * Below is a set of functions which control the GuC scheduling state which
> > > >     * require a lock.
> > > > @@ -1206,6 +1216,11 @@ int intel_guc_submission_init(struct intel_guc *guc)
> > > >    	INIT_WORK(&guc->submission_state.destroyed_worker,
> > > >    		  destroyed_worker_func);
> > > > +	guc->submission_state.guc_ids_bitmap =
> > > > +		bitmap_zalloc(NUMBER_MULTI_LRC_GUC_ID, GFP_KERNEL);
> > > > +	if (!guc->submission_state.guc_ids_bitmap)
> > > > +		return -ENOMEM;
> > > > +
> > > >    	return 0;
> > > >    }
> > > > @@ -1217,6 +1232,7 @@ void intel_guc_submission_fini(struct intel_guc *guc)
> > > >    	guc_lrc_desc_pool_destroy(guc);
> > > >    	guc_flush_destroyed_contexts(guc);
> > > >    	i915_sched_engine_put(guc->sched_engine);
> > > > +	bitmap_free(guc->submission_state.guc_ids_bitmap);
> > > >    }
> > > >    static inline void queue_request(struct i915_sched_engine *sched_engine,
> > > > @@ -1268,18 +1284,43 @@ static void guc_submit_request(struct i915_request *rq)
> > > >    	spin_unlock_irqrestore(&sched_engine->lock, flags);
> > > >    }
> > > > -static int new_guc_id(struct intel_guc *guc)
> > > > +static int new_guc_id(struct intel_guc *guc, struct intel_context *ce)
> > > >    {
> > > > -	return ida_simple_get(&guc->submission_state.guc_ids, 0,
> > > > -			      GUC_MAX_LRC_DESCRIPTORS, GFP_KERNEL |
> > > > -			      __GFP_RETRY_MAYFAIL | __GFP_NOWARN);
> > > > +	int ret;
> > > > +
> > > > +	GEM_BUG_ON(intel_context_is_child(ce));
> > > > +
> > > > +	if (intel_context_is_parent(ce))
> > > > +		ret = bitmap_find_free_region(guc->submission_state.guc_ids_bitmap,
> > > > +					      NUMBER_MULTI_LRC_GUC_ID,
> > > > +					      order_base_2(ce->parallel.number_children
> > > > +							   + 1));
> > > > +	else
> > > > +		ret = ida_simple_get(&guc->submission_state.guc_ids,
> > > > +				     NUMBER_MULTI_LRC_GUC_ID,
> > > > +				     GUC_MAX_LRC_DESCRIPTORS,
> > > > +				     GFP_KERNEL | __GFP_RETRY_MAYFAIL |
> > > > +				     __GFP_NOWARN);
> > > > +	if (unlikely(ret < 0))
> > > > +		return ret;
> > > > +
> > > > +	ce->guc_id.id = ret;
> > > > +	return 0;
> > > >    }
> > > >    static void __release_guc_id(struct intel_guc *guc, struct intel_context *ce)
> > > >    {
> > > > +	GEM_BUG_ON(intel_context_is_child(ce));
> > > > +
> > > >    	if (!context_guc_id_invalid(ce)) {
> > > > -		ida_simple_remove(&guc->submission_state.guc_ids,
> > > > -				  ce->guc_id.id);
> > > > +		if (intel_context_is_parent(ce))
> > > > +			bitmap_release_region(guc->submission_state.guc_ids_bitmap,
> > > > +					      ce->guc_id.id,
> > > > +					      order_base_2(ce->parallel.number_children
> > > > +							   + 1));
> > > There was a discussion on the previous revision about adding a BUG_ON to
> > > ensure that number_children cannot change between the bitmap alloc and the
> > > bitmap release. I'm not seeing the new BUG_ON mentioned in this patch.
> > > 
> > I thought you meant to add a BUG_ON to ensure before we release a region
> > / id it is occupied? I looked in both the bitmap API and ida API and
> > neither have a function that checks if region / id is occupied so can't
> > really add a BUG_ON for that.
> > 
> > How much you add BUG_ON to ensure the number of children canoot change
> > between alloc and release? I don't follow how that would work.
> > 
> > Matt
> I was thinking that where number_children is modified, you have a
> BUG_ON(guc_id_is_valid). That would ensure that the release has to match the
> alloc. Hmm, you already have a BUG_ON about the parent/child not being
> pinned in intel_context_bind_parent_child(), which I guess covers it because
> you shouldn't have a guc_id if you aren't pinned, right? And that is the
> only function which can modify number_children, yes? So maybe it's all good?
> 

I think we are all good.

Matt

> John.
> 
> > 
> > > John.
> > > 
> > > 
> > > > +		else
> > > > +			ida_simple_remove(&guc->submission_state.guc_ids,
> > > > +					  ce->guc_id.id);
> > > >    		reset_lrc_desc(guc, ce->guc_id.id);
> > > >    		set_context_guc_id_invalid(ce);
> > > >    	}
> > > > @@ -1296,49 +1337,64 @@ static void release_guc_id(struct intel_guc *guc, struct intel_context *ce)
> > > >    	spin_unlock_irqrestore(&guc->submission_state.lock, flags);
> > > >    }
> > > > -static int steal_guc_id(struct intel_guc *guc)
> > > > +static int steal_guc_id(struct intel_guc *guc, struct intel_context *ce)
> > > >    {
> > > > -	struct intel_context *ce;
> > > > -	int guc_id;
> > > > +	struct intel_context *cn;
> > > >    	lockdep_assert_held(&guc->submission_state.lock);
> > > > +	GEM_BUG_ON(intel_context_is_child(ce));
> > > > +	GEM_BUG_ON(intel_context_is_parent(ce));
> > > >    	if (!list_empty(&guc->submission_state.guc_id_list)) {
> > > > -		ce = list_first_entry(&guc->submission_state.guc_id_list,
> > > > +		cn = list_first_entry(&guc->submission_state.guc_id_list,
> > > >    				      struct intel_context,
> > > >    				      guc_id.link);
> > > > -		GEM_BUG_ON(atomic_read(&ce->guc_id.ref));
> > > > -		GEM_BUG_ON(context_guc_id_invalid(ce));
> > > > +		GEM_BUG_ON(atomic_read(&cn->guc_id.ref));
> > > > +		GEM_BUG_ON(context_guc_id_invalid(cn));
> > > > +		GEM_BUG_ON(intel_context_is_child(cn));
> > > > +		GEM_BUG_ON(intel_context_is_parent(cn));
> > > > -		list_del_init(&ce->guc_id.link);
> > > > -		guc_id = ce->guc_id.id;
> > > > +		list_del_init(&cn->guc_id.link);
> > > > +		ce->guc_id = cn->guc_id;
> > > >    		spin_lock(&ce->guc_state.lock);
> > > > -		clr_context_registered(ce);
> > > > +		clr_context_registered(cn);
> > > >    		spin_unlock(&ce->guc_state.lock);
> > > > -		set_context_guc_id_invalid(ce);
> > > > -		return guc_id;
> > > > +		set_context_guc_id_invalid(cn);
> > > > +
> > > > +		return 0;
> > > >    	} else {
> > > >    		return -EAGAIN;
> > > >    	}
> > > >    }
> > > > -static int assign_guc_id(struct intel_guc *guc, u16 *out)
> > > > +static int assign_guc_id(struct intel_guc *guc, struct intel_context *ce)
> > > >    {
> > > >    	int ret;
> > > >    	lockdep_assert_held(&guc->submission_state.lock);
> > > > +	GEM_BUG_ON(intel_context_is_child(ce));
> > > > -	ret = new_guc_id(guc);
> > > > +	ret = new_guc_id(guc, ce);
> > > >    	if (unlikely(ret < 0)) {
> > > > -		ret = steal_guc_id(guc);
> > > > +		if (intel_context_is_parent(ce))
> > > > +			return -ENOSPC;
> > > > +
> > > > +		ret = steal_guc_id(guc, ce);
> > > >    		if (ret < 0)
> > > >    			return ret;
> > > >    	}
> > > > -	*out = ret;
> > > > +	if (intel_context_is_parent(ce)) {
> > > > +		struct intel_context *child;
> > > > +		int i = 1;
> > > > +
> > > > +		for_each_child(ce, child)
> > > > +			child->guc_id.id = ce->guc_id.id + i++;
> > > > +	}
> > > > +
> > > >    	return 0;
> > > >    }
> > > > @@ -1356,7 +1412,7 @@ static int pin_guc_id(struct intel_guc *guc, struct intel_context *ce)
> > > >    	might_lock(&ce->guc_state.lock);
> > > >    	if (context_guc_id_invalid(ce)) {
> > > > -		ret = assign_guc_id(guc, &ce->guc_id.id);
> > > > +		ret = assign_guc_id(guc, ce);
> > > >    		if (ret)
> > > >    			goto out_unlock;
> > > >    		ret = 1;	/* Indidcates newly assigned guc_id */
> > > > @@ -1398,8 +1454,10 @@ static void unpin_guc_id(struct intel_guc *guc, struct intel_context *ce)
> > > >    	unsigned long flags;
> > > >    	GEM_BUG_ON(atomic_read(&ce->guc_id.ref) < 0);
> > > > +	GEM_BUG_ON(intel_context_is_child(ce));
> > > > -	if (unlikely(context_guc_id_invalid(ce)))
> > > > +	if (unlikely(context_guc_id_invalid(ce) ||
> > > > +		     intel_context_is_parent(ce)))
> > > >    		return;
> > > >    	spin_lock_irqsave(&guc->submission_state.lock, flags);
> 

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: [Intel-gfx] [PATCH 10/26] drm/i915/guc: Assign contexts in parent-child relationship consecutive guc_ids
Date: Wed, 13 Oct 2021 11:03:31 -0700	[thread overview]
Message-ID: <20211013180331.GA13066@jons-linux-dev-box> (raw)
In-Reply-To: <e58f0cb8-0261-1e8d-5b56-5dd69bf070e3@intel.com>

On Fri, Oct 08, 2021 at 09:40:43AM -0700, John Harrison wrote:
> On 10/7/2021 18:21, Matthew Brost wrote:
> > On Thu, Oct 07, 2021 at 03:03:04PM -0700, John Harrison wrote:
> > > On 10/4/2021 15:06, Matthew Brost wrote:
> > > > Assign contexts in parent-child relationship consecutive guc_ids. This
> > > > is accomplished by partitioning guc_id space between ones that need to
> > > > be consecutive (1/16 available guc_ids) and ones that do not (15/16 of
> > > > available guc_ids). The consecutive search is implemented via the bitmap
> > > > API.
> > > > 
> > > > This is a precursor to the full GuC multi-lrc implementation but aligns
> > > > to how GuC mutli-lrc interface is defined - guc_ids must be consecutive
> > > > when using the GuC multi-lrc interface.
> > > > 
> > > > v2:
> > > >    (Daniel Vetter)
> > > >     - Explicitly state why we assign consecutive guc_ids
> > > > v3:
> > > >    (John Harrison)
> > > >     - Bring back in spin lock
> > > > 
> > > > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > > > ---
> > > >    drivers/gpu/drm/i915/gt/uc/intel_guc.h        |   6 +-
> > > >    .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 104 ++++++++++++++----
> > > >    2 files changed, 86 insertions(+), 24 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > index 25a598e2b6e8..a9f4ec972bfb 100644
> > > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > > > @@ -76,9 +76,13 @@ struct intel_guc {
> > > >    		 */
> > > >    		spinlock_t lock;
> > > >    		/**
> > > > -		 * @guc_ids: used to allocate new guc_ids
> > > > +		 * @guc_ids: used to allocate new guc_ids, single-lrc
> > > >    		 */
> > > >    		struct ida guc_ids;
> > > > +		/**
> > > > +		 * @guc_ids_bitmap: used to allocate new guc_ids, multi-lrc
> > > > +		 */
> > > > +		unsigned long *guc_ids_bitmap;
> > > >    		/**
> > > >    		 * @guc_id_list: list of intel_context with valid guc_ids but no
> > > >    		 * refs
> > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > index 1f2809187513..79e7732e83b2 100644
> > > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > > @@ -128,6 +128,16 @@ guc_create_virtual(struct intel_engine_cs **siblings, unsigned int count);
> > > >    #define GUC_REQUEST_SIZE 64 /* bytes */
> > > > +/*
> > > > + * We reserve 1/16 of the guc_ids for multi-lrc as these need to be contiguous
> > > > + * per the GuC submission interface. A different allocation algorithm is used
> > > > + * (bitmap vs. ida) between multi-lrc and single-lrc hence the reason to
> > > > + * partition the guc_id space. We believe the number of multi-lrc contexts in
> > > > + * use should be low and 1/16 should be sufficient. Minimum of 32 guc_ids for
> > > > + * multi-lrc.
> > > > + */
> > > > +#define NUMBER_MULTI_LRC_GUC_ID		(GUC_MAX_LRC_DESCRIPTORS / 16)
> > > > +
> > > >    /*
> > > >     * Below is a set of functions which control the GuC scheduling state which
> > > >     * require a lock.
> > > > @@ -1206,6 +1216,11 @@ int intel_guc_submission_init(struct intel_guc *guc)
> > > >    	INIT_WORK(&guc->submission_state.destroyed_worker,
> > > >    		  destroyed_worker_func);
> > > > +	guc->submission_state.guc_ids_bitmap =
> > > > +		bitmap_zalloc(NUMBER_MULTI_LRC_GUC_ID, GFP_KERNEL);
> > > > +	if (!guc->submission_state.guc_ids_bitmap)
> > > > +		return -ENOMEM;
> > > > +
> > > >    	return 0;
> > > >    }
> > > > @@ -1217,6 +1232,7 @@ void intel_guc_submission_fini(struct intel_guc *guc)
> > > >    	guc_lrc_desc_pool_destroy(guc);
> > > >    	guc_flush_destroyed_contexts(guc);
> > > >    	i915_sched_engine_put(guc->sched_engine);
> > > > +	bitmap_free(guc->submission_state.guc_ids_bitmap);
> > > >    }
> > > >    static inline void queue_request(struct i915_sched_engine *sched_engine,
> > > > @@ -1268,18 +1284,43 @@ static void guc_submit_request(struct i915_request *rq)
> > > >    	spin_unlock_irqrestore(&sched_engine->lock, flags);
> > > >    }
> > > > -static int new_guc_id(struct intel_guc *guc)
> > > > +static int new_guc_id(struct intel_guc *guc, struct intel_context *ce)
> > > >    {
> > > > -	return ida_simple_get(&guc->submission_state.guc_ids, 0,
> > > > -			      GUC_MAX_LRC_DESCRIPTORS, GFP_KERNEL |
> > > > -			      __GFP_RETRY_MAYFAIL | __GFP_NOWARN);
> > > > +	int ret;
> > > > +
> > > > +	GEM_BUG_ON(intel_context_is_child(ce));
> > > > +
> > > > +	if (intel_context_is_parent(ce))
> > > > +		ret = bitmap_find_free_region(guc->submission_state.guc_ids_bitmap,
> > > > +					      NUMBER_MULTI_LRC_GUC_ID,
> > > > +					      order_base_2(ce->parallel.number_children
> > > > +							   + 1));
> > > > +	else
> > > > +		ret = ida_simple_get(&guc->submission_state.guc_ids,
> > > > +				     NUMBER_MULTI_LRC_GUC_ID,
> > > > +				     GUC_MAX_LRC_DESCRIPTORS,
> > > > +				     GFP_KERNEL | __GFP_RETRY_MAYFAIL |
> > > > +				     __GFP_NOWARN);
> > > > +	if (unlikely(ret < 0))
> > > > +		return ret;
> > > > +
> > > > +	ce->guc_id.id = ret;
> > > > +	return 0;
> > > >    }
> > > >    static void __release_guc_id(struct intel_guc *guc, struct intel_context *ce)
> > > >    {
> > > > +	GEM_BUG_ON(intel_context_is_child(ce));
> > > > +
> > > >    	if (!context_guc_id_invalid(ce)) {
> > > > -		ida_simple_remove(&guc->submission_state.guc_ids,
> > > > -				  ce->guc_id.id);
> > > > +		if (intel_context_is_parent(ce))
> > > > +			bitmap_release_region(guc->submission_state.guc_ids_bitmap,
> > > > +					      ce->guc_id.id,
> > > > +					      order_base_2(ce->parallel.number_children
> > > > +							   + 1));
> > > There was a discussion on the previous revision about adding a BUG_ON to
> > > ensure that number_children cannot change between the bitmap alloc and the
> > > bitmap release. I'm not seeing the new BUG_ON mentioned in this patch.
> > > 
> > I thought you meant to add a BUG_ON to ensure before we release a region
> > / id it is occupied? I looked in both the bitmap API and ida API and
> > neither have a function that checks if region / id is occupied so can't
> > really add a BUG_ON for that.
> > 
> > How much you add BUG_ON to ensure the number of children canoot change
> > between alloc and release? I don't follow how that would work.
> > 
> > Matt
> I was thinking that where number_children is modified, you have a
> BUG_ON(guc_id_is_valid). That would ensure that the release has to match the
> alloc. Hmm, you already have a BUG_ON about the parent/child not being
> pinned in intel_context_bind_parent_child(), which I guess covers it because
> you shouldn't have a guc_id if you aren't pinned, right? And that is the
> only function which can modify number_children, yes? So maybe it's all good?
> 

I think we are all good.

Matt

> John.
> 
> > 
> > > John.
> > > 
> > > 
> > > > +		else
> > > > +			ida_simple_remove(&guc->submission_state.guc_ids,
> > > > +					  ce->guc_id.id);
> > > >    		reset_lrc_desc(guc, ce->guc_id.id);
> > > >    		set_context_guc_id_invalid(ce);
> > > >    	}
> > > > @@ -1296,49 +1337,64 @@ static void release_guc_id(struct intel_guc *guc, struct intel_context *ce)
> > > >    	spin_unlock_irqrestore(&guc->submission_state.lock, flags);
> > > >    }
> > > > -static int steal_guc_id(struct intel_guc *guc)
> > > > +static int steal_guc_id(struct intel_guc *guc, struct intel_context *ce)
> > > >    {
> > > > -	struct intel_context *ce;
> > > > -	int guc_id;
> > > > +	struct intel_context *cn;
> > > >    	lockdep_assert_held(&guc->submission_state.lock);
> > > > +	GEM_BUG_ON(intel_context_is_child(ce));
> > > > +	GEM_BUG_ON(intel_context_is_parent(ce));
> > > >    	if (!list_empty(&guc->submission_state.guc_id_list)) {
> > > > -		ce = list_first_entry(&guc->submission_state.guc_id_list,
> > > > +		cn = list_first_entry(&guc->submission_state.guc_id_list,
> > > >    				      struct intel_context,
> > > >    				      guc_id.link);
> > > > -		GEM_BUG_ON(atomic_read(&ce->guc_id.ref));
> > > > -		GEM_BUG_ON(context_guc_id_invalid(ce));
> > > > +		GEM_BUG_ON(atomic_read(&cn->guc_id.ref));
> > > > +		GEM_BUG_ON(context_guc_id_invalid(cn));
> > > > +		GEM_BUG_ON(intel_context_is_child(cn));
> > > > +		GEM_BUG_ON(intel_context_is_parent(cn));
> > > > -		list_del_init(&ce->guc_id.link);
> > > > -		guc_id = ce->guc_id.id;
> > > > +		list_del_init(&cn->guc_id.link);
> > > > +		ce->guc_id = cn->guc_id;
> > > >    		spin_lock(&ce->guc_state.lock);
> > > > -		clr_context_registered(ce);
> > > > +		clr_context_registered(cn);
> > > >    		spin_unlock(&ce->guc_state.lock);
> > > > -		set_context_guc_id_invalid(ce);
> > > > -		return guc_id;
> > > > +		set_context_guc_id_invalid(cn);
> > > > +
> > > > +		return 0;
> > > >    	} else {
> > > >    		return -EAGAIN;
> > > >    	}
> > > >    }
> > > > -static int assign_guc_id(struct intel_guc *guc, u16 *out)
> > > > +static int assign_guc_id(struct intel_guc *guc, struct intel_context *ce)
> > > >    {
> > > >    	int ret;
> > > >    	lockdep_assert_held(&guc->submission_state.lock);
> > > > +	GEM_BUG_ON(intel_context_is_child(ce));
> > > > -	ret = new_guc_id(guc);
> > > > +	ret = new_guc_id(guc, ce);
> > > >    	if (unlikely(ret < 0)) {
> > > > -		ret = steal_guc_id(guc);
> > > > +		if (intel_context_is_parent(ce))
> > > > +			return -ENOSPC;
> > > > +
> > > > +		ret = steal_guc_id(guc, ce);
> > > >    		if (ret < 0)
> > > >    			return ret;
> > > >    	}
> > > > -	*out = ret;
> > > > +	if (intel_context_is_parent(ce)) {
> > > > +		struct intel_context *child;
> > > > +		int i = 1;
> > > > +
> > > > +		for_each_child(ce, child)
> > > > +			child->guc_id.id = ce->guc_id.id + i++;
> > > > +	}
> > > > +
> > > >    	return 0;
> > > >    }
> > > > @@ -1356,7 +1412,7 @@ static int pin_guc_id(struct intel_guc *guc, struct intel_context *ce)
> > > >    	might_lock(&ce->guc_state.lock);
> > > >    	if (context_guc_id_invalid(ce)) {
> > > > -		ret = assign_guc_id(guc, &ce->guc_id.id);
> > > > +		ret = assign_guc_id(guc, ce);
> > > >    		if (ret)
> > > >    			goto out_unlock;
> > > >    		ret = 1;	/* Indidcates newly assigned guc_id */
> > > > @@ -1398,8 +1454,10 @@ static void unpin_guc_id(struct intel_guc *guc, struct intel_context *ce)
> > > >    	unsigned long flags;
> > > >    	GEM_BUG_ON(atomic_read(&ce->guc_id.ref) < 0);
> > > > +	GEM_BUG_ON(intel_context_is_child(ce));
> > > > -	if (unlikely(context_guc_id_invalid(ce)))
> > > > +	if (unlikely(context_guc_id_invalid(ce) ||
> > > > +		     intel_context_is_parent(ce)))
> > > >    		return;
> > > >    	spin_lock_irqsave(&guc->submission_state.lock, flags);
> 

  reply	other threads:[~2021-10-13 18:08 UTC|newest]

Thread overview: 165+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-04 22:06 [PATCH 00/26] Parallel submission aka multi-bb execbuf Matthew Brost
2021-10-04 22:06 ` [Intel-gfx] " Matthew Brost
2021-10-04 22:06 ` [PATCH 01/26] drm/i915/guc: Move GuC guc_id allocation under submission state sub-struct Matthew Brost
2021-10-04 22:06   ` [Intel-gfx] " Matthew Brost
2021-10-07  3:06   ` John Harrison
2021-10-07  3:06     ` [Intel-gfx] " John Harrison
2021-10-07 15:05     ` Matthew Brost
2021-10-07 15:05       ` [Intel-gfx] " Matthew Brost
2021-10-07 18:13       ` John Harrison
2021-10-07 18:13         ` [Intel-gfx] " John Harrison
2021-10-04 22:06 ` [PATCH 02/26] drm/i915/guc: Take GT PM ref when deregistering context Matthew Brost
2021-10-04 22:06   ` [Intel-gfx] " Matthew Brost
2021-10-07  3:37   ` John Harrison
2021-10-07  3:37     ` [Intel-gfx] " John Harrison
2021-10-08  1:28     ` Matthew Brost
2021-10-08  1:28       ` [Intel-gfx] " Matthew Brost
2021-10-08 18:23     ` Matthew Brost
2021-10-08 18:23       ` [Intel-gfx] " 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   ` John Harrison
2021-10-07  3:45     ` [Intel-gfx] " John Harrison
2021-10-07 15:19     ` Matthew Brost
2021-10-07 15:19       ` [Intel-gfx] " Matthew Brost
2021-10-07 18:15       ` John Harrison
2021-10-07 18:15         ` [Intel-gfx] " John Harrison
2021-10-08  1:23         ` Matthew Brost
2021-10-08  1:23           ` [Intel-gfx] " Matthew Brost
2021-10-04 22:06 ` [PATCH 04/26] drm/i915/guc: Don't call switch_to_kernel_context " Matthew Brost
2021-10-04 22:06   ` [Intel-gfx] " Matthew Brost
2021-10-07  3:49   ` John Harrison
2021-10-07  3:49     ` [Intel-gfx] " 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   ` John Harrison
2021-10-07 19:03     ` [Intel-gfx] " John Harrison
2021-10-04 22:06 ` [PATCH 06/26] drm/i915: Expose logical engine instance to user Matthew Brost
2021-10-04 22:06   ` [Intel-gfx] " Matthew Brost
2021-10-04 22:06 ` [PATCH 07/26] drm/i915/guc: Introduce context parent-child relationship Matthew Brost
2021-10-04 22:06   ` [Intel-gfx] " Matthew Brost
2021-10-07 19:35   ` John Harrison
2021-10-07 19:35     ` [Intel-gfx] " John Harrison
2021-10-08 18:33     ` Matthew Brost
2021-10-08 18:33       ` [Intel-gfx] " Matthew Brost
2021-10-04 22:06 ` [PATCH 08/26] drm/i915/guc: Add multi-lrc context registration Matthew Brost
2021-10-04 22:06   ` [Intel-gfx] " Matthew Brost
2021-10-07 19:50   ` John Harrison
2021-10-07 19:50     ` [Intel-gfx] " John Harrison
2021-10-08  1:31     ` Matthew Brost
2021-10-08  1:31       ` [Intel-gfx] " Matthew Brost
2021-10-08 17:20     ` John Harrison
2021-10-08 17:29       ` Matthew Brost
2021-10-04 22:06 ` [PATCH 09/26] drm/i915/guc: Ensure GuC schedule operations do not operate on child contexts Matthew Brost
2021-10-04 22:06   ` [Intel-gfx] " Matthew Brost
2021-10-07 20:23   ` John Harrison
2021-10-07 20:23     ` [Intel-gfx] " John Harrison
2021-10-04 22:06 ` [PATCH 10/26] drm/i915/guc: Assign contexts in parent-child relationship consecutive guc_ids Matthew Brost
2021-10-04 22:06   ` [Intel-gfx] " Matthew Brost
2021-10-07 22:03   ` John Harrison
2021-10-07 22:03     ` [Intel-gfx] " John Harrison
2021-10-08  1:21     ` Matthew Brost
2021-10-08  1:21       ` [Intel-gfx] " Matthew Brost
2021-10-08 16:40       ` John Harrison
2021-10-08 16:40         ` [Intel-gfx] " John Harrison
2021-10-13 18:03         ` Matthew Brost [this message]
2021-10-13 18:03           ` Matthew Brost
2021-10-13 19:11           ` John Harrison
2021-10-13 19:11             ` [Intel-gfx] " 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     ` [Intel-gfx] " John Harrison
2021-10-13 18:24     ` Matthew Brost
2021-10-13 18:24       ` [Intel-gfx] " Matthew Brost
2021-10-04 22:06 ` [PATCH 13/26] drm/i915/guc: Insert submit fences between requests in parent-child relationship Matthew Brost
2021-10-04 22:06   ` [Intel-gfx] " Matthew Brost
2021-10-04 22:06 ` [PATCH 14/26] drm/i915/guc: Implement multi-lrc reset Matthew Brost
2021-10-04 22:06   ` [Intel-gfx] " Matthew Brost
2021-10-08 17:39   ` John Harrison
2021-10-08 17:39     ` [Intel-gfx] " John Harrison
2021-10-08 17:56     ` Matthew Brost
2021-10-08 17:56       ` [Intel-gfx] " Matthew Brost
2021-10-04 22:06 ` [PATCH 15/26] drm/i915/guc: Update debugfs for GuC multi-lrc Matthew Brost
2021-10-04 22:06   ` [Intel-gfx] " Matthew Brost
2021-10-08 17:46   ` John Harrison
2021-10-08 17:46     ` [Intel-gfx] " John Harrison
2021-10-04 22:06 ` [PATCH 16/26] drm/i915: Fix bug in user proto-context creation that leaked contexts Matthew Brost
2021-10-04 22:06   ` [Intel-gfx] " Matthew Brost
2021-10-08 17:49   ` John Harrison
2021-10-08 17:49     ` [Intel-gfx] " John Harrison
2021-10-04 22:06 ` [PATCH 17/26] drm/i915/guc: Connect UAPI to GuC multi-lrc interface Matthew Brost
2021-10-04 22:06   ` [Intel-gfx] " Matthew Brost
2021-10-11 22:09   ` John Harrison
2021-10-11 22:09     ` [Intel-gfx] " John Harrison
2021-10-11 22:59     ` Matthew Brost
2021-10-11 22:59       ` [Intel-gfx] " Matthew Brost
2021-10-04 22:06 ` [PATCH 18/26] drm/i915/doc: Update parallel submit doc to point to i915_drm.h Matthew Brost
2021-10-04 22:06   ` [Intel-gfx] " Matthew Brost
2021-10-04 22:06 ` [PATCH 19/26] drm/i915/guc: Add basic GuC multi-lrc selftest Matthew Brost
2021-10-04 22:06   ` [Intel-gfx] " Matthew Brost
2021-10-04 22:06 ` [PATCH 20/26] drm/i915/guc: Implement no mid batch preemption for multi-lrc Matthew Brost
2021-10-04 22:06   ` [Intel-gfx] " Matthew Brost
2021-10-11 23:32   ` John Harrison
2021-10-11 23:32     ` [Intel-gfx] " John Harrison
2021-10-13  1:52     ` Matthew Brost
2021-10-13  1:52       ` [Intel-gfx] " Matthew Brost
2021-10-04 22:06 ` [PATCH 21/26] drm/i915: Multi-BB execbuf Matthew Brost
2021-10-04 22:06   ` [Intel-gfx] " Matthew Brost
2021-10-05  8:31   ` 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     ` [Intel-gfx] " John Harrison
2021-10-13  0:37     ` Matthew Brost
2021-10-13  0:37       ` [Intel-gfx] " Matthew Brost
2021-10-04 22:06 ` [PATCH 22/26] drm/i915/guc: Handle errors in multi-lrc requests Matthew Brost
2021-10-04 22:06   ` [Intel-gfx] " Matthew Brost
2021-10-12 21:56   ` John Harrison
2021-10-12 21:56     ` [Intel-gfx] " John Harrison
2021-10-13  0:18     ` Matthew Brost
2021-10-13  0:18       ` [Intel-gfx] " Matthew Brost
2021-10-04 22:06 ` [PATCH 23/26] drm/i915: Make request conflict tracking understand parallel submits Matthew Brost
2021-10-04 22:06   ` [Intel-gfx] " Matthew Brost
2021-10-12 22:08   ` John Harrison
2021-10-12 22:08     ` [Intel-gfx] " John Harrison
2021-10-13  0:32     ` Matthew Brost
2021-10-13  0:32       ` [Intel-gfx] " Matthew Brost
2021-10-13 19:35       ` John Harrison
2021-10-13 19:35         ` [Intel-gfx] " John Harrison
2021-10-13 17:51     ` Matthew Brost
2021-10-13 17:51       ` [Intel-gfx] " Matthew Brost
2021-10-13 19:25       ` John Harrison
2021-10-13 19:25         ` [Intel-gfx] " John Harrison
2021-10-04 22:06 ` [PATCH 24/26] drm/i915: Update I915_GEM_BUSY IOCTL to understand composite fences Matthew Brost
2021-10-04 22:06   ` [Intel-gfx] " Matthew Brost
2021-10-11 22:15   ` Daniele Ceraolo Spurio
2021-10-11 22:15     ` [Intel-gfx] " Daniele Ceraolo Spurio
2021-10-12  7:53   ` Tvrtko Ursulin
2021-10-12 18:31     ` Matthew Brost
2021-10-04 22:06 ` [PATCH 25/26] drm/i915: Enable multi-bb execbuf Matthew Brost
2021-10-04 22:06   ` [Intel-gfx] " Matthew Brost
2021-10-04 22:06 ` [PATCH 26/26] drm/i915/execlists: Weak parallel submission support for execlists Matthew Brost
2021-10-04 22:06   ` [Intel-gfx] " 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 ` [PATCH 02/26] drm/i915/guc: Take GT PM ref when deregistering context Matthew Brost
2021-10-12 18:11   ` [Intel-gfx] " 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=20211013180331.GA13066@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.