All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Matthew Brost <matthew.brost@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	daniel.vetter@ffwll.ch, tony.ye@intel.com, zhengguo.xu@intel.com
Subject: Re: [Intel-gfx] [PATCH 05/27] drm/i915: Add GT PM unpark worker
Date: Mon, 13 Sep 2021 11:33:46 +0100	[thread overview]
Message-ID: <2b6daf2f-c20c-cc2d-c4fe-a705931fa82b@linux.intel.com> (raw)
In-Reply-To: <20210910200938.GA24255@jons-linux-dev-box>


On 10/09/2021 21:09, Matthew Brost wrote:
> On Fri, Sep 10, 2021 at 09:36:17AM +0100, Tvrtko Ursulin wrote:
>>
>> On 20/08/2021 23:44, Matthew Brost wrote:
>>> Sometimes it is desirable to queue work up for later if the GT PM isn't
>>> held and run that work on next GT PM unpark.
>>
>> Sounds maybe plausible, but it depends how much work can happen on unpark
>> and whether it can have too much of a negative impact on latency for
>> interactive loads? Or from a reverse angle, why the work wouldn't be done on
> 
> All it is does is add an interface to kick a work queue on unpark. i.e.
> All the actually work is done async in the work queue so it shouldn't
> add any latency.
> 
>> parking?
>>
>> Also what kind of mechanism for dealing with too much stuff being put on
>> this list you have? Can there be pressure which triggers (or would need to
> 
> No limits on pressure. See above, I don't think this is a concern.

On unpark it has the potential to send an unbound amount of actions for 
the GuC to process. Which will be competing, in GuC internal processing 
power, with the user action which caused the unpark. That logically does 
feel like can have effect on initial latency. Why you think it cannot?

Why the work wouldn't be done on parking?

With this scheme couldn't we end up with a situation that the worker 
keeps missing the GT unparked state and so keeps piling items on the 
deregistration list? Can you run of some ids like that (which is related 
to my question of how is pressure handled here).

Unpark
Register context
Submit work
Retire
Schedule context deregister
Park

Worker runs
GT parked
Work put on a list

Unpark
Schedule deregistration worker
Register new context
Submit work
Retire
Schedule contect deregister
Park

Worker runs (lets say there was CPU pressure)
GT already parked
  -> deregistration queue now has two contexts on it

... repeat until disaster ...

Unless I have misunderstood the logic.

>> trigger) these deregistrations to happen at runtime (no park/unpark
>> transitions)?
>>
>>> Implemented with a list in the GT of all pending work, workqueues in
>>> the list, a callback to add a workqueue to the list, and finally a
>>> wakeref post_get callback that iterates / drains the list + queues the
>>> workqueues.
>>>
>>> First user of this is deregistration of GuC contexts.
>>
>> Does first imply there are more incoming?
>>
> 
> Haven't found another user yet but this is generic mechanism so we can
> add more in the future if other use cases arrise.

My feeling is it would be best to leave it for later.

