[PATCH] drm/amdgpu: restore wait-free fastpath for GEM_WAIT_IDLE

unsignaled fences, which is not at all what userspace expects when it calls GEM_WAIT_IDLE with a timeout of 0. Signed-off-by: Lucas Stach --- This is most likely the correct kernel-side solution for the unexpected slowdown worked around with in userspace with this Mesa series: https://gitlab.freedeskto

Re: [PATCH] drm/amdgpu: restore wait-free fastpath for GEM_WAIT_IDLE

Hi Christian, Am Montag, dem 27.01.2025 um 17:14 +0100 schrieb Christian König: > Am 27.01.25 um 17:02 schrieb Lucas Stach: > > This effectively reverts 0fea2ed61e7f ("drm/amdgpu: Remove call to > > reservation_object_test_signaled_rcu before wait"), as the premise of

Re: [PATCH] drm/fourcc: add LINEAR modifiers with an exact pitch alignment

Am Montag, dem 16.12.2024 um 10:27 +0100 schrieb Michel Dänzer: > On 2024-12-15 21:53, Marek Olšák wrote: > > The comment explains the problem with DRM_FORMAT_MOD_LINEAR. > >     > > Signed-off-by: Marek Olšák > > > > > > diff --git a/include/uapi/drm/drm_fourcc.h b/in

Re: [PATCH 1/4] drm/scheduler: implement hardware time accounting

Hi Tvrtko, Am Dienstag, dem 02.07.2024 um 09:42 +0100 schrieb Tvrtko Ursulin: > Hi, > > I few questions below. > > On 01/07/2024 18:14, Lucas Stach wrote: > > From: Christian König > > > > Multiple drivers came up with the requirement to measure how > >

[PATCH 1/4] drm/scheduler: implement hardware time accounting

the other hand solves this task by keeping track of all the submissions and calculating how much time they have used on demand. Move this approach over into the scheduler to provide an easy to use interface for all drivers. Signed-off-by: Christian König Signed-off-by: Lucas Stach --- v2

[PATCH 3/4] drm/amdgpu: use new scheduler accounting

From: Christian König Instead of implementing this ourself. Signed-off-by: Christian König Signed-off-by: Lucas Stach --- v2: - rebased to v6.10-rc1 - adapted to match new function names --- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 52 - 1 file changed, 8 insertions

[PATCH 4/4] drm/etnaviv: export client GPU usage statistics via fdinfo

This exposes a accumulated GPU active time per client via the fdinfo infrastructure. Signed-off-by: Lucas Stach --- v2: - new patch --- drivers/gpu/drm/etnaviv/etnaviv_drv.c | 32 ++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/etnaviv

[PATCH 2/4] drm/amdgpu: mostly revert "fix force APP kill hang(v4)"

to amdgpu. Signed-off-by: Christian König Signed-off-by: Lucas Stach --- v2: - rebased to v6.10-rc1 --- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 59 ++--- drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h | 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2 +- 3 files changed, 5

Re: [PATCH 3/6] drm/amdgpu: Rework coredump to use memory dynamically

Sorry, accidentally hit sent on the previous mail. Am Mittwoch, dem 12.07.2023 um 12:39 +0200 schrieb Christian König: > Am 12.07.23 um 10:59 schrieb Lucas Stach: > > Am Mittwoch, dem 12.07.2023 um 10:37 +0200 schrieb Christian König: > > > Am 11.07.23 um 23:34 sch

Re: [PATCH 3/6] drm/amdgpu: Rework coredump to use memory dynamically

Am Mittwoch, dem 12.07.2023 um 12:39 +0200 schrieb Christian König: > Am 12.07.23 um 10:59 schrieb Lucas Stach: > > Am Mittwoch, dem 12.07.2023 um 10:37 +0200 schrieb Christian König: > > > Am 11.07.23 um 23:34 schrieb André Almeida: > > > > Instead of stori

Re: [PATCH 3/6] drm/amdgpu: Rework coredump to use memory dynamically

Am Mittwoch, dem 12.07.2023 um 10:37 +0200 schrieb Christian König: > Am 11.07.23 um 23:34 schrieb André Almeida: > > Instead of storing coredump information inside amdgpu_device struct, > > move if to a proper separated struct and allocate it dynamically. This > > will make it easier to further ex

