On Wed Jul 16, 2025 at 4:48 PM CEST, Tvrtko Ursulin wrote:
> Reduce to one spin_unlock for hopefully a little bit clearer flow in the
> function. It may appear that there is a behavioural change with the
> drm_sched_start_timeout_unlocked() now not being called if there were
> initially no jobs on
ned-off-by: Tvrtko Ursulin
Cc: Christian König
Cc: Danilo Krummrich
Cc: Matthew Brost
Cc: Philipp Stanner
---
v2:
* Improve commit text and kerneldoc. (Philipp)
* Rename run free work helper. (Philipp)
Maybe, would it be possible not to rename it? Otherwise, I won't be able
to
in
>> Cc: Christian König
>> Cc: Danilo Krummrich
>> Cc: Matthew Brost
>> Cc: Philipp Stanner
>
> Can also be branched out.
There seems to be something going on with your mail client. I saw it a couple of
times now that it somehow messes up the original c
On Wed, Jul 02, 2025 at 11:23:26AM +0200, Pierre-Eric Pelloux-Prayer wrote:
>
>
> Le 18/06/2025 à 11:18, Pierre-Eric Pelloux-Prayer a écrit :
> >
> >
> >
> > > >
> > > > Adding an API to reserve fixed numbers would work but:
> > > > * if the fixed numbers are chosen by the driver ("drm_reserv
On Fri, Jun 13, 2025 at 11:27:08AM +0200, Pierre-Eric Pelloux-Prayer wrote:
> Le 13/06/2025 à 10:35, Danilo Krummrich a écrit :
> > On Fri, Jun 13, 2025 at 10:23:15AM +0200, Christian König wrote:
> > > > Another option is to just add an interface to get a kernel client
On Fri, Jun 13, 2025 at 10:23:15AM +0200, Christian König wrote:
> > Another option is to just add an interface to get a kernel client_id from
> > the
> > same atomic / IDA.
>
> That won't give us fixed numbers for in kernel clients.
That's fine, then let's come up with an API that reserves fixe
On Fri, Jun 13, 2025 at 10:29:35AM +0200, Philipp Stanner wrote:
> Shouldn't the xarray be used nowadays for ID allocation? I think
> idr_alloc_cyclic() (ida_alloc_cyclic() doesn't exist) is just a wrapper
> around the xarray anyways.
Yes, IDR is basically xarray under the hood. But, a raw xarray
On Fri, Jun 13, 2025 at 09:51:27AM +0200, Pierre-Eric Pelloux-Prayer wrote:
> If the theoretical overlap with client drm id is a concern, adding code to
> drm_file_alloc() to not use the last 0xff ids would be easy.
Not the theoretical overlap is not of any concern for me. What I dislike is
driver
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 list.
> >>>>
> >>>> I think it would be nicer if we could use negative values
On Wed, Jun 11, 2025 at 04:57:50PM +0200, Christian König wrote:
> On 6/11/25 16:25, Danilo Krummrich wrote:
> > (Cc: dri-devel)
> >
> > On Tue, Jun 10, 2025 at 03:05:34PM +0200, Christian König wrote:
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
&
(Cc: dri-devel)
On Tue, Jun 10, 2025 at 03:05:34PM +0200, Christian König wrote:
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
> > index 5a8bc634..6108a6f9dba7 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
> > +++ b/drivers/g
On Wed, May 28, 2025 at 04:39:01PM +0200, Danilo Krummrich wrote:
> On Wed, May 28, 2025 at 09:29:30AM -0400, Alex Deucher wrote:
> > On Wed, May 28, 2025 at 8:45 AM Simona Vetter
> > wrote:
> > > I do occasionally find it useful as a record of different approaches
On Wed, May 28, 2025 at 09:29:30AM -0400, Alex Deucher wrote:
> On Wed, May 28, 2025 at 8:45 AM Simona Vetter wrote:
> > I do occasionally find it useful as a record of different approaches
> > considered, which sometimes people fail to adequately cover in their
> > commit messages. Also useful in
(Cc: Matthew)
Let's get this clarified to not work with assumptions. :)
On Mon, May 26, 2025 at 12:59:41PM +0200, Christian König wrote:
> On 5/24/25 13:17, Danilo Krummrich wrote:
> > On Fri, May 23, 2025 at 04:11:39PM +0200, Danilo Krummrich wrote:
> > So, your code he
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:
> > + if (xas_nomem(&xas, GFP_KERNEL)) {
> > + xa_lock(&job->dependencies);
> > + goto retry;
>
> Ple
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 optimize here.
> >
> > The previous code was horrible inefficient since it constantly release
On Fri, May 23, 2025 at 02:56:40PM +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 arra
On Tue, Mar 18, 2025 at 01:03:12PM +0100, Christian König wrote:
> /**
> * drm_sched_job_add_dependency - adds the fence as a job dependency
> * @job: scheduler job to add the dependencies to
> @@ -878,10 +910,12 @@ int drm_sched_job_add_dependency(struct drm_sched_job
> *job,
>* engi
e.
I think that's reasonable, in GPUVM we have a similar problem where we have to
preallocate in order to avoid allocations under a mutex used in the fence
signalling critical path.
Unfortunately, this even prevented us from using the maple tree, since it can't
preallocate for multip
> Acked-by: Matthew Brost # for Xe
> Reviewed-by: Boris Brezillon # for Panfrost
> and Panthor
> Reviewed-by: Christian Gmeiner # for Etnaviv
> Reviewed-by: Frank Binns # for Imagination
> Reviewed-by: Tvrtko Ursulin # for Sched
> Reviewed-by: Maíra Canal # for v3d
Reviewed-by: Danilo Krummrich
bytes */
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Danilo Krummrich
> Cc: Matthew Brost
> Cc: Philipp Stanner
> ---
> include/drm/gpu_scheduler.h | 38 +++--
> 1 file changed, 20 insertions(+), 18 deletions
eader file for internal scheduler API.
* Add helper for peeking too. (Danilo)
* Add (temporary?) drm_sched_cancel_all_jobs() helper to replace amdgpu
amdgpu_job_stop_all_jobs_on_sched().
v3:
* Settle for a copy of __drm_sched_entity_queue_pop in amdgpu for now.
Cc: Christian König
Cc: D
ons 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_internal.h | 43 +++
On Thu, Feb 06, 2025 at 02:46:40PM +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
> > > with the purpose of reducing the
On Wed, Jan 29, 2025 at 04:18:30PM +0100, Philipp Stanner wrote:
> 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:
> > > diff --git a/drivers/gpu/drm/nouveau/nouveau_sched.c
> > >
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 number of parameters reduces readability and has already caused
> one missnaming in:
>
> co
On Thu, Jan 23, 2025 at 10:35:43AM +0100, Philipp Stanner wrote:
> 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 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:
> >
> > > int drm_sched_init(struct drm_gpu_scheduler *sched,
> > > - const struct drm_sched_backend_o
On Wed, Jan 22, 2025 at 03:08:20PM +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 in:
>
> co
ce this is not documented it can be very fragile so lets
> just remove the internal helper and explicitly check for "nothing
> dequeued", before converting the node to a sched job.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Danilo Krummrich
to adding this function if it's *only* used for something that looks
like an abuse of the API by amdgpu. Let's not make that more convenient.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Christian König
> Cc: Danilo Krummrich
> Cc: Matthew Brost
> Cc: Philipp Stanne
lable video memory, with a default of 32. Adapt this for
the new client interface.
Signed-off-by: Thomas Zimmermann
Acked-by: Danilo Krummrich
Cc: Karol Herbst
Cc: Lyude Paul
Cc: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 7 +--
1 file changed, 5 insertions(
On 8/12/24 2:34 PM, Thomas Zimmermann wrote:
Hi
Am 12.08.24 um 14:17 schrieb Danilo Krummrich:
On 8/12/24 10:28 AM, Thomas Zimmermann wrote:
Replace the call to drm_fb_helper_output_poll_changed() with a call
to drm_client_dev_hotplug(). It is equivalent in functionality, but
uses the DRM
: Daniel Vetter
Acked-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_vga.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index ee637f1fe03d..ab4e11dc0b8a 100644
--- a/drivers/gpu
Vetter
Acked-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 1 -
drivers/gpu/drm/nouveau/nouveau_display.c | 1 -
2 files changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index e4c8ce6dd40a
Signed-off-by: Thomas Zimmermann
Acked-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 1 -
drivers/gpu/drm/nouveau/nouveau_vga.c | 7 ---
drivers/gpu/drm/nouveau/nouveau_vga.h | 1 -
3 files changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
b
Hi Easwar,
On 3/29/24 18:00, Easwar Hariharan wrote:
I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
with more appropriate terms. Inspired by and following on to Wolfram's
series to fix drivers/i2c/[1], fix the terminology for users of
I2C_ALGOBIT bitbanging interface, now
comments and a
helper for lock arrays of GEM objects.
Signed-off-by: Christian König
Reviewed-by: Danilo Krummrich
---
Documentation/gpu/drm-mm.rst | 12 ++
drivers/gpu/drm/Kconfig | 6 +
drivers/gpu/drm/Makefile | 2 +
drivers/gpu/drm/drm_exec.c | 278
On 2/28/23 09:33, Christian König wrote:
This adds the infrastructure for an execution context for GEM buffers
which is similar to the existinc TTMs execbuf util and intended to replace
"existing"
it in the long term.
The basic functionality is that we abstracts the necessary loop to lock
ma
Hi Christian,
On 2/28/23 09:33, Christian König wrote:
Hi guys,
thrid round for those patches. They have been in my queue for nearly a
year now because I couldn't find much time to push into this.
Danilo wants to use this for his GPU VAs tracker work and Arun needs it
for hist secure semaphore
40 matches
Mail list logo
