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

On Fri, Feb 28, 2020 at 12:48 AM Dave Airlie wrote: > > On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote: > > > > On Fri, 28 Feb 2020 at 03:38, Dave Airlie wrote: > > > b) we probably need to take a large step back here. > > > > > > Look at this from a sponsor POV, why would I give X.org/fd.o >

Re: [PATCH v3 1/5] drm/scheduler: rework job destruction

Andrey Grodzovsky writes: > From: Christian König > > We now destroy finished jobs from the worker thread to make sure that > we never destroy a job currently in timeout processing. > By this we avoid holding lock around ring mirror list in drm_sched_stop > which should solve a deadlock

Re: [PATCH] drm/v3d: Fix calling drm_sched_resubmit_jobs for same sched.

"Grodzovsky, Andrey" writes: > On 3/13/19 12:13 PM, Eric Anholt wrote: >> "Grodzovsky, Andrey" writes: >> >>> They are not the same, but the guilty job belongs to only one {entity, >>> scheduler} pair and so we mark as guilty only for that p

Re: [PATCH] drm/v3d: Fix calling drm_sched_resubmit_jobs for same sched.

"Grodzovsky, Andrey" writes: > They are not the same, but the guilty job belongs to only one {entity, > scheduler} pair and so we mark as guilty only for that particular > entity in the context of that scheduler only once. I get it now, sorry. I'll merge this through drm-misc-next.

Re: [PATCH] drm/v3d: Fix calling drm_sched_resubmit_jobs for same sched.

Andrey Grodzovsky writes: > Also stop calling drm_sched_increase_karma multiple times. Each v3d->queue[q].sched was initialized with a separate drm_sched_init(). I wouldn't have thought they were all the "same sched". signature.asc Description: PGP signature

Re: [PATCH] drm/sched: Always trace the dependencies we wait on, to fix a race.

"Koenig, Christian" writes: > Am 07.12.18 um 20:16 schrieb Eric Anholt: >> The entity->dependency can go away completely once we've called >> drm_sched_entity_add_dependency_cb() (if the cb is called before we >> get around to tracing). The tracepoint i

Re: [Intel-gfx] [PATCH 2/6] drm/drv: Prepare to remove drm_dev_unplug()

Daniel Vetter writes: > > Zooming out more looking at the big picture I'd say all your work in the > past few years has enormously simplified drm for simple drivers already. > If we can't resolve this one here right now that just means you "only" > made drm 98% simpler instead of maybe 99%. It's

Re: [PATCH] drm: return false in drm_arch_can_wc_memory() for ARM

Alex Deucher writes: > On Fri, Dec 21, 2018 at 9:16 AM Liviu Dudau wrote: >> >> On Thu, Dec 20, 2018 at 04:36:19PM +0100, Daniel Vetter wrote: >> > On Thu, Dec 20, 2018 at 09:56:57AM -0500, Alex Deucher wrote: >> > > I'm not familiar enough with ARM to know if write combining >> > > is actually

[PATCH] drm/sched: Always trace the dependencies we wait on, to fix a race.

xes any easy-to-produce OOPS when tracing the scheduler on V3D with "perf record -a -e gpu_scheduler:.\* glxgears" and DEBUG_SLAB enabled. Signed-off-by: Eric Anholt --- drivers/gpu/drm/scheduler/sched_entity.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git

[PATCH] drm/sched: Fix a use-after-free when tracing the scheduler.

With DEBUG_SLAB (poisoning on free) enabled, I could quickly produce an oops when tracing V3D. Signed-off-by: Eric Anholt --- I think this patch is correct (though maybe a bigger refactor could avoid the extra get/put?), but I've still got this with "vblank_mode=0 perf record -a -e v3d:.

Re: [PATCH 1/3] dma-buf: add dma_fence_get_stub