Re: [PATCH v2] Revert "drm/scheduler: Avoid accessing freed bad job."

Hi all, and almost 2 years later I stumbled across this exact issue still being present in the scheduler: if the driver bails out of the timeout handling before calling drm_sched_stop(), the timeout job will be leaked and the TDR timer will potentially not be restarted as the job isn't put back in

Re: [PATCH 3/6] drm/etnaviv: stop getting the excl fence separately here

Am Donnerstag, dem 28.10.2021 um 15:26 +0200 schrieb Christian König: > Just grab all fences in one go. > > Signed-off-by: Christian König Reviewed-by: Lucas Stach > --- > drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH 1/1] drm/scheduler: Job timeout handler returns status (v2)

Hi Luben, Am Freitag, dem 11.12.2020 um 15:36 -0500 schrieb Luben Tuikov: > On 2020-12-10 4:31 a.m., Lucas Stach wrote: > > Hi Luben, > > > > Am Mittwoch, den 09.12.2020, 21:14 -0500 schrieb Luben Tuikov: > > > This patch does not change current behaviour. > &g

Re: [PATCH 1/1] drm/scheduler: Job timeout handler returns status (v2)

_ALIVE is returned, as > per the default behaviour. > > A more involved driver's solutions can be had > in subequent patches. > > v2: Use enum as the status of a driver's job >     timeout callback method. > > Cc: Alexander Deucher > Cc: Andrey Grodzov

Re: [PATCH 3/6] drm/scheduler: Job timeout handler returns status

Am Mittwoch, den 25.11.2020, 11:22 + schrieb Steven Price: > On 25/11/2020 11:15, Lucas Stach wrote: > > Am Mittwoch, den 25.11.2020, 11:04 + schrieb Steven Price: > > > On 25/11/2020 03:17, Luben Tuikov wrote: > > > > The job timeout handler now returns sta

Re: [PATCH 3/6] drm/scheduler: Job timeout handler returns status

Am Mittwoch, den 25.11.2020, 11:04 + schrieb Steven Price: > On 25/11/2020 03:17, Luben Tuikov wrote: > > The job timeout handler now returns status > > indicating back to the DRM layer whether the job > > was successfully cancelled or whether more time > > should be given to the job to complet

Re: [PATCH v3 03/22] drm/etnaviv: Introduce GEM object functions

which is non-trivial to convert. > > Signed-off-by: Thomas Zimmermann > Reviewed-by: Daniel Vetter Acked-by: Lucas Stach > --- > drivers/gpu/drm/etnaviv/etnaviv_drv.c | 13 - > drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 - > drivers/gpu/drm/etnaviv/etnaviv_gem.c |

Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

Hi Andrey, Am Mittwoch, den 12.02.2020, 11:33 -0500 schrieb Andrey Grodzovsky: > On 2/11/20 7:53 PM, Luben Tuikov wrote: > > On 2020-02-11 4:27 p.m., Andrey Grodzovsky wrote: > > > On 2/11/20 10:55 AM, Andrey Grodzovsky wrote: > > > > On 2/10/20 4:50 PM, Luben Tuikov wrote: > > > > > Hi Lucas, > >

Re: [PATCH] drm/ttm: Schedule out if possibe in bo delayed delete worker

Am Donnerstag, den 09.04.2020, 14:35 +0200 schrieb Christian König: > Am 09.04.20 um 03:31 schrieb xinhui pan: > > The delayed delete list is per device which might be very huge. And in > > a heavy workload test, the list might always not be empty. That will > > trigger any RCU stall warnings or so

latencies and code inefficiencies in amdgpu display handling

Hi guys, recently I've been tracing some IRQ latencies in a system and the display handling in amdgpu doesn't really look that good. To be honest it also doesn't look too bad, but I still want to share my findings here. The trace below is from a single vblank IRQ with a pageflip. The most interes

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