>   
>>> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
>>> ---
>>>    drivers/gpu/drm/i915/Makefile                 |  1 +
>>>    drivers/gpu/drm/i915/gt/intel_gt.c            |  3 ++
>>>    drivers/gpu/drm/i915/gt/intel_gt_pm.c         |  8 ++++
>>>    .../gpu/drm/i915/gt/intel_gt_pm_unpark_work.c | 35 ++++++++++++++++
>>>    .../gpu/drm/i915/gt/intel_gt_pm_unpark_work.h | 40 +++++++++++++++++++
>>>    drivers/gpu/drm/i915/gt/intel_gt_types.h      | 10 +++++
>>>    drivers/gpu/drm/i915/gt/uc/intel_guc.h        |  8 ++--
>>>    .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 15 +++++--
>>>    drivers/gpu/drm/i915/intel_wakeref.c          |  5 +++
>>>    drivers/gpu/drm/i915/intel_wakeref.h          |  1 +
>>>    10 files changed, 119 insertions(+), 7 deletions(-)
>>>    create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_pm_unpark_work.c
>>>    create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_pm_unpark_work.h
>>>
>>> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
>>> index 642a5b5a1b81..579bdc069f25 100644
>>> --- a/drivers/gpu/drm/i915/Makefile
>>> +++ b/drivers/gpu/drm/i915/Makefile
>>> @@ -103,6 +103,7 @@ gt-y += \
>>>    	gt/intel_gt_clock_utils.o \
>>>    	gt/intel_gt_irq.o \
>>>    	gt/intel_gt_pm.o \
>>> +	gt/intel_gt_pm_unpark_work.o \
>>>    	gt/intel_gt_pm_irq.o \
>>>    	gt/intel_gt_requests.o \
>>>    	gt/intel_gtt.o \
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c b/drivers/gpu/drm/i915/gt/intel_gt.c
>>> index 62d40c986642..7e690e74baa2 100644
>>> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
>>> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
>>> @@ -29,6 +29,9 @@ void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915)
>>>    	spin_lock_init(&gt->irq_lock);
>>> +	spin_lock_init(&gt->pm_unpark_work_lock);
>>> +	INIT_LIST_HEAD(&gt->pm_unpark_work_list);
>>> +
>>>    	INIT_LIST_HEAD(&gt->closed_vma);
>>>    	spin_lock_init(&gt->closed_lock);
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
>>> index dea8e2479897..564c11a3748b 100644
>>> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
>>> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
>>> @@ -90,6 +90,13 @@ static int __gt_unpark(struct intel_wakeref *wf)
>>>    	return 0;
>>>    }
>>> +static void __gt_unpark_work_queue(struct intel_wakeref *wf)
>>> +{
>>> +	struct intel_gt *gt = container_of(wf, typeof(*gt), wakeref);
>>> +
>>> +	intel_gt_pm_unpark_work_queue(gt);
>>> +}
>>> +
>>>    static int __gt_park(struct intel_wakeref *wf)
>>>    {
>>>    	struct intel_gt *gt = container_of(wf, typeof(*gt), wakeref);
>>> @@ -118,6 +125,7 @@ static int __gt_park(struct intel_wakeref *wf)
>>>    static const struct intel_wakeref_ops wf_ops = {
>>>    	.get = __gt_unpark,
>>> +	.post_get = __gt_unpark_work_queue,
>>>    	.put = __gt_park,
>>>    };
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_unpark_work.c b/drivers/gpu/drm/i915/gt/intel_gt_pm_unpark_work.c
>>> new file mode 100644
>>> index 000000000000..23162dbd0c35
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_unpark_work.c
>>> @@ -0,0 +1,35 @@
>>> +// SPDX-License-Identifier: MIT
>>> +/*
>>> + * Copyright © 2021 Intel Corporation
>>> + */
>>> +
>>> +#include "i915_drv.h"
>>> +#include "intel_runtime_pm.h"
>>> +#include "intel_gt_pm.h"
>>> +
>>> +void intel_gt_pm_unpark_work_queue(struct intel_gt *gt)
>>> +{
>>> +	struct intel_gt_pm_unpark_work *work, *next;
>>> +	unsigned long flags;
>>> +
>>> +	spin_lock_irqsave(&gt->pm_unpark_work_lock, flags);
>>> +	list_for_each_entry_safe(work, next,
>>> +				 &gt->pm_unpark_work_list, link) {
>>> +		list_del_init(&work->link);
>>> +		queue_work(system_unbound_wq, &work->worker);
>>> +	}
>>> +	spin_unlock_irqrestore(&gt->pm_unpark_work_lock, flags);
>>> +}
>>> +
>>> +void intel_gt_pm_unpark_work_add(struct intel_gt *gt,
>>> +				 struct intel_gt_pm_unpark_work *work)
>>> +{
>>> +	unsigned long flags;
>>> +
>>> +	spin_lock_irqsave(&gt->pm_unpark_work_lock, flags);
>>> +	if (intel_gt_pm_is_awake(gt))
>>> +		queue_work(system_unbound_wq, &work->worker);
>>> +	else if (list_empty(&work->link))
>>
>> What's the list_empty check for, something can race by design?
>>
> 
> This function is allowed to be called twice, e.g. Two contexts can be
> tried to be deregistered while the GT PM is ideal but only first context
> results in the worker being added to the list of workers to be kicked on
> unpark.

Hmm okay.

> 
>>> +		list_add_tail(&work->link, &gt->pm_unpark_work_list);
>>> +	spin_unlock_irqrestore(&gt->pm_unpark_work_lock, flags);
>>> +}
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_unpark_work.h b/drivers/gpu/drm/i915/gt/intel_gt_pm_unpark_work.h
>>> new file mode 100644
>>> index 000000000000..eaf1dc313aa2
>>> --- /dev/null
>>> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_unpark_work.h
>>> @@ -0,0 +1,40 @@
>>> +/* SPDX-License-Identifier: MIT */
>>> +/*
>>> + * Copyright © 2021 Intel Corporation
>>> + */
>>> +
>>> +#ifndef INTEL_GT_PM_UNPARK_WORK_H
>>> +#define INTEL_GT_PM_UNPARK_WORK_H
>>> +
>>> +#include <linux/list.h>
>>> +#include <linux/workqueue.h>
>>> +
>>> +struct intel_gt;
>>> +
>>> +/**
>>> + * struct intel_gt_pm_unpark_work - work to be scheduled when GT unparked
>>> + */
>>> +struct intel_gt_pm_unpark_work {
>>> +	/**
>>> +	 * @link: link into gt->pm_unpark_work_list of workers that need to be
>>> +	 * scheduled when GT is unpark, protected by gt->pm_unpark_work_lock
>>> +	 */
>>> +	struct list_head link;
>>> +	/** @worker: will be scheduled when GT unparked */
>>> +	struct work_struct worker;
>>> +};
>>> +
>>> +void intel_gt_pm_unpark_work_queue(struct intel_gt *gt);
>>> +
>>> +void intel_gt_pm_unpark_work_add(struct intel_gt *gt,
>>> +				 struct intel_gt_pm_unpark_work *work);
>>> +
>>> +static inline void
>>> +intel_gt_pm_unpark_work_init(struct intel_gt_pm_unpark_work *work,
>>> +			     work_func_t fn)
>>> +{
>>> +	INIT_LIST_HEAD(&work->link);
>>> +	INIT_WORK(&work->worker, fn);
>>> +}
>>> +
>>> +#endif /* INTEL_GT_PM_UNPARK_WORK_H */
>>> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h b/drivers/gpu/drm/i915/gt/intel_gt_types.h
>>> index a81e21bf1bd1..4480312f0add 100644
>>> --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
>>> +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
>>> @@ -96,6 +96,16 @@ struct intel_gt {
>>>    	struct intel_wakeref wakeref;
>>>    	atomic_t user_wakeref;
>>> +	/**
>>> +	 * @pm_unpark_work_list: list of delayed work to scheduled which GT is
>>> +	 * unparked, protected by pm_unpark_work_lock
>>> +	 */
>>> +	struct list_head pm_unpark_work_list;
>>> +	/**
>>> +	 * @pm_unpark_work_lock: protects pm_unpark_work_list
>>> +	 */
>>> +	spinlock_t pm_unpark_work_lock;
>>> +
>>>    	struct list_head closed_vma;
>>>    	spinlock_t closed_lock; /* guards the list of closed_vma */
>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
>>> index 7358883f1540..023953e77553 100644
>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
>>> @@ -19,6 +19,7 @@
>>>    #include "intel_uc_fw.h"
>>>    #include "i915_utils.h"
>>>    #include "i915_vma.h"
>>> +#include "gt/intel_gt_pm_unpark_work.h"
>>>    struct __guc_ads_blob;
>>> @@ -78,11 +79,12 @@ struct intel_guc {
>>>    		 */
>>>    		struct list_head destroyed_contexts;
>>>    		/**
>>> -		 * @destroyed_worker: worker to deregister contexts, need as we
>>> +		 * @destroyed_worker: Worker to deregister contexts, need as we
>>>    		 * need to take a GT PM reference and can't from destroy
>>> -		 * function as it might be in an atomic context (no sleeping)
>>> +		 * function as it might be in an atomic context (no sleeping).
>>> +		 * Worker only issues deregister when GT is unparked.
>>>    		 */
>>> -		struct work_struct destroyed_worker;
>>> +		struct intel_gt_pm_unpark_work destroyed_worker;
>>>    	} submission_state;
>>>    	bool submission_supported;
>>> 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 f835e06e5f9f..dbf919801de2 100644
>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
>>> @@ -1135,7 +1135,8 @@ int intel_guc_submission_init(struct intel_guc *guc)
>>>    	INIT_LIST_HEAD(&guc->submission_state.guc_id_list);
>>>    	ida_init(&guc->submission_state.guc_ids);
>>>    	INIT_LIST_HEAD(&guc->submission_state.destroyed_contexts);
>>> -	INIT_WORK(&guc->submission_state.destroyed_worker, destroyed_worker_func);
>>> +	intel_gt_pm_unpark_work_init(&guc->submission_state.destroyed_worker,
>>> +				     destroyed_worker_func);
>>>    	return 0;
>>>    }
>>> @@ -1942,13 +1943,18 @@ static void deregister_destroyed_contexts(struct intel_guc *guc)
>>>    static void destroyed_worker_func(struct work_struct *w)
>>>    {
>>> -	struct intel_guc *guc = container_of(w, struct intel_guc,
>>> +	struct intel_gt_pm_unpark_work *destroyed_worker =
>>> +		container_of(w, struct intel_gt_pm_unpark_work, worker);
>>> +	struct intel_guc *guc = container_of(destroyed_worker, struct intel_guc,
>>>    					     submission_state.destroyed_worker);
>>>    	struct intel_gt *gt = guc_to_gt(guc);
>>>    	int tmp;
>>> -	with_intel_gt_pm(gt, tmp)
>>> +	with_intel_gt_pm_if_awake(gt, tmp)
>>>    		deregister_destroyed_contexts(guc);
>>> +
>>> +	if (!list_empty(&guc->submission_state.destroyed_contexts))
>>> +		intel_gt_pm_unpark_work_add(gt, destroyed_worker);
>>
>> This is the worker itself, right?
>>
> 
> Yes.
> 
>> There's a "if awake" here followed by another "if awake" inside
>> intel_gt_pm_unpark_work_add which raises questions.
>>
> 
> Even in the worker we only deregister the context if the GT is awake.

Yeah but the two "if awake" checks followed by one another is the 
confusing part since it is not atomic. Coupled with the list empty check 
I mean. So two external async condition can influence the flow, one of 
which is even checked twice.

The worker can decide not to deregister, but by the time 
intel_gt_pm_unpark_work_add runs GT may have became unparked so worker 
gets queued. When it runs GT is parked again and so it can bounce in a 
loop forever.

>   
>> Second question is what's the list_empty for - why is the state of the list
>> itself relevant to a single worker deciding whether to re-add itself to it
>> or not? And is there a lock protecting this list?
>>
> 
> Yes we have locking - pm_unpark_work_lock. It is basically all 2
> threads to call intel_gt_pm_unpark_work_add while the GT is idle - in
> that case only the first call adds the worker to the list of workers to
> kick when unparked (same explaination as above).
>   
>> On the overall it feels questionable to have unpark work which apparently
>> can race with subsequent parking. Presumably you cannot have it run sync on
>> unpark due execution context issues?
>>
> 
> No race, just allowed to be called twice.

But list_empty check is not under any locks so I don't follow.

> 
>>>    }
>>>    static void guc_context_destroy(struct kref *kref)
>>> @@ -1985,7 +1991,8 @@ static void guc_context_destroy(struct kref *kref)
>>>    	 * take the GT PM for the first time which isn't allowed from an atomic
>>>    	 * context.
>>>    	 */
>>> -	queue_work(system_unbound_wq, &guc->submission_state.destroyed_worker);
>>> +	intel_gt_pm_unpark_work_add(guc_to_gt(guc),
>>> +				    &guc->submission_state.destroyed_worker);
>>>    }
>>>    static int guc_context_alloc(struct intel_context *ce)
>>> diff --git a/drivers/gpu/drm/i915/intel_wakeref.c b/drivers/gpu/drm/i915/intel_wakeref.c
>>> index dfd87d082218..282fc4f312e3 100644
>>> --- a/drivers/gpu/drm/i915/intel_wakeref.c
>>> +++ b/drivers/gpu/drm/i915/intel_wakeref.c
>>> @@ -24,6 +24,8 @@ static void rpm_put(struct intel_wakeref *wf)
>>>    int __intel_wakeref_get_first(struct intel_wakeref *wf)
>>>    {
>>> +	bool do_post = false;
>>> +
>>>    	/*
>>>    	 * Treat get/put as different subclasses, as we may need to run
>>>    	 * the put callback from under the shrinker and do not want to
>>> @@ -44,8 +46,11 @@ int __intel_wakeref_get_first(struct intel_wakeref *wf)
>>>    		}
>>>    		smp_mb__before_atomic(); /* release wf->count */
>>> +		do_post = true;
>>>    	}
>>>    	atomic_inc(&wf->count);
>>> +	if (do_post && wf->ops->post_get)
>>> +		wf->ops->post_get(wf);
>>
>> You want this hook under the wf->mutex and why?
>>
> 
> I didn't really think about this but everything else in under the mutex
> so I included this under the mutex too. In this case this post_get op
> could likely be outside the mutex but I think it harmless to keep it
> under the mutex. For future safety, I think it should stay under the
> mutex.

If it is under the mutex then what is the point of two hooks? The only 
difference is get sees wf->count == 0, while post_get sees it as one.

No wait.. you have put post_get outside the 0->1 transition check so 
potentially called more than once. You probably do not want this.. But 
could you just do this from the existing hook is the main question.

Regards,

Tvrtko

> 
> Matt
> 
>> Regards,
>>
>> Tvrtko
>>
>>>    	mutex_unlock(&wf->mutex);
>>>    	INTEL_WAKEREF_BUG_ON(atomic_read(&wf->count) <= 0);
>>> diff --git a/drivers/gpu/drm/i915/intel_wakeref.h b/drivers/gpu/drm/i915/intel_wakeref.h
>>> index 545c8f277c46..ef7e6a698e8a 100644
>>> --- a/drivers/gpu/drm/i915/intel_wakeref.h
>>> +++ b/drivers/gpu/drm/i915/intel_wakeref.h
>>> @@ -30,6 +30,7 @@ typedef depot_stack_handle_t intel_wakeref_t;
>>>    struct intel_wakeref_ops {
>>>    	int (*get)(struct intel_wakeref *wf);
>>> +	void (*post_get)(struct intel_wakeref *wf);
>>>    	int (*put)(struct intel_wakeref *wf);
>>>    };
>>>

  reply	other threads:[~2021-09-13 10:34 UTC|newest]

Thread overview: 145+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-20 22:44 [PATCH 00/27] Parallel submission aka multi-bb execbuf Matthew Brost
2021-08-20 22:44 ` [Intel-gfx] " Matthew Brost
2021-08-20 22:44 ` [PATCH 01/27] drm/i915/guc: Squash Clean up GuC CI failures, simplify locking, and kernel DOC Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-08-20 22:44 ` [PATCH 02/27] drm/i915/guc: Allow flexible number of context ids Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-09-09 22:13   ` John Harrison
2021-09-10  0:14     ` Matthew Brost
2021-08-20 22:44 ` [PATCH 03/27] drm/i915/guc: Connect the number of guc_ids to debugfs Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-09-09 22:16   ` John Harrison
2021-09-10  0:16     ` Matthew Brost
2021-08-20 22:44 ` [PATCH 04/27] drm/i915/guc: Take GT PM ref when deregistering context Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-09-09 22:28   ` John Harrison
2021-09-10  0:21     ` Matthew Brost
2021-09-13  9:55   ` Tvrtko Ursulin
2021-09-13 17:12     ` Matthew Brost
2021-09-14  8:41       ` Tvrtko Ursulin
2021-08-20 22:44 ` [PATCH 05/27] drm/i915: Add GT PM unpark worker Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-09-09 22:36   ` John Harrison
2021-09-10  0:34     ` Matthew Brost
2021-09-10  8:36   ` Tvrtko Ursulin
2021-09-10 20:09     ` Matthew Brost
2021-09-13 10:33       ` Tvrtko Ursulin [this message]
2021-09-13 17:20         ` Matthew Brost
2021-08-20 22:44 ` [PATCH 06/27] drm/i915/guc: Take engine PM when a context is pinned with GuC submission Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-09-09 22:46   ` John Harrison
2021-09-10  0:41     ` Matthew Brost
2021-09-13 22:26       ` John Harrison
2021-09-14  1:12         ` Matthew Brost
2021-08-20 22:44 ` [PATCH 07/27] drm/i915/guc: Don't call switch_to_kernel_context " Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-09-09 22:51   ` John Harrison
2021-09-13 16:54     ` Matthew Brost
2021-09-13 22:38       ` John Harrison
2021-09-14  5:02         ` Matthew Brost
2021-09-13 16:55     ` Matthew Brost
2021-08-20 22:44 ` [PATCH 08/27] drm/i915: Add logical engine mapping Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-09-10 11:12   ` Tvrtko Ursulin
2021-09-10 19:49     ` Matthew Brost
2021-09-13  9:24       ` Tvrtko Ursulin
2021-09-13 16:50         ` Matthew Brost
2021-09-14  8:34           ` Tvrtko Ursulin
2021-09-14 18:04             ` Matthew Brost
2021-09-15  8:24               ` Tvrtko Ursulin
2021-09-15 16:58                 ` Matthew Brost
2021-09-16  8:31                   ` Tvrtko Ursulin
2021-08-20 22:44 ` [PATCH 09/27] drm/i915: Expose logical engine instance to user Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-09-13 23:06   ` John Harrison
2021-09-14  1:08     ` Matthew Brost
2021-08-20 22:44 ` [PATCH 10/27] drm/i915/guc: Introduce context parent-child relationship Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-09-13 23:19   ` John Harrison
2021-09-14  1:18     ` Matthew Brost
2021-08-20 22:44 ` [PATCH 11/27] drm/i915/guc: Implement parallel context pin / unpin functions Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-08-20 22:44 ` [PATCH 12/27] drm/i915/guc: Add multi-lrc context registration Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-09-15 19:21   ` John Harrison
2021-09-15 19:31     ` Matthew Brost
2021-09-15 20:23       ` John Harrison
2021-09-15 20:33         ` Matthew Brost
2021-08-20 22:44 ` [PATCH 13/27] drm/i915/guc: Ensure GuC schedule operations do not operate on child contexts Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-09-15 19:24   ` John Harrison
2021-09-15 19:34     ` Matthew Brost
2021-08-20 22:44 ` [PATCH 14/27] drm/i915/guc: Assign contexts in parent-child relationship consecutive guc_ids Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-09-15 20:04   ` John Harrison
2021-09-15 20:55     ` Matthew Brost
2021-08-20 22:44 ` [PATCH 15/27] drm/i915/guc: Implement multi-lrc submission Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-08-21 14:04   ` kernel test robot
2021-08-21 14:04     ` kernel test robot
2021-08-21 14:04     ` kernel test robot
2021-08-22  2:18   ` kernel test robot
2021-08-22  2:18     ` kernel test robot
2021-08-22  2:18     ` [Intel-gfx] " kernel test robot
2021-09-20 21:48   ` John Harrison
2021-09-22 16:25     ` Matthew Brost
2021-09-22 20:15       ` John Harrison
2021-09-23  2:44         ` Matthew Brost
2021-08-20 22:44 ` [PATCH 16/27] drm/i915/guc: Insert submit fences between requests in parent-child relationship Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-09-20 21:57   ` John Harrison
2021-08-20 22:44 ` [PATCH 17/27] drm/i915/guc: Implement multi-lrc reset Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-09-20 22:44   ` John Harrison
2021-09-22 16:16     ` Matthew Brost
2021-08-20 22:44 ` [Intel-gfx] [PATCH 18/27] drm/i915/guc: Update debugfs for GuC multi-lrc Matthew Brost
2021-08-20 22:44   ` Matthew Brost
2021-09-20 22:48   ` [Intel-gfx] " John Harrison
2021-09-21 19:13     ` Matthew Brost
2021-08-20 22:44 ` [PATCH 19/27] drm/i915: Fix bug in user proto-context creation that leaked contexts Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-09-20 22:57   ` John Harrison
2021-09-21 14:49     ` Tvrtko Ursulin
2021-09-21 19:28       ` Matthew Brost
2021-09-21 19:28     ` Matthew Brost
2021-08-20 22:44 ` [Intel-gfx] [PATCH 20/27] drm/i915/guc: Connect UAPI to GuC multi-lrc interface Matthew Brost
2021-08-20 22:44   ` Matthew Brost
2021-08-29  4:00   ` [Intel-gfx] " kernel test robot
2021-08-29  4:00     ` kernel test robot
2021-08-29 19:59   ` kernel test robot
2021-08-29 19:59     ` kernel test robot
2021-09-21  0:09   ` John Harrison
2021-09-22 16:38     ` Matthew Brost
2021-08-20 22:44 ` [PATCH 21/27] drm/i915/doc: Update parallel submit doc to point to i915_drm.h Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-09-21  0:12   ` John Harrison
2021-08-20 22:44 ` [PATCH 22/27] drm/i915/guc: Add basic GuC multi-lrc selftest Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-09-28 20:47   ` John Harrison
2021-08-20 22:44 ` [PATCH 23/27] drm/i915/guc: Implement no mid batch preemption for multi-lrc Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-09-10 11:25   ` Tvrtko Ursulin
2021-09-10 20:49     ` Matthew Brost
2021-09-13 10:52       ` Tvrtko Ursulin
2021-09-28 22:20   ` John Harrison
2021-09-28 22:33     ` Matthew Brost
2021-09-28 23:33       ` John Harrison
2021-09-29  0:22         ` Matthew Brost
2021-08-20 22:44 ` [PATCH 24/27] drm/i915: Multi-BB execbuf Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-08-21 19:01   ` kernel test robot
2021-08-21 19:01     ` kernel test robot
2021-08-30  3:46   ` kernel test robot
2021-08-30  3:46     ` kernel test robot
2021-09-30 22:16   ` Matthew Brost
2021-08-20 22:44 ` [PATCH 25/27] drm/i915/guc: Handle errors in multi-lrc requests Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-09-29 20:44   ` John Harrison
2021-09-29 20:58     ` Matthew Brost
2021-08-20 22:44 ` [PATCH 26/27] drm/i915: Enable multi-bb execbuf Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-08-20 22:44 ` [PATCH 27/27] drm/i915/execlists: Weak parallel submission support for execlists Matthew Brost
2021-08-20 22:44   ` [Intel-gfx] " Matthew Brost
2021-08-20 23:13 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Parallel submission aka multi-bb execbuf (rev3) Patchwork
2021-08-20 23:14 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-08-20 23:45 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork

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=2b6daf2f-c20c-cc2d-c4fe-a705931fa82b@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=matthew.brost@intel.com \
    --cc=tony.ye@intel.com \
    --cc=zhengguo.xu@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.