Hi,
On Fri, 2024-09-06 at 19:06 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> In a recent conversation with Christian there was a thought that
> drm_sched_entity_modify_sched() should start using the entity-
> >rq_lock to be
> safe against job submission and simultaneous priority chang
On Fri, 2024-09-06 at 19:06 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Without the locking amdgpu currently can race
> amdgpu_ctx_set_entity_priority() and drm_sched_job_arm(),
I would explicitly say "amdgpu's amdgpu_ctx_set_entity_priority() races
through drm_sched_entity_modify_s
On Fri, 2024-09-06 at 19:06 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Since drm_sched_entity_modify_sched() can modify the entities run
> queue
> lets make sure to only derefernce the pointer once so both adding and
> waking up are guaranteed to be consistent.
>
> Signed-off-by: Tv
On Mon, 2024-09-09 at 13:29 +0200, Christian König wrote:
> Am 09.09.24 um 11:44 schrieb Philipp Stanner:
> > On Fri, 2024-09-06 at 19:06 +0100, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > Without the locking amdgpu currently can race
> &
On Mon, 2024-09-09 at 13:37 +0100, Tvrtko Ursulin wrote:
>
> On 09/09/2024 13:18, Christian König wrote:
> > Am 09.09.24 um 14:13 schrieb Philipp Stanner:
> > > On Mon, 2024-09-09 at 13:29 +0200, Christian König wrote:
> > > > Am 09.09.24 um 11:44 schrieb Philip
On Mon, 2024-09-09 at 14:27 +0100, Tvrtko Ursulin wrote:
>
> On 09/09/2024 13:46, Philipp Stanner wrote:
> > On Mon, 2024-09-09 at 13:37 +0100, Tvrtko Ursulin wrote:
> > >
> > > On 09/09/2024 13:18, Christian König wrote:
> > > > Am 09.09.24 um 14:13
e the change in behaviour is
> simply
> to restart from the first entity, instead of continuing in RR mode
> from
> where FIFO left it, and that sounds completely fine.
>
> Signed-off-by: Tvrtko Ursulin
I went through the code and agree that this looks good.
Reviewed-by: Phili
visible."
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Alex Deucher
> Cc: Luben Tuikov
> Cc: Matthew Brost
> Cc: Philipp Stanner
> ---
> include/drm/gpu_scheduler.h | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> d
Why is dereferencing it a problem?
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Alex Deucher
> Cc: Luben Tuikov
> Cc: Matthew Brost
> Cc: Philipp Stanner
> ---
> drivers/gpu/drm/scheduler/sched_entity.c | 7 ++--
> drivers/gpu/drm/scheduler/
On Tue, 2024-09-10 at 11:42 +0100, Tvrtko Ursulin wrote:
>
> On 10/09/2024 11:05, Philipp Stanner wrote:
> > On Mon, 2024-09-09 at 18:19 +0100, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > Lets re-order the members to make it clear whic
On Wed, 2024-09-11 at 13:22 +0100, Tvrtko Ursulin wrote:
>
> On 10/09/2024 11:25, Philipp Stanner wrote:
> > On Mon, 2024-09-09 at 18:19 +0100, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > Having removed one re-lock cycle on the entity-&
Ursulin
> Cc: Christian König
> Cc: Alex Deucher
> Cc: Luben Tuikov
> Cc: Matthew Brost
> Cc: Philipp Stanner
> Reviewed-by: Christian König
Looks good, thx
Reviewed-by: Philipp Stanner
> ---
> include/drm/gpu_scheduler.h | 10 ++
> 1 file change
On Fri, 2023-12-01 at 02:37 +, zhuweixi wrote:
> From your argument on KVM I can see that the biggest miscommunication
> between us is that you believed that GMEM wanted to share the whole
> address space. No, it is not the case. GMEM is only providing
> coordination via certain mmap() calls. S
q_update_fifo_locked(),
> > drm_sched_rq_add_entity() and
> > drm_sched_rq_remove_fifo_locked() function signatures, by adding rq
> > as a
> > parameter to the latter.
> >
> > v2:
> > * Fix after rebase of the series.
> > * Avoid naming incos
; > We also align drm_sched_rq_update_fifo_locked(),
> > > > > drm_sched_rq_add_entity() and
> > > > > drm_sched_rq_remove_fifo_locked() function signatures, by
> > > > > adding rq
> > > > > as a
> > > > > parameter to the lat
_init()").
Introduce a new struct for the scheduler init parameters and port all
users.
Signed-off-by: Philipp Stanner
Reviewed-by: Liviu Dudau
Acked-by: Matthew Brost # for Xe
Reviewed-by: Boris Brezillon # for Panfrost and
Panthor
Reviewed-by: Christian Gmeiner # for Etnaviv
Reviewed
On Thu, 2025-02-06 at 14:46 +0100, Christian König wrote:
> Am 06.02.25 um 14:35 schrieb Philipp Stanner:
> > On Wed, 2025-02-05 at 15:33 +, Tvrtko Ursulin wrote:
> > > The helper copies code from the existing
> > > amdgpu_job_stop_all_jobs_on_sched
> > &
On Thu, 2025-02-06 at 13:53 +, Tvrtko Ursulin wrote:
>
> On 06/02/2025 13:46, Christian König wrote:
> > Am 06.02.25 um 14:35 schrieb Philipp Stanner:
> > > On Wed, 2025-02-05 at 15:33 +, Tvrtko Ursulin wrote:
> > > > The hel
re.
P.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Danilo Krummrich
> Cc: Matthew Brost
> Cc: Philipp Stanner
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 44
> ++
> include/drm/gpu_scheduler.h | 1 +
&
his also allows us to remove duplicate definition of
> to_drm_sched_job
> which the scheduler apparently tried to keep internal, but failed
> since
> in one of the previous patches we also removed a copy from amdgpu.
>
> Signed-off-by: Tvrtko Ursulin
This one LGTM, +1
> Cc: Christian
me in
nouveau_sched_init()").
Introduce a new struct for the scheduler init parameters and port all
users.
Signed-off-by: Philipp Stanner
Reviewed-by: Liviu Dudau
Acked-by: Matthew Brost # for Xe
Reviewed-by: Boris Brezillon # for Panfrost and
Panthor
Reviewed-by: Christian Gmeiner # for Etnavi
gt; amdgpu_job_stop_all_jobs_on_sched is removed.
> >
> > Signed-off-by: Tvrtko Ursulin
> > Cc: Christian König
> > Cc: Danilo Krummrich
> > Cc: Matthew Brost
> > Cc: Philipp Stanner
> > Cc: "Zhang, Hawking"
>
> Reviewed-by: Christian Kön
On Wed, 2025-02-12 at 12:30 +, Tvrtko Ursulin wrote:
>
> On 12/02/2025 10:40, Philipp Stanner wrote:
> > On Wed, 2025-02-12 at 09:32 +, Tvrtko Ursulin wrote:
> > >
> > > On 12/02/2025 09:02, Philipp Stanner wrote:
> > > > On Fri, 2025-
> Cc: Danilo Krummrich
> Cc: Matthew Brost
> Cc: Philipp Stanner
> ---
> drivers/gpu/drm/scheduler/sched_entity.c | 12
> drivers/gpu/drm/scheduler/sched_internal.h | 13 +
> include/drm/gpu_scheduler.h | 1 -
> 3 files chan
On Tue, 2025-02-11 at 12:14 +0100, Philipp Stanner wrote:
> drm_sched_init() has a great many parameters and upcoming new
> functionality for the scheduler might add even more. Generally, the
> great number of parameters reduces readability and has already caused
> one missnaming,
e definitions of
> to_drm_sched_job.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Danilo Krummrich
> Cc: Matthew Brost
> Cc: Philipp Stanner
> ---
> drivers/gpu/drm/scheduler/sched_entity.c | 11 +++---
> drivers/gpu/drm/scheduler/sched_
On Wed, 2025-02-12 at 09:32 +, Tvrtko Ursulin wrote:
>
> On 12/02/2025 09:02, Philipp Stanner wrote:
> > On Fri, 2025-02-07 at 14:50 +, Tvrtko Ursulin wrote:
> > > Idea is to add helpers for peeking and popping jobs from entities
> > > with
> >
On Wed, 2025-01-29 at 07:53 -0300, Maíra Canal wrote:
> Hi Philipp,
>
> On 28/01/25 11:29, Philipp Stanner wrote:
> > drm_sched_init() has a great many parameters and upcoming new
> > functionality for the scheduler might add even more. Generally, the
> > great n
On Tue, 2025-01-28 at 15:56 +0100, Danilo Krummrich wrote:
> On Tue, Jan 28, 2025 at 03:29:27PM +0100, Philipp Stanner wrote:
> > drm_sched_init() has a great many parameters and upcoming new
> > functionality for the scheduler might add even more. Generally, the
> > great
> the
> submission path use it.
>
> Signed-off-by: Tvrtko Ursulin
> References: 746ae46c1113 ("drm/sched: Mark scheduler work queues with
> WQ_MEM_RECLAIM")
> Fixes: a6149f039369 ("drm/sched: Convert drm scheduler to use a work
> queue rather than kthread&quo
On Wed, 2025-01-22 at 15:34 +0100, Christian König wrote:
> Am 22.01.25 um 15:08 schrieb Philipp Stanner:
> > drm_sched_init() has a great many parameters and upcoming new
> > functionality for the scheduler might add even more. Generally, the
> > great number of parameters re
On Wed, 2025-01-22 at 16:06 +0100, Christian König wrote:
> Am 22.01.25 um 15:48 schrieb Philipp Stanner:
> > On Wed, 2025-01-22 at 15:34 +0100, Christian König wrote:
> > > Am 22.01.25 um 15:08 schrieb Philipp Stanner:
> > > > drm_sched_init() has a great ma
me in
nouveau_sched_init()").
Introduce a new struct for the scheduler init parameters and port all
users.
Signed-off-by: Philipp Stanner
---
Howdy,
I have a patch-series in the pipe that will add a `flags` argument to
drm_sched_init(). I thought it would be wise to first rework the API as
detailed in this p
On Thu, 2025-01-23 at 09:10 +0100, Philipp Stanner wrote:
> On Wed, 2025-01-22 at 19:07 -0300, Maíra Canal wrote:
> > Hi Philipp,
> >
> > On 22/01/25 11:08, Philipp Stanner wrote:
> > > drm_sched_init() has a great many parameters and upcoming new
> > > fu
On Thu, 2025-01-23 at 10:29 +0100, Danilo Krummrich wrote:
> On Thu, Jan 23, 2025 at 08:33:01AM +0100, Philipp Stanner wrote:
> > On Wed, 2025-01-22 at 18:16 +0100, Boris Brezillon wrote:
> > > On Wed, 22 Jan 2025 15:08:20 +0100
> > > Philipp Stanner wrote:
> &g
On Wed, 2025-01-22 at 18:16 +0100, Boris Brezillon wrote:
> On Wed, 22 Jan 2025 15:08:20 +0100
> Philipp Stanner wrote:
>
> > int drm_sched_init(struct drm_gpu_scheduler *sched,
> > - const struct drm_sched_backend_ops *ops,
> > - struct workqueue_struct *subm
t; > On Wed, 22 Jan 2025 15:08:20 +0100
> > > > Philipp Stanner wrote:
> > > >
> > > > > --- a/drivers/gpu/drm/panthor/panthor_sched.c
> > > > > +++ b/drivers/gpu/drm/panthor/panthor_sched.c
> > > > > @@ -3272,6 +3272,7 @@ group_creat
On Wed, 2025-01-22 at 19:07 -0300, Maíra Canal wrote:
> Hi Philipp,
>
> On 22/01/25 11:08, Philipp Stanner wrote:
> > drm_sched_init() has a great many parameters and upcoming new
> > functionality for the scheduler might add even more. Generally, the
> > great n
On Thu, 2025-01-23 at 08:10 -0300, Maíra Canal wrote:
> Hi Philipp,
>
> On 23/01/25 05:10, Philipp Stanner wrote:
> > On Wed, 2025-01-22 at 19:07 -0300, Maíra Canal wrote:
> > > Hi Philipp,
> > >
> > > On 22/01/25 11:08, Philipp Stanner wrote:
> >
me in
nouveau_sched_init()").
Introduce a new struct for the scheduler init parameters and port all
users.
Signed-off-by: Philipp Stanner
---
Changes in v2:
- Point out that the hang-limit is deprecated. (Christian)
- Initialize the structs to 0 at declaration. (Planet Earth)
- Don't set stuff
On Tue, 2025-03-18 at 13:03 +0100, Christian König wrote:
> The problem is that drivers sometimes need to add dependencies
> without
> allocating any memory.
>
> Add a function which preallocates slots by inserting signaled stub
> fences
> into the dependency array.
I think I get what you're doin
r rework.
I suppose this was tested on a workstation with AMD card?
>
> As before, I am looking for feedback, ideas for what kind of
> submission
> scenarios to test. Testers on different GPUs would be very welcome
> too.
>
> And I should probably test round-robin at some poin
On Thu, 2025-03-20 at 11:49 +, Tvrtko Ursulin wrote:
>
> On 19/03/2025 11:23, Christian König wrote:
> > > > + *
> > > > + * Return:
> > > > + * 0 on success, or an error on failing to expand the array.
> > > > + */
> > > > +int drm_sched_job_prealloc_dependency_slots(struct
> > > > drm_sched_
On Wed, 2025-04-09 at 14:39 +0200, Boris Brezillon wrote:
> Hi Philipp,
>
> On Wed, 9 Apr 2025 14:06:37 +0200
> Philipp Stanner wrote:
>
> > dma_fence_is_signaled()'s name strongly reads as if this function
> > were
> > intended for checking whether
On Wed, 2025-04-09 at 09:52 +0200, Pierre-Eric Pelloux-Prayer wrote:
> Hi,
>
> I've rebased the series on top of drm-next, applied the minor tweaks
> suggested by Tvrtko on v8 and
> the R-b tags. The result can be found on gitlab.fdo:
>
> https://gitlab.freedesktop.org/pepp/linux/-/commits/impro
+Cc Matthew
On Wed, 2025-04-09 at 15:55 +0200, Christian König wrote:
> Am 09.04.25 um 12:28 schrieb Philipp Stanner:
> > On Fri, 2025-03-21 at 16:58 +0100, Christian König wrote:
> > > Sometimes drivers need to be able to submit multiple jobs which
> > > depend on
&g
On Fri, 2025-03-21 at 16:58 +0100, Christian König wrote:
> Sometimes drivers need to be able to submit multiple jobs which
> depend on
> each other to different schedulers at the same time, but using
> drm_sched_job_add_dependency() can't fail any more after the first
> job is
> initialized.
>
>
On Wed, 2025-04-09 at 15:14 +0200, Christian König wrote:
> Am 09.04.25 um 14:56 schrieb Philipp Stanner:
> > On Wed, 2025-04-09 at 14:51 +0200, Philipp Stanner wrote:
> > > On Wed, 2025-04-09 at 14:39 +0200, Boris Brezillon wrote:
> > > > Hi Philipp,
> > >
On Wed, 2025-04-09 at 14:51 +0200, Philipp Stanner wrote:
> On Wed, 2025-04-09 at 14:39 +0200, Boris Brezillon wrote:
> > Hi Philipp,
> >
> > On Wed, 9 Apr 2025 14:06:37 +0200
> > Philipp Stanner wrote:
> >
> > > dma_fence_is_signaled()'s nam
On Wed, 2025-04-09 at 16:10 +0200, Christian König wrote:
> Am 09.04.25 um 16:01 schrieb Philipp Stanner:
> > On Wed, 2025-04-09 at 15:14 +0200, Christian König wrote:
> > > Am 09.04.25 um 14:56 schrieb Philipp Stanner:
> > > > On Wed, 2025-04-09 at 14:51 +0200, Phili
at it becomes very, very explicit when reading code that this is a
place where fences can get signaled.
This series obsoletes this patch: [2]
P.
[1] https://lore.kernel.org/all/20250403101353.42880-2-pha...@kernel.org/
[2] https://lore.kernel.org/all/20250408122217.61530-2-pha...@kernel.org/
Ph
nouveau_fence_done() uses the function to check a fence, which causes a
race.
Give the function a more obvious name.
Signed-off-by: Philipp Stanner
---
drivers/dma-buf/dma-fence-array.c | 2 +-
drivers/dma-buf/dma-fence-chain.c | 6 +++---
drivers/dma-buf/dma-
style.
Signed-off-by: Philipp Stanner
---
include/linux/dma-fence.h | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index dc2ad171458b..3df370b2cc7c 100644
--- a/include/linux/dma-fence.h
+++ b/in
On Wed, 2025-04-09 at 16:04 +0200, Philipp Stanner wrote:
> +Cc Matthew
>
> On Wed, 2025-04-09 at 15:55 +0200, Christian König wrote:
> > Am 09.04.25 um 12:28 schrieb Philipp Stanner:
> > > On Fri, 2025-03-21 at 16:58 +0100, Christian König wrote:
> > > >
On Tue, 2025-02-18 at 14:17 -0800, Matthew Brost wrote:
> On Tue, Feb 18, 2025 at 06:26:15PM +, Tvrtko Ursulin wrote:
> >
> > On 18/02/2025 12:26, Philipp Stanner wrote:
> > > Thx for the updated version. Overlooked it, I was out on Friday.
> > > See
> &g
mplemented with a container_of.
>
> This also allows us to remove duplicate definitions of
> to_drm_sched_job.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Danilo Krummrich
> Cc: Matthew Brost
> Cc: Philipp Stanner
> ---
> drivers/gpu/drm/sched
On Thu, 2025-02-13 at 14:05 -0800, Matthew Brost wrote:
> On Wed, Feb 12, 2025 at 01:36:58PM +0100, Philipp Stanner wrote:
> > On Wed, 2025-02-12 at 12:30 +, Tvrtko Ursulin wrote:
> > >
> > > On 12/02/2025 10:40, Philipp Stanner wrote:
> > > > On Wed, 20
rmat.
>
> v6:
> * Added SPDX to the new header file.
>
> Cc: Christian König
> Cc: Danilo Krummrich
> Cc: Matthew Brost
> Cc: Philipp Stanner
>
> Tvrtko Ursulin (6):
> drm/sched: Add internal job peek/pop API
> drm/amdgpu: Pop jobs from the queue more
t we screwed up and someone really relies on RR, it
would be easy to revert.
I am not aware of any RR users and have, in past discussions, never
heard of any. So removing it is more tempting for the above reasons.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Danil
On Fri, 2025-03-21 at 16:58 +0100, Christian König wrote:
> Sometimes drivers need to be able to submit multiple jobs which
> depend on
> each other to different schedulers at the same time, but using
> drm_sched_job_add_dependency() can't fail any more after the first
> job is
> initialized.
>
>
On Wed, 2025-04-02 at 12:58 +0200, Michel Dänzer wrote:
> On 2025-04-02 12:46, Philipp Stanner wrote:
> > On Mon, 2025-03-31 at 21:16 +0100, Tvrtko Ursulin wrote:
> > > Round-robin being the non-default policy and unclear how much it
> > > is
> > > used
he function.
Same here, that's a good candidate for a separate patch / series.
P.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Danilo Krummrich
> Cc: Matthew Brost
> Cc: Philipp Stanner
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 37 +++
o Ursulin
> Cc: Christian König
> Cc: Danilo Krummrich
> Cc: Matthew Brost
> Cc: Philipp Stanner
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 ++--
> drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 6 ++--
> drivers/gpu/drm/amd/amdgpu/amdgpu_job.h | 5 +++-
>
every
> popped job.
That there is no need to do so doesn't imply that you can't keep them
around. The commit message doesn't make the motivation clear
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Danilo Krummrich
> Cc: Matthew Brost
> C
gt; completed jobs as soon as possible so the metric is most up to date
> when
> view from the submission side of things.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Danilo Krummrich
> Cc: Matthew Brost
> Cc: Philipp Stanner
> ---
&
heduling policy, not general other improvements.
P.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Danilo Krummrich
> Cc: Matthew Brost
> Cc: Philipp Stanner
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 39 +++-
> --
> 1
On Thu, 2025-05-15 at 17:17 +0100, Tvrtko Ursulin wrote:
>
> On 15/05/2025 16:00, Christian König wrote:
> > Sometimes drivers need to be able to submit multiple jobs which
> > depend on
> > each other to different schedulers at the same time, but using
> > drm_sched_job_add_dependency() can't fai
that will never be resolved. Fix this issue by ensuring
> that
> scheduled fences are properly signaled when an entity is killed,
> allowing
> dependent applications to continue execution.
That sounds perfect, yes, Thx.
Reviewed-by: Philipp Stanner
P.
>
> Thanks,
>
On Thu, 2025-04-24 at 10:38 +0200, Pierre-Eric Pelloux-Prayer wrote:
> This will be used in a later commit to trace the drm client_id in
> some of the gpu_scheduler trace events.
>
> This requires changing all the users of drm_sched_job_init to
> add an extra parameter.
>
> The newly added drm_cl
On Thu, 2025-04-24 at 10:38 +0200, Pierre-Eric Pelloux-Prayer wrote:
> Its only purpose was for trace events, but jobs can already be
> uniquely identified using their fence.
>
> The downside of using the fence is that it's only available
> after 'drm_sched_job_arm' was called which is true for al
On Tue, 2025-05-20 at 17:15 +0100, Tvrtko Ursulin wrote:
>
> On 19/05/2025 10:04, Philipp Stanner wrote:
> > On Mon, 2025-05-19 at 09:51 +0100, Tvrtko Ursulin wrote:
> > >
> > > On 16/05/2025 18:16, Philipp Stanner wrote:
> > > > On Fri, 2025-
On Fri, 2025-05-16 at 15:30 +0100, Tvrtko Ursulin wrote:
>
> On 16/05/2025 14:38, Philipp Stanner wrote:
> > On Fri, 2025-05-16 at 13:10 +0100, Tvrtko Ursulin wrote:
> > >
> > > On 16/05/2025 12:53, Tvrtko Ursulin wrote:
> > > >
> > > > On
On Fri, 2025-05-16 at 13:10 +0100, Tvrtko Ursulin wrote:
>
> On 16/05/2025 12:53, Tvrtko Ursulin wrote:
> >
> > On 16/05/2025 08:28, Philipp Stanner wrote:
> > > On Thu, 2025-05-15 at 17:17 +0100, Tvrtko Ursulin wrote:
> > > >
> > &
On Mon, 2025-05-19 at 13:02 +0200, Pierre-Eric Pelloux-Prayer wrote:
>
>
> Le 15/05/2025 à 08:53, Pierre-Eric Pelloux-Prayer a écrit :
> > Hi,
> >
> > Le 14/05/2025 à 14:44, Philipp Stanner a écrit :
> > > On Thu, 2025-04-24 at 10:38 +0200, Pierre-Eric Pell
On Mon, 2025-05-19 at 09:51 +0100, Tvrtko Ursulin wrote:
>
> On 16/05/2025 18:16, Philipp Stanner wrote:
> > On Fri, 2025-05-16 at 15:30 +0100, Tvrtko Ursulin wrote:
> > >
> > > On 16/05/2025 14:38, Philipp Stanner wrote:
> > > > On Fri, 2025-
On Mon, 2025-05-26 at 13:16 +0200, Christian König wrote:
> On 5/26/25 11:34, Philipp Stanner wrote:
> > On Mon, 2025-05-26 at 11:25 +0200, Christian König wrote:
> > > On 5/23/25 16:16, Danilo Krummrich wrote:
> > > > On Fri, May 23, 2025 at 04:11:39PM +0200,
+Cc Matthew, again :)
On Thu, 2025-05-22 at 18:19 +0200, Christian König wrote:
> On 5/22/25 16:27, Tvrtko Ursulin wrote:
> >
> > On 22/05/2025 14:41, Christian König wrote:
> > > Since we already iterated over the xarray we know at which index
> > > the new
> > > entry should be stored. So inste
On Mon, 2025-05-26 at 11:25 +0200, Christian König wrote:
> On 5/23/25 16:16, Danilo Krummrich wrote:
> > On Fri, May 23, 2025 at 04:11:39PM +0200, Danilo Krummrich wrote:
> > > On Fri, May 23, 2025 at 02:56:40PM +0200, Christian König wrote:
> > > > It turned out that we can actually massively opt
On Fri, 2025-05-23 at 14:56 +0200, Christian König wrote:
> It turned out that we can actually massively optimize here.
>
> The previous code was horrible inefficient since it constantly
> released
> and re-acquired the lock of the xarray and started each iteration
> from the
> base of the array t
On Mon, 2025-05-26 at 14:54 +0200, Pierre-Eric Pelloux-Prayer wrote:
> Hi,
>
> The initial goal of this series was to improve the drm and amdgpu
> trace events to be able to expose more of the inner workings of
> the scheduler and drivers to developers via tools.
>
> Then, the series evolved to b
On Fri, 2025-06-13 at 10:23 +0200, Christian König wrote:
> On 6/13/25 01:48, Danilo Krummrich wrote:
> > On Thu, Jun 12, 2025 at 09:00:34AM +0200, Christian König wrote:
> > > On 6/11/25 17:11, Danilo Krummrich wrote:
> > > > > > > Mhm, reiterating our internal discussion on the mailing
> > > > >
eat the signaled check.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Danilo Krummrich
> Cc: Matthew Brost
> Cc: Philipp Stanner
This one can be sent separately, like the one for drm_sched_init()
recently, can't it?
P.
> ---
> drivers/gpu/drm/schedule
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Danilo Krummrich
> Cc: Matthew Brost
> Cc: Philipp Stanner
> ---
> drivers/gpu/drm/scheduler/sched_internal.h | 2 -
> drivers/gpu/drm/scheduler/sched_main.c | 132 ++-
> --
>
On Tue, 2025-07-08 at 14:02 +0100, Tvrtko Ursulin wrote:
>
>
> On 11/02/2025 11:14, Philipp Stanner wrote:
> > drm_sched_init() has a great many parameters and upcoming new
> > functionality for the scheduler might add even more. Generally, the
> > great number of par
On Tue, 2025-07-08 at 10:51 +0100, Tvrtko Ursulin wrote:
> Extract out two copies of the identical code to function epilogue to
> make
> it smaller and more readable.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Danilo Krummrich
> Cc: Matthew Brost
>
On Tue, 2025-07-08 at 13:21 +0100, Tvrtko Ursulin wrote:
> Extract out two copies of the identical code to function epilogue to
> make
> it smaller and more readable.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Danilo Krummrich
> Cc: Matthew Bros
double re-lock on the job free path".
>
> v5:
> * Rebase on top of latest upstream DRM scheduler changes.
> * Kerneldoc fixup.
> * Improve commit message justification for one patch. (Philipp)
> * Add comment in drm_sched_alloc_wq. (Christian)
>
> v6:
> * Rebas
t way the work item does not
optional nit:
s/to free/to be freed
Reads a bit more cleanly.
> have
> to lock the list again and repeat the signaled check.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Danilo Krummrich
> Cc: Matthew Brost
> Cc: Phi
nce, -ESRCH);
> WARN_ON(job->s_fence->parent);
> job->sched->ops->free_job(job);
> --
>
>
> Thanks,
> Lin
>
>
>
>
>
> From: Koenig, Christian
> Sent: Thursday, July 10, 2025 15:52
> To: cao, lin ; dri-de...@lists.freedesktop.org
>
; of more jobs to free to the caller. That way the work item does not
> > have
> > to lock the list again and repeat the signaled check.
> >
> > Signed-off-by: Tvrtko Ursulin
> > Cc: Christian König
> > Cc: Danilo Krummrich
> > Cc: Matthew Brost
> &g
On Fri, 2025-07-04 at 14:30 +0100, Tvrtko Ursulin wrote:
>
> On 04/07/2025 13:56, Philipp Stanner wrote:
> > On Fri, 2025-07-04 at 09:29 -0300, Maíra Canal wrote:
> > > Hi Tvrtko,
> > >
> > > On 23/06/25 09:27, Tvrtko Ursulin wrote:
> > > &g
On Mon, 2025-06-23 at 13:27 +0100, Tvrtko Ursulin wrote:
> Move work queue allocation into a helper for a more streamlined
> function
> body.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Danilo Krummrich
> Cc: Matthew Brost
> Cc: Philipp Stanne
On Tue, 2025-07-01 at 22:19 +0530, Sunil Khatri wrote:
> client-id is a unique id across the system no matter if its from a VM
> or on a host system. This unique id is a good base to use create
> client-id based dentry in debugfs in the root directory.
>
> This directory could be a unique director
gt; > > > in the
> > > > > > > queue we can simply add the signaled check and have it return the
> > > > > > > presence
> > > > > > > of more jobs to be freed to the caller. That way the work item
> > > > > > &g
On Fri, 2025-07-18 at 10:35 +0100, Tvrtko Ursulin wrote:
>
> On 18/07/2025 10:31, Philipp Stanner wrote:
> > On Fri, 2025-07-18 at 08:13 +0100, Tvrtko Ursulin wrote:
> > >
> > > On 16/07/2025 21:44, Maíra Canal wrote:
> > > > Hi Tvrtko,
> > >
gt; > loosely called random. Under the assumption it will not always be the
> > > same
> > > entity which is re-joining the queue under these circumstances.
> > >
> > > Another way to look at this is that it is adding a little bit of limited
> > > random
96 matches
Mail list logo