On Fr, 2020-02-28 at 10:47 +0100, Daniel Vetter wrote: > On Fri, Feb 28, 2020 at 10:29 AM Erik Faye-Lund > wrote: > > On Fri, 2020-02-28 at 13:37 +1000, Dave Airlie wrote: > > > On Fri, 28 Feb 2020 at 07:27, Daniel Vetter > > > wrote: > > > > Hi all, > > > > > > > > You might have read the short

Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

Hi all, On Mi, 2020-02-05 at 19:24 +0100, Lucas Stach wrote: > Hi Andrey, > > This commit breaks all drivers, which may bail out of the timeout > processing as they wish to extend the timeout (etnaviv, v3d). > > Those drivers currently just return from the timeout handle

Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

Hi Andrey, This commit breaks all drivers, which may bail out of the timeout processing as they wish to extend the timeout (etnaviv, v3d). Those drivers currently just return from the timeout handler before calling drm_sched_stop(), which means with this commit applied we are removing the first j

Re: [PATCH] drm/amd/display: Use msleep instead of udelay for 8ms wait

Hi Harry, Am Dienstag, den 25.06.2019, 10:00 -0400 schrieb Harry Wentland: > arm32's udelay only allows values up to 2000 microseconds. msleep > does the trick for us here as there is no problem if this isn't > microsecond accurate and takes a tad longer. A "tad" longer in this case means likely

Re: [PATCH v2] drm/scheduler: fix timeout worker setup for out of order job completions

Am Montag, den 06.08.2018, 10:12 +0200 schrieb Christian König: > Am 03.08.2018 um 19:31 schrieb Lucas Stach: > > Am Montag, den 06.08.2018, 14:57 +0200 schrieb Christian König: > > > Am 03.08.2018 um 16:29 schrieb Lucas Stach: > > > > drm_sched_job_finish() is

[PATCH v3] drm/scheduler: fix timeout worker setup for out of order job completions

g, so that we don't need to take the job list lock twice. As a small optimization list_del is used to remove the job from the ring mirror list, as there is no need to reinit the list head in the job we are about to free. Signed-off-by: Lucas Stach Reviewed-by: Christian König --- v2: - prope

Re: [PATCH v2] drm/scheduler: fix timeout worker setup for out of order job completions

Am Montag, den 06.08.2018, 14:57 +0200 schrieb Christian König: > Am 03.08.2018 um 16:29 schrieb Lucas Stach: > > drm_sched_job_finish() is a work item scheduled for each finished job on > > a unbound system workqueue. This means the workers can execute out of order > > wi

[PATCH v2] drm/scheduler: fix timeout worker setup for out of order job completions

g, so that we don't need to take the job list lock twice. As a small optimization list_del is used to remove the job from the ring mirror list, as there is no need to reinit the list head in the job we are about to free. Signed-off-by: Lucas Stach --- v2: - properly handle last job in the ring

Re: [PATCH] drm/scheduler: fix timeout worker setup for out of order job completions

rds, Lucas > Cheers, > Christian. > > Am 03.08.2018 um 15:18 schrieb Lucas Stach: > > drm_sched_job_finish() is a work item scheduled for each finished job on > > a unbound system workqueue. This means the workers can execute out of order > > with regard to the real hard

[PATCH] drm/scheduler: fix timeout worker setup for out of order job completions

g, so that we don't need to take the job list lock twice. As a small optimization list_del is used to remove the job from the ring mirror list, as there is no need to reinit the list head in the job we are about to free. Signed-off-by: Lucas Stach --- drivers/gpu/drm/scheduler/gpu_schedu

Re: [PATCH 3/3] drm/v3d: Add a note about locking of v3d_fence_create().

Am Dienstag, den 05.06.2018, 12:03 -0700 schrieb Eric Anholt: > This isn't the first time I've had to argue to myself why the '++' was > safe. And now you need to do the same thing with me... > Signed-off-by: Eric Anholt > --- >  drivers/gpu/drm/v3d/v3d_fence.c | 3 +++ >  1 file changed, 3 inser

Re: [PATCH 2/3] drm/v3d: Remove the bad signaled() implementation.

> enable_signaling() and thus DMA_FENCE_SIGNALED_BIT will be set before > we could be called. > > Signed-off-by: Eric Anholt Reviewed-by: Lucas Stach > --- >  drivers/gpu/drm/v3d/v3d_drv.h   |  1 - >  drivers/gpu/drm/v3d/v3d_fence.c | 13 - >  drivers/gpu/drm