Christian König writes: > Am 03.12.18 um 17:08 schrieb Eric Anholt: >> Christian König writes: >> >>> Extract of useful code from the timeline work. This provides a function >>> to return a stub or dummy fence which is always signaled. >&

Re: [PATCH 1/3] dma-buf: add dma_fence_get_stub

Christian König writes: > Extract of useful code from the timeline work. This provides a function > to return a stub or dummy fence which is always signaled. > > Signed-off-by: Christian König > --- > drivers/dma-buf/dma-fence.c | 36 +++- >

Re: [PATCH v3 1/3] drm/connector: Add generic underscan properties

Boris Brezillon writes: > On Mon, 3 Dec 2018 16:40:11 +0200 > Ville Syrjälä wrote: > >> On Thu, Nov 22, 2018 at 12:23:29PM +0100, Boris Brezillon wrote: >> > @@ -924,6 +978,29 @@ struct drm_connector { >> > */ >> >struct drm_property_blob *path_blob_ptr; >> > >> > + /** >> > + *

Re: [PATCH 4/4] drm/edid: Add display_info.rgb_quant_range_selectable

Ville Syrjala writes: > From: Ville Syrjälä > > Move the CEA-861 QS bit handling entirely into the edid code. No > need to bother the drivers with this. > > Cc: Alex Deucher > Cc: "Christian König" > Cc: "David (ChunMing) Zhou" > Cc:

Re: [PATCH v3 1/3] drm/connector: Add generic underscan properties

y calling >>+ * drm_connector_attach_content_protection_property() on initialization): > > Should be drm_connector_attach_underscan_properties() Other than this typo, this series is: Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH RFC 4/5] drm/amdgpu: Add accounting of command submission via DRM cgroup

Christian König writes: > Am 20.11.18 um 21:57 schrieb Eric Anholt: >> Kenny Ho writes: >> >>> Account for the number of command submitted to amdgpu by type on a per >>> cgroup basis, for the purpose of profiling/monitoring applications. >> For

Re: [PATCH RFC 4/5] drm/amdgpu: Add accounting of command submission via DRM cgroup

Kenny Ho writes: > Account for the number of command submitted to amdgpu by type on a per > cgroup basis, for the purpose of profiling/monitoring applications. For profiling other drivers, I've used perf tracepoints, which let you get useful timelines of multiple events in the driver. Have you

Re: [PATCH RFC 5/5] drm/amdgpu: Add accounting of buffer object creation request via DRM cgroup

Kenny Ho writes: > Account for the total size of buffer object requested to amdgpu by > buffer type on a per cgroup basis. > > x prefix in the control file name x.bo_requested.amd.stat signify > experimental. Why is a counting of the size of buffer objects ever allocated useful, as opposed to

Re: [igt-dev] [PATCH] RFC: Make igts for cross-driver stuff mandatory?

Sean Paul writes: > On Fri, Oct 19, 2018 at 10:50:49AM +0200, Daniel Vetter wrote: >> Hi all, >> >> This is just to collect feedback on this idea, and see whether the >> overall dri-devel community stands on all this. I think the past few >> cross-vendor uapi extensions all came with igts

Re: [PATCH 2/2] drm/scheduler: remove sched field from the entity

Nayan Deshmukh writes: > The scheduler of the entity is decided by the run queue on which > it is queued. This patch avoids us the effort required to maintain > a sync between rq and sched field when we start shifting entites > among different rqs. Reviewed-by: Eric Anholt s

Re: [PATCH 1/2] drm/scheduler: modify API to avoid redundancy

ntity->sched; Maybe fold the initialization into the declaration above, like you did elsewhere? Regardless, this is a wonderful cleanup of the API. Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 3/3] drm/scheduler: modify args of drm_sched_entity_init

Nayan Deshmukh writes: > diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c > b/drivers/gpu/drm/scheduler/gpu_scheduler.c > index 3dc1a4f07e3f..b2dbd1c1ba69 100644 > --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c > +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c > @@ -162,26 +162,32 @@

Re: [PATCH 1/3] drm/scheduler: add a pointer to scheduler in the rq

Nayan Deshmukh writes: > Signed-off-by: Nayan Deshmukh > --- Acked-by: Eric Anholt signature.asc Description: PGP signature ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

Lucas Stach writes: > 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 >> ---

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

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. v2: move mutex unlock to the error label. Signed-off-by: Eric Anholt Fixes: 57692c94dcbe ("drm/v3d: Introduce a ne

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

This isn't the first time I've had to argue to myself why the '++' was safe. Signed-off-by: Eric Anholt --- drivers/gpu/drm/v3d/v3d_fence.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/v3d/v3d_fence.c b/drivers/gpu/drm/v3d/v3d_fence.c index bfe31a89668b..6265e9ab4a13

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

. Signed-off-by: Eric Anholt --- drivers/gpu/drm/v3d/v3d_drv.h | 1 - drivers/gpu/drm/v3d/v3d_fence.c | 13 - drivers/gpu/drm/v3d/v3d_gem.c | 7 ++- drivers/gpu/drm/v3d/v3d_irq.c | 3 --- 4 files changed, 6 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/v3d

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

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 ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+")

Re: [PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes

Ville Syrjälä writes: > On Fri, May 11, 2018 at 09:47:49PM +0200, Boris Brezillon wrote: >> On Fri, 11 May 2018 20:29:48 +0300 >> Ville Syrjälä wrote: >> >> > On Fri, May 11, 2018 at 07:12:21PM +0200, Boris Brezillon wrote: >> > >

Re: [PATCH v2 2/4] drm/vc4: Take underscan setup into account when updating planes

Ville Syrjälä writes: > On Fri, May 11, 2018 at 07:12:21PM +0200, Boris Brezillon wrote: >> On Fri, 11 May 2018 19:54:02 +0300 >> Ville Syrjälä wrote: >> >> > On Fri, May 11, 2018 at 05:52:56PM +0200, Boris Brezillon wrote: >> > >

Re: [RFC] Per file OOM badness

Michel Dänzer writes: > On 2018-01-19 11:02 AM, Michel Dänzer wrote: >> On 2018-01-19 10:58 AM, Christian König wrote: >>> Am 19.01.2018 um 10:32 schrieb Michel Dänzer: On 2018-01-19 09:39 AM, Christian König wrote: > Am 19.01.2018 um 09:20 schrieb Michal Hocko:

Re: [RFC] Per file OOM badness

Michal Hocko writes: > On Thu 18-01-18 18:00:06, Michal Hocko wrote: >> On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote: >> > Hi, this series is a revised version of an RFC sent by Christian König >> > a few years ago. The original RFC can be found at >> >

Re: [PATCH 0/6 v3] Add ASoC support for AMD Stoney APUs

Mark Brown writes: > [ Unknown signature status ] > On Wed, Aug 30, 2017 at 09:33:35AM -0400, Alex Deucher wrote: > >> Any comments? Can this patch set go in? This is the second time I've >> resent it since the addressing the initial feedback. Does anyone have >> a

Re: [PATCH 1/4] drm/vc4: Allow vblank_disable_immediate on non-fw-kms.

sable for power saving. > > For debugging in case of unexpected trouble, booting > with kernel cmdline option drm.vblankoffdelay=0 > would keep vblank irqs on to approximate old behavior. > > Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com> > Cc: Eric

Re: [PATCH] drm: add check for plane functions

Ville Syrjälä writes: > On Fri, Mar 17, 2017 at 05:57:52PM +0100, Daniel Vetter wrote: >> On Fri, Mar 17, 2017 at 01:08:43PM +0200, Ville Syrjälä wrote: >> > On Fri, Mar 17, 2017 at 03:46:34PM +0530, Shirish S wrote: >> > > On Fri, Mar 17, 2017 at 3:26 PM, Ville