(-cc some unrelated people)
On Mon, 2025-01-13 at 13:18 +0100, Philipp Stanner wrote:
> Luben has not been active and has not responded to mails since summer
> 2024. Remove him from MAINTAINERS and add an entry in CREDITS.
>
> Philipp has a new email address and an ACK to commit work
rk and helpers which queue the work check for the flag so all
> should be
> good.
>
> Signed-off-by: Tvrtko Ursulin
Ah yes, good catch.
Applied to drm-misc-next, thanks.
> Cc: Christian König
> Cc: Danilo Krummrich
> Cc: Matthew Brost
> Cc: Philipp Stanner
btw. F
On Mon, 2025-01-13 at 10:33 +, Tvrtko Ursulin wrote:
> Instead of manually peeking into the DRM scheduler implementation
> details
> lets use the previously added helper.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Danilo Krummrich
> Cc: Matt
On Mon, 2025-01-13 at 13:24 +0100, Christian König wrote:
> Am 13.01.25 um 13:18 schrieb Philipp Stanner:
> > Christian König is the original author of much of the scheduler's
> > code
> > and, thus, well suited to do reviews.
> >
> > Cc: Matthew Brost
>
Krummrich
Signed-off-by: Philipp Stanner
---
CREDITS | 4
MAINTAINERS | 5 ++---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/CREDITS b/CREDITS
index cda68f04d5f1..1593ada4209c 100644
--- a/CREDITS
+++ b/CREDITS
@@ -3948,6 +3948,10 @@ S: 1 Amherst Street
S: Cambridge, Mas
Christian König is the original author of much of the scheduler's code
and, thus, well suited to do reviews.
Cc: Matthew Brost
Cc: Danilo Krummrich
Cc: Christian König
Signed-off-by: Philipp Stanner
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTA
On Thu, 2025-01-09 at 15:01 +0100, Christian König wrote:
> Am 09.01.25 um 14:37 schrieb Philipp Stanner:
> > From: Philipp Stanner
> >
> > drm_sched_backend_ops.run_job() returns a dma_fence for the
> > scheduler.
> > That fence is signalled by the driver on
On Fri, 2025-01-10 at 11:13 +, Tvrtko Ursulin wrote:
> No driver is using the update_job_credits() schduler vfunc
> so lets remove it.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Danilo Krummrich
> Cc: Matthew Brost
> Cc: Philipp Stanner
>
+cc Danilo
+cc myself
On Wed, 2025-01-08 at 09:19 +0100, Christian König wrote:
> Am 07.01.25 um 16:21 schrieb Philipp Reisner:
> > [...]
> > > > The OOPS happens because the rq member of entity is NULL in
> > > > drm_sched_job_arm() after the call to
> > > > drm_sched_entity_select_rq().
> > > >
On Thu, 2025-01-09 at 15:30 +0100, Danilo Krummrich wrote:
> On Thu, Jan 09, 2025 at 02:37:10PM +0100, Philipp Stanner wrote:
> > From: Philipp Stanner
> >
> > drm_sched_backend_ops.run_job() returns a dma_fence for the
> > scheduler.
> > That fence is signalle
On Thu, 2025-01-09 at 13:44 +, Tvrtko Ursulin wrote:
>
> On 09/01/2025 13:37, Philipp Stanner wrote:
> > From: Philipp Stanner
> >
> > drm_sched_backend_ops.run_job() returns a dma_fence for the
> > scheduler.
> > That fence is signalled by the driver
ndles.
Signed-off-by: Philipp Stanner
---
include/drm/gpu_scheduler.h | 83 +++--
1 file changed, 52 insertions(+), 31 deletions(-)
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index c4e65f9f7f22..380b8840c591 100644
--- a/includ
e the behavior of drm_sched_backend_ops.run_job() being called
multiple times for the same job.
Signed-off-by: Philipp Stanner
---
include/drm/gpu_scheduler.h | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
From: Philipp Stanner
drm_sched_backend_ops.run_job() returns a dma_fence for the scheduler.
That fence is signalled by the driver once the hardware completed the
associated job. The scheduler does not increment the reference count on
that fence, but implicitly expects to inherit this fence from
feedback, especially on the RFC comments in patch3.
(This series still fires docu-build-warnings. I want to gather feedback
on the opion questions first and will solve them in v2.)
Thank you,
Philipp
[1] https://lore.kernel.org/all/20241220124515.93169-2-pha...@kernel.org/
Philipp Stanner (3
On Wed, 2024-12-11 at 12:00 +0100, Philipp Stanner wrote:
> Hi Luben,
>
> haven't seen you in a while on-list. Are you still up to maintaining
> the GPU Scheduler? You're still on the MAINTAINERS file.
*ping*
>
> Greetings,
> Philipp
An: dri-devel@lists.freedesktop.org
> > Cc: kernel-...@igalia.com; Tvrtko Ursulin; Koenig, Christian;
> > Danilo Krummrich; Matthew Brost; Philipp Stanner
> > Betreff: [RFC 00/14] Deadline scheduler and other ideas
> >
> > From: Tvrtko Ursulin
> >
> >
>
gt; > > noticed userspace already uses it so why not wire it up fully.
> > >
> > > Userspace uses the dma-fence deadlines you mean? Do you have a
> > > pointer
> > > for us?
> >
> > I've noticed it empirically and the one I could fine is this:
> >
On Fri, 2025-01-03 at 12:40 +, Tvrtko Ursulin wrote:
>
> On 02/01/2025 13:11, Philipp Stanner wrote:
> > On Mon, 2024-12-30 at 16:52 +, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > Deadline scheduling policy should be a fair
g on b) right now: Have you seen it in the wild that high
priorities starve lower ones? Is that a problem already?
I assume you have been working on that for a reason – do you have a
usecase in amdgpu or similar where the deadline policy improves things
in a way?
P.
>
> Sig
ven
> better if other drivers could give it a spin as is and see if some
> improvements
> can be detected. Or at least no regressions.
I hope I can dive deeper into the Nouveau side soon.
>
> Cc: Christian König
> Cc: Danilo Krummrich
> Cc: Matthew Brost
> Cc: Philipp
On Mon, 2024-12-30 at 11:25 +0100, Philipp Stanner wrote:
> On Fri, 2024-12-20 at 13:53 +0100, Christian König wrote:
> > Am 20.12.24 um 13:45 schrieb Philipp Stanner:
> > > From: Philipp Stanner
> > >
> > > drm_sched_backend_ops.run_job() returns a dma_fence
On Fri, 2024-12-20 at 13:53 +0100, Christian König wrote:
> Am 20.12.24 um 13:45 schrieb Philipp Stanner:
> > From: Philipp Stanner
> >
> > drm_sched_backend_ops.run_job() returns a dma_fence for the
> > scheduler.
> > That fence is signalled by the driver on
On Fri, 2024-12-20 at 14:25 +0100, Christian König wrote:
> Am 20.12.24 um 14:18 schrieb Danilo Krummrich:
> > On Fri, Dec 20, 2024 at 01:53:34PM +0100, Christian König wrote:
> > > Am 20.12.24 um 13:45 schrieb Philipp Stanner:
> > &
From: Philipp Stanner
drm_sched_backend_ops.run_job() returns a dma_fence for the scheduler.
That fence is signalled by the driver once the hardware completed the
associated job. The scheduler does not increment the reference count on
that fence, but implicitly expects to inherit this fence from
On Tue, 2024-12-17 at 10:49 +0700, Bagas Sanjaya wrote:
> Commit baf4afc5831438 ("drm/sched: Improve teardown documentation")
> documents drm_sched_fini() with a post-function call checklist for
> drivers. The checklist triggers htmldocs warning (but renders
> correctly
> in htmldocs output):
>
>
> 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
Hi Luben,
haven't seen you in a while on-list. Are you still up to maintaining
the GPU Scheduler? You're still on the MAINTAINERS file.
Greetings,
Philipp
On Thu, 2024-11-21 at 17:05 +0100, Alice Ryhl wrote:
> On Fri, Nov 15, 2024 at 11:36 AM Philipp Stanner
> wrote:
> >
> > The various objects defined and used by the GPU scheduler are
> > currently
> > not fully documented. Furthermore, there is no documentation y
lsdc currently just ioremaps its PCI BAR with pcim_iomap(). Performing
a region regquest additionally can make the driver more robust.
Replace pcim_iomap() with the managed function pcim_iomap_region() which
performs the request and ioremaps the BAR.
Signed-off-by: Philipp Stanner
Reviewed-by
On Wed, 2024-09-18 at 15:39 +0200, Christian König wrote:
> Sima requested that in a discussion, just copy&paste my explanation
> from
> the mail.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/scheduler/sched_entity.c | 17 +++--
> 1 file changed, 15 insertions(+), 2 del
On Thu, 2024-11-21 at 10:05 -0800, Matthew Brost wrote:
> On Tue, Oct 29, 2024 at 08:22:22AM +0100, Philipp Stanner wrote:
> > Christian, Sima?
> >
> > Matthew? (+CC)
> >
>
> Sorry catching up here. Internally in Xe we ref count the scheduler
> as
> the sc
+CC Thomas Hellström
On Mon, 2024-11-18 at 12:48 +0100, Christian König wrote:
> Am 15.11.24 um 17:07 schrieb Philipp Stanner:
>
> >
> > On Fri, 2024-11-15 at 15:39 +0100, Christian König wrote:
> >
> > >
> > > Am
On Thu, 2024-10-17 at 14:51 +0200, Philipp Stanner wrote:
> bochs uses pcim_enable_device(), which causes pci_request_region() to
> implicitly set up devres callbacks which will release the region on
> driver detach. Despite this, the driver calls pci_release_regions()
> manual
wait_event_timeout() doesn't always
return the remaining timeout time.
Adjust the function so that it actually does what the documentation
states it shall do.
Cc: Christian König
Signed-off-by: Philipp Stanner
---
@AMD:
You guys are the only ones who use the function's return code, so
On Tue, 2024-11-19 at 15:27 +0100, Christian König wrote:
> Am 19.11.24 um 14:41 schrieb Philipp Stanner:
> > drm_sched_entity_flush()'s documentation states that an error is
> > being
> > returned when "the process was killed". That is not wha
On Tue, 2024-11-19 at 14:41 +0100, Philipp Stanner wrote:
> The documentation of drm_sched_entity_flush() states that the
> function
> shall - always - return the remaining timeout time in jiffies.
>
> However, that is not what the function actually does; in one of its
> if
&g
at statement to drm_sched_entity_destroy().
Correct drm_sched_entity_flush()'s documentation.
Cc: Christian König
Signed-off-by: Philipp Stanner
---
drivers/gpu/drm/scheduler/sched_entity.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/schedul
On Fri, 2024-11-15 at 15:39 +0100, Christian König wrote:
> Am 15.11.24 um 14:55 schrieb Philipp Stanner:
>
> > [SNIP]
> > >
> > > A good bunch of the problems we have here are caused by abusing
> > > the
> > > job
> > &
On Thu, 2024-11-14 at 12:30 +0100, Lucas Stach wrote:
> Hi,
>
> Am Donnerstag, dem 14.11.2024 um 11:01 +0100 schrieb Pierre-Eric
> Pelloux-Prayer:
> > This commit adds a document section in drm-uapi.rst about
> > tracepoints,
> > and mark the events gpu_scheduler_trace.h as stable uAPI.
> >
> > T
On Thu, 2024-11-14 at 11:01 +0100, Pierre-Eric Pelloux-Prayer wrote:
> A fence uniquely identify a job, so this commits updates the places
s/identify/identifies
> where a kernel pointer was used as an identifier by:
But better sth like this:
"Currently, the scheduler's tracing infrastructure us
On Thu, 2024-11-14 at 11:01 +0100, Pierre-Eric Pelloux-Prayer wrote:
> Until the switch from kthread to workqueue,
Could you include the commit ID here where that happened?
"Since switching the scheduler from using kthreads to workqueues in
commit 1234 ("foo: bar") userspace applications cannot
On Thu, 2024-11-14 at 11:01 +0100, 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.
I think this commit message should detail what the patch is actual
intended to do.
Especially, it should mention that
On Thu, 2024-11-14 at 11:01 +0100, Pierre-Eric Pelloux-Prayer wrote:
> client_id is a unique id used by fdinfo. Having it listed in
> 'clients'
> output means a userspace application can correlate the fields, eg:
> given a fdinfo id get the fdinfo name.
>
> Signed-off-by: Pierre-Eric Pelloux-Praye
On Fri, 2024-11-15 at 12:26 +0100, Christian König wrote:
> Interesting, those mails just showed up in my inbox as unread. More
> than
> 14 days after you send it.
>
> So sorry for the late reply.
I smell google mail :p
>
> Am 29.10.24 um 08:22 schrieb Philipp Stanner
pdate drm_sched_backend_ops.timedout_job()'s
documentation.
Co-developed-by: Christian König
Signed-off-by: Christian König
Signed-off-by: Philipp Stanner
---
I shamelessly stole- ahm, borrowed this documentation patch that
Christian had submitted a year ago:
https://lore.kernel.org
On Thu, 2024-11-14 at 11:01 +0100, Pierre-Eric Pelloux-Prayer wrote:
> Hi,
>
Hi,
I have only just discovered this thread; Danilo and I (we're
maintainers of the scheduler since early October) seem to miss on CC.
Do you use scripts/get_maintainer?
I'll look into this series soonish.
Regards,
P.
On Tue, 2024-11-12 at 12:08 -0800, Matthew Brost wrote:
> On Tue, Nov 12, 2024 at 10:06:21AM +0100, Philipp Stanner wrote:
> > Hi Matt,
> >
> > On Sat, 2024-11-09 at 09:29 -0800, Matthew Brost wrote:
> > > Follow the semantics of DMA_RESV_USAGE_PREEMPT in th
On Mon, 2024-11-11 at 13:41 +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> The upper layer transfer functions expect EBUSY as a return
> for when retries should be done.
>
> Fix the AUX error translation, but also check for both errors
> in a few places.
>
> Fixes: eb284f4b3781 ("drm/nouveau
On Tue, 2024-11-12 at 13:36 +0100, Christian König wrote:
> Gentle ping.
>
> Dave Philip noted in private chat that you had some comments? I don't
> see anything in my inbox.
Hi,
that was a misunderstanding – Dave answered on this one:
https://lore.kernel.org/all/CAPM=9tzacady1qn_wmaz_wp3n_pfta
> semantics, pipeline preemptive fences by enabling signaling on all
> preemptive fences before waiting on any of them.
the commit message lacks the *motivation*. Why is the current state a
problem, why is that feature needed etc.
>
> Cc: Philipp Stanner
> Cc: Danilo Krummrich
>
On Tue, 2024-11-05 at 15:31 +0100, Philipp Stanner wrote:
> If jobs are still enqueued in struct drm_gpu_scheduler.pending_list
> when drm_sched_fini() gets called, those jobs will be leaked since
> that
> function stops both job-submission and (automatic) job-cleanup. It
> is,
&g
automatic cleanup.
Signed-off-by: Philipp Stanner
---
Hi,
in our discussion about my proposed waitque-cleanup for this problem
Sima suggested [1] that we document the problems first and by doing so get
to a consenus what the problems actually are and how we could solve
them.
This is my proposal
On Tue, 2024-10-29 at 09:47 -0400, Alex Deucher wrote:
> On Tue, Oct 29, 2024 at 9:39 AM Philipp Stanner
> wrote:
> >
> > drm_sched_start()'s and drm_sched_stop()'s names suggest that those
> > functions might be intended for actively starting and stopping the
&
to prevent confusion.
Document those functions' purpose.
Signed-off-by: Philipp Stanner
---
drivers/gpu/drm/scheduler/sched_main.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
ind
4:07 +0200, Philipp Stanner wrote:
> On Mon, 2024-10-14 at 16:56 +0200, Danilo Krummrich wrote:
> > On Fri, Sep 27, 2024 at 11:04:48AM +0200, Christian König wrote:
> > > Am 25.09.24 um 16:53 schrieb Philipp Stanner:
> > > > On Tue, 2024-09-24 at 13:18 +0200, Simona Vetter wro
On Fri, 2024-10-25 at 02:32 +, Matthew Brost wrote:
> On Wed, Oct 23, 2024 at 04:15:31PM +0200, Philipp Stanner wrote:
> > drm_sched_job_init()'s name suggests that after the function
> > succeeded,
> > parameter "job" will be fully initialized. This is no
On Thu, 2024-10-24 at 15:47 +, Matthew Brost wrote:
> On Thu, Oct 24, 2024 at 05:35:47PM +0200, Philipp Stanner wrote:
> > On Wed, 2024-10-23 at 16:59 -0700, Matthew Brost wrote:
> > > drm_gpu_scheduler.submit_wq is used to submit jobs, jobs are in
> > > the
> >
; reclaim; without WQ_MEM_RECLAIM, work queues cannot make forward
> progress during reclaim.
>
> v2:
> - Fixes tags (Philipp)
> - Reword commit message (Philipp)
>
> Cc: Luben Tuikov
> Cc: Danilo Krummrich
> Cc: Philipp Stanner
> Cc: sta...@vger.kernel.org
> Fix
struct members.
Document the lifetime of drm_sched_job.sched.
Signed-off-by: Philipp Stanner
---
drivers/gpu/drm/scheduler/sched_main.c | 4
include/drm/gpu_scheduler.h| 8
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gp
On Tue, 2024-10-22 at 18:11 +, Matthew Brost wrote:
> On Tue, Oct 22, 2024 at 04:19:18PM +0200, Philipp Stanner wrote:
> > On Mon, 2024-10-21 at 10:57 -0700, Matthew Brost wrote:
> > > DRM scheduler work queues are used to submit jobs, jobs are in
> > > the
> >
opinion?
>
> Cc: Luben Tuikov
btw., how did you send this email? I couldn't find Luben on CC. Added
him.
Thx,
P.
> Cc: Danilo Krummrich
> Cc: Philipp Stanner
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 4 ++--
> 1 file chang
On Mon, 2024-10-21 at 15:05 +0200, Christian König wrote:
> Am 21.10.24 um 12:50 schrieb Philipp Stanner:
> > drm_sched_job_init() has no control over how users allocate struct
> > drm_sched_job. Unfortunately, the function can also not set some
> > struct
> >
ruct members.
Document that job->sched in particular is uninitialized before
drm_sched_job_arm().
Signed-off-by: Philipp Stanner
---
Changes in v2:
- Change grammar in the new comments a bit.
---
drivers/gpu/drm/scheduler/sched_main.c | 4
include/drm/gpu_scheduler.h|
bug such issues if these pointers are initialized to
NULL, so dereferencing them causes a NULL pointer exception.
Accordingly, drm_sched_entity_init() does precisely that and initializes
its struct with memset().
Initialize parameter "job" to 0 in drm_sched_job_init().
Signed-off-by: Phili
lsdc currently just ioremaps its PCI BAR with pcim_iomap(). Performing
a region regquest additionally can make the driver more robust.
Replace pcim_iomap() with the managed function pcim_iomap_region() which
performs the request and ioremaps the BAR.
Signed-off-by: Philipp Stanner
---
drivers
On Mon, 2024-10-14 at 16:56 +0200, Danilo Krummrich wrote:
> On Fri, Sep 27, 2024 at 11:04:48AM +0200, Christian König wrote:
> > Am 25.09.24 um 16:53 schrieb Philipp Stanner:
> > > On Tue, 2024-09-24 at 13:18 +0200, Simona Vetter wrote:
> > > > On Mon, Sep 23, 2024
81fcf28e74a3 ("PCI:
Document hybrid devres hazards").
Replace the calls to pci_request_region() with ones to always-managed
pcim_request_region(). Remove the unnecessary call to
pci_release_regions().
Signed-off-by: Philipp Stanner
---
drivers/gpu/drm/tiny/bochs.c | 6 +++---
1 file changed, 3
> two spin
> lock-unlock cycles are removed from the push job path by pulling
> taking of the
> locks one level up.
>
> I smoke tested it on the Steam Deck and lockdep seems happy.
>
> v2:
> * Tweaks to commit messages and rename of some leftover rq_lock
> naming ins
ore obvious what the lock
> protects.
>
> v2:
> * Rename some rq_lock straddlers in kerneldoc, improve commit text.
> (Philipp)
>
> Signed-off-by: Tvrtko Ursulin
> Suggested-by: Christian König
> Cc: Alex Deucher
> Cc: Luben Tuikov
> Cc: Matthew Brost
> Cc: Phil
On Wed, 2024-10-16 at 08:41 +0100, Tvrtko Ursulin wrote:
>
> On 15/10/2024 15:00, Philipp Stanner wrote:
> > > [...]
> > > How about this:
> > >
> > > """
> > > In FIFO mode (which is the default), both
> > > drm_sch
On Tue, 2024-10-15 at 14:14 +0100, Tvrtko Ursulin wrote:
>
> On 15/10/2024 12:38, Philipp Stanner wrote:
> > On Tue, 2024-10-15 at 09:12 +0100, Tvrtko Ursulin wrote:
> > >
> > > On 15/10/2024 08:11, Philipp Stanner wrote:
> > > > On Mon, 2024-
make it more obvious what the lock
protects.
> And to also re-order the structure members so all
> protected by the lock are together in a block.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Alex Deucher
> Cc: Luben Tuikov
> Cc: Matthew Brost
>
On Tue, 2024-10-15 at 09:12 +0100, Tvrtko Ursulin wrote:
>
> On 15/10/2024 08:11, Philipp Stanner wrote:
> > On Mon, 2024-10-14 at 13:07 +0100, Tvrtko Ursulin wrote:
> > >
> > > On 14/10/2024 12:32, Philipp Stanner wrote:
> > > > Hi,
> > > &
On Mon, 2024-10-14 at 13:07 +0100, Tvrtko Ursulin wrote:
>
> On 14/10/2024 12:32, Philipp Stanner wrote:
> > Hi,
> >
> > On Mon, 2024-10-14 at 11:46 +0100, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > In FIFO mode We can a
Thx
P.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Alex Deucher
> Cc: Luben Tuikov
> Cc: Matthew Brost
> Cc: Philipp Stanner
> Acked-by: Christian König
> Reviewed-by: Philipp Stanner
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 1 -
>
the other patches, too.
[1]
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#describe-your-changes
> v2:
> * Remove drm_sched_rq_update_fifo() altogether. (Christian)
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Alex Deucher
> Cc:
; > 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
ndividually, but in generally will take care of that.
P.
>
> >
> > Best Regards
> > Shuicheng
> >
> > > -Original Message-
> > > From: Lin, Shuicheng
> > > Sent: Tuesday, September 17, 2024 7:48 AM
> > > To: dri-devel@l
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
On Tue, 2024-09-24 at 13:18 +0200, Simona Vetter wrote:
> On Mon, Sep 23, 2024 at 05:24:10PM +0200, Christian König wrote:
> > Am 20.09.24 um 15:26 schrieb Philipp Stanner:
> > > On Fri, 2024-09-20 at 12:33 +0200, Christian König wrote:
> > > > Am 20.09.24 um
On Fri, 2024-09-20 at 12:33 +0200, Christian König wrote:
> Am 20.09.24 um 10:57 schrieb Philipp Stanner:
> > On Wed, 2024-09-18 at 15:39 +0200, Christian König wrote:
> > > Tearing down the scheduler with jobs still on the pending list
> > > can
> > > lead to
On Wed, 2024-09-18 at 15:39 +0200, Christian König wrote:
> Tearing down the scheduler with jobs still on the pending list can
> lead to use after free issues. Add a warning if drivers try to
> destroy a scheduler which still has work pushed to the HW.
Did you have time yet to look into my propose
ection with related comments.
>
> Signed-off-by: Shuicheng Lin
Except for the nit above, looks good to me:
Reviewed-by: Philipp Stanner
Thx
> Cc: Philipp Stanner
> ---
> drivers/gpu/drm/scheduler/sched_entity.c | 10 --
> drivers/gpu/drm/scheduler/sched_mai
DRM's GPU scheduler is arguably in need of more intensive maintenance.
Danilo and Philipp volunteer to help with the maintainership.
Signed-off-by: Philipp Stanner
Cc: Christian König
Cc: Luben Tuikov
Cc: Matthew Brost
Cc: Danilo Krummrich
Cc: Tvrtko Ursulin
---
MAINTAINERS | 2 ++
1
Hi,
I would call the commit "drm/scheduler: Improve documentation"
On Sun, 2024-09-15 at 15:52 +, Shuicheng Lin wrote:
> function drm_sched_entity_push_job doesn't have return value,
s/function/Function
It's also nice to always terminate a function's name with its
parenthesis: drm_sched_ent
On Fri, 2024-09-13 at 09:53 -0700, Rob Clark wrote:
> From: Rob Clark
>
> Fixes a race condition reported here:
> https://github.com/AsahiLinux/linux/issues/309#issuecomment-2238968609
As Danilo suggested before, I'd put this in a Fixes: section at the
bottom and instead have a sentence here det
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, 2024-09-13 at 12:56 +0100, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 28/08/2024 10:41, Philipp Stanner wrote:
> > drm_sched_job_init() has no control over how users allocate struct
> > drm_sched_job. Unfortunately, the function can also not set some
> > struct
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-&
Hi everyone,
it seemed to me in recent weeks that the GPU Scheduler is not that
actively maintained.
At least I haven't seen Luben posting that much, and a trivial patch of
mine [1] has been pending for a while now. We also didn't have that
much discussion yet about looking deeper into the schedu
On Thu, 2024-09-12 at 16:55 +0200, Christian König wrote:
> Am 11.09.24 um 11:44 schrieb Philipp Stanner:
> > On Wed, 2024-09-11 at 10:58 +0200, Christian König wrote:
> > > Calling the signaling a NULL fence is obviously a coding error in
> > > a
> > > driver
On Wed, 2024-09-11 at 10:58 +0200, Christian König wrote:
> Calling the signaling a NULL fence is obviously a coding error in a
> driver. Those functions unfortunately just returned silently without
> raising a warning.
Good catch
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-
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
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/
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
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
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
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 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
> &
1 - 100 of 313 matches
Mail list logo