Re: [PATCH 1/3 v2] drm/v3d: Take a lock across GPU scheduler job creation and queuing.

k to the error label. > > > Signed-off-by: Eric Anholt > Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D > V3.x+") Reviewed-by: Lucas Stach > --- >  drivers/gpu/drm/v3d/v3d_drv.h | 5 + >  drivers/gpu/drm/v3d/v3d_gem.c | 4 >  2 fil

Re: [PATCH 1/2] drm/scheduler: Rename cleanup functions.

to the opening parenthesis where it was previously aligned. I would prefer if the second line is also changed to keep the alignment. Acked-by: Lucas Stach ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 1/3] drm/v3d: Take a lock across GPU scheduler job creation and queuing.

Am Dienstag, den 05.06.2018, 12:03 -0700 schrieb Eric Anholt: > Between creation and queueing of a job, you need to prevent any other > job from being created and queued.  Otherwise the scheduler's fences > may be signaled out of seqno order. > > > Signed-off-by: Eric Anholt > Fixes: 57692c94dcbe

Re: [PATCH 2/2] drm/scheduler: Remove obsolete spinlock.

Am Mittwoch, den 16.05.2018, 15:10 +0200 schrieb Christian König: > Am 16.05.2018 um 15:00 schrieb Lucas Stach: > > Am Mittwoch, den 16.05.2018, 14:32 +0200 schrieb Christian König: > > > Am 16.05.2018 um 14:28 schrieb Lucas Stach: > > > > Am Mittwoch, den 16.05.2018,

Re: [PATCH 2/2] drm/scheduler: Remove obsolete spinlock.

Am Mittwoch, den 16.05.2018, 14:32 +0200 schrieb Christian König: > Am 16.05.2018 um 14:28 schrieb Lucas Stach: > > Am Mittwoch, den 16.05.2018, 14:08 +0200 schrieb Christian König: > > > Yes, exactly. > > > > > > For normal user space command submissio

Re: [PATCH 2/2] drm/scheduler: Remove obsolete spinlock.

Am Mittwoch, den 16.05.2018, 14:08 +0200 schrieb Christian König: > Yes, exactly. > > For normal user space command submission we should have tons of > locks  > guaranteeing that (e.g. just the VM lock should do). > > For kernel moves we have the mutex for the GTT windows which protects > it. >

Re: [PATCH 01/13] ttm: abstruct evictable bo

All of those changes are including a Change-Id that has no bearing in upstream patches and are missing a proper commit description explaining why a specific change is done. Regards, Lucas Am Mittwoch, den 09.05.2018, 14:45 +0800 schrieb Chunming Zhou: > Change-Id: Ie81985282fab1e564fc2948109fae21

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

Am Mittwoch, den 25.04.2018, 13:44 -0400 schrieb Alex Deucher: > On Wed, Apr 25, 2018 at 2:41 AM, Christoph Hellwig > wrote: > > On Wed, Apr 25, 2018 at 02:24:36AM -0400, Alex Deucher wrote: > > > > It has a non-coherent transaction mode (which the chipset can opt to > > > > not implement and stil

Re: [PATCH 1/2] drm/prime: Iterate SG DMA addresses separately

Am Donnerstag, den 12.04.2018, 11:35 +0200 schrieb Christian König: > Am 12.04.2018 um 11:11 schrieb Lucas Stach: > > Am Mittwoch, den 11.04.2018, 20:26 +0200 schrieb Christian König: > > > Am 11.04.2018 um 19:11 schrieb Robin Murphy: > > > > For dma_map_sg(), DMA A

Re: [PATCH 1/2] drm/prime: Iterate SG DMA addresses separately

Am Mittwoch, den 11.04.2018, 20:26 +0200 schrieb Christian König: > Am 11.04.2018 um 19:11 schrieb Robin Murphy: > > For dma_map_sg(), DMA API implementations are free to merge consecutive > > segments into a single DMA mapping if conditions are suitable, thus the > > resulting DMA addresses may be

Re: [RFC] Per file OOM badness

Am Mittwoch, den 04.04.2018, 11:09 +0200 schrieb Michel Dänzer: > On 2018-03-26 04:36 PM, Lucas Stach wrote: > > Am Dienstag, den 30.01.2018, 11:28 +0100 schrieb Michal Hocko: > > > On Tue 30-01-18 10:29:10, Michel Dänzer wrote: > > > > On 2018-01-24 12:50 PM, Michal

Re: [RFC] Per file OOM badness

Hi all, Am Dienstag, den 30.01.2018, 11:28 +0100 schrieb Michal Hocko: > On Tue 30-01-18 10:29:10, Michel Dänzer wrote: > > On 2018-01-24 12:50 PM, Michal Hocko wrote: > > > On Wed 24-01-18 12:23:10, Michel Dänzer wrote: > > > > On 2018-01-24 12:01 PM, Michal Hocko wrote: > > > > > On Wed 24-01-18

Re: [PATCH 1/5] drm/prime: fix potential race in drm_gem_map_detach

Hi Christian, Am Dienstag, den 27.02.2018, 12:49 +0100 schrieb Christian König: > Unpin the GEM object only after freeing the sg table. What is the race that is being fixed here? The SG table is private to the importer and the importer should hopefully only call map_detach if it is done with all

[PATCH v2 1/2] drm: move amd_gpu_scheduler into common location

the need to export the drm_sched_fence_ops_scheduled and drm_sched_fence_ops_finished structures. Signed-off-by: Lucas Stach --- drivers/gpu/drm/Kconfig| 5 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/amd/amdgpu/Makefile

[PATCH v2 0/2] AMDGPU scheduler move, take 2

rently, so I would be very happy to receive some tested-bys from the AMD side. Alex, if this looks good please pull this in so it gets your usual testing. Thanks, Lucas Lucas Stach (2): drm: move amd_gpu_scheduler into common location drm/sched: move fence slab handling to module init/exit d

[PATCH v2 2/2] drm/sched: move fence slab handling to module init/exit

This is the only part of the scheduler which must not be called from different drivers. Move it to module init/exit so it is done a single time when loading the scheduler. Signed-off-by: Lucas Stach --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 8 drivers/gpu/drm/scheduler

Re: [PATCH 0/2] Move scheduler out of AMDGPU

Hi Alex, Am Montag, den 04.12.2017, 16:47 -0500 schrieb Alex Deucher: > On Fri, Dec 1, 2017 at 10:55 AM, Christian König > > wrote: > > Am 01.12.2017 um 16:28 schrieb Lucas Stach: > > > > > > Hi all, > > > > > > so this is the first step to ma

Re: [PATCH 0/2] Move scheduler out of AMDGPU

r. Regards, Lucas > > -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On > Behalf Of Christian K?nig > Sent: Friday, December 1, 2017 11:55 PM > To: Lucas Stach ; Deucher, Alexander er.deuc...@amd.com> > Cc: Grodzovsky, Andr

Re: [PATCH 0/2] Move scheduler out of AMDGPU

Am Freitag, den 01.12.2017, 16:55 +0100 schrieb Christian König: > Am 01.12.2017 um 16:28 schrieb Lucas Stach: > > Hi all, > > > > so this is the first step to make the marvelous AMDGPU scheduler > > useable > > for other drivers. I have a (mostly) working proto

[PATCH 1/2] drm: move amd_gpu_scheduler into common location

the need to export the drm_sched_fence_ops_scheduled and drm_sched_fence_ops_finished structures. Signed-off-by: Lucas Stach --- drivers/gpu/drm/Kconfig| 5 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/amd/amdgpu/Makefile

[PATCH 0/2] Move scheduler out of AMDGPU

h and don't want to take people by surprise when the Etnaviv implementation surfaces. Also this might need some coordination between AMDGPU and Etnaviv, which might be good to get going now. Please speak up now if you have any objections or comments. Regards, Lucas Lucas Stach (2):

[PATCH 2/2] drm/sched: move fence slab handling to module init/exit

This is the only part of the scheduler which must not be called from different drivers. Move it to module init/exit so it is done a single time when loading the scheduler. Signed-off-by: Lucas Stach --- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 8 drivers/gpu/drm/scheduler