Re: [Intel-gfx] [PATCH v5 02/20] drm/msm: Fix drm/sched point of no return rules
On Thu, Aug 5, 2021 at 3:47 AM Daniel Vetter wrote:
>
> Originally drm_sched_job_init was the point of no return, after which
> drivers must submit a job. I've split that up, which allows us to fix
> this issue pretty easily.
>
> Only thing we have to take care of is to not skip to error paths after
> that. Other drivers do this the same for out-fence and similar things.
>
> Fixes: 1d8a5ca436ee ("drm/msm: Conversion to drm scheduler")
> Cc: Rob Clark
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: Sumit Semwal
> Cc: "Christian König"
> Cc: linux-arm-...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: freedr...@lists.freedesktop.org
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/msm/msm_gem_submit.c | 15 +++
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> b/drivers/gpu/drm/msm/msm_gem_submit.c
> index 6d6c44f0e1f3..d0ed4ddc509e 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -52,9 +52,6 @@ static struct msm_gem_submit *submit_create(struct
> drm_device *dev,
> return ERR_PTR(ret);
> }
>
> - /* FIXME: this is way too early */
> - drm_sched_job_arm(&job->base);
> -
> xa_init_flags(&submit->deps, XA_FLAGS_ALLOC);
>
> kref_init(&submit->ref);
> @@ -883,6 +880,9 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
>
> submit->user_fence = dma_fence_get(&submit->base.s_fence->finished);
>
> + /* point of no return, we _have_ to submit no matter what */
> + drm_sched_job_arm(&submit->base);
> +
> /*
> * Allocate an id which can be used by WAIT_FENCE ioctl to map back
> * to the underlying fence.
> @@ -892,17 +892,16 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
> if (submit->fence_id < 0) {
> ret = submit->fence_id = 0;
> submit->fence_id = 0;
> - goto out;
> }
>
> - if (args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
> + if (ret == 0 && args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
> struct sync_file *sync_file =
> sync_file_create(submit->user_fence);
> if (!sync_file) {
> ret = -ENOMEM;
> - goto out;
> + } else {
> + fd_install(out_fence_fd, sync_file->file);
> + args->fence_fd = out_fence_fd;
> }
> - fd_install(out_fence_fd, sync_file->file);
> - args->fence_fd = out_fence_fd;
I wonder if instead we should (approximately) undo "drm/msm/submit:
Simplify out-fence-fd handling" so that the point that it could fail
is moved up ahead of the drm_sched_job_arm()?
Also, does the dma_fence_get() work before drm_sched_job_arm()? From
a quick look, it looks like it won't, but I'm still playing catchup
and haven't had a chance to look at your entire series. If it doesn't
work before drm_sched_job_arm(), then there is really no way to
prevent a error path between the fence-init and job-submit.
But, prior to your series, wouldn't a failure after
drm_sched_job_init() but before the job is submitted just burn a
fence-id, and otherwise carry on it's merry way?
BR,
-R
> }
>
> submit_attach_object_fences(submit);
> --
> 2.32.0
>
Re: [Intel-gfx] [PATCH v5 02/20] drm/msm: Fix drm/sched point of no return rules
On Fri, Aug 6, 2021 at 9:42 AM Daniel Vetter wrote:
>
> On Fri, Aug 6, 2021 at 12:58 AM Rob Clark wrote:
> >
> > On Thu, Aug 5, 2021 at 3:47 AM Daniel Vetter wrote:
> > >
> > > Originally drm_sched_job_init was the point of no return, after which
> > > drivers must submit a job. I've split that up, which allows us to fix
> > > this issue pretty easily.
> > >
> > > Only thing we have to take care of is to not skip to error paths after
> > > that. Other drivers do this the same for out-fence and similar things.
> > >
> > > Fixes: 1d8a5ca436ee ("drm/msm: Conversion to drm scheduler")
> > > Cc: Rob Clark
> > > Cc: Rob Clark
> > > Cc: Sean Paul
> > > Cc: Sumit Semwal
> > > Cc: "Christian König"
> > > Cc: linux-arm-...@vger.kernel.org
> > > Cc: dri-de...@lists.freedesktop.org
> > > Cc: freedr...@lists.freedesktop.org
> > > Cc: linux-me...@vger.kernel.org
> > > Cc: linaro-mm-...@lists.linaro.org
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/msm/msm_gem_submit.c | 15 +++
> > > 1 file changed, 7 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> > > b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > index 6d6c44f0e1f3..d0ed4ddc509e 100644
> > > --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> > > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > @@ -52,9 +52,6 @@ static struct msm_gem_submit *submit_create(struct
> > > drm_device *dev,
> > > return ERR_PTR(ret);
> > > }
> > >
> > > - /* FIXME: this is way too early */
> > > - drm_sched_job_arm(&job->base);
> > > -
> > > xa_init_flags(&submit->deps, XA_FLAGS_ALLOC);
> > >
> > > kref_init(&submit->ref);
> > > @@ -883,6 +880,9 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> > > *data,
> > >
> > > submit->user_fence =
> > > dma_fence_get(&submit->base.s_fence->finished);
> > >
> > > + /* point of no return, we _have_ to submit no matter what */
> > > + drm_sched_job_arm(&submit->base);
> > > +
> > > /*
> > > * Allocate an id which can be used by WAIT_FENCE ioctl to map
> > > back
> > > * to the underlying fence.
> > > @@ -892,17 +892,16 @@ int msm_ioctl_gem_submit(struct drm_device *dev,
> > > void *data,
> > > if (submit->fence_id < 0) {
> > > ret = submit->fence_id = 0;
> > > submit->fence_id = 0;
> > > - goto out;
> > > }
> > >
> > > - if (args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
> > > + if (ret == 0 && args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
> > > struct sync_file *sync_file =
> > > sync_file_create(submit->user_fence);
> > > if (!sync_file) {
> > > ret = -ENOMEM;
> > > - goto out;
> > > + } else {
> > > + fd_install(out_fence_fd, sync_file->file);
> > > + args->fence_fd = out_fence_fd;
> > > }
> > > - fd_install(out_fence_fd, sync_file->file);
> > > - args->fence_fd = out_fence_fd;
> >
> > I wonder if instead we should (approximately) undo "drm/msm/submit:
> > Simplify out-fence-fd handling" so that the point that it could fail
> > is moved up ahead of the drm_sched_job_arm()?
>
> Hm yeah. Up to you how you want to paint this shed, I think either is fine.
>
> > Also, does the dma_fence_get() work before drm_sched_job_arm()? From
> > a quick look, it looks like it won't, but I'm still playing catchup
> > and haven't had a chance to look at your entire series. If it doesn't
> > work before drm_sched_job_arm(), then there is really no way to
> > prevent a error path between the fence-init and job-submit.
>
> Yes. I thought I've checked that I put the _arm() in the right spot,
> but I guess I screwed up and you need the fence before the point where
> I've put the job_arm()? And yes the error path cannot be avoided for
> out-fences, that's what I tried to explain in the commit message.
>
> > But, prior to your ser
Re: [Intel-gfx] [PATCH v5 02/20] drm/msm: Fix drm/sched point of no return rules
On Fri, Aug 6, 2021 at 11:41 AM Daniel Vetter wrote:
>
> On Fri, Aug 6, 2021 at 7:15 PM Rob Clark wrote:
> >
> > On Fri, Aug 6, 2021 at 9:42 AM Daniel Vetter wrote:
> > >
> > > On Fri, Aug 6, 2021 at 12:58 AM Rob Clark wrote:
> > > >
> > > > On Thu, Aug 5, 2021 at 3:47 AM Daniel Vetter
> > > > wrote:
> > > > >
> > > > > Originally drm_sched_job_init was the point of no return, after which
> > > > > drivers must submit a job. I've split that up, which allows us to fix
> > > > > this issue pretty easily.
> > > > >
> > > > > Only thing we have to take care of is to not skip to error paths after
> > > > > that. Other drivers do this the same for out-fence and similar things.
> > > > >
> > > > > Fixes: 1d8a5ca436ee ("drm/msm: Conversion to drm scheduler")
> > > > > Cc: Rob Clark
> > > > > Cc: Rob Clark
> > > > > Cc: Sean Paul
> > > > > Cc: Sumit Semwal
> > > > > Cc: "Christian König"
> > > > > Cc: linux-arm-...@vger.kernel.org
> > > > > Cc: dri-de...@lists.freedesktop.org
> > > > > Cc: freedr...@lists.freedesktop.org
> > > > > Cc: linux-me...@vger.kernel.org
> > > > > Cc: linaro-mm-...@lists.linaro.org
> > > > > Signed-off-by: Daniel Vetter
> > > > > ---
> > > > > drivers/gpu/drm/msm/msm_gem_submit.c | 15 +++
> > > > > 1 file changed, 7 insertions(+), 8 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > index 6d6c44f0e1f3..d0ed4ddc509e 100644
> > > > > --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > @@ -52,9 +52,6 @@ static struct msm_gem_submit *submit_create(struct
> > > > > drm_device *dev,
> > > > > return ERR_PTR(ret);
> > > > > }
> > > > >
> > > > > - /* FIXME: this is way too early */
> > > > > - drm_sched_job_arm(&job->base);
> > > > > -
> > > > > xa_init_flags(&submit->deps, XA_FLAGS_ALLOC);
> > > > >
> > > > > kref_init(&submit->ref);
> > > > > @@ -883,6 +880,9 @@ int msm_ioctl_gem_submit(struct drm_device *dev,
> > > > > void *data,
> > > > >
> > > > > submit->user_fence =
> > > > > dma_fence_get(&submit->base.s_fence->finished);
> > > > >
> > > > > + /* point of no return, we _have_ to submit no matter what */
> > > > > + drm_sched_job_arm(&submit->base);
> > > > > +
> > > > > /*
> > > > > * Allocate an id which can be used by WAIT_FENCE ioctl to
> > > > > map back
> > > > > * to the underlying fence.
> > > > > @@ -892,17 +892,16 @@ int msm_ioctl_gem_submit(struct drm_device
> > > > > *dev, void *data,
> > > > > if (submit->fence_id < 0) {
> > > > > ret = submit->fence_id = 0;
> > > > > submit->fence_id = 0;
> > > > > - goto out;
> > > > > }
> > > > >
> > > > > - if (args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
> > > > > + if (ret == 0 && args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
> > > > > struct sync_file *sync_file =
> > > > > sync_file_create(submit->user_fence);
> > > > > if (!sync_file) {
> > > > > ret = -ENOMEM;
> > > > > - goto out;
> > > > > + } else {
> > > > > + fd_install(out_fence_fd, sync_file->file);
> > > > > + args->fence_fd = out_fence_fd;
> > > > > }
> > > > > - fd_install(out_fence_fd, sync_file->file);
> > > > > - args->fence_fd = out_fence_fd;
> > > >
> > > > I wonder if instead we should (approximately) undo "drm/msm/submit:
> > > > Simpli
Re: [Intel-gfx] [PATCH v5 02/20] drm/msm: Fix drm/sched point of no return rules
On Fri, Aug 6, 2021 at 12:11 PM Daniel Vetter wrote:
>
> On Fri, Aug 6, 2021 at 8:57 PM Rob Clark wrote:
> >
> > On Fri, Aug 6, 2021 at 11:41 AM Daniel Vetter
> > wrote:
> > >
> > > On Fri, Aug 6, 2021 at 7:15 PM Rob Clark wrote:
> > > >
> > > > On Fri, Aug 6, 2021 at 9:42 AM Daniel Vetter
> > > > wrote:
> > > > >
> > > > > On Fri, Aug 6, 2021 at 12:58 AM Rob Clark wrote:
> > > > > >
> > > > > > On Thu, Aug 5, 2021 at 3:47 AM Daniel Vetter
> > > > > > wrote:
> > > > > > >
> > > > > > > Originally drm_sched_job_init was the point of no return, after
> > > > > > > which
> > > > > > > drivers must submit a job. I've split that up, which allows us to
> > > > > > > fix
> > > > > > > this issue pretty easily.
> > > > > > >
> > > > > > > Only thing we have to take care of is to not skip to error paths
> > > > > > > after
> > > > > > > that. Other drivers do this the same for out-fence and similar
> > > > > > > things.
> > > > > > >
> > > > > > > Fixes: 1d8a5ca436ee ("drm/msm: Conversion to drm scheduler")
> > > > > > > Cc: Rob Clark
> > > > > > > Cc: Rob Clark
> > > > > > > Cc: Sean Paul
> > > > > > > Cc: Sumit Semwal
> > > > > > > Cc: "Christian König"
> > > > > > > Cc: linux-arm-...@vger.kernel.org
> > > > > > > Cc: dri-de...@lists.freedesktop.org
> > > > > > > Cc: freedr...@lists.freedesktop.org
> > > > > > > Cc: linux-me...@vger.kernel.org
> > > > > > > Cc: linaro-mm-...@lists.linaro.org
> > > > > > > Signed-off-by: Daniel Vetter
> > > > > > > ---
> > > > > > > drivers/gpu/drm/msm/msm_gem_submit.c | 15 +++
> > > > > > > 1 file changed, 7 insertions(+), 8 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > > > b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > > > index 6d6c44f0e1f3..d0ed4ddc509e 100644
> > > > > > > --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > > > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> > > > > > > @@ -52,9 +52,6 @@ static struct msm_gem_submit
> > > > > > > *submit_create(struct drm_device *dev,
> > > > > > > return ERR_PTR(ret);
> > > > > > > }
> > > > > > >
> > > > > > > - /* FIXME: this is way too early */
> > > > > > > - drm_sched_job_arm(&job->base);
> > > > > > > -
> > > > > > > xa_init_flags(&submit->deps, XA_FLAGS_ALLOC);
> > > > > > >
> > > > > > > kref_init(&submit->ref);
> > > > > > > @@ -883,6 +880,9 @@ int msm_ioctl_gem_submit(struct drm_device
> > > > > > > *dev, void *data,
> > > > > > >
> > > > > > > submit->user_fence =
> > > > > > > dma_fence_get(&submit->base.s_fence->finished);
> > > > > > >
> > > > > > > + /* point of no return, we _have_ to submit no matter what
> > > > > > > */
> > > > > > > + drm_sched_job_arm(&submit->base);
> > > > > > > +
> > > > > > > /*
> > > > > > > * Allocate an id which can be used by WAIT_FENCE ioctl
> > > > > > > to map back
> > > > > > > * to the underlying fence.
> > > > > > > @@ -892,17 +892,16 @@ int msm_ioctl_gem_submit(struct drm_device
> > > > > > > *dev, void *data,
> > > > > > > if (submit->fence_id < 0) {
> > > > > > > ret = submit->fence_id = 0;
> > > > > > > submit->fence_id = 0;
> > > > > > > - goto out;
> > > > > > > }
> > > > > > >
> > > > > > > - i
Re: [Intel-gfx] [Mesa-dev] [PATCH 01/11] drm/amdgpu: Comply with implicit fencing rules
On Fri, May 21, 2021 at 2:10 AM Daniel Vetter wrote: > > - msm is mildly entertaining. It also supports MSM_SUBMIT_NO_IMPLICIT, > but because it doesn't use the drm/scheduler it handles fences from > the wrong context with a synchronous dma_fence_wait. See > submit_fence_sync() leading to msm_gem_sync_object(). Investing into > a scheduler might be a good idea. Yeah, drm/scheduler is (along with a lot of other things) on the TODO list. But this isn't quite as bad as it sounds because userspace uses a u_queue thread to call the submit ioctl rather than blocking the driver. (It also offloads some other work from the driver thread, like submit merging to reduce # of ioctls. Coincidentally that arrangement was a step towards preparing userspace for some hypothetical non-ioctl uapi ;-)) OTOH it would be good to move blocking until the system can free enough pages to repin bo's out of the ioctl path to better handle some memory pressure corner cases without having to be interruptable over a lot more of the submit path.. Running chrome+android on devices without a lot of memory is fun.. BR, -R ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/msm: Improve drm/sched point of no return rules
On Thu, Aug 26, 2021 at 2:33 AM Daniel Vetter wrote:
>
> Originally drm_sched_job_init was the point of no return, after which
> drivers really should submit a job. I've split that up, which allows
> us to fix this issue pretty easily.
>
> Only thing we have to take care of is to not skip to error paths after
> that. Other drivers do this the same for out-fence and similar things.
>
> v2: It's not really a bugfix, just an improvement, since all
> drm_sched_job_arm does is reserve the fence number. And gaps should be
> fine, as long as the drm_sched_job doesn't escape anywhere at all.
>
> For robustness it's still better to align with other drivers here and
> not bail out after job_arm().
>
> v3: I misplaced drm_sched_job_arm by _one_ line! Thanks to Rob for
> testing and debug help.
>
> Cc: Rob Clark
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: Sumit Semwal
> Cc: "Christian König"
> Cc: linux-arm-...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: freedr...@lists.freedesktop.org
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> Signed-off-by: Daniel Vetter
t-b && r-b
BR,
-R
> ---
> drivers/gpu/drm/msm/msm_gem_submit.c | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> b/drivers/gpu/drm/msm/msm_gem_submit.c
> index 4d1c4d5f6a2a..71b8c8f752a3 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -52,8 +52,6 @@ static struct msm_gem_submit *submit_create(struct
> drm_device *dev,
> return ERR_PTR(ret);
> }
>
> - drm_sched_job_arm(&job->base);
> -
> xa_init_flags(&submit->deps, XA_FLAGS_ALLOC);
>
> kref_init(&submit->ref);
> @@ -880,6 +878,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
>
> submit->nr_cmds = i;
>
> + drm_sched_job_arm(&submit->base);
> +
> submit->user_fence = dma_fence_get(&submit->base.s_fence->finished);
>
> /*
> @@ -891,17 +891,16 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
> if (submit->fence_id < 0) {
> ret = submit->fence_id = 0;
> submit->fence_id = 0;
> - goto out;
> }
>
> - if (args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
> + if (ret == 0 && args->flags & MSM_SUBMIT_FENCE_FD_OUT) {
> struct sync_file *sync_file =
> sync_file_create(submit->user_fence);
> if (!sync_file) {
> ret = -ENOMEM;
> - goto out;
> + } else {
> + fd_install(out_fence_fd, sync_file->file);
> + args->fence_fd = out_fence_fd;
> }
> - fd_install(out_fence_fd, sync_file->file);
> - args->fence_fd = out_fence_fd;
> }
>
> submit_attach_object_fences(submit);
> --
> 2.32.0
>
Re: [Intel-gfx] [PATCH v5 12/20] drm/msm: Use scheduler dependency handling
On Thu, Aug 5, 2021 at 3:47 AM Daniel Vetter wrote:
>
> drm_sched_job_init is already at the right place, so this boils down
> to deleting code.
>
> Signed-off-by: Daniel Vetter
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: Sumit Semwal
> Cc: "Christian König"
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
r-b
> ---
> drivers/gpu/drm/msm/msm_gem.h| 5 -
> drivers/gpu/drm/msm/msm_gem_submit.c | 19 +--
> drivers/gpu/drm/msm/msm_ringbuffer.c | 12
> 3 files changed, 5 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
> index f9e3ffb2309a..8bf0ac707fd7 100644
> --- a/drivers/gpu/drm/msm/msm_gem.h
> +++ b/drivers/gpu/drm/msm/msm_gem.h
> @@ -312,11 +312,6 @@ struct msm_gem_submit {
> struct ww_acquire_ctx ticket;
> uint32_t seqno; /* Sequence number of the submit on the ring
> */
>
> - /* Array of struct dma_fence * to block on before submitting this job.
> -*/
> - struct xarray deps;
> - unsigned long last_dep;
> -
> /* Hw fence, which is created when the scheduler executes the job, and
> * is signaled when the hw finishes (via seqno write from cmdstream)
> */
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
> b/drivers/gpu/drm/msm/msm_gem_submit.c
> index 96cea0ba4cfd..fb5a2eab27a2 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -52,8 +52,6 @@ static struct msm_gem_submit *submit_create(struct
> drm_device *dev,
> return ERR_PTR(ret);
> }
>
> - xa_init_flags(&submit->deps, XA_FLAGS_ALLOC);
> -
> kref_init(&submit->ref);
> submit->dev = dev;
> submit->aspace = queue->ctx->aspace;
> @@ -72,8 +70,6 @@ void __msm_gem_submit_destroy(struct kref *kref)
> {
> struct msm_gem_submit *submit =
> container_of(kref, struct msm_gem_submit, ref);
> - unsigned long index;
> - struct dma_fence *fence;
> unsigned i;
>
> if (submit->fence_id) {
> @@ -82,12 +78,6 @@ void __msm_gem_submit_destroy(struct kref *kref)
> mutex_unlock(&submit->queue->lock);
> }
>
> - xa_for_each (&submit->deps, index, fence) {
> - dma_fence_put(fence);
> - }
> -
> - xa_destroy(&submit->deps);
> -
> dma_fence_put(submit->user_fence);
> dma_fence_put(submit->hw_fence);
>
> @@ -343,8 +333,9 @@ static int submit_fence_sync(struct msm_gem_submit
> *submit, bool no_implicit)
> if (no_implicit)
> continue;
>
> - ret = drm_gem_fence_array_add_implicit(&submit->deps, obj,
> - write);
> + ret = drm_sched_job_add_implicit_dependencies(&submit->base,
> + obj,
> + write);
> if (ret)
> break;
> }
> @@ -588,7 +579,7 @@ static struct drm_syncobj **msm_parse_deps(struct
> msm_gem_submit *submit,
> if (ret)
> break;
>
> - ret = drm_gem_fence_array_add(&submit->deps, fence);
> + ret = drm_sched_job_add_dependency(&submit->base, fence);
> if (ret)
> break;
>
> @@ -798,7 +789,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void
> *data,
> goto out_unlock;
> }
>
> - ret = drm_gem_fence_array_add(&submit->deps, in_fence);
> + ret = drm_sched_job_add_dependency(&submit->base, in_fence);
> if (ret)
> goto out_unlock;
> }
> diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c
> b/drivers/gpu/drm/msm/msm_ringbuffer.c
> index bd54c1412649..652b1dedd7c1 100644
> --- a/drivers/gpu/drm/msm/msm_ringbuffer.c
> +++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
> @@ -11,17 +11,6 @@ static uint num_hw_submissions = 8;
> MODULE_PARM_DESC(num_hw_submissions, "The max # of jobs to write into
> ringbuffer (default 8)");
> module_param(num_hw_submissions, uint, 0600);
>
> -static struct dma_fence *msm_job_dependency(struct drm_sched_job *job,
> - struct drm_sched_entity *s_entity)
> -{
> - struct msm_
Re: [Intel-gfx] [PATCH v5 16/20] drm/msm: Don't break exclusive fence ordering
On Thu, Aug 5, 2021 at 3:47 AM Daniel Vetter wrote: > > There's only one exclusive slot, and we must not break the ordering. > > Adding a new exclusive fence drops all previous fences from the > dma_resv. To avoid violating the signalling order we err on the side of > over-synchronizing by waiting for the existing fences, even if > userspace asked us to ignore them. > > A better fix would be to us a dma_fence_chain or _array like e.g. > amdgpu now uses, but > - msm has a synchronous dma_fence_wait for anything from another > context, so doesn't seem to care much, > - and it probably makes sense to lift this into dma-resv.c code as a > proper concept, so that drivers don't have to hack up their own > solution each on their own. > > v2: Improve commit message per Lucas' suggestion. > > Cc: Lucas Stach > Signed-off-by: Daniel Vetter > Cc: Rob Clark > Cc: Sean Paul > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org a-b > --- > drivers/gpu/drm/msm/msm_gem_submit.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c > b/drivers/gpu/drm/msm/msm_gem_submit.c > index fb5a2eab27a2..66633dfd58a2 100644 > --- a/drivers/gpu/drm/msm/msm_gem_submit.c > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c > @@ -330,7 +330,8 @@ static int submit_fence_sync(struct msm_gem_submit > *submit, bool no_implicit) > return ret; > } > > - if (no_implicit) > + /* exclusive fences must be ordered */ > + if (no_implicit && !write) > continue; > > ret = drm_sched_job_add_implicit_dependencies(&submit->base, > -- > 2.32.0 >
Re: [Intel-gfx] [PATCH v4 14/18] drm/msm: Don't break exclusive fence ordering
On Mon, Jul 12, 2021 at 1:02 PM Daniel Vetter wrote: > > There's only one exclusive slot, and we must not break the ordering. > > Adding a new exclusive fence drops all previous fences from the > dma_resv. To avoid violating the signalling order we err on the side of > over-synchronizing by waiting for the existing fences, even if > userspace asked us to ignore them. > > A better fix would be to us a dma_fence_chain or _array like e.g. > amdgpu now uses, but > - msm has a synchronous dma_fence_wait for anything from another > context, so doesn't seem to care much, > - and it probably makes sense to lift this into dma-resv.c code as a > proper concept, so that drivers don't have to hack up their own > solution each on their own. > > v2: Improve commit message per Lucas' suggestion. > > Cc: Lucas Stach > Signed-off-by: Daniel Vetter > Cc: Rob Clark > Cc: Sean Paul > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > --- > drivers/gpu/drm/msm/msm_gem_submit.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c > b/drivers/gpu/drm/msm/msm_gem_submit.c > index b71da71a3dd8..edd0051d849f 100644 > --- a/drivers/gpu/drm/msm/msm_gem_submit.c > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c > @@ -306,7 +306,8 @@ static int submit_fence_sync(struct msm_gem_submit > *submit, bool no_implicit) > return ret; > } > > - if (no_implicit) > + /* exclusive fences must be ordered */ > + if (no_implicit && !write) > continue; In practice, modern userspace (the kind that is more likely to set the no-implicit flag on every submit) also sets MSM_SUBMIT_BO_WRITE on every bo, to shave some cpu overhead so I suppose this would not really hurt anything Do you know if this is covered in any piglit/etc test? BR, -R > > ret = msm_gem_sync_object(&msm_obj->base, submit->ring->fctx, > -- > 2.32.0 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 14/18] drm/msm: Don't break exclusive fence ordering
On Tue, Jul 13, 2021 at 9:58 AM Daniel Vetter wrote: > > On Tue, Jul 13, 2021 at 6:51 PM Rob Clark wrote: > > > > On Mon, Jul 12, 2021 at 1:02 PM Daniel Vetter > > wrote: > > > > > > There's only one exclusive slot, and we must not break the ordering. > > > > > > Adding a new exclusive fence drops all previous fences from the > > > dma_resv. To avoid violating the signalling order we err on the side of > > > over-synchronizing by waiting for the existing fences, even if > > > userspace asked us to ignore them. > > > > > > A better fix would be to us a dma_fence_chain or _array like e.g. > > > amdgpu now uses, but > > > - msm has a synchronous dma_fence_wait for anything from another > > > context, so doesn't seem to care much, > > > - and it probably makes sense to lift this into dma-resv.c code as a > > > proper concept, so that drivers don't have to hack up their own > > > solution each on their own. > > > > > > v2: Improve commit message per Lucas' suggestion. > > > > > > Cc: Lucas Stach > > > Signed-off-by: Daniel Vetter > > > Cc: Rob Clark > > > Cc: Sean Paul > > > Cc: linux-arm-...@vger.kernel.org > > > Cc: freedr...@lists.freedesktop.org > > > --- > > > drivers/gpu/drm/msm/msm_gem_submit.c | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c > > > b/drivers/gpu/drm/msm/msm_gem_submit.c > > > index b71da71a3dd8..edd0051d849f 100644 > > > --- a/drivers/gpu/drm/msm/msm_gem_submit.c > > > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c > > > @@ -306,7 +306,8 @@ static int submit_fence_sync(struct msm_gem_submit > > > *submit, bool no_implicit) > > > return ret; > > > } > > > > > > - if (no_implicit) > > > + /* exclusive fences must be ordered */ > > > + if (no_implicit && !write) > > > continue; > > > > In practice, modern userspace (the kind that is more likely to set the > > no-implicit flag on every submit) also sets MSM_SUBMIT_BO_WRITE on > > every bo, to shave some cpu overhead so I suppose this would not > > really hurt anything > > > > Do you know if this is covered in any piglit/etc test? > > You need some command submission, plus buffer sharing with vgem > setting it's own exclusive fences, plus checking with dma_buf poll() > whether it signals all in the right order. That's pretty low-level, so > maybe something in igt, but I haven't typed that. Maybe I need to do > that for i915 at least. ok, you lost me at vgem ;-) (the vgem vs cache situation on arm is kinda hopeless) BR, -R > -Daniel > > > BR, > > -R > > > > > > > > ret = msm_gem_sync_object(&msm_obj->base, > > > submit->ring->fctx, > > > -- > > > 2.32.0 > > > > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH libdrm] headers: Sync with drm-next
On Tue, Apr 9, 2019 at 8:27 AM Eric Engestrom wrote:
>
> On Tuesday, 2019-04-09 12:59:13 +0100, Eric Engestrom wrote:
> > On Tuesday, 2019-04-09 11:35:14 +, Ayan Halder wrote:
> > > Generated using make headers_install from the drm-next
> > > tree - git://anongit.freedesktop.org/drm/drm
> > > branch - drm-next
> > > commit - 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f
> > >
> > > The changes were as follows :-
> > >
> > > core: (drm.h, drm_fourcc.h, drm_mode.h)
> > > - Added 'struct drm_syncobj_transfer', 'struct drm_syncobj_timeline_wait'
> > > and 'struct drm_syncobj_timeline_array'
> > > - Added various DRM_IOCTL_SYNCOBJ_ ioctls
> > > - Added some new RGB and YUV formats
> > > - Added 'DRM_FORMAT_MOD_VENDOR_ALLWINNER'
> > > - Added 'SAMSUNG' and Arm's 'AFBC' and 'ALLWINNER' format modifiers
> > > - Added 'struct drm_mode_rect'
> > >
> > > i915:
> > > - Added struct 'struct i915_user_extension' and various 'struct
> > > drm_i915_gem_context_'
> > > - Added different modes of per-process Graphics Translation Table
> > >
> > > msm:
> > > - Added various get or set GEM buffer info flags
> > > - Added some MSM_SUBMIT_BO_ macros
> > > - Modified 'struct drm_msm_gem_info'
> > >
> > > Signed-off-by: Ayan Kumar halder
> >
> > This looks sane, and applies cleanly :)
> > Acked-by: Eric Engestrom
>
> Actually, revoking that, as this patch breaks the build; see below.
>
> >
> > > ---
> > > include/drm/drm.h| 36 +++
> > > include/drm/drm_fourcc.h | 136 +++
> > > include/drm/drm_mode.h | 23 -
> > > include/drm/i915_drm.h | 237
> > > ---
> > > include/drm/msm_drm.h| 25 +++--
> > > 5 files changed, 415 insertions(+), 42 deletions(-)
> > >
> [snip]
> > > diff --git a/include/drm/msm_drm.h b/include/drm/msm_drm.h
> > > index c06d0a5..91a16b3 100644
> > > --- a/include/drm/msm_drm.h
> > > +++ b/include/drm/msm_drm.h
> > > @@ -105,14 +105,24 @@ struct drm_msm_gem_new {
> > > __u32 handle; /* out */
> > > };
> > >
> > > -#define MSM_INFO_IOVA 0x01
> > > -
> > > -#define MSM_INFO_FLAGS (MSM_INFO_IOVA)
> > > +/* Get or set GEM buffer info. The requested value can be passed
> > > + * directly in 'value', or for data larger than 64b 'value' is a
> > > + * pointer to userspace buffer, with 'len' specifying the number of
> > > + * bytes copied into that buffer. For info returned by pointer,
> > > + * calling the GEM_INFO ioctl with null 'value' will return the
> > > + * required buffer size in 'len'
> > > + */
> > > +#define MSM_INFO_GET_OFFSET0x00 /* get mmap() offset, returned
> > > by value */
> > > +#define MSM_INFO_GET_IOVA 0x01 /* get iova, returned by value */
> > > +#define MSM_INFO_SET_NAME 0x02 /* set the debug name (by pointer) */
> > > +#define MSM_INFO_GET_NAME 0x03 /* get debug name, returned by pointer
> > > */
> > >
> > > struct drm_msm_gem_info {
> > > __u32 handle; /* in */
> > > - __u32 flags; /* in - combination of MSM_INFO_* flags */
> > > - __u64 offset; /* out, mmap() offset or iova */
> > > + __u32 info; /* in - one of MSM_INFO_* */
> > > + __u64 value; /* in or out */
> > > + __u32 len;/* in or out */
> > > + __u32 pad;
>
> freedreno/msm/msm_bo.c needs to be updated to reflect those changes.
I think you can just rename flags->info and offset->value, the rest of
the struct should be zero-initialized.. if in doubt you can check
$mesa/src/freedreno/drm/msm_bo.c
side-note: the libdrm_freedreno code was folded into mesa in 19.0, so
at *some* point we can probably disable libdrm_freedreno build by
default. (I'd kinda still like to keep the code around for some misc
standalone tools I have, but that is the sort of thing where I can fix
libdrm if it gets broken). When to switch to disabled by default I
guess comes down to how long we want to support mesa 18.x with latest
libdrm?? Maybe after 19.1, since (selfishly motivated) that gives me
a long enough window back in case I find myself needing to bisect for
some regression..
BR,
-R
>
> > > };
> > >
> > > #define MSM_PREP_READ0x01
> > > @@ -188,8 +198,11 @@ struct drm_msm_gem_submit_cmd {
> > > */
> > > #define MSM_SUBMIT_BO_READ 0x0001
> > > #define MSM_SUBMIT_BO_WRITE0x0002
> > > +#define MSM_SUBMIT_BO_DUMP 0x0004
> > >
> > > -#define MSM_SUBMIT_BO_FLAGS(MSM_SUBMIT_BO_READ |
> > > MSM_SUBMIT_BO_WRITE)
> > > +#define MSM_SUBMIT_BO_FLAGS(MSM_SUBMIT_BO_READ | \
> > > + MSM_SUBMIT_BO_WRITE | \
> > > + MSM_SUBMIT_BO_DUMP)
> > >
> > > struct drm_msm_gem_submit_bo {
> > > __u32 flags; /* in, mask of MSM_SUBMIT_BO_x */
> > > --
> > > 2.7.4
> > >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listin
Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl: Don't mark pipes as dirty unless we've added/removed pipes
On Tue, Jul 19, 2016 at 1:19 PM, Matt Roper wrote:
> On Tue, Jul 19, 2016 at 12:30:56PM -0400, Lyude wrote:
>> Now that we update the watermark values atomically, we still need to fix
>> the case of how we update watermarks when we haven't added or removed
>> pipes.
>>
>> When we haven't added or removed any pipes, we don't need to worry about
>> the ddb allocation changing. As such there's no order of flushing pipes
>> we have to guarantee; e.g. each pipe can be flushed at the earliest
>> given oppurtunity. This means all we have to do is:
>>
>> - Calculate the new wm values
>> - Update each plane's settings and wm values
>> - Arm the plane's registers to update at the next vblank
>>
>> Right now the watermark code takes an additional few steps:
>> - Rewrite the ddb allocations
>> - Arm all of the planes for another update at the start of the next
>>vblank
>> - *Potentially underrun later if we update the wm registers before the
>>start of the next vblank*
>>
>> This patch prevents us from marking pipes as dirty unless the number of
>> pipes, and with that the ddb allocation, has actually changed. This
>> results in us skipping the additional steps, preventing the hardware
>> from using any intermediate values during each wm update.
>>
>> This also fixes cursors causing monitors to flicker on Skylake. Finally.
>>
>
> This doesn't look right to me. It's true that we don't need to worry
> about *inter*-pipe DDB allocation changing, but *intra*-pipe DDB
> allocations can still change. We may be resizing planes, changing
> scalers, enabling/disabling new planes, etc. Those operations change
> the DDB allocations for the planes within the fixed pipe allocation.
> The watermark values will also change accordingly in that case.
>
fwiw, msm/mdp5 has potentially similar constraints w/ SMP block
allocation (which seems like basically the same thing as DDB).. we
just disallow changing width/bpp/etc on an active plane, so userspace
would pick a different plane (or skip the plane for one frame of
composition)..
not sure if that would help.. maybe we are more limited in not
actually being able to safely change SMP allocation on an active
plane/pipe. But treating it as a disable of current pipe and switch
to new pipe is convenient, rather than dealing with all the cases that
could effect SMP block assignment.
BR,
-R
>
> Matt
>
>> Signed-off-by: Lyude Paul
>> Cc: sta...@vger.kernel.org
>> Cc: Ville Syrjälä
>> Cc: Daniel Vetter
>> Cc: Radhakrishna Sripada
>> Cc: Hans de Goede
>> Cc: Matt Roper
>> ---
>> drivers/gpu/drm/i915/intel_pm.c | 16 +++-
>> 1 file changed, 11 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c
>> b/drivers/gpu/drm/i915/intel_pm.c
>> index 3a7709c..92158e3 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -4086,12 +4086,18 @@ skl_compute_wm(struct drm_atomic_state *state)
>> if (ret)
>> return ret;
>>
>> - if (changed)
>> - results->dirty_pipes |= drm_crtc_mask(crtc);
>> + /*
>> + * We don't need to do any additional setup for the pipes if we
>> + * haven't changed the number of active crtcs
>> + */
>> + if (intel_state->active_pipe_changes) {
>> + if (changed)
>> + results->dirty_pipes |= drm_crtc_mask(crtc);
>>
>> - if ((results->dirty_pipes & drm_crtc_mask(crtc)) == 0)
>> - /* This pipe's WM's did not change */
>> - continue;
>> + if ((results->dirty_pipes & drm_crtc_mask(crtc)) == 0)
>> + /* This pipe's WM's did not change */
>> + continue;
>> + }
>>
>> intel_cstate->update_wm_pre = true;
>> skl_compute_wm_results(crtc->dev, pipe_wm, results,
>> intel_crtc);
>> --
>> 2.7.4
>>
>
> --
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/atomic: Take the atomic toys away from X
On Tue, Sep 3, 2019 at 12:07 PM Daniel Vetter wrote: > > The -modesetting ddx has a totally broken idea of how atomic works: > - doesn't disable old connectors, assuming they get auto-disable like > with the legacy setcrtc > - assumes ASYNC_FLIP is wired through for the atomic ioctl > - not a single call to TEST_ONLY > > Iow the implementation is a 1:1 translation of legacy ioctls to > atomic, which is a) broken b) pointless. > > We already have bugs in both i915 and amdgpu-DC where this prevents us > from enabling neat features. > > If anyone ever cares about atomic in X we can easily add a new atomic > level (req->value == 2) for X to get back the shiny toys. > > Since these broken versions of -modesetting have been shipping, > there's really no other way to get out of this bind. > > References: https://gitlab.freedesktop.org/xorg/xserver/issues/629 > References: https://gitlab.freedesktop.org/xorg/xserver/merge_requests/180 > Cc: Maarten Lankhorst > Cc: Michel Dänzer > Cc: Alex Deucher > Cc: Adam Jackson > Cc: Sean Paul > Cc: David Airlie > Cc: sta...@vger.kernel.org > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/drm_ioctl.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c > index 2c120c58f72d..1cb7b4c3c87c 100644 > --- a/drivers/gpu/drm/drm_ioctl.c > +++ b/drivers/gpu/drm/drm_ioctl.c > @@ -334,6 +334,9 @@ drm_setclientcap(struct drm_device *dev, void *data, > struct drm_file *file_priv) > file_priv->universal_planes = req->value; > break; > case DRM_CLIENT_CAP_ATOMIC: > + /* The modesetting DDX has a totally broken idea of atomic. */ > + if (strstr(current->comm, "X")) > + return -EOPNOTSUPP; Seems like we can be a bit more targeted than "anything that has 'X' in the name".. at a minimum restrict things to "starts with 'X'" seems saner. But I guess we could probably somehow look at the processes memory map and look for modesetting_drv.so. BR, -R > if (!drm_core_check_feature(dev, DRIVER_ATOMIC)) > return -EOPNOTSUPP; > if (req->value > 1) > -- > 2.23.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/9] drm/msm: use drm_debug_enabled() to check for debug categories
On Fri, Sep 13, 2019 at 4:52 AM Jani Nikula wrote:
>
> Allow better abstraction of the drm_debug global variable in the
> future. No functional changes.
>
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Signed-off-by: Jani Nikula
Reviewed-by: Rob Clark
I don't think this should conflict w/ anything, so land via drm-misc?
BR,
-R
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> index 9e40f559c51f..00e3353f9aad 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
> @@ -29,7 +29,7 @@
> */
> #define DPU_DEBUG(fmt, ...)\
> do { \
> - if (unlikely(drm_debug & DRM_UT_KMS)) \
> + if (unlikely(drm_debug_enabled(DRM_UT_KMS))) \
> DRM_DEBUG(fmt, ##__VA_ARGS__); \
> else \
> pr_debug(fmt, ##__VA_ARGS__); \
> @@ -41,7 +41,7 @@
> */
> #define DPU_DEBUG_DRIVER(fmt, ...) \
> do { \
> - if (unlikely(drm_debug & DRM_UT_DRIVER)) \
> + if (unlikely(drm_debug_enabled(DRM_UT_DRIVER)))\
> DRM_ERROR(fmt, ##__VA_ARGS__); \
> else \
> pr_debug(fmt, ##__VA_ARGS__); \
> --
> 2.20.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker
On Thu, May 26, 2022 at 4:55 PM Dmitry Osipenko
wrote:
>
> Introduce a common DRM SHMEM shrinker framework that allows to reduce
> code duplication among DRM drivers by replacing theirs custom shrinker
> implementations with the generic shrinker.
>
> In order to start using DRM SHMEM shrinker drivers should:
>
> 1. Implement new evict() shmem object callback.
> 2. Register shrinker using drm_gem_shmem_shrinker_register(drm_device).
> 3. Use drm_gem_shmem_set_purgeable(shmem) and alike API functions to
>activate shrinking of shmem GEMs.
>
> This patch is based on a ideas borrowed from Rob's Clark MSM shrinker,
> Thomas' Zimmermann variant of SHMEM shrinker and Intel's i915 shrinker.
>
> Signed-off-by: Daniel Almeida
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c| 540 --
> .../gpu/drm/panfrost/panfrost_gem_shrinker.c | 9 +-
> drivers/gpu/drm/virtio/virtgpu_drv.h | 3 +
> include/drm/drm_device.h | 4 +
> include/drm/drm_gem_shmem_helper.h| 87 ++-
> 5 files changed, 594 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 555fe212bd98..4cd0b5913492 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -126,6 +126,42 @@ struct drm_gem_shmem_object *drm_gem_shmem_create(struct
> drm_device *dev, size_t
> }
> EXPORT_SYMBOL_GPL(drm_gem_shmem_create);
>
> +static bool drm_gem_shmem_is_evictable(struct drm_gem_shmem_object *shmem)
> +{
> + return (shmem->madv >= 0) && shmem->evict &&
> + shmem->eviction_enabled && shmem->pages_use_count &&
> + !shmem->pages_pin_count && !shmem->base.dma_buf &&
> + !shmem->base.import_attach && shmem->sgt && !shmem->evicted;
> +}
> +
> +static void
> +drm_gem_shmem_update_pages_state(struct drm_gem_shmem_object *shmem)
> +{
> + struct drm_gem_object *obj = &shmem->base;
> + struct drm_gem_shmem_shrinker *gem_shrinker =
> obj->dev->shmem_shrinker;
> +
> + dma_resv_assert_held(shmem->base.resv);
> +
> + if (!gem_shrinker || obj->import_attach)
> + return;
> +
> + mutex_lock(&gem_shrinker->lock);
> +
> + if (drm_gem_shmem_is_evictable(shmem) ||
> + drm_gem_shmem_is_purgeable(shmem))
> + list_move_tail(&shmem->madv_list,
> &gem_shrinker->lru_evictable);
> + else if (shmem->madv < 0)
> + list_del_init(&shmem->madv_list);
> + else if (shmem->evicted)
> + list_move_tail(&shmem->madv_list, &gem_shrinker->lru_evicted);
> + else if (!shmem->pages)
> + list_del_init(&shmem->madv_list);
> + else
> + list_move_tail(&shmem->madv_list, &gem_shrinker->lru_pinned);
> +
> + mutex_unlock(&gem_shrinker->lock);
> +}
> +
> /**
> * drm_gem_shmem_free - Free resources associated with a shmem GEM object
> * @shmem: shmem GEM object to free
> @@ -142,6 +178,9 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> *shmem)
> } else {
> dma_resv_lock(shmem->base.resv, NULL);
>
> + /* take out shmem GEM object from the memory shrinker */
> + drm_gem_shmem_madvise(shmem, -1);
> +
> WARN_ON(shmem->vmap_use_count);
>
> if (shmem->sgt) {
> @@ -150,7 +189,7 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> *shmem)
> sg_free_table(shmem->sgt);
> kfree(shmem->sgt);
> }
> - if (shmem->pages)
> + if (shmem->pages_use_count)
> drm_gem_shmem_put_pages(shmem);
>
> WARN_ON(shmem->pages_use_count);
> @@ -163,18 +202,82 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> *shmem)
> }
> EXPORT_SYMBOL_GPL(drm_gem_shmem_free);
>
> -static int drm_gem_shmem_get_pages(struct drm_gem_shmem_object *shmem)
> +/**
> + * drm_gem_shmem_set_evictable() - Make GEM evictable by memory shrinker
> + * @shmem: shmem GEM object
> + *
> + * Tell memory shrinker that this GEM can be evicted. Initially eviction is
> + * disabled for all GEMs. If GEM was purged, then -ENOMEM is returned.
> + *
> + * Returns:
> + * 0 on success or a negative error code on failure.
> + */
> +int drm_gem_shmem_set_evictable(struct drm_gem_shmem_object *shmem)
> +{
> + dma_resv_lock(shmem->base.resv, NULL);
> +
> + if (shmem->madv < 0)
> + return -ENOMEM;
> +
> + shmem->eviction_enabled = true;
> +
> + dma_resv_unlock(shmem->base.resv);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(drm_gem_shmem_set_evictable);
> +
> +/**
> + * drm_gem_shmem_set_purgeable() - Make GEM purgeable by memory shrinker
> + * @shmem: shmem GEM object
> + *
> + * Tell memory shrinker that this GEM can be purged. Initially purging is
> + * disabled for all GE
Re: [Intel-gfx] [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker
On Mon, Jun 20, 2022 at 7:09 AM Dmitry Osipenko
wrote:
>
> On 6/19/22 20:53, Rob Clark wrote:
> ...
> >> +static unsigned long
> >> +drm_gem_shmem_shrinker_count_objects(struct shrinker *shrinker,
> >> +struct shrink_control *sc)
> >> +{
> >> + struct drm_gem_shmem_shrinker *gem_shrinker =
> >> to_drm_shrinker(shrinker);
> >> + struct drm_gem_shmem_object *shmem;
> >> + unsigned long count = 0;
> >> +
> >> + if (!mutex_trylock(&gem_shrinker->lock))
> >> + return 0;
> >> +
> >> + list_for_each_entry(shmem, &gem_shrinker->lru_evictable,
> >> madv_list) {
> >> + count += shmem->base.size;
> >> +
> >> + if (count >= SHRINK_EMPTY)
> >> + break;
> >> + }
> >> +
> >> + mutex_unlock(&gem_shrinker->lock);
> >
> > As I mentioned on other thread, count_objects, being approximate but
> > lockless and fast is the important thing. Otherwise when you start
> > hitting the shrinker on many threads, you end up serializing them all,
> > even if you have no pages to return to the system at that point.
>
> Daniel's point for dropping the lockless variant was that we're already
> in trouble if we're hitting shrinker too often and extra optimizations
> won't bring much benefits to us.
At least with zram swap (which I highly recommend using even if you
are not using a physical swap file/partition), swapin/out is actually
quite fast. And if you are leaning on zram swap to fit 8GB of chrome
browser on a 4GB device, the shrinker gets hit quite a lot. Lower
spec (4GB RAM) chromebooks can be under constant memory pressure and
can quite easily get into a situation where you are hitting the
shrinker on many threads simultaneously. So it is pretty important
for all shrinkers in the system (not just drm driver) to be as
concurrent as possible. As long as you avoid serializing reclaim on
all the threads, performance can still be quite good, but if you don't
performance will fall off a cliff.
jfwiw, we are seeing pretty good results (iirc 40-70% increase in open
tab counts) with the combination of eviction + multigen LRU[1] +
sizing zram swap to be 2x physical RAM
[1] https://lwn.net/Articles/856931/
> Alright, I'll add back the lockless variant (or will use yours
> drm_gem_lru) in the next revision. The code difference is very small
> after all.
>
> ...
> >> + /* prevent racing with the dma-buf importing/exporting */
> >> + if (!mutex_trylock(&gem_shrinker->dev->object_name_lock)) {
> >> + *lock_contention |= true;
> >> + goto resv_unlock;
> >> + }
> >
> > I'm not sure this is a good idea to serialize on object_name_lock.
> > Purgeable buffers should never be shared (imported or exported). So
> > at best you are avoiding evicting and immediately swapping back in, in
> > a rare case, at the cost of serializing multiple threads trying to
> > reclaim pages in parallel.
>
> The object_name_lock shouldn't cause contention in practice. But objects
> are also pinned on attachment, hence maybe this lock is indeed
> unnecessary.. I'll re-check it.
I'm not worried about contention with export/import/etc, but
contention between multiple threads hitting the shrinker in parallel.
I guess since you are using trylock, it won't *block* the other
threads hitting shrinker, but they'll just end up looping in
do_shrink_slab() because they are hitting contention.
I'd have to do some experiments to see how it works out in practice,
but my gut feel is that it isn't a good idea
BR,
-R
> --
> Best regards,
> Dmitry
Re: [Intel-gfx] [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker
()
On Thu, May 26, 2022 at 4:55 PM Dmitry Osipenko
wrote:
>
> Introduce a common DRM SHMEM shrinker framework that allows to reduce
> code duplication among DRM drivers by replacing theirs custom shrinker
> implementations with the generic shrinker.
>
> In order to start using DRM SHMEM shrinker drivers should:
>
> 1. Implement new evict() shmem object callback.
> 2. Register shrinker using drm_gem_shmem_shrinker_register(drm_device).
> 3. Use drm_gem_shmem_set_purgeable(shmem) and alike API functions to
>activate shrinking of shmem GEMs.
>
> This patch is based on a ideas borrowed from Rob's Clark MSM shrinker,
> Thomas' Zimmermann variant of SHMEM shrinker and Intel's i915 shrinker.
>
> Signed-off-by: Daniel Almeida
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c| 540 --
> .../gpu/drm/panfrost/panfrost_gem_shrinker.c | 9 +-
> drivers/gpu/drm/virtio/virtgpu_drv.h | 3 +
> include/drm/drm_device.h | 4 +
> include/drm/drm_gem_shmem_helper.h| 87 ++-
> 5 files changed, 594 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 555fe212bd98..4cd0b5913492 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -126,6 +126,42 @@ struct drm_gem_shmem_object *drm_gem_shmem_create(struct
> drm_device *dev, size_t
> }
> EXPORT_SYMBOL_GPL(drm_gem_shmem_create);
>
> +static bool drm_gem_shmem_is_evictable(struct drm_gem_shmem_object *shmem)
> +{
> + return (shmem->madv >= 0) && shmem->evict &&
> + shmem->eviction_enabled && shmem->pages_use_count &&
> + !shmem->pages_pin_count && !shmem->base.dma_buf &&
> + !shmem->base.import_attach && shmem->sgt && !shmem->evicted;
> +}
> +
> +static void
> +drm_gem_shmem_update_pages_state(struct drm_gem_shmem_object *shmem)
> +{
> + struct drm_gem_object *obj = &shmem->base;
> + struct drm_gem_shmem_shrinker *gem_shrinker =
> obj->dev->shmem_shrinker;
> +
> + dma_resv_assert_held(shmem->base.resv);
> +
> + if (!gem_shrinker || obj->import_attach)
> + return;
> +
> + mutex_lock(&gem_shrinker->lock);
> +
> + if (drm_gem_shmem_is_evictable(shmem) ||
> + drm_gem_shmem_is_purgeable(shmem))
> + list_move_tail(&shmem->madv_list,
> &gem_shrinker->lru_evictable);
> + else if (shmem->madv < 0)
> + list_del_init(&shmem->madv_list);
> + else if (shmem->evicted)
> + list_move_tail(&shmem->madv_list, &gem_shrinker->lru_evicted);
> + else if (!shmem->pages)
> + list_del_init(&shmem->madv_list);
> + else
> + list_move_tail(&shmem->madv_list, &gem_shrinker->lru_pinned);
> +
> + mutex_unlock(&gem_shrinker->lock);
> +}
> +
> /**
> * drm_gem_shmem_free - Free resources associated with a shmem GEM object
> * @shmem: shmem GEM object to free
> @@ -142,6 +178,9 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> *shmem)
> } else {
> dma_resv_lock(shmem->base.resv, NULL);
>
> + /* take out shmem GEM object from the memory shrinker */
> + drm_gem_shmem_madvise(shmem, -1);
> +
> WARN_ON(shmem->vmap_use_count);
>
> if (shmem->sgt) {
> @@ -150,7 +189,7 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> *shmem)
> sg_free_table(shmem->sgt);
> kfree(shmem->sgt);
> }
> - if (shmem->pages)
> + if (shmem->pages_use_count)
> drm_gem_shmem_put_pages(shmem);
>
> WARN_ON(shmem->pages_use_count);
> @@ -163,18 +202,82 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> *shmem)
> }
> EXPORT_SYMBOL_GPL(drm_gem_shmem_free);
>
> -static int drm_gem_shmem_get_pages(struct drm_gem_shmem_object *shmem)
> +/**
> + * drm_gem_shmem_set_evictable() - Make GEM evictable by memory shrinker
> + * @shmem: shmem GEM object
> + *
> + * Tell memory shrinker that this GEM can be evicted. Initially eviction is
> + * disabled for all GEMs. If GEM was purged, then -ENOMEM is returned.
> + *
> + * Returns:
> + * 0 on success or a negative error code on failure.
> + */
> +int drm_gem_shmem_set_evictable(struct drm_gem_shmem_object *shmem)
> +{
> + dma_resv_lock(shmem->base.resv, NULL);
> +
> + if (shmem->madv < 0)
> + return -ENOMEM;
> +
> + shmem->eviction_enabled = true;
> +
> + dma_resv_unlock(shmem->base.resv);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(drm_gem_shmem_set_evictable);
> +
> +/**
> + * drm_gem_shmem_set_purgeable() - Make GEM purgeable by memory shrinker
> + * @shmem: shmem GEM object
> + *
> + * Tell memory shrinker that this GEM can be purged. Initially purging is
> + * disabled for al
Re: [Intel-gfx] [PATCH v6 00/22] Add generic memory shrinker to VirtIO-GPU and Panfrost DRM drivers
On Tue, Jun 28, 2022 at 5:51 AM Dmitry Osipenko
wrote:
>
> On 6/28/22 15:31, Robin Murphy wrote:
> > ->8-
> > [ 68.295951] ==
> > [ 68.295956] WARNING: possible circular locking dependency detected
> > [ 68.295963] 5.19.0-rc3+ #400 Not tainted
> > [ 68.295972] --
> > [ 68.295977] cc1/295 is trying to acquire lock:
> > [ 68.295986] 08d7f1a0
> > (reservation_ww_class_mutex){+.+.}-{3:3}, at: drm_gem_shmem_free+0x7c/0x198
> > [ 68.296036]
> > [ 68.296036] but task is already holding lock:
> > [ 68.296041] 8c14b820 (fs_reclaim){+.+.}-{0:0}, at:
> > __alloc_pages_slowpath.constprop.0+0x4d8/0x1470
> > [ 68.296080]
> > [ 68.296080] which lock already depends on the new lock.
> > [ 68.296080]
> > [ 68.296085]
> > [ 68.296085] the existing dependency chain (in reverse order) is:
> > [ 68.296090]
> > [ 68.296090] -> #1 (fs_reclaim){+.+.}-{0:0}:
> > [ 68.296111]fs_reclaim_acquire+0xb8/0x150
> > [ 68.296130]dma_resv_lockdep+0x298/0x3fc
> > [ 68.296148]do_one_initcall+0xe4/0x5f8
> > [ 68.296163]kernel_init_freeable+0x414/0x49c
> > [ 68.296180]kernel_init+0x2c/0x148
> > [ 68.296195]ret_from_fork+0x10/0x20
> > [ 68.296207]
> > [ 68.296207] -> #0 (reservation_ww_class_mutex){+.+.}-{3:3}:
> > [ 68.296229]__lock_acquire+0x1724/0x2398
> > [ 68.296246]lock_acquire+0x218/0x5b0
> > [ 68.296260]__ww_mutex_lock.constprop.0+0x158/0x2378
> > [ 68.296277]ww_mutex_lock+0x7c/0x4d8
> > [ 68.296291]drm_gem_shmem_free+0x7c/0x198
> > [ 68.296304]panfrost_gem_free_object+0x118/0x138
> > [ 68.296318]drm_gem_object_free+0x40/0x68
> > [ 68.296334]drm_gem_shmem_shrinker_run_objects_scan+0x42c/0x5b8
> > [ 68.296352]drm_gem_shmem_shrinker_scan_objects+0xa4/0x170
> > [ 68.296368]do_shrink_slab+0x220/0x808
> > [ 68.296381]shrink_slab+0x11c/0x408
> > [ 68.296392]shrink_node+0x6ac/0xb90
> > [ 68.296403]do_try_to_free_pages+0x1dc/0x8d0
> > [ 68.296416]try_to_free_pages+0x1ec/0x5b0
> > [ 68.296429]__alloc_pages_slowpath.constprop.0+0x528/0x1470
> > [ 68.296444]__alloc_pages+0x4e0/0x5b8
> > [ 68.296455]__folio_alloc+0x24/0x60
> > [ 68.296467]vma_alloc_folio+0xb8/0x2f8
> > [ 68.296483]alloc_zeroed_user_highpage_movable+0x58/0x68
> > [ 68.296498]__handle_mm_fault+0x918/0x12a8
> > [ 68.296513]handle_mm_fault+0x130/0x300
> > [ 68.296527]do_page_fault+0x1d0/0x568
> > [ 68.296539]do_translation_fault+0xa0/0xb8
> > [ 68.296551]do_mem_abort+0x68/0xf8
> > [ 68.296562]el0_da+0x74/0x100
> > [ 68.296572]el0t_64_sync_handler+0x68/0xc0
> > [ 68.296585]el0t_64_sync+0x18c/0x190
> > [ 68.296596]
> > [ 68.296596] other info that might help us debug this:
> > [ 68.296596]
> > [ 68.296601] Possible unsafe locking scenario:
> > [ 68.296601]
> > [ 68.296604]CPU0CPU1
> > [ 68.296608]
> > [ 68.296612] lock(fs_reclaim);
> > [ 68.296622] lock(reservation_ww_class_mutex);
> > [ 68.296633]lock(fs_reclaim);
> > [ 68.296644] lock(reservation_ww_class_mutex);
> > [ 68.296654]
> > [ 68.296654] *** DEADLOCK ***
>
> This splat could be ignored for now. I'm aware about it, although
> haven't looked closely at how to fix it since it's a kind of a lockdep
> misreporting.
The lockdep splat could be fixed with something similar to what I've
done in msm, ie. basically just not acquire the lock in the finalizer:
https://patchwork.freedesktop.org/patch/489364/
There is one gotcha to watch for, as danvet pointed out
(scan_objects() could still see the obj in the LRU before the
finalizer removes it), but if scan_objects() does the
kref_get_unless_zero() trick, it is safe.
BR,
-R
[Intel-gfx] [PATCH] drm/i915: Remove __dma_fence_is_chain()
From: Rob Clark
drive-by cleanup
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
index 319936f91ac5..667841780514 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
@@ -73,11 +73,6 @@ static void fence_set_priority(struct dma_fence *fence,
rcu_read_unlock();
}
-static inline bool __dma_fence_is_chain(const struct dma_fence *fence)
-{
- return fence->ops == &dma_fence_chain_ops;
-}
-
void i915_gem_fence_wait_priority(struct dma_fence *fence,
const struct i915_sched_attr *attr)
{
@@ -93,7 +88,7 @@ void i915_gem_fence_wait_priority(struct dma_fence *fence,
for (i = 0; i < array->num_fences; i++)
fence_set_priority(array->fences[i], attr);
- } else if (__dma_fence_is_chain(fence)) {
+ } else if (dma_fence_is_chain(fence)) {
struct dma_fence *iter;
/* The chain is ordered; if we boost the last, we boost all */
--
2.36.1
Re: [Intel-gfx] [Freedreno] [PATCH v4 00/14] drm/hdcp: Pull HDCP auth/exchange/check into helpers
On Thu, Nov 4, 2021 at 8:04 PM Sean Paul wrote: > > From: Sean Paul > > Just me with another revision of HDCP support for msm. > > This v4 patch series is mostly a retread of v3 with the following > changes: > - rebased on Bjorn's displayport-controller register refactor > - another change to the dt bindings to remove the compatible string added in > v3 > - updated review tags > > I'm missing reviews on the core, i915 patches, and the final patch. It would > be > fantastic to get some feedback on these before the set once again drifts too > far > from -tip and I need a painful rebase :-) > > Thank you to the reviewers for their feedback thus far! > > Please take a look, It looks like all but the last two (msm specific) patches have at least a-b or r-b.. I'll try and get someone to look at those last two Any thoughts about preferred way to land this. I currently have a few of the msm patches which don't depend on core patches in msm-next-staging, but I can drop those before it gets pushed to msm-next. Maybe we want a topic branch that both msm and i915 can pull into their -next branches? BR, -R > > Sean > > Link: https://patchwork.freedesktop.org/series/94623/ #v1 > Link: https://patchwork.freedesktop.org/series/94713/ #v2 > Link: https://patchwork.freedesktop.org/series/94712/ #v3 > > Sean Paul (14): > drm/hdcp: Add drm_hdcp_atomic_check() > drm/hdcp: Avoid changing crtc state in hdcp atomic check > drm/hdcp: Update property value on content type and user changes > drm/hdcp: Expand HDCP helper library for enable/disable/check > drm/i915/hdcp: Consolidate HDCP setup/state cache > drm/i915/hdcp: Retain hdcp_capable return codes > drm/i915/hdcp: Use HDCP helpers for i915 > drm/msm/dpu_kms: Re-order dpu includes > drm/msm/dpu: Remove useless checks in dpu_encoder > drm/msm/dpu: Remove encoder->enable() hack > drm/msm/dp: Re-order dp_audio_put in deinit_sub_modules > dt-bindings: msm/dp: Add bindings for HDCP registers > arm64: dts: qcom: sc7180: Add support for HDCP in dp-controller > drm/msm: Implement HDCP 1.x using the new drm HDCP helpers > > .../bindings/display/msm/dp-controller.yaml |8 +- > arch/arm64/boot/dts/qcom/sc7180.dtsi |8 +- > drivers/gpu/drm/drm_hdcp.c| 1197 - > drivers/gpu/drm/i915/display/intel_atomic.c |7 +- > drivers/gpu/drm/i915/display/intel_ddi.c | 29 +- > .../drm/i915/display/intel_display_debugfs.c | 11 +- > .../drm/i915/display/intel_display_types.h| 58 +- > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 345 ++--- > drivers/gpu/drm/i915/display/intel_dp_mst.c | 17 +- > drivers/gpu/drm/i915/display/intel_hdcp.c | 1011 +++--- > drivers/gpu/drm/i915/display/intel_hdcp.h | 36 +- > drivers/gpu/drm/i915/display/intel_hdmi.c | 256 ++-- > drivers/gpu/drm/msm/Makefile |1 + > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 17 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 30 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h |2 - > drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h |4 - > drivers/gpu/drm/msm/dp/dp_debug.c | 46 +- > drivers/gpu/drm/msm/dp/dp_debug.h |6 +- > drivers/gpu/drm/msm/dp/dp_display.c | 48 +- > drivers/gpu/drm/msm/dp/dp_display.h |5 + > drivers/gpu/drm/msm/dp/dp_drm.c | 68 +- > drivers/gpu/drm/msm/dp/dp_drm.h |5 + > drivers/gpu/drm/msm/dp/dp_hdcp.c | 462 +++ > drivers/gpu/drm/msm/dp/dp_hdcp.h | 27 + > drivers/gpu/drm/msm/dp/dp_parser.c| 20 +- > drivers/gpu/drm/msm/dp/dp_parser.h|4 + > drivers/gpu/drm/msm/dp/dp_reg.h | 32 +- > drivers/gpu/drm/msm/msm_atomic.c | 15 + > include/drm/drm_hdcp.h| 194 +++ > 30 files changed, 2592 insertions(+), 1377 deletions(-) > create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.c > create mode 100644 drivers/gpu/drm/msm/dp/dp_hdcp.h > > -- > Sean Paul, Software Engineer, Google / Chromium OS >
Re: [Intel-gfx] [Freedreno] [PATCH v4 13/14] arm64: dts: qcom: sc7180: Add support for HDCP in dp-controller
On Thu, Nov 4, 2021 at 8:05 PM Sean Paul wrote:
>
> From: Sean Paul
>
> This patch adds the register ranges required for HDCP key injection and
> HDCP TrustZone interaction as described in the dt-bindings for the
> sc7180 dp controller. Now that these are supported, change the
> compatible string to "dp-hdcp".
>
> Signed-off-by: Sean Paul
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-15-s...@poorly.run
> #v1
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-14-s...@poorly.run
> #v2
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20211001151145.55916-14-s...@poorly.run
> #v3
>
> Changes in v3:
> -Split off into a new patch containing just the dts change (Stephen)
> -Add hdcp compatible string (Stephen)
> Changes in v4:
> -Rebase on Bjorn's multi-dp patchset
> ---
> arch/arm64/boot/dts/qcom/sc7180.dtsi | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> index c8921e2d6480..838270f70b62 100644
> --- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
> @@ -3088,7 +3088,13 @@ mdss_dp: displayport-controller@ae9 {
> compatible = "qcom,sc7180-dp";
> status = "disabled";
>
> - reg = <0 0x0ae9 0 0x1400>;
> + reg = <0 0x0ae9 0 0x200>,
> + <0 0x0ae90200 0 0x200>,
> + <0 0x0ae90400 0 0xc00>,
> + <0 0x0ae91000 0 0x400>,
> + <0 0x0ae91400 0 0x400>,
> + <0 0x0aed1000 0 0x175>,
> + <0 0x0aee1000 0 0x2c>;
So one small issue, if someone tries to get linux running on a sc7180
windows laptop (which uses qcom's tz instead of the CrOS tz), things
will go BOOM!
We might want instead to move this somewhere chromebook specific,
maybe sc7180-trogdor.dtsi?
BR,
-R
>
> interrupt-parent = <&mdss>;
> interrupts = <12>;
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
Re: [Intel-gfx] [PATCH v6 17/22] drm/shmem-helper: Add generic memory shrinker
On Sun, Jun 5, 2022 at 9:47 AM Daniel Vetter wrote:
>
> On Fri, 27 May 2022 at 01:55, Dmitry Osipenko
> wrote:
> >
> > Introduce a common DRM SHMEM shrinker framework that allows to reduce
> > code duplication among DRM drivers by replacing theirs custom shrinker
> > implementations with the generic shrinker.
> >
> > In order to start using DRM SHMEM shrinker drivers should:
> >
> > 1. Implement new evict() shmem object callback.
> > 2. Register shrinker using drm_gem_shmem_shrinker_register(drm_device).
> > 3. Use drm_gem_shmem_set_purgeable(shmem) and alike API functions to
> >activate shrinking of shmem GEMs.
> >
> > This patch is based on a ideas borrowed from Rob's Clark MSM shrinker,
> > Thomas' Zimmermann variant of SHMEM shrinker and Intel's i915 shrinker.
> >
> > Signed-off-by: Daniel Almeida
> > Signed-off-by: Dmitry Osipenko
>
> So I guess I get a price for being blind since forever, because this
> thing existed since at least 2013. I just stumbled over
> llist_lru.[hc], a purpose built list helper for shrinkers. I think we
> should try to adopt that so that our gpu shrinkers look more like
> shrinkers for everything else.
followup from a bit of irc discussion w/ danvet about list_lru:
* It seems to be missing a way to bail out of iteration before
nr_to_scan is hit.. which is going to be inconvenient if you
want to allow active bos on the LRU but bail scanning once
you encounter the first one.
* Not sure if the numa node awareness is super useful for GEM
bos
First issue is perhaps not too hard to fix. But maybe a better
idea is a drm_gem_lru helper type thing which is more tailored
to GEM buffers?
BR,
-R
> Apologies for this, since I fear this might cause a bit of churn.
> Hopefully it's all contained to the list manipulation code in shmem
> helpers, I don't think this should leak any further.
> -Daniel
>
> > ---
> > drivers/gpu/drm/drm_gem_shmem_helper.c| 540 --
> > .../gpu/drm/panfrost/panfrost_gem_shrinker.c | 9 +-
> > drivers/gpu/drm/virtio/virtgpu_drv.h | 3 +
> > include/drm/drm_device.h | 4 +
> > include/drm/drm_gem_shmem_helper.h| 87 ++-
> > 5 files changed, 594 insertions(+), 49 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > index 555fe212bd98..4cd0b5913492 100644
> > --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> > @@ -126,6 +126,42 @@ struct drm_gem_shmem_object
> > *drm_gem_shmem_create(struct drm_device *dev, size_t
> > }
> > EXPORT_SYMBOL_GPL(drm_gem_shmem_create);
> >
> > +static bool drm_gem_shmem_is_evictable(struct drm_gem_shmem_object *shmem)
> > +{
> > + return (shmem->madv >= 0) && shmem->evict &&
> > + shmem->eviction_enabled && shmem->pages_use_count &&
> > + !shmem->pages_pin_count && !shmem->base.dma_buf &&
> > + !shmem->base.import_attach && shmem->sgt && !shmem->evicted;
> > +}
> > +
> > +static void
> > +drm_gem_shmem_update_pages_state(struct drm_gem_shmem_object *shmem)
> > +{
> > + struct drm_gem_object *obj = &shmem->base;
> > + struct drm_gem_shmem_shrinker *gem_shrinker =
> > obj->dev->shmem_shrinker;
> > +
> > + dma_resv_assert_held(shmem->base.resv);
> > +
> > + if (!gem_shrinker || obj->import_attach)
> > + return;
> > +
> > + mutex_lock(&gem_shrinker->lock);
> > +
> > + if (drm_gem_shmem_is_evictable(shmem) ||
> > + drm_gem_shmem_is_purgeable(shmem))
> > + list_move_tail(&shmem->madv_list,
> > &gem_shrinker->lru_evictable);
> > + else if (shmem->madv < 0)
> > + list_del_init(&shmem->madv_list);
> > + else if (shmem->evicted)
> > + list_move_tail(&shmem->madv_list,
> > &gem_shrinker->lru_evicted);
> > + else if (!shmem->pages)
> > + list_del_init(&shmem->madv_list);
> > + else
> > + list_move_tail(&shmem->madv_list,
> > &gem_shrinker->lru_pinned);
> > +
> > + mutex_unlock(&gem_shrinker->lock);
> > +}
> > +
> > /**
> > * drm_gem_shmem_free - Free resources associated with a shmem GEM object
> > * @shmem: shmem GEM object to free
> > @@ -142,6 +178,9 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> > *shmem)
> > } else {
> > dma_resv_lock(shmem->base.resv, NULL);
> >
> > + /* take out shmem GEM object from the memory shrinker */
> > + drm_gem_shmem_madvise(shmem, -1);
> > +
> > WARN_ON(shmem->vmap_use_count);
> >
> > if (shmem->sgt) {
> > @@ -150,7 +189,7 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> > *shmem)
> > sg_free_table(shmem->sgt);
> > kfree(shmem->sgt);
> > }
> > - if (shmem->pages)
> > + if (shmem->pages_use_count)
> >
Re: [Intel-gfx] [CI 8/8] drm/i915: Expose client engine utilisation via fdinfo
On Tue, Apr 5, 2022 at 1:09 AM Tvrtko Ursulin
wrote:
>
>
> On 04/04/2022 16:36, Daniel Vetter wrote:
> > On Mon, Apr 04, 2022 at 10:23:53AM +0100, Tvrtko Ursulin wrote:
> >>
> >> + Dave and Daniel
> >>
> >> Guys, are you okay with merging this via drm-intel-gt-next? It is one new
> >> file at Documentation/gpu/drm-usage-stats.rst only which is outside i915.
> >> It
> >> has acks from Christian and Rob.
> >
> > Acked-by: Daniel Vetter
>
> Thanks, pushed now.
>
> Rob - you can proceed with your driver at your leisure. I will re-send
> the rebased gputop to igt-dev shortly and copy you.
Thx, I was planning to respin, but trying to figure out where the
drm-usage-stats.rst patch ended up (since I can't add to a file that
isn't there
BR,
-R
> Regards,
>
> Tvrtko
>
> >>
> >> Daniel, series is also fully reviewed and IGT reviewed and ready. Rob also
> >> demonstrated the approach works for msm when using the vendor agnosstic
> >> gputop tool I sketched out (see
> >> 20220225202614.225197-3-robdcl...@gmail.com).
> >>
> >> My plan is to merge the i915 support with the common spec and intel_gpu_top
> >> on the IGT side. Then follow-up with vendor agnostic gputop and later yet
> >> potentially re-visit the AMD side by re-sending the patch which tweaks the
> >> fdinfo format there and adds support for relative engine utilisation as
> >> provided by amdgpu.
> >>
> >> Regards,
> >>
> >> Tvrtko
> >>
> >> On 04/04/2022 10:12, Tvrtko Ursulin wrote:
> >>>
> >>> On 01/04/2022 15:22, Tvrtko Ursulin wrote:
> >>>> From: Tvrtko Ursulin
> >>>>
> >>>> Similar to AMD commit
> >>>> 874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
> >>>> infrastructure added in previous patches, we add basic client info
> >>>> and GPU engine utilisation for i915.
> >>>>
> >>>> Example of the output:
> >>>>
> >>>> pos:0
> >>>> flags: 012
> >>>> mnt_id: 21
> >>>> drm-driver: i915
> >>>> drm-pdev: :00:02.0
> >>>> drm-client-id: 7
> >>>> drm-engine-render: 9288864723 ns
> >>>> drm-engine-copy:2035071108 ns
> >>>> drm-engine-video: 0 ns
> >>>> drm-engine-video-enhance: 0 ns
> >>>>
> >>>> v2:
> >>>>* Update for removal of name and pid.
> >>>>
> >>>> v3:
> >>>>* Use drm_driver.name.
> >>>>
> >>>> v4:
> >>>>* Added drm-engine-capacity- tag.
> >>>>* Fix typo. (Umesh)
> >>>>
> >>>> v5:
> >>>>* Don't output engine data before Gen8.
> >>>>
> >>>> Signed-off-by: Tvrtko Ursulin
> >>>> Cc: David M Nieto
> >>>> Cc: Christian König
> >>>> Cc: Daniel Vetter
> >>>> Cc: Chris Healy
> >>>> Acked-by: Christian König
> >>>> Reviewed-by: Umesh Nerlige Ramappa
> >>>
> >>> Forgot to apply an earlier:
> >>>
> >>> Acked-by: Rob Clark
> >>>
> >>> Regards,
> >>>
> >>> Tvrtko
> >>>
> >>>> ---
> >>>>Documentation/gpu/drm-usage-stats.rst | 6 ++
> >>>>Documentation/gpu/i915.rst | 28 +
> >>>>drivers/gpu/drm/i915/i915_driver.c | 3 +
> >>>>drivers/gpu/drm/i915/i915_drm_client.c | 84 ++
> >>>>drivers/gpu/drm/i915/i915_drm_client.h | 4 ++
> >>>>5 files changed, 125 insertions(+)
> >>>>
> >>>> diff --git a/Documentation/gpu/drm-usage-stats.rst
> >>>> b/Documentation/gpu/drm-usage-stats.rst
> >>>> index b8cc28f4da6f..6c9f166a8d6f 100644
> >>>> --- a/Documentation/gpu/drm-usage-stats.rst
> >>>> +++ b/Documentation/gpu/drm-usage-stats.rst
> >>>> @@ -104,3 +104,9 @@ object belong to this client, in the respective
> >>>> memory region.
> >>>>Default unit shall be bytes with optional unit specifiers of 'KiB'
> >>>> or 'MiB'
> >>>>indicating kibi- or mebi-bytes.
> >>>> +
> >>>
Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
On Thu, Mar 31, 2022 at 8:20 AM Daniel Vetter wrote:
>
> The stuff never really worked, and leads to lots of fun because it
> out-of-order frees atomic states. Which upsets KASAN, among other
> things.
>
> For async updates we now have a more solid solution with the
> ->atomic_async_check and ->atomic_async_commit hooks. Support for that
> for msm and vc4 landed. nouveau and i915 have their own commit
> routines, doing something similar.
>
> For everyone else it's probably better to remove the use-after-free
> bug, and encourage folks to use the async support instead. The
> affected drivers which register a legacy cursor plane and don't either
> use the new async stuff or their own commit routine are: amdgpu,
> atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx.
>
> Inspired by an amdgpu bug report.
>
> v2: Drop RFC, I think with amdgpu converted over to use
> atomic_async_check/commit done in
>
> commit 674e78acae0dfb4beb56132e41cbae5b60f7d662
> Author: Nicholas Kazlauskas
> Date: Wed Dec 5 14:59:07 2018 -0500
>
> drm/amd/display: Add fast path for cursor plane updates
>
> we don't have any driver anymore where we have userspace expecting
> solid legacy cursor support _and_ they are using the atomic helpers in
> their fully glory. So we can retire this.
>
> v3: Paper over msm and i915 regression. The complete_all is the only
> thing missing afaict.
>
> v4: Fixup i915 fixup ...
>
> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
> References:
> https://lore.kernel.org/all/20220221134155.125447-9-max...@cerno.tech/
> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
> Cc: Maxime Ripard
> Tested-by: Maxime Ripard
> Cc: mikita.lip...@amd.com
> Cc: Michel Dänzer
> Cc: harry.wentl...@amd.com
> Cc: Rob Clark
> Cc: "Kazlauskas, Nicholas"
> Cc: Dmitry Osipenko
> Signed-off-by: Daniel Vetter
Tested-by: Rob Clark
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 13 -
> drivers/gpu/drm/i915/display/intel_display.c | 14 ++
> drivers/gpu/drm/msm/msm_atomic.c | 2 ++
> 3 files changed, 16 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 9603193d2fa1..a2899af82b4a 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1498,13 +1498,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device
> *dev,
> int i, ret;
> unsigned int crtc_mask = 0;
>
> -/*
> - * Legacy cursor ioctls are completely unsynced, and userspace
> - * relies on that (by doing tons of cursor updates).
> - */
> - if (old_state->legacy_cursor_update)
> - return;
> -
> for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state,
> new_crtc_state, i) {
> if (!new_crtc_state->active)
> continue;
> @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct
> drm_atomic_state *state,
> continue;
> }
>
> - /* Legacy cursor updates are fully unsynced. */
> - if (state->legacy_cursor_update) {
> - complete_all(&commit->flip_done);
> - continue;
> - }
> -
> if (!new_crtc_state->event) {
> commit->event = kzalloc(sizeof(*commit->event),
> GFP_KERNEL);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index d2abe0e430bf..6ca5a6e7703b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -8799,6 +8799,20 @@ static int intel_atomic_commit(struct drm_device *dev,
> intel_runtime_pm_put(&dev_priv->runtime_pm, state->wakeref);
> return ret;
> }
> +
> + /*
> +* FIXME: Cut over to (async) commit helpers instead of hand-rolling
> +* everything.
> +*/
> + if (state->base.legacy_cursor_update) {
> + struct intel_crtc_state *new_crtc_state;
> + struct intel_crtc *crtc;
> + int i;
> +
> + for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state,
> i)
> + complete_all(&new_crtc_state->uapi.commit->flip_done);
> + }
> +
> intel_shared_dpll_swap_state(state);
>
Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang wrote:
>
>
>
> On 3/31/2022 8:20 AM, Daniel Vetter wrote:
> > The stuff never really worked, and leads to lots of fun because it
> > out-of-order frees atomic states. Which upsets KASAN, among other
> > things.
> >
> > For async updates we now have a more solid solution with the
> > ->atomic_async_check and ->atomic_async_commit hooks. Support for that
> > for msm and vc4 landed. nouveau and i915 have their own commit
> > routines, doing something similar.
> >
> > For everyone else it's probably better to remove the use-after-free
> > bug, and encourage folks to use the async support instead. The
> > affected drivers which register a legacy cursor plane and don't either
> > use the new async stuff or their own commit routine are: amdgpu,
> > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx.
> >
> > Inspired by an amdgpu bug report.
> >
> > v2: Drop RFC, I think with amdgpu converted over to use
> > atomic_async_check/commit done in
> >
> > commit 674e78acae0dfb4beb56132e41cbae5b60f7d662
> > Author: Nicholas Kazlauskas
> > Date: Wed Dec 5 14:59:07 2018 -0500
> >
> > drm/amd/display: Add fast path for cursor plane updates
> >
> > we don't have any driver anymore where we have userspace expecting
> > solid legacy cursor support _and_ they are using the atomic helpers in
> > their fully glory. So we can retire this.
> >
> > v3: Paper over msm and i915 regression. The complete_all is the only
> > thing missing afaict.
> >
> > v4: Fixup i915 fixup ...
> >
> > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
> > References:
> > https://lore.kernel.org/all/20220221134155.125447-9-max...@cerno.tech/
> > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
> > Cc: Maxime Ripard
> > Tested-by: Maxime Ripard
> > Cc: mikita.lip...@amd.com
> > Cc: Michel Dänzer
> > Cc: harry.wentl...@amd.com
> > Cc: Rob Clark
>
> Hey Rob,
>
> I saw your tested-by and reviewed-by tags on Patchwork. Just curious,
> what device did you test on?
I was testing on strongbad.. v5.18-rc1 + patches (notably, revert
80253168dbfd ("drm: of: Lookup if child node has panel or bridge")
I think the display setup shouldn't be significantly different than
limozeen (ie. it's an eDP panel). But I didn't do much start/stop
ui.. I was mostly looking to make sure cursor movements weren't
causing fps drops ;-)
BR,
-R
> I'm hitting several instances of this error when doing a start/stop ui
> on Lazor Chromebook with this patch:
>
> [ 3092.608322] CPU: 2 PID: 18579 Comm: DrmThread Tainted: GW
> 5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155
> e5912cd286513b064a82a38938b3fdef86b079aa
> [ 3092.622880] Hardware name: Google Lazor Limozeen without Touchscreen
> (rev4) (DT)
> [ 3092.630492] pstate: 8049 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS
> BTYPE=--)
> [ 3092.637664] pc : dpu_crtc_atomic_flush+0x9c/0x144
> [ 3092.642523] lr : dpu_crtc_atomic_flush+0x60/0x144
> [ 3092.647379] sp : ffc00c1e3760
> [ 3092.650805] x29: ffc00c1e3760 x28: ff80985dd800 x27:
> 0425
> [ 3092.658164] x26: ff80985dc500 x25: ff80985ddc00 x24:
> ffdf8ae3b6f0
> [ 3092.665522] x23: x22: x21:
> ff809b82da00
> [ 3092.672890] x20: ff80840e1000 x19: ff80840e2000 x18:
> 1000
> [ 3092.680255] x17: 0400 x16: 0100 x15:
> 003b
> [ 3092.687622] x14: x13: 0002 x12:
> 0003
> [ 3092.694979] x11: ff8084009000 x10: 0040 x9 :
> 0040
> [ 3092.702340] x8 : 0300 x7 : 000c x6 :
> 0004
> [ 3092.709698] x5 : 0320 x4 : 0018 x3 :
>
> [ 3092.717056] x2 : x1 : 7bfb38b2a3a89800 x0 :
> ff809a1eb300
> [ 3092.724424] Call trace:
> [ 3092.726958] dpu_crtc_atomic_flush+0x9c/0x144
> [ 3092.731463] drm_atomic_helper_commit_planes+0x1bc/0x1c4
> [ 3092.736944] msm_atomic_commit_tail+0x23c/0x3e0
> [ 3092.741627] commit_tail+0x7c/0xfc
> [ 3092.745145] drm_atomic_helper_commit+0x158/0x15c
> [ 3092.749998] drm_atomic_commit+0x60/0x74
> [ 3092.754055] drm_atomic_helper_update_plane+0x100/0x110
> [ 3092.759449] __setplane_atomic+0x11c/0x120
> [ 3092.763685] drm_mode_cursor_universal+0x188/0x22c
> [ 3092.768633] drm_mode_cursor_common+0x120/0x1f8
> [ 3092.773310] drm_mode_cursor_ioctl+0x68/0x8c
> [ 3092.21] drm_ioctl_kernel+0xe8
Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar wrote:
>
> Hi Rob and Daniel
>
> On 4/7/2022 3:51 PM, Rob Clark wrote:
> > On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang
> > wrote:
> >>
> >>
> >>
> >> On 3/31/2022 8:20 AM, Daniel Vetter wrote:
> >>> The stuff never really worked, and leads to lots of fun because it
> >>> out-of-order frees atomic states. Which upsets KASAN, among other
> >>> things.
> >>>
> >>> For async updates we now have a more solid solution with the
> >>> ->atomic_async_check and ->atomic_async_commit hooks. Support for that
> >>> for msm and vc4 landed. nouveau and i915 have their own commit
> >>> routines, doing something similar.
> >>>
> >>> For everyone else it's probably better to remove the use-after-free
> >>> bug, and encourage folks to use the async support instead. The
> >>> affected drivers which register a legacy cursor plane and don't either
> >>> use the new async stuff or their own commit routine are: amdgpu,
> >>> atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx.
> >>>
> >>> Inspired by an amdgpu bug report.
> >>>
> >>> v2: Drop RFC, I think with amdgpu converted over to use
> >>> atomic_async_check/commit done in
> >>>
> >>> commit 674e78acae0dfb4beb56132e41cbae5b60f7d662
> >>> Author: Nicholas Kazlauskas
> >>> Date: Wed Dec 5 14:59:07 2018 -0500
> >>>
> >>> drm/amd/display: Add fast path for cursor plane updates
> >>>
> >>> we don't have any driver anymore where we have userspace expecting
> >>> solid legacy cursor support _and_ they are using the atomic helpers in
> >>> their fully glory. So we can retire this.
> >>>
> >>> v3: Paper over msm and i915 regression. The complete_all is the only
> >>> thing missing afaict.
> >>>
> >>> v4: Fixup i915 fixup ...
> >>>
> >>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
> >>> References:
> >>> https://lore.kernel.org/all/20220221134155.125447-9-max...@cerno.tech/
> >>> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
> >>> Cc: Maxime Ripard
> >>> Tested-by: Maxime Ripard
> >>> Cc: mikita.lip...@amd.com
> >>> Cc: Michel Dänzer
> >>> Cc: harry.wentl...@amd.com
> >>> Cc: Rob Clark
> >>
> >> Hey Rob,
> >>
> >> I saw your tested-by and reviewed-by tags on Patchwork. Just curious,
> >> what device did you test on?
> >
> > I was testing on strongbad.. v5.18-rc1 + patches (notably, revert
> > 80253168dbfd ("drm: of: Lookup if child node has panel or bridge")
> >
> > I think the display setup shouldn't be significantly different than
> > limozeen (ie. it's an eDP panel). But I didn't do much start/stop
> > ui.. I was mostly looking to make sure cursor movements weren't
> > causing fps drops ;-)
> >
> > BR,
> > -R
>
> start ui/ stop ui is a basic operation for us to use IGT on msm-next.
> So we cannot let that break.
>
> I think we need to check whats causing this splat.
>
> Can we hold back this change till then?
Can you reproduce on v5.18-rc1 (plus 80253168dbfd)? I'm running a
loop of stop ui / start ui and hasn't triggered a splat yet.
Otherwise maybe you can addr2line to figure out where it crashed?
BR,
-R
> Thanks
>
> Abhinav
> >
> >> I'm hitting several instances of this error when doing a start/stop ui
> >> on Lazor Chromebook with this patch:
> >>
> >> [ 3092.608322] CPU: 2 PID: 18579 Comm: DrmThread Tainted: GW
> >>5.17.0-rc2-lockdep-00089-g7f17ab7bf567 #155
> >> e5912cd286513b064a82a38938b3fdef86b079aa
> >> [ 3092.622880] Hardware name: Google Lazor Limozeen without Touchscreen
> >> (rev4) (DT)
> >> [ 3092.630492] pstate: 8049 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS
> >> BTYPE=--)
> >> [ 3092.637664] pc : dpu_crtc_atomic_flush+0x9c/0x144
> >> [ 3092.642523] lr : dpu_crtc_atomic_flush+0x60/0x144
> >> [ 3092.647379] sp : ffc00c1e3760
> >> [ 3092.650805] x29: ffc00c1e3760 x28: ff80985dd800 x27:
> >> 0425
> >> [ 3092.658164] x26: ff80985dc500 x25: ff80985ddc00 x24:
> >> ffdf8ae3b6f0
> >> [ 3092.665522] x23: x22: 0
Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes
On Wed, Feb 2, 2022 at 7:41 AM Jani Nikula wrote:
>
> On Wed, 02 Feb 2022, Laurent Pinchart
> wrote:
> > Hi Jani,
> >
> > On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
> >> On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> >> > On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj wrote:
> >> >> Changing rcar_du driver to accomadate the change of
> >> >> drm_writeback_connector.base and drm_writeback_connector.encoder
> >> >> to a pointer the reason for which is explained in the
> >> >> Patch(drm: add writeback pointers to drm_connector).
> >> >>
> >> >> Signed-off-by: Kandpal Suraj
> >> >> ---
> >> >> drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 ++
> >> >> drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +---
> >> >> 2 files changed, 7 insertions(+), 3 deletions(-)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >> >> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >> >> index 66e8839db708..68f387a04502 100644
> >> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> >> >> @@ -72,6 +72,8 @@ struct rcar_du_crtc {
> >> >> const char *const *sources;
> >> >> unsigned int sources_count;
> >> >>
> >> >> + struct drm_connector connector;
> >> >> + struct drm_encoder encoder;
> >> >
> >> > Those fields are, at best, poorly named. Furthermore, there's no need in
> >> > this driver or in other drivers using drm_writeback_connector to create
> >> > an encoder or connector manually. Let's not polute all drivers because
> >> > i915 doesn't have its abstractions right.
> >>
> >> i915 uses the quite common model for struct inheritance:
> >>
> >> struct intel_connector {
> >> struct drm_connector base;
> >> /* ... */
> >> }
> >>
> >> Same with at least amd, ast, fsl-dcu, hisilicon, mga200, msm, nouveau,
> >> radeon, tilcdc, and vboxvideo.
> >>
> >> We could argue about the relative merits of that abstraction, but I
> >> think the bottom line is that it's popular and the drivers using it are
> >> not going to be persuaded to move away from it.
> >
> > Nobody said inheritance is bad.
> >
> >> It's no coincidence that the drivers who've implemented writeback so far
> >> (komeda, mali, rcar-du, vc4, and vkms) do not use the abstraction,
> >> because the drm_writeback_connector midlayer does, forcing the issue.
> >
> > Are you sure it's not a coincidence ? :-)
> >
> > The encoder and especially connector created by drm_writeback_connector
> > are there only because KMS requires a drm_encoder and a drm_connector to
> > be exposed to userspace (and I could argue that using a connector for
> > writeback is a hack, but that won't change). The connector is "virtual",
> > I still fail to see why i915 or any other driver would need to wrap it
> > into something else. The whole point of the drm_writeback_connector
> > abstraction is that drivers do not have to manage the writeback
> > drm_connector manually, they shouldn't touch it at all.
>
> The thing is, drm_writeback_connector_init() calling
> drm_connector_init() on the drm_connector embedded in
> drm_writeback_connector leads to that connector being added to the
> drm_device's list of connectors. Ditto for the encoder.
>
> All the driver code that handles drm_connectors would need to take into
> account they might not be embedded in intel_connector. Throughout the
> driver. Ditto for the encoders.
The assumption that a connector is embedded in intel_connector doesn't
really play that well with how bridge and panel connectors work.. so
in general this seems like a good thing to unwind.
But as a point of practicality, i915 is a large driver covering a lot
of generations of hw with a lot of users. So I can understand
changing this design isn't something that can happen quickly or
easily. IMO we should allow i915 to create it's own connector for
writeback, and just document clearly that this isn't the approach new
drivers should take. I mean, I understand idealism, but sometimes a
dose of pragmatism is needed. :-)
BR,
-R
> The point is, you can't initialize a connector or an encoder for a
> drm_device in isolation of the rest of the driver, even if it were
> supposed to be hidden away.
>
> BR,
> Jani.
>
Re: [Intel-gfx] [PATCH 8/8] drm/i915: Expose client engine utilisation via fdinfo
On Tue, Feb 22, 2022 at 6:05 AM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> Similar to AMD commit
> 874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
> infrastructure added in previous patches, we add basic client info
> and GPU engine utilisation for i915.
>
> Example of the output:
>
> pos:0
> flags: 012
> mnt_id: 21
> drm-driver: i915
> drm-pdev: :00:02.0
> drm-client-id: 7
> drm-engine-render: 9288864723 ns
> drm-engine-copy:2035071108 ns
> drm-engine-video: 0 ns
> drm-engine-video-enhance: 0 ns
>
> v2:
> * Update for removal of name and pid.
>
> v3:
> * Use drm_driver.name.
>
> v4:
> * Added drm-engine-capacity- tag.
> * Fix typo. (Umesh)
>
> Signed-off-by: Tvrtko Ursulin
> Cc: David M Nieto
> Cc: Christian König
> Cc: Daniel Vetter
> Cc: Chris Healy
> Acked-by: Christian König
> Reviewed-by: Umesh Nerlige Ramappa # v3
Acked-by: Rob Clark
> ---
> Documentation/gpu/drm-usage-stats.rst | 6 ++
> Documentation/gpu/i915.rst | 28 +
> drivers/gpu/drm/i915/i915_driver.c | 3 +
> drivers/gpu/drm/i915/i915_drm_client.c | 81 ++
> drivers/gpu/drm/i915/i915_drm_client.h | 4 ++
> 5 files changed, 122 insertions(+)
>
> diff --git a/Documentation/gpu/drm-usage-stats.rst
> b/Documentation/gpu/drm-usage-stats.rst
> index b8cc28f4da6f..6c9f166a8d6f 100644
> --- a/Documentation/gpu/drm-usage-stats.rst
> +++ b/Documentation/gpu/drm-usage-stats.rst
> @@ -104,3 +104,9 @@ object belong to this client, in the respective memory
> region.
>
> Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
> indicating kibi- or mebi-bytes.
> +
> +===
> +Driver specific implementations
> +===
> +
> +:ref:`i915-usage-stats`
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index bcaefc952764..cfc64f5795a4 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -709,3 +709,31 @@ The style guide for ``i915_reg.h``.
>
> .. kernel-doc:: drivers/gpu/drm/i915/i915_reg.h
> :doc: The i915 register macro definition style guide
> +
> +.. _i915-usage-stats:
> +
> +i915 DRM client usage stats implementation
> +==
> +
> +The drm/i915 driver implements the DRM client usage stats specification as
> +documented in :ref:`drm-client-usage-stats`.
> +
> +Example of the output showing the implemented key value pairs and entirety of
> +the currently possible format options:
> +
> +::
> +
> + pos:0
> + flags: 012
> + mnt_id: 21
> + drm-driver: i915
> + drm-pdev: :00:02.0
> + drm-client-id: 7
> + drm-engine-render: 9288864723 ns
> + drm-engine-copy:2035071108 ns
> + drm-engine-video: 0 ns
> + drm-engine-capacity-video: 2
> + drm-engine-video-enhance: 0 ns
> +
> +Possible `drm-engine-` key names are: `render`, `copy`, `video` and
> +`video-enhance`.
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index 4bf6715c5c3a..fe33e79cef8b 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -1746,6 +1746,9 @@ static const struct file_operations i915_driver_fops = {
> .read = drm_read,
> .compat_ioctl = i915_ioc32_compat_ioctl,
> .llseek = noop_llseek,
> +#ifdef CONFIG_PROC_FS
> + .show_fdinfo = i915_drm_client_fdinfo,
> +#endif
> };
>
> static int
> diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
> b/drivers/gpu/drm/i915/i915_drm_client.c
> index 91a8559bebf7..54b40f451959 100644
> --- a/drivers/gpu/drm/i915/i915_drm_client.c
> +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> @@ -7,7 +7,13 @@
> #include
> #include
>
> +#include
> +
> +#include
> +
> +#include "gem/i915_gem_context.h"
> #include "i915_drm_client.h"
> +#include "i915_file_private.h"
> #include "i915_gem.h"
> #include "i915_utils.h"
>
> @@ -68,3 +74,78 @@ void i915_drm_clients_fini(struct i915_drm_clients
> *clients)
> GEM_BUG_ON(!xa_empty(&clients->xarray));
> xa_destroy(&clients->xarray);
> }
> +
> +#ifdef CONFIG_PROC_FS
> +static const char * const uabi_class_names[] = {
> + [I915_ENGINE_CLASS_RENDER] = "render",
> + [I915_ENGINE_CLASS_COPY] = "copy",
> + [I915_ENGINE_CLASS_VIDEO] = "video",
&g
Re: [Intel-gfx] [PATCH 6/7] drm: Document fdinfo format specification
On Wed, Jan 19, 2022 at 7:09 AM Daniel Vetter wrote: > > On Thu, Jan 06, 2022 at 04:55:35PM +, Tvrtko Ursulin wrote: > > From: Tvrtko Ursulin > > > > Proposal to standardise the fdinfo text format as optionally output by DRM > > drivers. > > > > Idea is that a simple but, well defined, spec will enable generic > > userspace tools to be written while at the same time avoiding a more heavy > > handed approach of adding a mid-layer to DRM. > > > > i915 implements a subset of the spec, everything apart from the memory > > stats currently, and a matching intel_gpu_top tool exists. > > > > Open is to see if AMD can migrate to using the proposed GPU utilisation > > key-value pairs, or if they are not workable to see whether to go > > vendor specific, or if a standardised alternative can be found which is > > workable for both drivers. > > > > Same for the memory utilisation key-value pairs proposal. > > > > v2: > > * Update for removal of name and pid. > > > > v3: > > * 'Drm-driver' tag will be obtained from struct drm_driver.name. (Daniel) > > > > Signed-off-by: Tvrtko Ursulin > > Cc: David M Nieto > > Cc: Christian König > > Cc: Daniel Vetter > > Cc: Daniel Stone > > Cc: Chris Healy > > Acked-by: Christian König > > I'm assuming this ack here and later on is a "amdgpu plans to use this > too" kind of affair. Especially also in the lights of eventually using > matching semantics for cgroups and everything else tied to gpu execution > resource management. > > If not I'm mildly worried that we're creating fake-standard stuff here > which cannot actually be used by anything resembling driver-agnostic > userspace. I think I could implement something like this for drm/msm. I am a bit uncertain about the memory stats (ie. how are we intended to account for imported/exported/shared bo's)? But we already track cycles+time per submit for devfreq, it would be pretty easy to add per drm_file counters to accumulate the per-submit results. We could even track per-context (submitqueue) for processes that have more than a single context, although not sure if that is useful. And I think there is probably some room for shared helper to print parts other than the per-engine stats (and maybe memory stats, although even that could be a shared implementation for some drivers).. with a driver callback for the non-generic parts, ie. something like: drm_driver::show_client_stats(struct drm_file *, struct drm_printer *) but that can come later. If there is a tool somewhere that displays this info, that would be useful for testing my implementation. BR, -R > -Daniel > > > --- > > Documentation/gpu/drm-usage-stats.rst | 97 +++ > > Documentation/gpu/index.rst | 1 + > > 2 files changed, 98 insertions(+) > > create mode 100644 Documentation/gpu/drm-usage-stats.rst > > > > diff --git a/Documentation/gpu/drm-usage-stats.rst > > b/Documentation/gpu/drm-usage-stats.rst > > new file mode 100644 > > index ..c669026be244 > > --- /dev/null > > +++ b/Documentation/gpu/drm-usage-stats.rst > > @@ -0,0 +1,97 @@ > > +.. _drm-client-usage-stats: > > + > > +== > > +DRM client usage stats > > +== > > + > > +DRM drivers can choose to export partly standardised text output via the > > +`fops->show_fdinfo()` as part of the driver specific file operations > > registered > > +in the `struct drm_driver` object registered with the DRM core. > > + > > +One purpose of this output is to enable writing as generic as practicaly > > +feasible `top(1)` like userspace monitoring tools. > > + > > +Given the differences between various DRM drivers the specification of the > > +output is split between common and driver specific parts. Having said that, > > +wherever possible effort should still be made to standardise as much as > > +possible. > > + > > +File format specification > > += > > + > > +- File shall contain one key value pair per one line of text. > > +- Colon character (`:`) must be used to delimit keys and values. > > +- All keys shall be prefixed with `drm-`. > > +- Whitespace between the delimiter and first non-whitespace character > > shall be > > + ignored when parsing. > > +- Neither keys or values are allowed to contain whitespace characters. > > +- Numerical key value pairs can end with optional unit string. > > +- Data type of the value is fixed as defined in the specification. > > + > > +Key types > > +- > > + > > +1. Mandatory, fully standardised. > > +2. Optional, fully standardised. > > +3. Driver specific. > > + > > +Data types > > +-- > > + > > +- - Unsigned integer without defining the maximum value. > > +- - String excluding any above defined reserved characters or > > whitespace. > > + > > +Mandatory fully standardised keys > > +- > > + > > +- drm-driver: > > + > > +String shall contain the name this driver registered as via the respective > > +`stru
Re: [Intel-gfx] [PATCH 3/3] drm/msm: Don't init ww_mutec acquire ctx before needed
On Tue, Nov 19, 2019 at 1:08 PM Daniel Vetter wrote: > > For locking semantics it really doesn't matter when we grab the > ticket. But for lockdep validation it does: the acquire ctx is a fake > lockdep. Since other drivers might want to do a full multi-lock dance > in their fault-handler, not just lock a single dma_resv. Therefore we > must init the acquire_ctx only after we've done all the copy_*_user or > anything else that might trigger a pagefault. For msm this means we > need to move it past submit_lookup_objects. seems reasonable.. but maybe a comment would be useful to prevent future-me from "cleaning-this-up" back to the way it was with that, r-b > > Aside: Why is msm still using struct_mutex, it seems to be using > dma_resv_lock for general buffer state protection? only because I (or anyone else) hasn't had time to revisit the struct_mutex usage since we moved to per-object-locks.. the downside, I suppose, of kernel generally working ok and this not being a big enough fire to bubble up to the top of my todo list BR, -R > > Signed-off-by: Daniel Vetter > Cc: Rob Clark > Cc: Sean Paul > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > --- > drivers/gpu/drm/msm/msm_gem_submit.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c > b/drivers/gpu/drm/msm/msm_gem_submit.c > index fb1fdd7fa3ef..126b2f62bfe7 100644 > --- a/drivers/gpu/drm/msm/msm_gem_submit.c > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c > @@ -54,7 +54,6 @@ static struct msm_gem_submit *submit_create(struct > drm_device *dev, > > INIT_LIST_HEAD(&submit->node); > INIT_LIST_HEAD(&submit->bo_list); > - ww_acquire_init(&submit->ticket, &reservation_ww_class); > > return submit; > } > @@ -489,6 +488,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void > *data, > if (ret) > goto out; > > + ww_acquire_init(&submit->ticket, &reservation_ww_class); > ret = submit_lock_objects(submit); > if (ret) > goto out; > -- > 2.24.0 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/msm: Don't init ww_mutec acquire ctx before needed
On Wed, Nov 20, 2019 at 2:56 AM Daniel Vetter wrote: > > For locking semantics it really doesn't matter when we grab the > ticket. But for lockdep validation it does: the acquire ctx is a fake > lockdep. Since other drivers might want to do a full multi-lock dance > in their fault-handler, not just lock a single dma_resv. Therefore we > must init the acquire_ctx only after we've done all the copy_*_user or > anything else that might trigger a pagefault. For msm this means we > need to move it past submit_lookup_objects. > > Aside: Why is msm still using struct_mutex, it seems to be using > dma_resv_lock for general buffer state protection? > > v2: > - Add comment to explain why the ww ticket setup is separate (Rob) > - Fix up error handling, we need to make sure we don't call > ww_acquire_fini without _init. > > Signed-off-by: Daniel Vetter > Cc: Rob Clark > Cc: Sean Paul > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org found a few minutes to take this for a spin and seems fine.. t-b && r-b BR, -R > --- > drivers/gpu/drm/msm/msm_gem_submit.c | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c > b/drivers/gpu/drm/msm/msm_gem_submit.c > index fb1fdd7fa3ef..385d4965a8d0 100644 > --- a/drivers/gpu/drm/msm/msm_gem_submit.c > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c > @@ -54,7 +54,6 @@ static struct msm_gem_submit *submit_create(struct > drm_device *dev, > > INIT_LIST_HEAD(&submit->node); > INIT_LIST_HEAD(&submit->bo_list); > - ww_acquire_init(&submit->ticket, &reservation_ww_class); > > return submit; > } > @@ -390,8 +389,6 @@ static void submit_cleanup(struct msm_gem_submit *submit) > list_del_init(&msm_obj->submit_entry); > drm_gem_object_put(&msm_obj->base); > } > - > - ww_acquire_fini(&submit->ticket); > } > > int msm_ioctl_gem_submit(struct drm_device *dev, void *data, > @@ -408,6 +405,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void > *data, > struct msm_ringbuffer *ring; > int out_fence_fd = -1; > struct pid *pid = get_pid(task_pid(current)); > + bool has_ww_ticket = false; > unsigned i; > int ret, submitid; > if (!gpu) > @@ -489,6 +487,9 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void > *data, > if (ret) > goto out; > > + /* copy_*_user while holding a ww ticket upsets lockdep */ > + ww_acquire_init(&submit->ticket, &reservation_ww_class); > + has_ww_ticket = true; > ret = submit_lock_objects(submit); > if (ret) > goto out; > @@ -588,6 +589,8 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void > *data, > > out: > submit_cleanup(submit); > + if (has_ww_ticket) > + ww_acquire_fini(&submit->ticket); > if (ret) > msm_gem_submit_free(submit); > out_unlock: > -- > 2.24.0 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly > > pre-merge CI. > > Thanks for the suggestion! I implemented something like this for Mesa: > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > I wouldn't mind manually triggering pipelines, but unless there is some trick I'm not realizing, it is super cumbersome. Ie. you have to click first the container jobs.. then wait.. then the build jobs.. then wait some more.. and then finally the actual runners. That would be a real step back in terms of usefulness of CI.. one might call it a regression :-( Is there a possible middle ground where pre-marge pipelines that touch a particular driver trigger that driver's CI jobs, but MRs that don't touch that driver but do touch shared code don't until triggered by marge? Ie. if I have a MR that only touches nir, it's probably ok to not run freedreno jobs until marge triggers it. But if I have a MR that is touching freedreno, I'd really rather not have to wait until marge triggers the freedreno CI jobs. Btw, I was under the impression (from periodically skimming the logs in #freedesktop, so I could well be missing or misunderstanding something) that caching/etc had been improved and mesa's part of the egress wasn't the bigger issue at this point? BR, -R ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne wrote: > > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit : > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > > For Mesa, we could run CI only when Marge pushes, so that it's a > > > > strictly > > > > pre-merge CI. > > > > > > Thanks for the suggestion! I implemented something like this for Mesa: > > > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > > > > > > > I wouldn't mind manually triggering pipelines, but unless there is > > some trick I'm not realizing, it is super cumbersome. Ie. you have to > > click first the container jobs.. then wait.. then the build jobs.. > > then wait some more.. and then finally the actual runners. That would > > be a real step back in terms of usefulness of CI.. one might call it a > > regression :-( > > On GStreamer side we have moved some existing pipeline to manual mode. > As we use needs: between jobs, we could simply set the first job to > manual (in our case it's a single job called manifest in your case it > would be the N container jobs). This way you can have a manual pipeline > that is triggered in single (or fewer) clicks. Here's an example: > > https://gitlab.freedesktop.org/gstreamer/gstreamer/pipelines/128292 > > That our post-merge pipelines, we only trigger then if we suspect a > problem. > I'm not sure that would work for mesa since the hierarchy of jobs branches out pretty far.. ie. if I just clicked the arm64 build + test container jobs, and everything else ran automatically after that, it would end up running all the CI jobs for all the arm devices (or at least all the 64b ones) I'm not sure why gitlab works this way, a more sensible approach would be to click on the last jobs you want to run and for that to automatically propagate up to run the jobs needed to run clicked job. BR, -R ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
On Sat, Apr 4, 2020 at 11:16 AM Rob Clark wrote: > > On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne wrote: > > > > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit : > > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > > > For Mesa, we could run CI only when Marge pushes, so that it's a > > > > > strictly > > > > > pre-merge CI. > > > > > > > > Thanks for the suggestion! I implemented something like this for Mesa: > > > > > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > > > > > > > > > > I wouldn't mind manually triggering pipelines, but unless there is > > > some trick I'm not realizing, it is super cumbersome. Ie. you have to > > > click first the container jobs.. then wait.. then the build jobs.. > > > then wait some more.. and then finally the actual runners. That would > > > be a real step back in terms of usefulness of CI.. one might call it a > > > regression :-( > > > > On GStreamer side we have moved some existing pipeline to manual mode. > > As we use needs: between jobs, we could simply set the first job to > > manual (in our case it's a single job called manifest in your case it > > would be the N container jobs). This way you can have a manual pipeline > > that is triggered in single (or fewer) clicks. Here's an example: > > > > https://gitlab.freedesktop.org/gstreamer/gstreamer/pipelines/128292 > > > > That our post-merge pipelines, we only trigger then if we suspect a > > problem. > > > > I'm not sure that would work for mesa since the hierarchy of jobs > branches out pretty far.. ie. if I just clicked the arm64 build + test > container jobs, and everything else ran automatically after that, it > would end up running all the CI jobs for all the arm devices (or at > least all the 64b ones) update: pepp pointed out on #dri-devel that the path-based rules should still apply to prune out hw CI jobs for hw not affected by the MR. If that is the case, and we only need to click the container jobs (without then doing the wait&click dance), then this doesn't sound as bad as I feared. BR, -R ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
On Sat, Apr 4, 2020 at 11:41 AM Rob Clark wrote: > > On Sat, Apr 4, 2020 at 11:16 AM Rob Clark wrote: > > > > On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne > > wrote: > > > > > > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit : > > > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > > > > For Mesa, we could run CI only when Marge pushes, so that it's a > > > > > > strictly > > > > > > pre-merge CI. > > > > > > > > > > Thanks for the suggestion! I implemented something like this for Mesa: > > > > > > > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > > > > > > > > > > > > > I wouldn't mind manually triggering pipelines, but unless there is > > > > some trick I'm not realizing, it is super cumbersome. Ie. you have to > > > > click first the container jobs.. then wait.. then the build jobs.. > > > > then wait some more.. and then finally the actual runners. That would > > > > be a real step back in terms of usefulness of CI.. one might call it a > > > > regression :-( > > > > > > On GStreamer side we have moved some existing pipeline to manual mode. > > > As we use needs: between jobs, we could simply set the first job to > > > manual (in our case it's a single job called manifest in your case it > > > would be the N container jobs). This way you can have a manual pipeline > > > that is triggered in single (or fewer) clicks. Here's an example: > > > > > > https://gitlab.freedesktop.org/gstreamer/gstreamer/pipelines/128292 > > > > > > That our post-merge pipelines, we only trigger then if we suspect a > > > problem. > > > > > > > I'm not sure that would work for mesa since the hierarchy of jobs > > branches out pretty far.. ie. if I just clicked the arm64 build + test > > container jobs, and everything else ran automatically after that, it > > would end up running all the CI jobs for all the arm devices (or at > > least all the 64b ones) > > update: pepp pointed out on #dri-devel that the path-based rules > should still apply to prune out hw CI jobs for hw not affected by the > MR. If that is the case, and we only need to click the container jobs > (without then doing the wait&click dance), then this doesn't sound as > bad as I feared. PS. I should add, that in these wfh days, I'm relying on CI to be able to test changes on some generations of hw that I don't physically have with me. It's easy to take for granted, I did until I thought about what I'd do without CI. So big thanks to all the people who are working on CI, it's more important these days than you might realize :-) BR, -R ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
On Mon, Apr 6, 2020 at 8:43 AM Adam Jackson wrote: > > On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote: > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > > For Mesa, we could run CI only when Marge pushes, so that it's a > > > > strictly > > > > pre-merge CI. > > > > > > Thanks for the suggestion! I implemented something like this for Mesa: > > > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > > > > I wouldn't mind manually triggering pipelines, but unless there is > > some trick I'm not realizing, it is super cumbersome. Ie. you have to > > click first the container jobs.. then wait.. then the build jobs.. > > then wait some more.. and then finally the actual runners. That would > > be a real step back in terms of usefulness of CI.. one might call it a > > regression :-( > > I think that's mostly a complaint about the conditionals we've written > so far, tbh. As I commented on the bug, when I clicked the container > job (which the rules happen to have evaluated to being "manual"), every > job (recursively) downstream of it got enqueued, which isn't what > you're describing. So I think if you can describe the UX you'd like we > can write rules to make that reality. Ok, I was fearing that we'd have to manually trigger each stage of dependencies in the pipeline. Which wouldn't be so bad except that gitlab makes you wait for the previous stage to complete before triggering the next one. The ideal thing would be to be able to click any jobs that we want to run, say "arm64_a630_gles31", and for gitlab to realize that it needs to automatically trigger dependencies of that job (meson-arm64, and arm_build+arm_test). But not sure if that is a thing gitlab can do. Triggering just the first container jobs and having everything from there run automatically would be ok if the current rules to filter out unneeded jobs still apply, ie. a panfrost change isn't triggering freedreno CI jobs and visa versa. But tbh I don't understand enough of what that MR is doing to understand if that is what it does. (It was suggested on IRC that this is probably what it does.) BR, -R ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services
On Mon, Apr 6, 2020 at 10:04 AM Michel Dänzer wrote: > > On 2020-04-06 6:34 p.m., Rob Clark wrote: > > > > The ideal thing would be to be able to click any jobs that we want to > > run, say "arm64_a630_gles31", and for gitlab to realize that it needs > > to automatically trigger dependencies of that job (meson-arm64, and > > arm_build+arm_test). But not sure if that is a thing gitlab can do. > > Not that I know of. The dependency handling is still pretty rudimentary > in general. > > > > Triggering just the first container jobs and having everything from > > there run automatically would be ok if the current rules to filter out > > unneeded jobs still apply, ie. a panfrost change isn't triggering > > freedreno CI jobs and visa versa. But tbh I don't understand enough > > of what that MR is doing to understand if that is what it does. (It > > was suggested on IRC that this is probably what it does.) > > It is. Filtered jobs don't exist at all in the pipeline, so they can't > be triggered by any means. :) > ahh, ok, I didn't realize that.. thx for the explaination BR, -R ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/3] drm/gem: don't force writecombine mmap'ing
From: Rob Clark The driver should be in control of this. Signed-off-by: Rob Clark --- It is possible that this was masking bugs (ie. not setting appropriate pgprot) in drivers. I don't have a particularly good idea for tracking those down (since I don't have the hw for most drivers). Unless someone has a better idea, maybe land this and let driver maintainers fix any potential fallout in their drivers? This is necessary for the last patch to fix VGEM brokenness on arm. drivers/gpu/drm/drm_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 8a55f71325b1..7d6242cc69f2 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -1110,7 +1110,7 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size, vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP; vma->vm_private_data = obj; - vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); + vma->vm_page_prot = vm_get_page_prot(vma->vm_flags); vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); /* Take a ref for this mapping of the object, so that the fault -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/3] drm: plumb attaching dev thru to prime_pin/unpin
From: Rob Clark
Needed in the following patch for cache operations.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/drm_gem.c | 10 ++
drivers/gpu/drm/drm_gem_vram_helper.c | 6 --
drivers/gpu/drm/drm_prime.c | 4 ++--
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 4 ++--
drivers/gpu/drm/msm/msm_drv.h | 4 ++--
drivers/gpu/drm/msm/msm_gem_prime.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_gem.h | 4 ++--
drivers/gpu/drm/nouveau/nouveau_prime.c | 4 ++--
drivers/gpu/drm/qxl/qxl_prime.c | 4 ++--
drivers/gpu/drm/radeon/radeon_prime.c | 4 ++--
drivers/gpu/drm/vboxvideo/vbox_prime.c | 4 ++--
drivers/gpu/drm/vgem/vgem_drv.c | 4 ++--
include/drm/drm_drv.h | 4 ++--
include/drm/drm_gem.h | 4 ++--
include/drm/drm_gem_vram_helper.h | 4 ++--
15 files changed, 36 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 7d6242cc69f2..0a2645769624 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1219,18 +1219,19 @@ void drm_gem_print_info(struct drm_printer *p, unsigned
int indent,
/**
* drm_gem_pin - Pin backing buffer in memory
* @obj: GEM object
+ * @dev: the device the buffer is being pinned for
*
* Make sure the backing buffer is pinned in memory.
*
* Returns:
* 0 on success or a negative error code on failure.
*/
-int drm_gem_pin(struct drm_gem_object *obj)
+int drm_gem_pin(struct drm_gem_object *obj, struct device *dev)
{
if (obj->funcs && obj->funcs->pin)
return obj->funcs->pin(obj);
else if (obj->dev->driver->gem_prime_pin)
- return obj->dev->driver->gem_prime_pin(obj);
+ return obj->dev->driver->gem_prime_pin(obj, dev);
else
return 0;
}
@@ -1239,15 +1240,16 @@ EXPORT_SYMBOL(drm_gem_pin);
/**
* drm_gem_unpin - Unpin backing buffer from memory
* @obj: GEM object
+ * @dev: the device the buffer is being pinned for
*
* Relax the requirement that the backing buffer is pinned in memory.
*/
-void drm_gem_unpin(struct drm_gem_object *obj)
+void drm_gem_unpin(struct drm_gem_object *obj, struct device *dev)
{
if (obj->funcs && obj->funcs->unpin)
obj->funcs->unpin(obj);
else if (obj->dev->driver->gem_prime_unpin)
- obj->dev->driver->gem_prime_unpin(obj);
+ obj->dev->driver->gem_prime_unpin(obj, dev);
}
EXPORT_SYMBOL(drm_gem_unpin);
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 4de782ca26b2..62fafec93948 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -548,7 +548,8 @@ EXPORT_SYMBOL(drm_gem_vram_driver_dumb_mmap_offset);
* 0 on success, or
* a negative errno code otherwise.
*/
-int drm_gem_vram_driver_gem_prime_pin(struct drm_gem_object *gem)
+int drm_gem_vram_driver_gem_prime_pin(struct drm_gem_object *gem,
+ struct device *dev)
{
struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem);
@@ -569,7 +570,8 @@ EXPORT_SYMBOL(drm_gem_vram_driver_gem_prime_pin);
Implements &struct drm_driver.gem_prime_unpin
* @gem: The GEM object to unpin
*/
-void drm_gem_vram_driver_gem_prime_unpin(struct drm_gem_object *gem)
+void drm_gem_vram_driver_gem_prime_unpin(struct drm_gem_object *gem,
+struct device *dev)
{
struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem);
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index d0c01318076b..505893cfac8e 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -196,7 +196,7 @@ int drm_gem_map_attach(struct dma_buf *dma_buf,
{
struct drm_gem_object *obj = dma_buf->priv;
- return drm_gem_pin(obj);
+ return drm_gem_pin(obj, attach->dev);
}
EXPORT_SYMBOL(drm_gem_map_attach);
@@ -213,7 +213,7 @@ void drm_gem_map_detach(struct dma_buf *dma_buf,
{
struct drm_gem_object *obj = dma_buf->priv;
- drm_gem_unpin(obj);
+ drm_gem_unpin(obj, attach->dev);
}
EXPORT_SYMBOL(drm_gem_map_detach);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
index 00e8b6a817e3..44385d590aa7 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
@@ -43,7 +43,7 @@ int etnaviv_gem_prime_mmap(struct drm_gem_object *obj,
return etnaviv_obj->ops->mmap(etnaviv_obj, vma);
}
-int etnaviv_gem_prime_pin(struct drm_gem_object *obj)
+int etnaviv_gem_prime_pin(struct drm_gem_object *obj, struct device *dev)
{
if (!obj->import_attac
[Intel-gfx] [PATCH v2 3/3] drm/vgem: use normal cached mmap'ings
From: Rob Clark
Since there is no real device associated with VGEM, it is impossible to
end up with appropriate dev->dma_ops, meaning that we have no way to
invalidate the shmem pages allocated by VGEM. So, at least on platforms
without drm_cflush_pages(), we end up with corruption when cache lines
from previous usage of VGEM bo pages get evicted to memory.
The only sane option is to use cached mappings.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/vgem/vgem_drv.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index a179e962b79e..b6071a466b92 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -259,9 +259,6 @@ static int vgem_mmap(struct file *filp, struct
vm_area_struct *vma)
if (ret)
return ret;
- /* Keep the WC mmaping set by drm_gem_mmap() but our pages
-* are ordinary and not special.
-*/
vma->vm_flags = flags | VM_DONTEXPAND | VM_DONTDUMP;
return 0;
}
@@ -310,17 +307,17 @@ static void vgem_unpin_pages(struct drm_vgem_gem_object
*bo)
static int vgem_prime_pin(struct drm_gem_object *obj, struct device *dev)
{
struct drm_vgem_gem_object *bo = to_vgem_bo(obj);
- long n_pages = obj->size >> PAGE_SHIFT;
+ long i, n_pages = obj->size >> PAGE_SHIFT;
struct page **pages;
pages = vgem_pin_pages(bo);
if (IS_ERR(pages))
return PTR_ERR(pages);
- /* Flush the object from the CPU cache so that importers can rely
-* on coherent indirect access via the exported dma-address.
-*/
- drm_clflush_pages(pages, n_pages);
+ for (i = 0; i < n_pages; i++) {
+ dma_sync_single_for_device(dev, page_to_phys(pages[i]),
+ PAGE_SIZE, DMA_BIDIRECTIONAL);
+ }
return 0;
}
@@ -328,6 +325,13 @@ static int vgem_prime_pin(struct drm_gem_object *obj,
struct device *dev)
static void vgem_prime_unpin(struct drm_gem_object *obj, struct device *dev)
{
struct drm_vgem_gem_object *bo = to_vgem_bo(obj);
+ long i, n_pages = obj->size >> PAGE_SHIFT;
+ struct page **pages = bo->pages;
+
+ for (i = 0; i < n_pages; i++) {
+ dma_sync_single_for_cpu(dev, page_to_phys(pages[i]),
+ PAGE_SIZE, DMA_BIDIRECTIONAL);
+ }
vgem_unpin_pages(bo);
}
@@ -382,7 +386,7 @@ static void *vgem_prime_vmap(struct drm_gem_object *obj)
if (IS_ERR(pages))
return NULL;
- return vmap(pages, n_pages, 0, pgprot_writecombine(PAGE_KERNEL));
+ return vmap(pages, n_pages, 0, PAGE_KERNEL);
}
static void vgem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
@@ -411,7 +415,7 @@ static int vgem_prime_mmap(struct drm_gem_object *obj,
fput(vma->vm_file);
vma->vm_file = get_file(obj->filp);
vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
- vma->vm_page_prot =
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
+ vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
return 0;
}
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/3] drm/gem: don't force writecombine mmap'ing
From: Rob Clark The driver should be in control of this. Signed-off-by: Rob Clark --- It is possible that this was masking bugs (ie. not setting appropriate pgprot) in drivers. I don't have a particularly good idea for tracking those down (since I don't have the hw for most drivers). Unless someone has a better idea, maybe land this and let driver maintainers fix any potential fallout in their drivers? This is necessary for the last patch to fix VGEM brokenness on arm. v3: rebased on drm-tip drivers/gpu/drm/drm_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index e6c12c6ec728..84689ccae885 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -1109,7 +1109,7 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size, vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP; vma->vm_private_data = obj; - vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); + vma->vm_page_prot = vm_get_page_prot(vma->vm_flags); vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); /* Take a ref for this mapping of the object, so that the fault -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/3] drm: plumb attaching dev thru to prime_pin/unpin
From: Rob Clark
Needed in the following patch for cache operations.
Signed-off-by: Rob Clark
---
v3: rebased on drm-tip
drivers/gpu/drm/drm_gem.c | 8
drivers/gpu/drm/drm_internal.h | 4 ++--
drivers/gpu/drm/drm_prime.c | 4 ++--
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 4 ++--
drivers/gpu/drm/msm/msm_drv.h | 4 ++--
drivers/gpu/drm/msm/msm_gem_prime.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_gem.h | 4 ++--
drivers/gpu/drm/nouveau/nouveau_prime.c | 4 ++--
drivers/gpu/drm/qxl/qxl_prime.c | 4 ++--
drivers/gpu/drm/radeon/radeon_prime.c | 4 ++--
drivers/gpu/drm/vgem/vgem_drv.c | 4 ++--
include/drm/drm_drv.h | 5 ++---
12 files changed, 26 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 84689ccae885..af2549c45027 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1215,22 +1215,22 @@ void drm_gem_print_info(struct drm_printer *p, unsigned
int indent,
obj->dev->driver->gem_print_info(p, indent, obj);
}
-int drm_gem_pin(struct drm_gem_object *obj)
+int drm_gem_pin(struct drm_gem_object *obj, struct device *dev)
{
if (obj->funcs && obj->funcs->pin)
return obj->funcs->pin(obj);
else if (obj->dev->driver->gem_prime_pin)
- return obj->dev->driver->gem_prime_pin(obj);
+ return obj->dev->driver->gem_prime_pin(obj, dev);
else
return 0;
}
-void drm_gem_unpin(struct drm_gem_object *obj)
+void drm_gem_unpin(struct drm_gem_object *obj, struct device *dev)
{
if (obj->funcs && obj->funcs->unpin)
obj->funcs->unpin(obj);
else if (obj->dev->driver->gem_prime_unpin)
- obj->dev->driver->gem_prime_unpin(obj);
+ obj->dev->driver->gem_prime_unpin(obj, dev);
}
void *drm_gem_vmap(struct drm_gem_object *obj)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 51a2055c8f18..e64090373e3a 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -133,8 +133,8 @@ void drm_gem_release(struct drm_device *dev, struct
drm_file *file_private);
void drm_gem_print_info(struct drm_printer *p, unsigned int indent,
const struct drm_gem_object *obj);
-int drm_gem_pin(struct drm_gem_object *obj);
-void drm_gem_unpin(struct drm_gem_object *obj);
+int drm_gem_pin(struct drm_gem_object *obj, struct device *dev);
+void drm_gem_unpin(struct drm_gem_object *obj, struct device *dev);
void *drm_gem_vmap(struct drm_gem_object *obj);
void drm_gem_vunmap(struct drm_gem_object *obj, void *vaddr);
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 189d980402ad..126860432ff9 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -575,7 +575,7 @@ int drm_gem_map_attach(struct dma_buf *dma_buf,
{
struct drm_gem_object *obj = dma_buf->priv;
- return drm_gem_pin(obj);
+ return drm_gem_pin(obj, attach->dev);
}
EXPORT_SYMBOL(drm_gem_map_attach);
@@ -593,7 +593,7 @@ void drm_gem_map_detach(struct dma_buf *dma_buf,
{
struct drm_gem_object *obj = dma_buf->priv;
- drm_gem_unpin(obj);
+ drm_gem_unpin(obj, attach->dev);
}
EXPORT_SYMBOL(drm_gem_map_detach);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
index a05292e8ed6f..67e69a5f00f2 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
@@ -43,7 +43,7 @@ int etnaviv_gem_prime_mmap(struct drm_gem_object *obj,
return etnaviv_obj->ops->mmap(etnaviv_obj, vma);
}
-int etnaviv_gem_prime_pin(struct drm_gem_object *obj)
+int etnaviv_gem_prime_pin(struct drm_gem_object *obj, struct device *dev)
{
if (!obj->import_attach) {
struct etnaviv_gem_object *etnaviv_obj = to_etnaviv_bo(obj);
@@ -55,7 +55,7 @@ int etnaviv_gem_prime_pin(struct drm_gem_object *obj)
return 0;
}
-void etnaviv_gem_prime_unpin(struct drm_gem_object *obj)
+void etnaviv_gem_prime_unpin(struct drm_gem_object *obj, struct device *dev)
{
if (!obj->import_attach) {
struct etnaviv_gem_object *etnaviv_obj = to_etnaviv_bo(obj);
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index ee7b512dc158..0eea68618b68 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -288,8 +288,8 @@ void msm_gem_prime_vunmap(struct drm_gem_object *obj, void
*vaddr);
int msm_gem_prime_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma);
struct drm_gem_object *msm_gem_prime_import_sg_table(struct drm_device *dev,
s
[Intel-gfx] [PATCH v3 3/3] drm/vgem: use normal cached mmap'ings
From: Rob Clark
Since there is no real device associated with VGEM, it is impossible to
end up with appropriate dev->dma_ops, meaning that we have no way to
invalidate the shmem pages allocated by VGEM. So, at least on platforms
without drm_cflush_pages(), we end up with corruption when cache lines
from previous usage of VGEM bo pages get evicted to memory.
The only sane option is to use cached mappings.
Signed-off-by: Rob Clark
---
v3: rebased on drm-tip
drivers/gpu/drm/vgem/vgem_drv.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index e7d12e93b1f0..84262e2bd7f7 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -259,9 +259,6 @@ static int vgem_mmap(struct file *filp, struct
vm_area_struct *vma)
if (ret)
return ret;
- /* Keep the WC mmaping set by drm_gem_mmap() but our pages
-* are ordinary and not special.
-*/
vma->vm_flags = flags | VM_DONTEXPAND | VM_DONTDUMP;
return 0;
}
@@ -310,17 +307,17 @@ static void vgem_unpin_pages(struct drm_vgem_gem_object
*bo)
static int vgem_prime_pin(struct drm_gem_object *obj, struct device *dev)
{
struct drm_vgem_gem_object *bo = to_vgem_bo(obj);
- long n_pages = obj->size >> PAGE_SHIFT;
+ long i, n_pages = obj->size >> PAGE_SHIFT;
struct page **pages;
pages = vgem_pin_pages(bo);
if (IS_ERR(pages))
return PTR_ERR(pages);
- /* Flush the object from the CPU cache so that importers can rely
-* on coherent indirect access via the exported dma-address.
-*/
- drm_clflush_pages(pages, n_pages);
+ for (i = 0; i < n_pages; i++) {
+ dma_sync_single_for_device(dev, page_to_phys(pages[i]),
+ PAGE_SIZE, DMA_BIDIRECTIONAL);
+ }
return 0;
}
@@ -328,6 +325,13 @@ static int vgem_prime_pin(struct drm_gem_object *obj,
struct device *dev)
static void vgem_prime_unpin(struct drm_gem_object *obj, struct device *dev)
{
struct drm_vgem_gem_object *bo = to_vgem_bo(obj);
+ long i, n_pages = obj->size >> PAGE_SHIFT;
+ struct page **pages = bo->pages;
+
+ for (i = 0; i < n_pages; i++) {
+ dma_sync_single_for_cpu(dev, page_to_phys(pages[i]),
+ PAGE_SIZE, DMA_BIDIRECTIONAL);
+ }
vgem_unpin_pages(bo);
}
@@ -382,7 +386,7 @@ static void *vgem_prime_vmap(struct drm_gem_object *obj)
if (IS_ERR(pages))
return NULL;
- return vmap(pages, n_pages, 0, pgprot_writecombine(PAGE_KERNEL));
+ return vmap(pages, n_pages, 0, PAGE_KERNEL);
}
static void vgem_prime_vunmap(struct drm_gem_object *obj, void *vaddr)
@@ -411,7 +415,7 @@ static int vgem_prime_mmap(struct drm_gem_object *obj,
fput(vma->vm_file);
vma->vm_file = get_file(obj->filp);
vma->vm_flags |= VM_DONTEXPAND | VM_DONTDUMP;
- vma->vm_page_prot =
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
+ vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
return 0;
}
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 3/3] drm/vgem: use normal cached mmap'ings
On Tue, Jul 16, 2019 at 4:39 PM Eric Anholt wrote: > > Rob Clark writes: > > > From: Rob Clark > > > > Since there is no real device associated with VGEM, it is impossible to > > end up with appropriate dev->dma_ops, meaning that we have no way to > > invalidate the shmem pages allocated by VGEM. So, at least on platforms > > without drm_cflush_pages(), we end up with corruption when cache lines > > from previous usage of VGEM bo pages get evicted to memory. > > > > The only sane option is to use cached mappings. > > This may be an improvement, but... > > pin/unpin is only on attaching/closing the dma-buf, right? So, great, > you flushed the cached map once after exporting the vgem dma-buf to the > actual GPU device, but from then on you still have no interface for > getting coherent access through VGEM's mapping again, which still > exists. In *theory* one would detach before doing further CPU access to buffer, and then re-attach when passing back to GPU. Ofc that isn't how actual drivers do things. But maybe it is enough for vgem to serve it's purpose (ie. test code). > I feel like this is papering over something that's really just broken, > and we should stop providing VGEM just because someone wants to write > dma-buf test code without driver-specific BO alloc ioctl code. yup, it is vgem that is fundamentally broken (or maybe more specifically doesn't fit in w/ dma-mappings view of how to do cache maint), and I'm just papering over it because people and CI systems want to be able to use it to do some dma-buf tests ;-) I'm kinda wondering, at least for arm/dt based systems, if there is a way (other than in early boot) that we can inject a vgem device node into the dtb. That isn't a thing drivers should normally do, but (if possible) since vgem is really just test infrastructure, it could be a way to make dma-mapping happily think vgem is a real device. BR, -R ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/atomic-helpers: remove legacy_cursor_update hacks
On Wed, Oct 21, 2020 at 9:32 AM Daniel Vetter wrote:
>
> The stuff never really worked, and leads to lots of fun because it
> out-of-order frees atomic states. Which upsets KASAN, among other
> things.
>
> For async updates we now have a more solid solution with the
> ->atomic_async_check and ->atomic_async_commit hooks. Support for that
> for msm and vc4 landed. nouveau and i915 have their own commit
> routines, doing something similar.
>
> For everyone else it's probably better to remove the use-after-free
> bug, and encourage folks to use the async support instead. The
> affected drivers which register a legacy cursor plane and don't either
> use the new async stuff or their own commit routine are: amdgpu,
> atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx.
>
> Inspired by an amdgpu bug report.
>
> v2: Drop RFC, I think with amdgpu converted over to use
> atomic_async_check/commit done in
>
> commit 674e78acae0dfb4beb56132e41cbae5b60f7d662
> Author: Nicholas Kazlauskas
> Date: Wed Dec 5 14:59:07 2018 -0500
>
> drm/amd/display: Add fast path for cursor plane updates
>
> we don't have any driver anymore where we have userspace expecting
> solid legacy cursor support _and_ they are using the atomic helpers in
> their fully glory. So we can retire this.
>
> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
> Cc: mikita.lip...@amd.com
> Cc: Michel Dänzer
> Cc: harry.wentl...@amd.com
> Signed-off-by: Daniel Vetter
This *completely* destroys fps when there is cursor movement, it would
be a pretty bad regression, so nak
BR,
-R
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 13 -
> 1 file changed, 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index a7bcb4b4586c..549a31e6042c 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1481,13 +1481,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device
> *dev,
> int i, ret;
> unsigned crtc_mask = 0;
>
> -/*
> - * Legacy cursor ioctls are completely unsynced, and userspace
> - * relies on that (by doing tons of cursor updates).
> - */
> - if (old_state->legacy_cursor_update)
> - return;
> -
> for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state,
> new_crtc_state, i) {
> if (!new_crtc_state->active)
> continue;
> @@ -2106,12 +2099,6 @@ int drm_atomic_helper_setup_commit(struct
> drm_atomic_state *state,
> continue;
> }
>
> - /* Legacy cursor updates are fully unsynced. */
> - if (state->legacy_cursor_update) {
> - complete_all(&commit->flip_done);
> - continue;
> - }
> -
> if (!new_crtc_state->event) {
> commit->event = kzalloc(sizeof(*commit->event),
> GFP_KERNEL);
> --
> 2.28.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/atomic-helpers: remove legacy_cursor_update hacks
On Thu, Oct 22, 2020 at 10:02 AM Rob Clark wrote:
>
> On Wed, Oct 21, 2020 at 9:32 AM Daniel Vetter wrote:
> >
> > The stuff never really worked, and leads to lots of fun because it
> > out-of-order frees atomic states. Which upsets KASAN, among other
> > things.
> >
> > For async updates we now have a more solid solution with the
> > ->atomic_async_check and ->atomic_async_commit hooks. Support for that
> > for msm and vc4 landed. nouveau and i915 have their own commit
> > routines, doing something similar.
> >
> > For everyone else it's probably better to remove the use-after-free
> > bug, and encourage folks to use the async support instead. The
> > affected drivers which register a legacy cursor plane and don't either
> > use the new async stuff or their own commit routine are: amdgpu,
> > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx.
> >
> > Inspired by an amdgpu bug report.
> >
> > v2: Drop RFC, I think with amdgpu converted over to use
> > atomic_async_check/commit done in
> >
> > commit 674e78acae0dfb4beb56132e41cbae5b60f7d662
> > Author: Nicholas Kazlauskas
> > Date: Wed Dec 5 14:59:07 2018 -0500
> >
> > drm/amd/display: Add fast path for cursor plane updates
> >
> > we don't have any driver anymore where we have userspace expecting
> > solid legacy cursor support _and_ they are using the atomic helpers in
> > their fully glory. So we can retire this.
> >
> > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
> > Cc: mikita.lip...@amd.com
> > Cc: Michel Dänzer
> > Cc: harry.wentl...@amd.com
> > Signed-off-by: Daniel Vetter
>
> This *completely* destroys fps when there is cursor movement, it would
> be a pretty bad regression, so nak
Which I *guess* is due to dpu not wiring up the plane->async_* funcs,
effectively making cursor updates synchronous.. but it will take some
time to sort out :-(
> BR,
> -R
>
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 13 -
> > 1 file changed, 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index a7bcb4b4586c..549a31e6042c 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -1481,13 +1481,6 @@ drm_atomic_helper_wait_for_vblanks(struct drm_device
> > *dev,
> > int i, ret;
> > unsigned crtc_mask = 0;
> >
> > -/*
> > - * Legacy cursor ioctls are completely unsynced, and userspace
> > - * relies on that (by doing tons of cursor updates).
> > - */
> > - if (old_state->legacy_cursor_update)
> > - return;
> > -
> > for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state,
> > new_crtc_state, i) {
> > if (!new_crtc_state->active)
> > continue;
> > @@ -2106,12 +2099,6 @@ int drm_atomic_helper_setup_commit(struct
> > drm_atomic_state *state,
> > continue;
> > }
> >
> > - /* Legacy cursor updates are fully unsynced. */
> > - if (state->legacy_cursor_update) {
> > - complete_all(&commit->flip_done);
> > - continue;
> > - }
> > -
> > if (!new_crtc_state->event) {
> > commit->event = kzalloc(sizeof(*commit->event),
> > GFP_KERNEL);
> > --
> > 2.28.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/atomic-helpers: remove legacy_cursor_update hacks
On Thu, Oct 22, 2020 at 12:16 PM Daniel Vetter wrote: > > On Thu, Oct 22, 2020 at 7:22 PM Rob Clark wrote: > > > > On Thu, Oct 22, 2020 at 10:02 AM Rob Clark wrote: > > > > > > On Wed, Oct 21, 2020 at 9:32 AM Daniel Vetter > > > wrote: > > > > > > > > The stuff never really worked, and leads to lots of fun because it > > > > out-of-order frees atomic states. Which upsets KASAN, among other > > > > things. > > > > > > > > For async updates we now have a more solid solution with the > > > > ->atomic_async_check and ->atomic_async_commit hooks. Support for that > > > > for msm and vc4 landed. nouveau and i915 have their own commit > > > > routines, doing something similar. > > > > > > > > For everyone else it's probably better to remove the use-after-free > > > > bug, and encourage folks to use the async support instead. The > > > > affected drivers which register a legacy cursor plane and don't either > > > > use the new async stuff or their own commit routine are: amdgpu, > > > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and vmwgfx. > > > > > > > > Inspired by an amdgpu bug report. > > > > > > > > v2: Drop RFC, I think with amdgpu converted over to use > > > > atomic_async_check/commit done in > > > > > > > > commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > > > > Author: Nicholas Kazlauskas > > > > Date: Wed Dec 5 14:59:07 2018 -0500 > > > > > > > > drm/amd/display: Add fast path for cursor plane updates > > > > > > > > we don't have any driver anymore where we have userspace expecting > > > > solid legacy cursor support _and_ they are using the atomic helpers in > > > > their fully glory. So we can retire this. > > > > > > > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > > > Cc: mikita.lip...@amd.com > > > > Cc: Michel Dänzer > > > > Cc: harry.wentl...@amd.com > > > > Signed-off-by: Daniel Vetter > > > > > > This *completely* destroys fps when there is cursor movement, it would > > > be a pretty bad regression, so nak > > > > Which I *guess* is due to dpu not wiring up the plane->async_* funcs, > > effectively making cursor updates synchronous.. but it will take some > > time to sort out :-( > > Does something like the below (not even compile tested) get dpu back in order? > > diff --git a/drivers/gpu/drm/msm/msm_atomic.c > b/drivers/gpu/drm/msm/msm_atomic.c > index 561bfa48841c..ec8b4f74da49 100644 > --- a/drivers/gpu/drm/msm/msm_atomic.c > +++ b/drivers/gpu/drm/msm/msm_atomic.c > @@ -215,6 +215,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state > *state) >/* async updates are limited to single-crtc updates: */ >WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > > + complete_all(async_crtc->state->flip_done); > + >/* > * Start timer if we don't already have an update pending > * on this crtc: > > That way we could perhaps still move ahead with removing the hacks > from shared helpers, and msm-dpu can keep doing what it does. The > other hunk is in a function that dpu code doesn't even use, so can't > see how that would change anything. That causes massive explosions... angering WARN_ON(dpu_crtc->event); Seems it is probably the right idea but the wrong place? I'll try to make some time in next few days to look at this more, but juggling a bunch of different things atm (and I guess at any rate this won't be a 5.10 thing, so we have a bit of time) BR, -R > -Daniel > > > > > > BR, > > > -R > > > > > > > --- > > > > drivers/gpu/drm/drm_atomic_helper.c | 13 - > > > > 1 file changed, 13 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > > > > b/drivers/gpu/drm/drm_atomic_helper.c > > > > index a7bcb4b4586c..549a31e6042c 100644 > > > > --- a/drivers/gpu/drm/drm_atomic_helper.c > > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c > > > > @@ -1481,13 +1481,6 @@ drm_atomic_helper_wait_for_vblanks(struct > > > > drm_device *dev, > > > > int i, ret; > > > > unsigned crtc_mask = 0; > > > > > > > > -/* > > > &
Re: [Intel-gfx] [PATCH 1/3] drm/atomic-helpers: remove legacy_cursor_update hacks
On Fri, Oct 23, 2020 at 9:00 AM Daniel Vetter wrote: > > On Fri, Oct 23, 2020 at 5:02 PM Rob Clark wrote: > > > > On Thu, Oct 22, 2020 at 12:16 PM Daniel Vetter > > wrote: > > > > > > On Thu, Oct 22, 2020 at 7:22 PM Rob Clark wrote: > > > > > > > > On Thu, Oct 22, 2020 at 10:02 AM Rob Clark wrote: > > > > > > > > > > On Wed, Oct 21, 2020 at 9:32 AM Daniel Vetter > > > > > wrote: > > > > > > > > > > > > The stuff never really worked, and leads to lots of fun because it > > > > > > out-of-order frees atomic states. Which upsets KASAN, among other > > > > > > things. > > > > > > > > > > > > For async updates we now have a more solid solution with the > > > > > > ->atomic_async_check and ->atomic_async_commit hooks. Support for > > > > > > that > > > > > > for msm and vc4 landed. nouveau and i915 have their own commit > > > > > > routines, doing something similar. > > > > > > > > > > > > For everyone else it's probably better to remove the use-after-free > > > > > > bug, and encourage folks to use the async support instead. The > > > > > > affected drivers which register a legacy cursor plane and don't > > > > > > either > > > > > > use the new async stuff or their own commit routine are: amdgpu, > > > > > > atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and > > > > > > vmwgfx. > > > > > > > > > > > > Inspired by an amdgpu bug report. > > > > > > > > > > > > v2: Drop RFC, I think with amdgpu converted over to use > > > > > > atomic_async_check/commit done in > > > > > > > > > > > > commit 674e78acae0dfb4beb56132e41cbae5b60f7d662 > > > > > > Author: Nicholas Kazlauskas > > > > > > Date: Wed Dec 5 14:59:07 2018 -0500 > > > > > > > > > > > > drm/amd/display: Add fast path for cursor plane updates > > > > > > > > > > > > we don't have any driver anymore where we have userspace expecting > > > > > > solid legacy cursor support _and_ they are using the atomic helpers > > > > > > in > > > > > > their fully glory. So we can retire this. > > > > > > > > > > > > References: https://bugzilla.kernel.org/show_bug.cgi?id=199425 > > > > > > Cc: mikita.lip...@amd.com > > > > > > Cc: Michel Dänzer > > > > > > Cc: harry.wentl...@amd.com > > > > > > Signed-off-by: Daniel Vetter > > > > > > > > > > This *completely* destroys fps when there is cursor movement, it would > > > > > be a pretty bad regression, so nak > > > > > > > > Which I *guess* is due to dpu not wiring up the plane->async_* funcs, > > > > effectively making cursor updates synchronous.. but it will take some > > > > time to sort out :-( > > > > > > Does something like the below (not even compile tested) get dpu back in > > > order? > > > > > > diff --git a/drivers/gpu/drm/msm/msm_atomic.c > > > b/drivers/gpu/drm/msm/msm_atomic.c > > > index 561bfa48841c..ec8b4f74da49 100644 > > > --- a/drivers/gpu/drm/msm/msm_atomic.c > > > +++ b/drivers/gpu/drm/msm/msm_atomic.c > > > @@ -215,6 +215,8 @@ void msm_atomic_commit_tail(struct drm_atomic_state > > > *state) > > >/* async updates are limited to single-crtc updates: */ > > >WARN_ON(crtc_mask != drm_crtc_mask(async_crtc)); > > > > > > + complete_all(async_crtc->state->flip_done); > > > + > > >/* > > > * Start timer if we don't already have an update pending > > > * on this crtc: > > > > > > That way we could perhaps still move ahead with removing the hacks > > > from shared helpers, and msm-dpu can keep doing what it does. The > > > other hunk is in a function that dpu code doesn't even use, so can't > > > see how that would change anything. > > > > That causes massive explosions... angering WARN_ON(dpu_crtc->event); > > > > Seems it is probably the right idea but the wrong place? I'll try to >
Re: [Intel-gfx] [PATCH 1/9] drm/msm: Don't call dma_buf_vunmap without _vmap
On Mon, May 11, 2020 at 2:36 AM Daniel Vetter wrote:
>
> I honestly don't exactly understand what's going on here, but the
> current code is wrong for sure: It calls dma_buf_vunmap without ever
> calling dma_buf_vmap.
>
> What I'm not sure about is whether the WARN_ON is correct:
> - msm imports dma-buf using drm_prime_sg_to_page_addr_arrays. Which is
> a pretty neat layering violation of how you shouldn't peek behind
> the curtain of the dma-buf exporter, but par for course. Note that
> all the nice new helpers don't (and we should probably have a bit a
> warning about this in the kerneldoc).
>
> - but then in the get_vaddr() in msm_gem.c, and that seems to happily
> wrap a vmap() around any object with ->pages set (so including
> imported dma-buf)
>
> - I'm not seeing any guarantees that userspace can't use an imported
> dma-buf for e.g. MSM_SUBMIT_CMD_BUF in a5xx_submit_in_rb, so no
> guarantees that an imported dma-buf won't end up with a ->vaddr set.
fwiw, a5xx_submit_in_rb() isn't a "normal" path (build-time disabled
by default, and restricted to sudo).. it really only exists to
simplify poking at fw.
There could be vmap's in the msm_gem_submit path, however. If we
don't, we should probably just disallow using an imported dma-buf as
cmdstream.. I don't think there is any sane reason to permit that. We
should probably also disallow get_vaddr() on imported buffers.
BR,
-R
>
> But even if that WARN_ON is wrong, cleaning up a vmap() done by msm by
> calling dma_buf_vmap is the wrong thing to do.
>
> Signed-off-by: Daniel Vetter
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> ---
> drivers/gpu/drm/msm/msm_gem.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index 5a6a79fbc9d6..3305a457960e 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -907,8 +907,7 @@ static void free_object(struct msm_gem_object *msm_obj)
> put_iova(obj);
>
> if (obj->import_attach) {
> - if (msm_obj->vaddr)
> - dma_buf_vunmap(obj->import_attach->dmabuf,
> msm_obj->vaddr);
> + WARN_ON(msm_obj->vaddr);
>
> /* Don't drop the pages for imported dmabuf, as they are not
> * ours, just free the array we allocated:
> --
> 2.26.2
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/9] drm/msm: Don't call dma_buf_vunmap without _vmap
On Mon, May 11, 2020 at 8:29 AM Daniel Vetter wrote:
>
> On Mon, May 11, 2020 at 5:24 PM Rob Clark wrote:
> >
> > On Mon, May 11, 2020 at 2:36 AM Daniel Vetter
> > wrote:
> > >
> > > I honestly don't exactly understand what's going on here, but the
> > > current code is wrong for sure: It calls dma_buf_vunmap without ever
> > > calling dma_buf_vmap.
> > >
> > > What I'm not sure about is whether the WARN_ON is correct:
> > > - msm imports dma-buf using drm_prime_sg_to_page_addr_arrays. Which is
> > > a pretty neat layering violation of how you shouldn't peek behind
> > > the curtain of the dma-buf exporter, but par for course. Note that
> > > all the nice new helpers don't (and we should probably have a bit a
> > > warning about this in the kerneldoc).
> > >
> > > - but then in the get_vaddr() in msm_gem.c, and that seems to happily
> > > wrap a vmap() around any object with ->pages set (so including
> > > imported dma-buf)
> > >
> > > - I'm not seeing any guarantees that userspace can't use an imported
> > > dma-buf for e.g. MSM_SUBMIT_CMD_BUF in a5xx_submit_in_rb, so no
> > > guarantees that an imported dma-buf won't end up with a ->vaddr set.
> >
> > fwiw, a5xx_submit_in_rb() isn't a "normal" path (build-time disabled
> > by default, and restricted to sudo).. it really only exists to
> > simplify poking at fw.
> >
> > There could be vmap's in the msm_gem_submit path, however. If we
> > don't, we should probably just disallow using an imported dma-buf as
> > cmdstream.. I don't think there is any sane reason to permit that. We
> > should probably also disallow get_vaddr() on imported buffers.
>
> Yeah if that's possible and won't blow up (I can't test) I think it'd
> be best. Something like
> if (bo->import_attach) return NULL; should do the trick I think.
> Should I type that up as v2 of this?
Sure. It should probably be something like
if (obj->import_attach)
return ERR_PTR(-ESOMETHING)
looks like the gem-submit path handles an IS_ERR() return
BR,
-R
> -Daniel
>
> >
> > BR,
> > -R
> >
> > >
> > > But even if that WARN_ON is wrong, cleaning up a vmap() done by msm by
> > > calling dma_buf_vmap is the wrong thing to do.
> > >
> > > Signed-off-by: Daniel Vetter
> > > Cc: Rob Clark
> > > Cc: Sean Paul
> > > Cc: linux-arm-...@vger.kernel.org
> > > Cc: freedr...@lists.freedesktop.org
> > > ---
> > > drivers/gpu/drm/msm/msm_gem.c | 3 +--
> > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> > > index 5a6a79fbc9d6..3305a457960e 100644
> > > --- a/drivers/gpu/drm/msm/msm_gem.c
> > > +++ b/drivers/gpu/drm/msm/msm_gem.c
> > > @@ -907,8 +907,7 @@ static void free_object(struct msm_gem_object
> > > *msm_obj)
> > > put_iova(obj);
> > >
> > > if (obj->import_attach) {
> > > - if (msm_obj->vaddr)
> > > - dma_buf_vunmap(obj->import_attach->dmabuf,
> > > msm_obj->vaddr);
> > > + WARN_ON(msm_obj->vaddr);
> > >
> > > /* Don't drop the pages for imported dmabuf, as they are
> > > not
> > > * ours, just free the array we allocated:
> > > --
> > > 2.26.2
> > >
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
On Fri, Feb 28, 2020 at 3:43 AM Michel Dänzer wrote: > > On 2020-02-28 10:28 a.m., Erik Faye-Lund wrote: > > > > We could also do stuff like reducing the amount of tests we run on each > > commit, and punt some testing to a per-weekend test-run or someting > > like that. We don't *need* to know about every problem up front, just > > the stuff that's about to be released, really. The other stuff is just > > nice to have. If it's too expensive, I would say drop it. > > I don't agree that pre-merge testing is just nice to have. A problem > which is only caught after it lands in mainline has a much bigger impact > than one which is already caught earlier. > one thought.. since with mesa+margebot we effectively get at least two(ish) CI runs per MR, ie. one when it is initially pushed, and one when margebot rebases and tries to merge, could we leverage this to have trimmed down pre-margebot CI which tries to just target affected drivers, with margebot doing a full CI run (when it is potentially batching together multiple MRs)? Seems like a way to reduce our CI runs with a good safety net to prevent things from slipping through the cracks. (Not sure how much that would help reduce bandwidth costs, but I guess it should help a bit.) BR, -R ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Document code of conduct
On Tue, Apr 11, 2017 at 2:48 AM, Daniel Vetter wrote: > freedesktop.org has adopted a formal&enforced code of conduct: > > https://www.fooishbar.org/blog/fdo-contributor-covenant/ > https://www.freedesktop.org/wiki/CodeOfConduct/ > > Besides formalizing things a bit more I don't think this changes > anything for us, we've already peer-enforced respectful and > constructive interactions since a long time. But it's good to document > things properly. > > Note: As Daniel Stone mentioned in the announcement fd.o admins > started chatting with the communities their hosting, which includs the > X.org foundation board, to figure out how to fan out enforcement and > allow projects to run things on their own (with fd.o still as the > fallback). So the details of enforcement (and appealing decisions) > might still change, but since this involves the board and lots more > people it'll take a while to get there. For now this is good enough I > think. s/includs/includes/ But spelling aside, Acked-by: Rob Clark > For the text itself I went with the same blurb as the Wayland project, > didn't feel creative yet this early in the morning: > > https://cgit.freedesktop.org/wayland/wayland/commit/?id=0eefe99fe0683ae409b665a8b18cc7eb648c6c0c > > Cc: Daniel Stone > Cc: Keith Packard > Cc: tfh...@err.no > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/introduction.rst | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/Documentation/gpu/introduction.rst > b/Documentation/gpu/introduction.rst > index 05a82bdfbca4..0f5173e29bdc 100644 > --- a/Documentation/gpu/introduction.rst > +++ b/Documentation/gpu/introduction.rst > @@ -85,3 +85,14 @@ This means that there's a blackout-period of about one > month where feature work > can't be merged. The recommended way to deal with that is having a -next tree > that's always open, but making sure to not feed it into linux-next during the > blackout period. As an example, drm-misc works like that. > + > +Code of Conduct > +--- > + > +As a freedesktop.org project, dri-devel and the DRM community follows the > +Contributor Covenant, found at: > https://www.freedesktop.org/wiki/CodeOfConduct > + > +Please conduct yourself in a respectful and civilised manner when > +interacting with community members on mailing lists, IRC, or bug > +trackers. The community represents the project as a whole, and abusive > +or bullying behaviour is not tolerated by the project. > -- > 2.11.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: make drm_get_format_name thread-safe
On Sun, Aug 14, 2016 at 8:02 PM, Eric Engestrom wrote:
> Signed-off-by: Eric Engestrom
> ---
>
> I moved the main bits to be the first diffs, shouldn't affect anything
> when applying the patch, but I wanted to ask:
> I don't like the hard-coded `32` the appears in both kmalloc() and
> snprintf(), what do you think? If you don't like it either, what would
> you suggest? Should I #define it?
>
> Second question is about the patch mail itself: should I send this kind
> of patch separated by module, with a note requesting them to be squashed
> when applying? It has to land as a single patch, but for review it might
> be easier if people only see the bits they each care about, as well as
> to collect ack's/r-b's.
>
> Cheers,
> Eric
>
> ---
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 6 ++--
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 6 ++--
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 6 ++--
> drivers/gpu/drm/drm_atomic.c| 5 ++--
> drivers/gpu/drm/drm_crtc.c | 21 -
> drivers/gpu/drm/drm_fourcc.c| 17 ++-
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 6 ++--
> drivers/gpu/drm/i915/i915_debugfs.c | 11 ++-
> drivers/gpu/drm/i915/intel_atomic_plane.c | 6 ++--
> drivers/gpu/drm/i915/intel_display.c| 39
> -
> drivers/gpu/drm/radeon/atombios_crtc.c | 12 +---
> include/drm/drm_fourcc.h| 2 +-
> 12 files changed, 89 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 0645c85..38216a1 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -39,16 +39,14 @@ static char printable_char(int c)
> * drm_get_format_name - return a string for drm fourcc format
> * @format: format to compute name of
> *
> - * Note that the buffer used by this function is globally shared and owned by
> - * the function itself.
> - *
> - * FIXME: This isn't really multithreading safe.
> + * Note that the buffer returned by this function is owned by the caller
> + * and will need to be freed.
> */
> const char *drm_get_format_name(uint32_t format)
> {
> - static char buf[32];
> + char *buf = kmalloc(32, GFP_KERNEL);
hmm, I guess I wasn't paying attention at the time this patch came by,
but unfortunately this makes drm_get_format_name() no longer safe in
atomic contexts :-/
We should probably either revert this or have two variants of
drm_get_format_name()? (ie. one that is not thread safe but is good
enough for debugging)
BR,
-R
> - snprintf(buf, sizeof(buf),
> + snprintf(buf, 32,
> "%c%c%c%c %s-endian (0x%08x)",
> printable_char(format & 0xff),
> printable_char((format >> 8) & 0xff),
> @@ -73,6 +71,8 @@ EXPORT_SYMBOL(drm_get_format_name);
> void drm_fb_get_bpp_depth(uint32_t format, unsigned int *depth,
> int *bpp)
> {
> + const char *format_name;
> +
> switch (format) {
> case DRM_FORMAT_C8:
> case DRM_FORMAT_RGB332:
> @@ -127,8 +127,9 @@ void drm_fb_get_bpp_depth(uint32_t format, unsigned int
> *depth,
> *bpp = 32;
> break;
> default:
> - DRM_DEBUG_KMS("unsupported pixel format %s\n",
> - drm_get_format_name(format));
> + format_name = drm_get_format_name(format);
> + DRM_DEBUG_KMS("unsupported pixel format %s\n", format_name);
> + kfree(format_name);
> *depth = 0;
> *bpp = 0;
> break;
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index 7f90a39..030d22d 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -32,6 +32,6 @@ int drm_format_horz_chroma_subsampling(uint32_t format);
> int drm_format_vert_chroma_subsampling(uint32_t format);
> int drm_format_plane_width(int width, uint32_t format, int plane);
> int drm_format_plane_height(int height, uint32_t format, int plane);
> -const char *drm_get_format_name(uint32_t format);
> +const char *drm_get_format_name(uint32_t format) __malloc;
>
> #endif /* __DRM_FOURCC_H__ */
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index c1b04e9..0bf8959 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -2071,6 +2071,7 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc
> *crtc,
> u32 tmp, viewport_w, viewport_h;
> int r;
> bool bypass_lut = false;
> + const char *format_name;
>
> /* no fb bound */
> if (!atomic && !crtc->primary->fb) {
> @@ -2182,8 +2183,9 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc
> *crtc,
> bypass_lut = true;
>
Re: [Intel-gfx] [PATCH] drm: move allocation out of drm_get_format_name()
On Sat, Nov 5, 2016 at 12:38 PM, Eric Engestrom wrote:
> On Saturday, 2016-11-05 13:11:36 +0100, Christian König wrote:
>> Am 05.11.2016 um 02:33 schrieb Eric Engestrom:
>> > +typedef char drm_format_name_buf[32];
>>
>> Please don't use a typedef for this, just define the maximum size of
>> characters the function might write somewhere.
>>
>> See the kernel coding style as well:
>> > In general, a pointer, or a struct that has elements that can reasonably
>> > be directly accessed should **never** be a typedef.
>>
>
> I would normally agree as I tend to hate typedefs ($DAYJOB {ab,mis}uses
> them way too much), and your way was what I wrote at first, but Rob Clark's
> typedef idea makes it much harder for someone to allocate a buffer of
> the wrong size, which IMO is good thing here.
IMHO I would make a small test program to verify this actually helps
the compiler catch problems. And if it does, I would stick with it.
The coding-style should be guidelines, not something that supersedes
common sense / practicality.
That is my $0.02 anyways.. if others vehemently disagree and want to
dogmatically stick to the coding-style guidelines, ok then. OTOH, if
this approach doesn't help the compiler catch issues, then it isn't
worth it.
BR,
-R
> I can rewrite the typedef out if you think it's better.
>
> Cheers,
> Eric
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: move allocation out of drm_get_format_name()
On Sun, Nov 6, 2016 at 4:47 AM, Christian König
wrote:
> Am 05.11.2016 um 17:49 schrieb Rob Clark:
>>
>> On Sat, Nov 5, 2016 at 12:38 PM, Eric Engestrom wrote:
>>>
>>> On Saturday, 2016-11-05 13:11:36 +0100, Christian König wrote:
>>>>
>>>> Am 05.11.2016 um 02:33 schrieb Eric Engestrom:
>>>>>
>>>>> +typedef char drm_format_name_buf[32];
>>>>
>>>> Please don't use a typedef for this, just define the maximum size of
>>>> characters the function might write somewhere.
>>>>
>>>> See the kernel coding style as well:
>>>>>
>>>>> In general, a pointer, or a struct that has elements that can
>>>>> reasonably
>>>>> be directly accessed should **never** be a typedef.
>>>
>>> I would normally agree as I tend to hate typedefs ($DAYJOB {ab,mis}uses
>>> them way too much), and your way was what I wrote at first, but Rob
>>> Clark's
>>> typedef idea makes it much harder for someone to allocate a buffer of
>>> the wrong size, which IMO is good thing here.
>>
>> IMHO I would make a small test program to verify this actually helps
>> the compiler catch problems. And if it does, I would stick with it.
>> The coding-style should be guidelines, not something that supersedes
>> common sense / practicality.
>
>
> Well completely agree that we should be able to question the coding style
> rules, but when we do it we discuss this on a the mailing list first and
> then start to use it in code. Not the other way around.
if I'm not mistaken, that is what we are doing ;-)
>>
>> That is my $0.02 anyways.. if others vehemently disagree and want to
>> dogmatically stick to the coding-style guidelines, ok then. OTOH, if
>> this approach doesn't help the compiler catch issues, then it isn't
>> worth it.
>
>
> Yeah, exactly that's the point. If I'm not completely mistaken the compiler
> won't issue a warning here if you pass an array with the wrong size.
>
> I think you need something like "struct drm_format_name_buf { char str[32];
> };" to trigger this.
hmm, actually the struct is a nice idea then if the compiler wouldn't
catch the wrong-size-array
> Apart from that is this function really called so often that using
> kasprintf() is a problem here? Or is there another motivation behind the
> change?
Two things trouble me about the kasprintf approach.. (ignoring the
fact that atm it is not GFP_ATOMIC)
1) you can't do DRM_DEBUG("format: %s\n", drm_get_format_name(..)) so
it pulls the memory allocation and sprintf outside of the drm_debug
check
2) seems awfully easy to forget the kfree... I wouldn't have even
known that now you need to free the result (with some patches I'm
working on) if it weren't for the fact that lockdep alerted me to the
GFP_KERNEL allocation in atomic ctx ;-)
BR,
-R
> Regards,
> Christian.
>
>
>>
>> BR,
>> -R
>>
>>> I can rewrite the typedef out if you think it's better.
>>>
>>> Cheers,
>>>Eric
>>> ___
>>> dri-devel mailing list
>>> dri-de...@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm: move allocation out of drm_get_format_name()
On Sun, Nov 6, 2016 at 7:48 PM, Eric Engestrom wrote:
> Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
>
> drm: make drm_get_format_name thread-safe
>
> Signed-off-by: Eric Engestrom
> [danvet: Clarify that the returned pointer must be freed with
> kfree().]
> Signed-off-by: Daniel Vetter
>
> Cc: Rob Clark
> Cc: Christian König
> Suggested-by: Ville Syrjälä
> Signed-off-by: Eric Engestrom
Thanks,
Acked-by: Rob Clark
> ---
>
> v2: use single-field struct instead of typedef to let the compiler
> enforce the type (Christian König)
>
> ---
> include/drm/drm_fourcc.h| 10 +-
> drivers/gpu/drm/drm_fourcc.c| 14 +++--
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 7 ++---
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 7 ++---
> drivers/gpu/drm/amd/amdgpu/dce_v6_0.c | 3 +-
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 7 ++---
> drivers/gpu/drm/drm_atomic.c| 7 +++--
> drivers/gpu/drm/drm_crtc.c | 7 +++--
> drivers/gpu/drm/drm_framebuffer.c | 7 +++--
> drivers/gpu/drm/drm_modeset_helper.c| 7 +++--
> drivers/gpu/drm/drm_plane.c | 7 +++--
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 7 ++---
> drivers/gpu/drm/i915/i915_debugfs.c | 10 +++---
> drivers/gpu/drm/i915/intel_atomic_plane.c | 8 ++---
> drivers/gpu/drm/i915/intel_display.c| 41
> ++---
> drivers/gpu/drm/radeon/atombios_crtc.c | 14 -
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 3 +-
> 17 files changed, 80 insertions(+), 86 deletions(-)
>
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index dc0aafa..4b03ca0 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -45,6 +45,14 @@ struct drm_format_info {
> u8 vsub;
> };
>
> +/**
> + * struct drm_format_name_buf - name of a DRM format
> + * @str: string buffer containing the format name
> + */
> +struct drm_format_name_buf {
> + char str[32];
> +};
> +
> const struct drm_format_info *__drm_format_info(u32 format);
> const struct drm_format_info *drm_format_info(u32 format);
> uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
> @@ -54,6 +62,6 @@ int drm_format_horz_chroma_subsampling(uint32_t format);
> int drm_format_vert_chroma_subsampling(uint32_t format);
> int drm_format_plane_width(int width, uint32_t format, int plane);
> int drm_format_plane_height(int height, uint32_t format, int plane);
> -char *drm_get_format_name(uint32_t format) __malloc;
> +char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf);
>
> #endif /* __DRM_FOURCC_H__ */
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index cbb8b77..99b0b60 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -79,17 +79,13 @@ uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t
> depth)
> EXPORT_SYMBOL(drm_mode_legacy_fb_format);
>
> /**
> - * drm_get_format_name - return a string for drm fourcc format
> + * drm_get_format_name - fill a string with a drm fourcc format's name
> * @format: format to compute name of
> + * @buf: caller-supplied buffer
> - *
> - * Note that the buffer returned by this function is owned by the caller
> - * and will need to be freed using kfree().
> */
> -char *drm_get_format_name(uint32_t format)
> +char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf)
> {
> - char *buf = kmalloc(32, GFP_KERNEL);
> -
> - snprintf(buf, 32,
> + snprintf(buf->str, sizeof(buf->str),
> "%c%c%c%c %s-endian (0x%08x)",
> printable_char(format & 0xff),
> printable_char((format >> 8) & 0xff),
> @@ -98,7 +94,7 @@ char *drm_get_format_name(uint32_t format)
> format & DRM_FORMAT_BIG_ENDIAN ? "big" : "little",
> format);
>
> - return buf;
> + return buf->str;
> }
> EXPORT_SYMBOL(drm_get_format_name);
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index 199d3f7..2924cdd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -2032,7 +2032,7 @@ static int dce_v10_0_crtc_do_set_base(struct drm_crtc
> *crtc,
> u32 tmp, viewport_w, viewport_h;
> int r;
> bool bypass_lut = false;
> - char *format_name;
> + struct
Re: [Intel-gfx] [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting
On Tue, Feb 23, 2016 at 9:33 PM, Thulasimani, Sivakumar
wrote:
>
>
> On 2/24/2016 3:41 AM, Lyude wrote:
>>
>> As it turns out, resuming DP MST is racey since we don't make sure MST
>> is ready before we start modesetting, it just usually happens to be
>> ready in time. This isn't the case on all systems, particularly a
>> ThinkPad T560 with displays connected through the dock. On these
>> systems, resuming the laptop while connected to the dock usually results
>> in blank monitors. Making sure MST is ready before doing any kind of
>> modesetting fixes this issue.
>
> basic question since i haven't worked on MST much. MST should work like any
> other digital panel on resume. i.e detect followed by modeset. in the
> modified
> commit mentioned below is it failing to detect the panel or failing at the
> modeset ?
> if we are depending on the intel_display_resume, how about moving the
> intel_dp_mst_resume just above intel_display_resume?
>
so I think the issue is there needs to be communication with (for
example) hubs that sit downstream.. we probably do need enough clks
and irq's going so that dpcd xfer's work, but then I think we should
do mst_resume() first and then display_resume()
BR,
-R
>
> Generic question to others in mail list on i915_drm_resume
> we are doing a modeset and then doing the detect/hpd init.
> shouldn't this be the other way round ? almost all displays
> will pass a modeset even if display is not connected so we
> are spending time on modeset even for displays that were
> removed during the suspend state. if this is to simply
> drm_state being saved and restored,
>>
>> We originally changed the resume order in
>>
>> commit e7d6f7d70829 ("drm/i915: resume MST after reading back hw
>> state")
>>
>> to fix a ton of WARN_ON's after resume, but this doesn't seem to be an
>> issue now anyhow.
>>
>> CC: sta...@vger.kernel.org
>> Signed-off-by: Lyude
>> ---
>> drivers/gpu/drm/i915/i915_drv.c | 10 --
>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index f357058..4dcf3dd 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -733,6 +733,14 @@ static int i915_drm_resume(struct drm_device *dev)
>> intel_opregion_setup(dev);
>> intel_init_pch_refclk(dev);
>> +
>> + /*
>> +* We need to make sure that we resume MST before doing anything
>> +* display related, otherwise we risk trying to bring up a display
>> on
>> +* MST before the hub is actually ready
>> +*/
>> + intel_dp_mst_resume(dev);
>> +
>
> This does not look proper. if the CD clock is turned off during suspend
> our dpcd read itself might fail till we enable CD Clock.
>
> regards,
> Sivakumar
>>
>> drm_mode_config_reset(dev);
>> /*
>> @@ -765,8 +773,6 @@ static int i915_drm_resume(struct drm_device *dev)
>> intel_display_resume(dev);
>> drm_modeset_unlock_all(dev);
>> - intel_dp_mst_resume(dev);
>> -
>> /*
>> * ... but also need to make sure that hotplug processing
>> * doesn't cause havoc. Like in the driver load code we don't
>
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Change WARN_ON(!wm_changed) to I915_STATE_WARN_ON()
On Feb 29 2016 or thereabouts, Daniel Vetter wrote: > On Mon, Feb 22, 2016 at 02:22:49PM -0500, Lyude wrote: > > These warnings still seem to be present with DP MST configurations. They > > don't actually indicate any impending doom, so we may as well use > > I915_STATE_WARN_ON() here to help quiet things down a little bit for > > distro kernel users. > > > > Signed-off-by: Lyude > > I thought we've fixed up all offenders in drm-intel-nightly? Can you pls > confirm this is the case - this isn't something we should shrug off ... I was still seeing this w/ nightly as of perhaps ~mid last week.. Note that upstream default is still to have verbose state warn's so this would still be the splat that you want to see ;-) BR, -R > Also, I kinda wonder whether we should try another attempt at enabling > this, in 4.6/fc rawhide perhaps, and see what happens? We /should/ be a > lot better with all this fail now. > > I guess if this is all fixed in upstream/4.6 already then we could apply > this to 4.5 and stable kernels. But I don't really want this in upstream, > if it can be avoided. > > Thanks, Daniel > > > --- > > drivers/gpu/drm/i915/intel_pm.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c > > b/drivers/gpu/drm/i915/intel_pm.c > > index a234687..1870185 100644 > > --- a/drivers/gpu/drm/i915/intel_pm.c > > +++ b/drivers/gpu/drm/i915/intel_pm.c > > @@ -3545,7 +3545,7 @@ static void skl_update_other_pipe_wm(struct > > drm_device *dev, > > * because it was really needed, so we expect the WM values to > > * be different. > > */ > > - WARN_ON(!wm_changed); > > + I915_STATE_WARN_ON(!wm_changed); > > > > skl_compute_wm_results(dev, &pipe_wm, r, intel_crtc); > > r->dirty[intel_crtc->pipe] = true; > > -- > > 2.5.0 > > > > ___ > > dri-devel mailing list > > dri-de...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting
On Mon, Feb 29, 2016 at 11:12 AM, Daniel Vetter wrote:
> On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote:
>>
>>
>> On 2/24/2016 3:41 AM, Lyude wrote:
>> >As it turns out, resuming DP MST is racey since we don't make sure MST
>> >is ready before we start modesetting, it just usually happens to be
>> >ready in time. This isn't the case on all systems, particularly a
>> >ThinkPad T560 with displays connected through the dock. On these
>> >systems, resuming the laptop while connected to the dock usually results
>> >in blank monitors. Making sure MST is ready before doing any kind of
>> >modesetting fixes this issue.
>> basic question since i haven't worked on MST much. MST should work like any
>> other digital panel on resume. i.e detect followed by modeset. in the
>> modified
>> commit mentioned below is it failing to detect the panel or failing at the
>> modeset ?
>> if we are depending on the intel_display_resume, how about moving the
>> intel_dp_mst_resume just above intel_display_resume?
>>
>>
>> Generic question to others in mail list on i915_drm_resume
>> we are doing a modeset and then doing the detect/hpd init.
>> shouldn't this be the other way round ? almost all displays
>> will pass a modeset even if display is not connected so we
>> are spending time on modeset even for displays that were
>> removed during the suspend state. if this is to simply
>> drm_state being saved and restored,
>
> We must restore anyway, we're not really allowed to shut down a display
> without userspace's consent. DP mst breaks this, and it's not fun really.
well, that isn't completely true.. I mean, if the user unplugs (for
example) an hdmi monitor, it isn't with userspace's consent..
I wonder if we could just have flag per connector, ie.
connector->no_auto_resume and just automatically send unplug events
for those to userspace (followed shortly by a plug event if it is
still connected and the normal hpd mechanism kicks in? I mean, for
all we know, the user unplugged the DP monitor/hub/etc and plugged in
a different one while we were suspended..
BR,
-R
> So for hotunplug the flow should always be:
> 1. kernel notices something has changed in the output config.
> 2. kernel sends out uevent
> 3. userspace figures out what changed, and what needs to be done
> 4. userspace asks the kernel to change display configuration through
> setCrtc and Atomic ioctl calls.
>
> Irrespective of hotunplug handling, the kernel also _must_ restore the
> entire display configuration before userspace resumes. We can do that
> asynchronously (and there's plans for that), but even then we must stall
> userspace on the first KMS ioclt to keep up the illusion that a system s/r
> is transparent.
>
> In short, even if we do hpd processing before resuming the display,
> nothing will be faster - we must wait for userspace to make up its mind,
> and that can only happen once we've restored the display config.
>
> And again, mst is kinda breaking this, since and mst unplug results in a
> force-disable. Which can upset userspace and in general results in the
> need for lots of fragile error handling all over.
>
>> >We originally changed the resume order in
>> >
>> > commit e7d6f7d70829 ("drm/i915: resume MST after reading back hw
>> > state")
>> >
>> >to fix a ton of WARN_ON's after resume, but this doesn't seem to be an
>> >issue now anyhow.
>> >
>> >CC: sta...@vger.kernel.org
>> >Signed-off-by: Lyude
>
> Wrt the patch itself: I think only in 4.6 we've actually fixed up all
> these mst WARN_ON. Cc: stable seems extremely risky on this one. Also, the
> modeset state readout for mst is still not entirely correct (it still
> relies on software state), so I'm not sure we've actually managed to shut
> up all the WARNINGs. Iirc the way to repro them is to hot-unplug something
> while suspended. In short the get_hw_state functions for mst should not
> rely on any mst software state, but instead just look at hw registers and
> dp aux registers to figure out what's going on. But not sure whether this
> will result on WARNINGs on resume, since generally the bios doesn't enable
> anything in that case.
>
> Furthermore MST still does a force-modeset when processing a hotunplug.
> Doing that before we've resumed the display is likely a very bad idea.
> What we need to fix that part is to separate the dp mst connector
> hotplug/unplugging from actually updating the modeset change. This needs
> reference-counting on drm_connector (so that we can lazily free
> drm_connector structs after hot-unplug), and is a major change.
>
> In short: I'm scared about this patch ;-)
>
> Thanks, Daniel
>
>
>> >---
>> > drivers/gpu/drm/i915/i915_drv.c | 10 --
>> > 1 file changed, 8 insertions(+), 2 deletions(-)
>> >
>> >diff --git a/drivers/gpu/drm/i915/i915_drv.c
>> >b/drivers/gpu/drm/i915/i915_drv.c
>> >index f357058..4dcf3dd 100644
>> >--- a/drivers/gpu/drm/i915/i915_drv.c
>> >+++ b/drivers/gpu/drm/i915/i915_drv.c
>> >@@ -733,6 +733,14 @@
Re: [Intel-gfx] [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting
On Mon, Feb 29, 2016 at 7:47 PM, Thulasimani, Sivakumar wrote: > > > On 3/1/2016 5:03 AM, Rob Clark wrote: >> >> On Mon, Feb 29, 2016 at 11:12 AM, Daniel Vetter wrote: >>> >>> On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote: >>>> >>>> >>>> On 2/24/2016 3:41 AM, Lyude wrote: >>>>> >>>>> As it turns out, resuming DP MST is racey since we don't make sure MST >>>>> is ready before we start modesetting, it just usually happens to be >>>>> ready in time. This isn't the case on all systems, particularly a >>>>> ThinkPad T560 with displays connected through the dock. On these >>>>> systems, resuming the laptop while connected to the dock usually >>>>> results >>>>> in blank monitors. Making sure MST is ready before doing any kind of >>>>> modesetting fixes this issue. >>>> >>>> basic question since i haven't worked on MST much. MST should work like >>>> any >>>> other digital panel on resume. i.e detect followed by modeset. in the >>>> modified >>>> commit mentioned below is it failing to detect the panel or failing at >>>> the >>>> modeset ? >>>> if we are depending on the intel_display_resume, how about moving the >>>> intel_dp_mst_resume just above intel_display_resume? >>>> >>>> >>>> Generic question to others in mail list on i915_drm_resume >>>> we are doing a modeset and then doing the detect/hpd init. >>>> shouldn't this be the other way round ? almost all displays >>>> will pass a modeset even if display is not connected so we >>>> are spending time on modeset even for displays that were >>>> removed during the suspend state. if this is to simply >>>> drm_state being saved and restored, >>> >>> We must restore anyway, we're not really allowed to shut down a display >>> without userspace's consent. DP mst breaks this, and it's not fun really. >> >> well, that isn't completely true.. I mean, if the user unplugs (for >> example) an hdmi monitor, it isn't with userspace's consent.. >> >> I wonder if we could just have flag per connector, ie. >> connector->no_auto_resume and just automatically send unplug events >> for those to userspace (followed shortly by a plug event if it is >> still connected and the normal hpd mechanism kicks in? I mean, for >> all we know, the user unplugged the DP monitor/hub/etc and plugged in >> a different one while we were suspended.. >> >> BR, >> -R > > i agree. performing a modeset on a display without even confirming > if it is the same one when we had suspended the system will result in > issues such as applying a mode that may not be supported on the > new display or corruption or blankout or simply failing the modeset > restore or worst case of doing modeset without a display connected. > if we will not allow such a scenario during normal operation, i.e prevent > incorrect modeset requests during normal functioning, why allow such > a modeset during suspend-resume alone ? > we can store the edid hash and if the display has the same hash > post resume then we can allow mode to be restored. that seems like a good idea for HDMI/DVI/etc.. although I suspect for DP there may be 50 more shades of grey.. ie. same monitor re-attached through different sequence of hubs.. :-( BR, -R > regards, > Sivakumar > >>> So for hotunplug the flow should always be: >>> 1. kernel notices something has changed in the output config. >>> 2. kernel sends out uevent >>> 3. userspace figures out what changed, and what needs to be done >>> 4. userspace asks the kernel to change display configuration through >>> setCrtc and Atomic ioctl calls. >>> >>> Irrespective of hotunplug handling, the kernel also _must_ restore the >>> entire display configuration before userspace resumes. We can do that >>> asynchronously (and there's plans for that), but even then we must stall >>> userspace on the first KMS ioclt to keep up the illusion that a system >>> s/r >>> is transparent. >>> >>> In short, even if we do hpd processing before resuming the display, >>> nothing will be faster - we must wait for userspace to make up its mind, >>> and that can only happen once we've restored the display config. >>> >>> And again, mst is kinda breaking this, since and mst unplug results in a &g
Re: [Intel-gfx] [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting
On Wed, Mar 2, 2016 at 4:29 AM, Daniel Vetter wrote: > On Mon, Feb 29, 2016 at 06:33:42PM -0500, Rob Clark wrote: >> On Mon, Feb 29, 2016 at 11:12 AM, Daniel Vetter wrote: >> > On Wed, Feb 24, 2016 at 08:03:04AM +0530, Thulasimani, Sivakumar wrote: >> >> >> >> >> >> On 2/24/2016 3:41 AM, Lyude wrote: >> >> >As it turns out, resuming DP MST is racey since we don't make sure MST >> >> >is ready before we start modesetting, it just usually happens to be >> >> >ready in time. This isn't the case on all systems, particularly a >> >> >ThinkPad T560 with displays connected through the dock. On these >> >> >systems, resuming the laptop while connected to the dock usually results >> >> >in blank monitors. Making sure MST is ready before doing any kind of >> >> >modesetting fixes this issue. >> >> basic question since i haven't worked on MST much. MST should work like >> >> any >> >> other digital panel on resume. i.e detect followed by modeset. in the >> >> modified >> >> commit mentioned below is it failing to detect the panel or failing at the >> >> modeset ? >> >> if we are depending on the intel_display_resume, how about moving the >> >> intel_dp_mst_resume just above intel_display_resume? >> >> >> >> >> >> Generic question to others in mail list on i915_drm_resume >> >> we are doing a modeset and then doing the detect/hpd init. >> >> shouldn't this be the other way round ? almost all displays >> >> will pass a modeset even if display is not connected so we >> >> are spending time on modeset even for displays that were >> >> removed during the suspend state. if this is to simply >> >> drm_state being saved and restored, >> > >> > We must restore anyway, we're not really allowed to shut down a display >> > without userspace's consent. DP mst breaks this, and it's not fun really. >> >> well, that isn't completely true.. I mean, if the user unplugs (for >> example) an hdmi monitor, it isn't with userspace's consent.. > > But the pipe keeps running, which means the next pageflip or vblank wait > won't just fail and result in hilarity. well, then shut it down? But what do we do on hot unplug? It seems like we should be able to make it look like an unplug plus later replug. >> I wonder if we could just have flag per connector, ie. >> connector->no_auto_resume and just automatically send unplug events >> for those to userspace (followed shortly by a plug event if it is >> still connected and the normal hpd mechanism kicks in? I mean, for >> all we know, the user unplugged the DP monitor/hub/etc and plugged in >> a different one while we were suspended.. > > We need to be able to restore mst to avoid upsetting the desktop. I don't > think this would work. I think the desktop already supports hotplug, or we'd have bigger issues. What happens if the DP topology changes while suspended. Ie. user plugs in a different monitor with a hub in between, or things like that? Seems like you can end up in scenarios where previous mode is no longer valid/possible. BR, -R > -Daniel > >> >> BR, >> -R >> >> > So for hotunplug the flow should always be: >> > 1. kernel notices something has changed in the output config. >> > 2. kernel sends out uevent >> > 3. userspace figures out what changed, and what needs to be done >> > 4. userspace asks the kernel to change display configuration through >> > setCrtc and Atomic ioctl calls. >> > >> > Irrespective of hotunplug handling, the kernel also _must_ restore the >> > entire display configuration before userspace resumes. We can do that >> > asynchronously (and there's plans for that), but even then we must stall >> > userspace on the first KMS ioclt to keep up the illusion that a system s/r >> > is transparent. >> > >> > In short, even if we do hpd processing before resuming the display, >> > nothing will be faster - we must wait for userspace to make up its mind, >> > and that can only happen once we've restored the display config. >> > >> > And again, mst is kinda breaking this, since and mst unplug results in a >> > force-disable. Which can upset userspace and in general results in the >> > need for lots of fragile error handling all over. >> > >> >> >We originally changed the resume order in >> >> >
Re: [Intel-gfx] [RFC/PATCH xf86-video-intel] sna: Let modestting + glamor handle gen9+
On Fri, Mar 11, 2016 at 5:07 AM, Timo Aaltonen wrote: > 29.02.2016, 16:47, Hans de Goede kirjoitti: >> sna has no meaningfull accel for gen9+, this causes problems with i.e. >> apps using XVideo since the sprite XVideo support does not work well >> for many apps. >> >> Therefor it is better to just let the xserver fall back to modesetting + >> glamor. This is implemented by returning FALSE from the probe methods, >> just like how nouveau handles falling back to modesetting for newer cards. >> >> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1305369 >> Signed-off-by: Hans de Goede > > I've been trying to make this work, but there are cases where it fails bad: > > # a config file with a Device section that loads 'intel' makes the > server fail > [10.153] (EE) No devices detected. > [10.153] (EE) > Fatal server error: > [10.153] (EE) no screens found(EE) I'd be awfully tempted to call that NOTABUG.. I mean, it would fail in same way if you had a .conf that tried to force ati ddx on a system without a radeon card.. BR, -R > ie. no fallback in that case > > # with X run as root (wrapper or not), same thing different cause > [ 145.943] (EE) modeset(0): drmSetMaster failed: Invalid argument > [ 145.943] (EE) > Fatal server error: > [ 145.943] (EE) AddScreen/ScreenInit failed for driver 0 > > > but it does work with startx run by a user. Tests done on Debian with > 1.18.1 and intel ddx git. > > -- > t > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: problems fetching the drm-intel, etc trees
yeah, {cgit,anongit}.fd.o have been having problems all day.. (the ssh
git urls for folks who have push access work fine).. although it has
worked for me a couple times today, given enough time.
(not sure if we have github/etc mirrors somewhere? I do have a github
clone of mesa which is up to date as of ~10min ago.. I could do the
same for other git trees if someone somewhere is stuck)
BR,
-R
On Wed, Nov 30, 2016 at 5:39 PM, Stephen Rothwell wrote:
> Hi all,
>
> There is something seriaously wrong with anongit.freedesktop.org this
> morning. Fething trees from there takes an enormous amount of time -
> so long that I had to abort the fetches ...
>
> --
> Cheers,
> Stephen Rothwell
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/11] drm/msm: Remove call to reservation_object_test_signaled_rcu before wait
On Fri, Sep 23, 2016 at 8:55 AM, Daniel Vetter wrote:
> On Mon, Aug 29, 2016 at 08:08:26AM +0100, Chris Wilson wrote:
>> Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
>> timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
>> need to handle such conversion in the caller. The only challenge are
>> those callers that wish to differentiate the error code between the
>> nonblocking busy check and potentially blocking wait.
>>
>> v2: 9 is only 0 in German.
>>
>> Signed-off-by: Chris Wilson
>> Cc: Rob Clark
>
> Reviewed-by: Daniel Vetter
fyi, this is in my msm-next pull-req sent last week.. (with one small
s/MSG_PREP_NOSYNC/MSM_PREP_NOSYNC/ fixup ;-))
BR,
-R
>> ---
>> drivers/gpu/drm/msm/msm_gem.c | 22 ++
>> 1 file changed, 10 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
>> index 6cd4af443139..45796a88d353 100644
>> --- a/drivers/gpu/drm/msm/msm_gem.c
>> +++ b/drivers/gpu/drm/msm/msm_gem.c
>> @@ -584,18 +584,16 @@ int msm_gem_cpu_prep(struct drm_gem_object *obj,
>> uint32_t op, ktime_t *timeout)
>> {
>> struct msm_gem_object *msm_obj = to_msm_bo(obj);
>> bool write = !!(op & MSM_PREP_WRITE);
>> -
>> - if (op & MSM_PREP_NOSYNC) {
>> - if (!reservation_object_test_signaled_rcu(msm_obj->resv,
>> write))
>> - return -EBUSY;
>> - } else {
>> - int ret;
>> -
>> - ret = reservation_object_wait_timeout_rcu(msm_obj->resv, write,
>> - true, timeout_to_jiffies(timeout));
>> - if (ret <= 0)
>> - return ret == 0 ? -ETIMEDOUT : ret;
>> - }
>> + unsigned long remain =
>> + op & MSG_PREP_NOSYNC ? 0 : timeout_to_jiffies(timeout);
>> + long ret;
>> +
>> + ret = reservation_object_wait_timeout_rcu(msm_obj->resv, write,
>> + true, remain);
>> + if (ret == 0)
>> + return remain == 0 ? -EBUSY : -ETIMEDOUT;
>> + else if (ret < 0)
>> + return ret;
>>
>> /* TODO cache maintenance */
>>
>> --
>> 2.9.3
>>
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 00/16] drm: drm: Per-plane rotation etc.
On Mon, Sep 26, 2016 at 12:30 PM, wrote: > From: Ville Syrjälä > > Another, rebased, version of my earlier series [1] to add the per-plane > rotation property. One thing holding back the previous version was the > weird regression on omap, but apparently I managed to fix it (see [2]). > > msm and omap still lack r-bs/acks. > > Entire series available here: > git://github.com/vsyrjala/linux.git chv_mirror_4 > > Cc: Tomi Valkeinen > Cc: Rob Clark > Cc: Jilai Wang > Cc: Archit Taneja > > Ville Syrjälä (15): > drm: Add drm_rotation_90_or_270() > drm/atomic: Reject attempts to use multiple rotation angles at once > drm: Add support for optional per-plane rotation property > drm/arm: Use per-plane rotation property > drm/atmel-hlcdc: Use per-plane rotation property > drm/omap: Set rotation property initial value to BIT(DRM_ROTATE_0) > insted of 0 > drm/omap: Use per-plane rotation property > drm/msm/mdp5: Set rotation property initial value to BIT(DRM_ROTATE_0) > insted of 0 fwiw, this one (but with s/BIT(DRM_ROTATE_x)/DRM_ROTATE_x/) is in msm-next for 4.9.. the other msm patches (from previous patchset) looked reasonable but needed some rebasing so I skipped them. But you can go ahead and slap on my r-b. BR, -R > drm/msm/mdp5: Use per-plane rotation property > drm/msm/mdp5: Advertize 180 degree rotation > drm/i915: Use the per-plane rotation property > drm: RIP mode_config->rotation_property > drm/i915: Use & instead if == to check for rotations > drm/i915: Clean up rotation DSPCNTR/DVSCNTR/etc. setup > drm/i915: Add horizontal mirroring support for CHV pipe B planes > > drivers/gpu/drm/arm/malidp_planes.c | 13 ++- > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 41 - > drivers/gpu/drm/drm_atomic.c| 6 +- > drivers/gpu/drm/drm_atomic_helper.c | 2 +- > drivers/gpu/drm/drm_blend.c | 39 + > drivers/gpu/drm/drm_crtc.c | 3 +- > drivers/gpu/drm/drm_fb_helper.c | 5 +- > drivers/gpu/drm/i915/intel_atomic_plane.c | 11 ++- > drivers/gpu/drm/i915/intel_display.c| 107 > > drivers/gpu/drm/i915/intel_drv.h| 9 -- > drivers/gpu/drm/i915/intel_fbc.c| 2 +- > drivers/gpu/drm/i915/intel_pm.c | 12 +-- > drivers/gpu/drm/i915/intel_sprite.c | 53 > drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 35 +--- > drivers/gpu/drm/omapdrm/omap_crtc.c | 13 ++- > drivers/gpu/drm/omapdrm/omap_drv.c | 50 +-- > drivers/gpu/drm/omapdrm/omap_plane.c| 21 +++-- > include/drm/drm_blend.h | 10 ++- > include/drm/drm_crtc.h | 5 -- > include/drm/drm_plane.h | 2 + > 20 files changed, 243 insertions(+), 196 deletions(-) > > -- > 2.7.4 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/11] drm/msm: A5XX preemption
On Mon, Feb 6, 2017 at 1:23 PM, Daniel Stone wrote: > Hi, > > On 6 February 2017 at 17:59, Daniel Vetter wrote: >> On Mon, Feb 06, 2017 at 10:39:28AM -0700, Jordan Crouse wrote: >>> This initial series implements 4 ringbuffers to give sufficient coverage >>> for the >>> range of priority levels requested by the GLES and compute extensions. The >>> targeted ringbuffer is specified in the command submission flags. The >>> default >>> ring is 0 (lowest priority). >> >> Link to userspace part that implements these extensions? Also which >> gles/compute extensions are you talking about? Asking not just because of >> the open source userspace requirement, but also because we want to >> upstream a scheduler on the i915 side. Getting alignment on that across >> drm drivers would be sweet. > > Assuming he meant EGL rather than GLES, this is the usual one: > https://www.khronos.org/registry/EGL/extensions/IMG/EGL_IMG_context_priority.txt > There was an RFC for this from Chris.. not sure if it landed yet, but that is what I was planning to use from the userspace side. Probably first step would be to enable this without preemption points. Although I think I have a reasonable idea how the preemption points work.. BR, -R ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/fb-helper: Fix fb refcounting in pan_display_atomic
On Fri, Oct 16, 2015 at 12:23 PM, Daniel Vetter wrote:
> In
>
> commit bbb1e52402b2a288b09ae37e8182599931c7e9df
> Author: Rob Clark
> Date: Tue Aug 25 15:35:58 2015 -0400
>
> drm/fb-helper: atomic restore_fbdev_mode()..
>
> we've forgotten to do the plane->old_fb refcount dance for
> pan_display_atomic, which can result in refcount leaks if the current
> configuration is not from fbcon. Which apparently can happen when
> vt-switching - fbcon does a pan first before a set_par.
oh, whoops
> OCD-align function parameters while at it.
did you mean to drop that line from the commit msg, or include an
extra hunk that you missed?
at any rate,
Reviewed-by: Rob Clark
> Cc: Rob Clark
> Cc: Rodrigo Vivi
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92483
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fb_helper.c | 27 +--
> 1 file changed, 25 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 0ac0fcc9b0d2..b2cf28dd90fe 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1249,6 +1249,8 @@ retry:
>
> mode_set = &fb_helper->crtc_info[i].mode_set;
>
> + mode_set->crtc->primary->old_fb = mode_set->crtc->primary->fb;
> +
> mode_set->x = var->xoffset;
> mode_set->y = var->yoffset;
>
> @@ -1264,13 +1266,34 @@ retry:
> info->var.xoffset = var->xoffset;
> info->var.yoffset = var->yoffset;
>
> - return 0;
>
> fail:
> + for(i = 0; i < fb_helper->crtc_count; i++) {
> + struct drm_mode_set *mode_set;
> + struct drm_plane *plane;
> +
> + mode_set = &fb_helper->crtc_info[i].mode_set;
> + plane = mode_set->crtc->primary;
> +
> + if (ret == 0) {
> + struct drm_framebuffer *new_fb = plane->state->fb;
> +
> + if (new_fb)
> + drm_framebuffer_reference(new_fb);
> + plane->fb = new_fb;
> + plane->crtc = plane->state->crtc;
> +
> + if (plane->old_fb)
> + drm_framebuffer_unreference(plane->old_fb);
> + }
> + plane->old_fb = NULL;
> + }
> +
> if (ret == -EDEADLK)
> goto backoff;
>
> - drm_atomic_state_free(state);
> + if (ret != 0)
> + drm_atomic_state_free(state);
>
> return ret;
>
> --
> 2.5.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm: Use userspace compatible type in fourcc_mod_code macro
On Thu, Nov 5, 2015 at 7:51 AM, Jani Nikula wrote: > On Wed, 23 Sep 2015, Ville Syrjälä wrote: >> On Wed, Sep 23, 2015 at 10:10:31AM +0100, Tvrtko Ursulin wrote: >>> From: Tvrtko Ursulin >>> >>> __u64 should be used instead of u64. >>> >>> Feature originally added in: >>> >>> commit e3eb3250d84ef97b766312345774367b6a310db8 >>> Author: Rob Clark >>> Date: Thu Feb 5 14:41:52 2015 + >>> >>> drm: add support for tiled/compressed/etc modifier in addfb2 >>> >>> Signed-off-by: Tvrtko Ursulin >>> Cc: Rob Clark >>> Cc: Daniel Stone >>> Cc: Daniel Vetter >>> Cc: dri-de...@lists.freedesktop.org >>> Cc: sta...@vger.kernel.org >> >> Reviewed-by: Ville Syrjälä > > Pushed to our topic/drm-fixes branch, thanks for the patch and review. and I've pushed the libdrm part BR, -R > BR, > Jani. > >> >>> --- >>> include/uapi/drm/drm_fourcc.h | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h >>> index 8c5e8b91a3cb..0b69a7753558 100644 >>> --- a/include/uapi/drm/drm_fourcc.h >>> +++ b/include/uapi/drm/drm_fourcc.h >>> @@ -158,7 +158,7 @@ >>> /* add more to the end as needed */ >>> >>> #define fourcc_mod_code(vendor, val) \ >>> -u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & >>> 0x00ffULL)) >>> +__u64)DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | (val & >>> 0x00ffULL)) >>> >>> /* >>> * Format Modifier tokens: >>> -- >>> 2.5.1 >>> >>> ___ >>> Intel-gfx mailing list >>> Intel-gfx@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Jani Nikula, Intel Open Source Technology Center > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm: Create a format/modifier blob
On Wed, May 17, 2017 at 8:00 PM, Ben Widawsky wrote:
> On 17-05-17 13:31:44, Daniel Vetter wrote:
>>
>> On Tue, May 16, 2017 at 02:19:12PM -0700, Ben Widawsky wrote:
>>>
>>> On 17-05-03 17:08:27, Daniel Vetter wrote:
>>> > On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
>>> > > +struct drm_format_modifier_blob {
>>> > > +#define FORMAT_BLOB_CURRENT 1
>>> > > + /* Version of this blob format */
>>> > > + u32 version;
>>> > > +
>>> > > + /* Flags */
>>> > > + u32 flags;
>>> > > +
>>> > > + /* Number of fourcc formats supported */
>>> > > + u32 count_formats;
>>> > > +
>>> > > + /* Where in this blob the formats exist (in bytes) */
>>> > > + u32 formats_offset;
>>> > > +
>>> > > + /* Number of drm_format_modifiers */
>>> > > + u32 count_modifiers;
>>> > > +
>>> > > + /* Where in this blob the modifiers exist (in bytes) */
>>> > > + u32 modifiers_offset;
>>> > > +
>>> > > + /* u32 formats[] */
>>> > > + /* struct drm_format_modifier modifiers[] */
>>> > > +} __packed;
>>> >
>>> > The struct should be in the uapi header. Otherwise it won't show up in
>>> > libdrm headers when following the proper process.
>>> > -Daniel
>>> >
>>>
>>> I don't agree that blobs are ever really part of the API, but it doesn't
>>> hurt to
>>> move it... in other words, done.
>>
>>
>> Userspace writes them, the kernel reads them (or maybe even the other way
>> round). How exactly is a specific blob and its layout not part of uapi?
>> Can you explain your reasoning here pls?
>> -Daniel
>
>
> The API says there is a blob. If we wanted the fields in the blob to be
> explicit
> we'd make an API that has the exact structure.
>
well, maybe don't confuse uabi and what can be represented in a 'C' struct..
we've designed the blob layout w/ uabi in mind (ie. w/ offsets to the
different sections, etc).. doesn't necessarily mean it is something
representable as a 'C' struct.. but it's still a form of uabi..
BR,
-R
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm: Create a format/modifier blob
On Wed, May 17, 2017 at 8:38 PM, Rob Clark wrote:
> On Wed, May 17, 2017 at 8:00 PM, Ben Widawsky wrote:
>> On 17-05-17 13:31:44, Daniel Vetter wrote:
>>>
>>> On Tue, May 16, 2017 at 02:19:12PM -0700, Ben Widawsky wrote:
>>>>
>>>> On 17-05-03 17:08:27, Daniel Vetter wrote:
>>>> > On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
>>>> > > +struct drm_format_modifier_blob {
>>>> > > +#define FORMAT_BLOB_CURRENT 1
>>>> > > + /* Version of this blob format */
>>>> > > + u32 version;
>>>> > > +
>>>> > > + /* Flags */
>>>> > > + u32 flags;
>>>> > > +
>>>> > > + /* Number of fourcc formats supported */
>>>> > > + u32 count_formats;
>>>> > > +
>>>> > > + /* Where in this blob the formats exist (in bytes) */
>>>> > > + u32 formats_offset;
>>>> > > +
>>>> > > + /* Number of drm_format_modifiers */
>>>> > > + u32 count_modifiers;
>>>> > > +
>>>> > > + /* Where in this blob the modifiers exist (in bytes) */
>>>> > > + u32 modifiers_offset;
>>>> > > +
>>>> > > + /* u32 formats[] */
>>>> > > + /* struct drm_format_modifier modifiers[] */
>>>> > > +} __packed;
>>>> >
>>>> > The struct should be in the uapi header. Otherwise it won't show up in
>>>> > libdrm headers when following the proper process.
>>>> > -Daniel
>>>> >
>>>>
>>>> I don't agree that blobs are ever really part of the API, but it doesn't
>>>> hurt to
>>>> move it... in other words, done.
>>>
>>>
>>> Userspace writes them, the kernel reads them (or maybe even the other way
>>> round). How exactly is a specific blob and its layout not part of uapi?
>>> Can you explain your reasoning here pls?
>>> -Daniel
>>
>>
>> The API says there is a blob. If we wanted the fields in the blob to be
>> explicit
>> we'd make an API that has the exact structure.
>>
>
> well, maybe don't confuse uabi and what can be represented in a 'C' struct..
>
> we've designed the blob layout w/ uabi in mind (ie. w/ offsets to the
> different sections, etc).. doesn't necessarily mean it is something
> representable as a 'C' struct.. but it's still a form of uabi..
>
and by "we've" I really mean Ben plus irc and/or list bikeshedding
from daniels and myself and various others..
BR,
-R
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] gpu: drm: drivers: Convert printk(KERN_ to pr_
On Tue, Feb 28, 2017 at 7:55 AM, Joe Perches wrote:
> Use a more common logging style.
>
> Miscellanea:
>
> o Coalesce formats and realign arguments
> o Neaten a few macros now using pr_
>
> Signed-off-by: Joe Perches
for drm/msm part:
Acked-by: Rob Clark
> ---
> drivers/gpu/drm/gma500/cdv_intel_lvds.c | 9 -
> drivers/gpu/drm/gma500/oaktrail_lvds.c| 18 +-
> drivers/gpu/drm/gma500/psb_drv.h | 5 ++---
> drivers/gpu/drm/gma500/psb_intel_lvds.c | 7 +++
> drivers/gpu/drm/i915/i915_sw_fence.c | 8
> drivers/gpu/drm/mgag200/mgag200_mode.c| 2 +-
> drivers/gpu/drm/msm/msm_drv.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_acpi.c| 7 ---
> drivers/gpu/drm/nouveau/nouveau_vga.c | 4 ++--
> drivers/gpu/drm/nouveau/nv50_display.c| 22 +++---
> drivers/gpu/drm/nouveau/nvkm/core/mm.c| 10 +-
> drivers/gpu/drm/omapdrm/dss/dsi.c | 17 -
> drivers/gpu/drm/omapdrm/dss/dss.c | 3 +--
> drivers/gpu/drm/omapdrm/dss/dss.h | 15 ++-
> drivers/gpu/drm/omapdrm/omap_gem.c| 5 ++---
> drivers/gpu/drm/r128/r128_cce.c | 7 +++
> drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 6 ++
> drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 3 +--
> drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 4 ++--
> 20 files changed, 72 insertions(+), 84 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> index 5efdb7fbb7ee..e64960db3224 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
> @@ -284,8 +284,7 @@ static bool cdv_intel_lvds_mode_fixup(struct drm_encoder
> *encoder,
> head) {
> if (tmp_encoder != encoder
> && tmp_encoder->crtc == encoder->crtc) {
> - printk(KERN_ERR "Can't enable LVDS and another "
> - "encoder on the same pipe\n");
> + pr_err("Can't enable LVDS and another encoder on the
> same pipe\n");
> return false;
> }
> }
> @@ -756,13 +755,13 @@ void cdv_intel_lvds_init(struct drm_device *dev,
>
> failed_find:
> mutex_unlock(&dev->mode_config.mutex);
> - printk(KERN_ERR "Failed find\n");
> + pr_err("Failed find\n");
> psb_intel_i2c_destroy(gma_encoder->ddc_bus);
> failed_ddc:
> - printk(KERN_ERR "Failed DDC\n");
> + pr_err("Failed DDC\n");
> psb_intel_i2c_destroy(gma_encoder->i2c_bus);
> failed_blc_i2c:
> - printk(KERN_ERR "Failed BLC\n");
> + pr_err("Failed BLC\n");
> drm_encoder_cleanup(encoder);
> drm_connector_cleanup(connector);
> kfree(lvds_priv);
> diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds.c
> b/drivers/gpu/drm/gma500/oaktrail_lvds.c
> index f7038f12ac76..e6943fef0611 100644
> --- a/drivers/gpu/drm/gma500/oaktrail_lvds.c
> +++ b/drivers/gpu/drm/gma500/oaktrail_lvds.c
> @@ -255,15 +255,15 @@ static void oaktrail_lvds_get_configuration_mode(struct
> drm_device *dev,
> ((ti->vblank_hi << 8) | ti->vblank_lo);
> mode->clock = ti->pixel_clock * 10;
> #if 0
> - printk(KERN_INFO "hdisplay is %d\n", mode->hdisplay);
> - printk(KERN_INFO "vdisplay is %d\n", mode->vdisplay);
> - printk(KERN_INFO "HSS is %d\n", mode->hsync_start);
> - printk(KERN_INFO "HSE is %d\n", mode->hsync_end);
> - printk(KERN_INFO "htotal is %d\n", mode->htotal);
> - printk(KERN_INFO "VSS is %d\n", mode->vsync_start);
> - printk(KERN_INFO "VSE is %d\n", mode->vsync_end);
> - printk(KERN_INFO "vtotal is %d\n", mode->vtotal);
> - printk(KERN_INFO "clock is %d\n", mode->clock);
> + pr_info("hdisplay is %d\n", mode->hdisplay);
> + pr_info("vdisplay is %d\n", mode->vdisplay);
> + pr_info("HSS is %d\n", mode->hsync_start);
> + pr_info("HSE is %d\n", mode->hsync_end);
> + pr_info("htotal is %d\n", mode->htotal);
> +
Re: [Intel-gfx] drm_mm crash with multi threads
On Thu, Dec 22, 2016 at 11:07 PM, Mark yao wrote: > Hi Chris Wilson > > We port drm_mm to my internal kernel, with high load test, found following > crash: > > [49451.856244] > == > [49451.856350] BUG: KASAN: wild-memory-access on address dead0108 > [49451.856379] Write of size 8 by task Binder:218_4/683 [49451.856417] CPU: > 2 PID: 683 Comm: Binder:218_4 Not tainted 4.4.36 #62 [49451.856443] Hardware > name: Rockchip RK3399 Excavator Board edp (Android) (DT) [49451.856469] Call > trace: [49451.856519] [] dump_backtrace+0x0/0x230 > [49451.856556] [] show_stack+0x14/0x1c [49451.856592] > [] dump_stack+0xa0/0xc8 [49451.856633] > [] kasan_report+0x110/0x4dc [49451.856670] > [] __asan_store8+0x24/0x7c [49451.856715] > [] drm_mm_insert_node_generic+0x2dc/0x464 [49451.856760] > [] rockchip_gem_iommu_map+0x60/0x158 [49451.856794] > [] rockchip_gem_create_object+0x278/0x488 [49451.856827] > [] rockchip_gem_create_with_handle+0x24/0x10c > [49451.856862] [] rockchip_gem_create_ioctl+0x3c/0x50 > [49451.856896] [] drm_ioctl+0x354/0x52c [49451.856939] > [] do_vfs_ioctl+0x670/0x78c [49451.856976] > [] SyS_ioctl+0x60/0x88 [49451.857009] [] > el0_svc_naked+0x24/0x28 > We only use drm_mm_insert_node_generic to alloc memory, and use > drm_mm_remove_node to release memory > > alloc/release maybe on difference threads. > > Seem the problem is threads problem, drm_mm seems is not threads safe, we > found drm_mm_insert_node_generic and drm_mm_remove_node > may access same resource with list ops, such as some mm->hole_stack. > > After use mutex lock protect drm_mm_remove_node and > drm_mm_insert_node_generic, the crash disappear. > > I'm not familiar with drm mm, Do you know how to fix it? I don't think drm_mm is intended to be thread safe, but instead the driver should provide whatever locking is needed before calling in to drm_mm. (And presumably you already need some lock to protect driver level data structures when creating/destroying gem objects.) BR, -R > Thanks. > > On 2016年12月17日 03:25, Chris Wilson wrote: > > With a lot of polish applied, Joonas has reviewed the series - all but > for [04/38] "lib: Add a simple prime number generator" > [lib/prime_numbers.c]. Anyone feel like poking around at a bit of number > theory? > > Other than it would appear to be ready for Daniel to sort out the merge > between drm-misc/i915... Please do take a look and see if you can spot > anything else that needs fixing/improving. > -Chris > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > > -- > Ｍark Yao > > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm: Add new DRM_IOCTL_MODE_GETPLANE2
On Wed, Jan 11, 2017 at 7:51 PM, Ben Widawsky wrote:
>
> +struct drm_format_modifier {
> + /* Bitmask of formats in get_plane format list this info
> +* applies to. */
> + uint64_t formats;
re: the uabi, I'd suggest to at least make this 'u32 offset; u32
formats'.. we can keep the existing implementation in this patch and
always set 'offset' to zero, and let the first one to hit more than 32
formats deal with the implementation. (Maybe a strategically placed
WARN_ON() if you go that route..)
Otherwise I guess it is just a couple years until getplane3 ;-)
BR,
-R
> +
> + /* This modifier can be used with the format for this plane. */
> + uint64_t modifier;
> +};
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm: Add new DRM_IOCTL_MODE_GETPLANE2
On Thu, Jan 12, 2017 at 4:38 AM, Ville Syrjälä
wrote:
> On Wed, Jan 11, 2017 at 08:43:16PM -0500, Rob Clark wrote:
>> On Wed, Jan 11, 2017 at 7:51 PM, Ben Widawsky wrote:
>> >
>> > +struct drm_format_modifier {
>> > + /* Bitmask of formats in get_plane format list this info
>> > +* applies to. */
>> > + uint64_t formats;
>>
>> re: the uabi, I'd suggest to at least make this 'u32 offset; u32
>> formats'.. we can keep the existing implementation in this patch and
>> always set 'offset' to zero, and let the first one to hit more than 32
>> formats deal with the implementation. (Maybe a strategically placed
>> WARN_ON() if you go that route..)
>
> Isn't an implicit offset enough? As in first mask for a specific
> modifier is for format indexes 0-63, second mask for the same modifier
> is for 64-127, and so on.
hmm, hadn't thought of that approach. Definitely if we go w/ implicit
then we want to have userspace support from the get-go. For explicit,
I guess userspace could complain and ignore if it saw a non-zero
offset similar to what we do w/ pad and unknown flags in the other
direction?
Not sure if that would fly or not.. I guess it is not a *critical*
fail, it just means userspace won't realize that some modifiers are
supported on some formats.. otoh the implicit approach could confuse a
userspace that didn't realize the offset into thinking modifiers
*were* supported on formats where they are not.. that seems like a
bigger problem.
BR,
-R
> The bigger issue is the userspace side I think. If we don't add the
> userspace side code to handle this case from the get go, it's going to
> be hard to actually start doing it from the kernel side.
>
>>
>> Otherwise I guess it is just a couple years until getplane3 ;-)
>>
>> BR,
>> -R
>>
>> > +
>> > + /* This modifier can be used with the format for this plane. */
>> > + uint64_t modifier;
>> > +};
>> ___
>> dri-devel mailing list
>> dri-de...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm: Update file owner during use
On Wed, Jun 21, 2023 at 2:48 AM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> With the typical model where the display server opens the file descriptor
> and then hands it over to the client(*), we were showing stale data in
> debugfs.
>
> Fix it by updating the drm_file->pid on ioctl access from a different
> process.
>
> The field is also made RCU protected to allow for lockless readers. Update
> side is protected with dev->filelist_mutex.
>
> Before:
>
> $ cat /sys/kernel/debug/dri/0/clients
> command pid dev master a uid magic
> Xorg 2344 0 yy 0 0
> Xorg 2344 0 ny 0 2
> Xorg 2344 0 ny 0 3
> Xorg 2344 0 ny 0 4
>
> After:
>
> $ cat /sys/kernel/debug/dri/0/clients
> command tgid dev master a uid magic
> Xorg 830 0 yy 0 0
>xfce4-session 880 0 ny 0 1
>xfwm4 943 0 ny 0 2
>neverball 1095 0 ny 0 3
>
> *)
> More detailed and historically accurate description of various handover
> implementation kindly provided by Emil Velikov:
>
> """
> The traditional model, the server was the orchestrator managing the
> primary device node. From the fd, to the master status and
> authentication. But looking at the fd alone, this has varied across
> the years.
>
> IIRC in the DRI1 days, Xorg (libdrm really) would have a list of open
> fd(s) and reuse those whenever needed, DRI2 the client was responsible
> for open() themselves and with DRI3 the fd was passed to the client.
>
> Around the inception of DRI3 and systemd-logind, the latter became
> another possible orchestrator. Whereby Xorg and Wayland compositors
> could ask it for the fd. For various reasons (hysterical and genuine
> ones) Xorg has a fallback path going the open(), whereas Wayland
> compositors are moving to solely relying on logind... some never had
> fallback even.
>
> Over the past few years, more projects have emerged which provide
> functionality similar (be that on API level, Dbus, or otherwise) to
> systemd-logind.
> """
>
> v2:
> * Fixed typo in commit text and added a fine historical explanation
>from Emil.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: "Christian König"
> Cc: Daniel Vetter
> Acked-by: Christian König
> Reviewed-by: Emil Velikov
Reviewed-by: Rob Clark
Tested-by: Rob Clark
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 6 ++--
> drivers/gpu/drm/drm_auth.c | 3 +-
> drivers/gpu/drm/drm_debugfs.c | 10 ---
> drivers/gpu/drm/drm_file.c | 40 +++--
> drivers/gpu/drm/drm_ioctl.c | 3 ++
> drivers/gpu/drm/nouveau/nouveau_drm.c | 5 +++-
> drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 6 ++--
> include/drm/drm_file.h | 13 ++--
> 8 files changed, 71 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> index 74055cba3dc9..849097dff02b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> @@ -963,6 +963,7 @@ static int amdgpu_debugfs_gem_info_show(struct seq_file
> *m, void *unused)
> list_for_each_entry(file, &dev->filelist, lhead) {
> struct task_struct *task;
> struct drm_gem_object *gobj;
> + struct pid *pid;
> int id;
>
> /*
> @@ -972,8 +973,9 @@ static int amdgpu_debugfs_gem_info_show(struct seq_file
> *m, void *unused)
> * Therefore, we need to protect this ->comm access using RCU.
> */
> rcu_read_lock();
> - task = pid_task(file->pid, PIDTYPE_TGID);
> - seq_printf(m, "pid %8d command %s:\n", pid_nr(file->pid),
> + pid = rcu_dereference(file->pid);
> + task = pid_task(pid, PIDTYPE_TGID);
> + seq_printf(m, "pid %8d command %s:\n", pid_nr(pid),
>task ? task->comm : "");
> rcu_read_unlock();
>
> diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> index cf92a9ae8034..2ed2585ded37 100644
> --- a/drivers/gpu/drm/drm_auth.c
> +++ b/drivers/gpu/drm/drm_auth.c
> @@ -235,7 +235,8 @@ static int drm_new_set_master(struct drm_device *dev,
> struct drm_file *fpriv)
> static int
>
Re: [Intel-gfx] [PATCH] drm/atomic-helper: Don't set deadline for modesets
On Wed, Apr 5, 2023 at 6:31 AM Daniel Vetter wrote:
>
> If the crtc is being switched on or off then the semantics of
> computing the timestampe of the next vblank is somewhat ill-defined.
> And indeed, the code splats with a warning in the timestamp
> computation code. Specifically it hits the check to make sure that
> atomic drivers have full set up the timing constants in the drm_vblank
> structure, and that's just not the case before the crtc is actually
> on.
>
> For robustness it seems best to just not set deadlines for modesets.
>
> v2: Also skip on inactive crtc (Ville)
>
> Link:
> https://lore.kernel.org/dri-devel/dfc21f18-7e1e-48f0-c05a-d659b9c90...@linaro.org/
> Fixes: d39e48ca80c0 ("drm/atomic-helper: Set fence deadline for vblank")
> Cc: Ville Syrjälä
> Cc: Rob Clark
> Cc: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Reported-by: Dmitry Baryshkov
> Tested-by: Dmitry Baryshkov # test patch only
> Cc: Dmitry Baryshkov
> Signed-off-by: Daniel Vetter
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index f21b5a74176c..d44fb9b87ef8 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1528,6 +1528,12 @@ static void set_fence_deadline(struct drm_device *dev,
> for_each_new_crtc_in_state (state, crtc, new_crtc_state, i) {
> ktime_t v;
>
> + if (drm_atomic_crtc_needs_modeset(new_crtc_state))
> + continue;
> +
> + if (!new_crtc_state->active)
> + continue;
> +
> if (drm_crtc_next_vblank_start(crtc, &v))
> continue;
>
> --
> 2.40.0
>
Re: [Intel-gfx] [PATCH i-g-t 8/8] gputop: Basic vendor agnostic GPU top tool
On Tue, Jan 31, 2023 at 3:33 AM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> Rudimentary vendor agnostic example of how lib_igt_drm_clients can be used
> to display a sorted by card and usage list of processes using GPUs.
>
> Borrows a bit of code from intel_gpu_top but for now omits the fancy
> features like interactive functionality, card selection, client
> aggregation, sort modes, JSON output and pretty engine names. Also no
> support for global GPU or system metrics.
>
> On the other hand it shows clients from all DRM cards which
> intel_gpu_top does not do.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Rob Clark
> Cc: Christian König
> Acked-by: Christian König
Reviewed-by: Rob Clark
> ---
> tools/gputop.c| 260 ++
> tools/meson.build | 5 +
> 2 files changed, 265 insertions(+)
> create mode 100644 tools/gputop.c
>
> diff --git a/tools/gputop.c b/tools/gputop.c
> new file mode 100644
> index ..d259cac1ab17
> --- /dev/null
> +++ b/tools/gputop.c
> @@ -0,0 +1,260 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2022 Intel Corporation
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "igt_drm_clients.h"
> +#include "igt_drm_fdinfo.h"
> +
> +static const char *bars[] = { " ", "▏", "▎", "▍", "▌", "▋", "▊", "▉", "█" };
> +
> +static void n_spaces(const unsigned int n)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < n; i++)
> + putchar(' ');
> +}
> +
> +static void print_percentage_bar(double percent, int max_len)
> +{
> + int bar_len, i, len = max_len - 2;
> + const int w = 8;
> +
> + assert(max_len > 0);
> +
> + bar_len = ceil(w * percent * len / 100.0);
> + if (bar_len > w * len)
> + bar_len = w * len;
> +
> + putchar('|');
> +
> + for (i = bar_len; i >= w; i -= w)
> + printf("%s", bars[w]);
> + if (i)
> + printf("%s", bars[i]);
> +
> + len -= (bar_len + (w - 1)) / w;
> + n_spaces(len);
> +
> + putchar('|');
> +}
> +
> +static int
> +print_client_header(struct igt_drm_client *c, int lines, int con_w, int
> con_h,
> + int *engine_w)
> +{
> + const char *pidname = "PID NAME ";
> + int ret, len = strlen(pidname);
> +
> + if (lines++ >= con_h || len >= con_w)
> + return lines;
> + printf("\033[7m");
> + ret = printf("DRM minor %u", c->drm_minor);
> + n_spaces(con_w - ret);
> +
> + if (lines++ >= con_h)
> + return lines;
> + printf("\n%s", pidname);
> +
> + if (c->engines->num_engines) {
> + unsigned int i;
> + int width;
> +
> + *engine_w = width = (con_w - len) / c->engines->num_engines;
> +
> + for (i = 0; i <= c->engines->max_engine_id; i++) {
> + const char *name = c->engines->names[i];
> + int name_len = strlen(name);
> + int pad = (width - name_len) / 2;
> + int spaces = width - pad - name_len;
> +
> + if (!name)
> + continue;
> +
> + if (pad < 0 || spaces < 0)
> + continue;
> +
> + n_spaces(pad);
> + printf("%s", name);
> + n_spaces(spaces);
> + len += pad + name_len + spaces;
> + }
> + }
> +
> + n_spaces(con_w - len);
> + printf("\033[0m\n");
> +
> + return lines;
> +}
> +
> +
> +static bool
> +newheader(const struct igt_drm_client *c, const struct igt_drm_client *pc)
> +{
> + return !pc || c->drm_minor != pc->drm_minor;
> +}
> +
> +static int
> +print_client(struct igt_drm_client *c, struct igt_drm_client **prevc,
> +double t, int lines, int con_w, int con_h,
> +
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 8/8] gputop: Basic vendor agnostic GPU top tool
On Thu, Apr 6, 2023 at 4:08 AM Tvrtko Ursulin
wrote:
>
>
> On 05/04/2023 18:57, Rob Clark wrote:
> > On Tue, Jan 31, 2023 at 3:33 AM Tvrtko Ursulin
> > wrote:
> >>
> >> From: Tvrtko Ursulin
> >>
> >> Rudimentary vendor agnostic example of how lib_igt_drm_clients can be used
> >> to display a sorted by card and usage list of processes using GPUs.
> >>
> >> Borrows a bit of code from intel_gpu_top but for now omits the fancy
> >> features like interactive functionality, card selection, client
> >> aggregation, sort modes, JSON output and pretty engine names. Also no
> >> support for global GPU or system metrics.
> >>
> >> On the other hand it shows clients from all DRM cards which
> >> intel_gpu_top does not do.
> >>
> >> Signed-off-by: Tvrtko Ursulin
> >> Cc: Rob Clark
> >> Cc: Christian König
> >> Acked-by: Christian König
> >
> > Reviewed-by: Rob Clark
>
> Presumably for 8/8 only?
>
> The rest of the series does not apply any more by now. I need to rebase..
I didn't look closely at the rest of the series (was kinda assuming
that was mostly just moving things around).. but I see you rebased it
so I can take a look.
BR,
-R
> Regards,
>
> Tvrtko
>
> >
> >> ---
> >> tools/gputop.c| 260 ++
> >> tools/meson.build | 5 +
> >> 2 files changed, 265 insertions(+)
> >> create mode 100644 tools/gputop.c
> >>
> >> diff --git a/tools/gputop.c b/tools/gputop.c
> >> new file mode 100644
> >> index ..d259cac1ab17
> >> --- /dev/null
> >> +++ b/tools/gputop.c
> >> @@ -0,0 +1,260 @@
> >> +// SPDX-License-Identifier: MIT
> >> +/*
> >> + * Copyright © 2022 Intel Corporation
> >> + */
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +#include "igt_drm_clients.h"
> >> +#include "igt_drm_fdinfo.h"
> >> +
> >> +static const char *bars[] = { " ", "▏", "▎", "▍", "▌", "▋", "▊", "▉", "█"
> >> };
> >> +
> >> +static void n_spaces(const unsigned int n)
> >> +{
> >> + unsigned int i;
> >> +
> >> + for (i = 0; i < n; i++)
> >> + putchar(' ');
> >> +}
> >> +
> >> +static void print_percentage_bar(double percent, int max_len)
> >> +{
> >> + int bar_len, i, len = max_len - 2;
> >> + const int w = 8;
> >> +
> >> + assert(max_len > 0);
> >> +
> >> + bar_len = ceil(w * percent * len / 100.0);
> >> + if (bar_len > w * len)
> >> + bar_len = w * len;
> >> +
> >> + putchar('|');
> >> +
> >> + for (i = bar_len; i >= w; i -= w)
> >> + printf("%s", bars[w]);
> >> + if (i)
> >> + printf("%s", bars[i]);
> >> +
> >> + len -= (bar_len + (w - 1)) / w;
> >> + n_spaces(len);
> >> +
> >> + putchar('|');
> >> +}
> >> +
> >> +static int
> >> +print_client_header(struct igt_drm_client *c, int lines, int con_w, int
> >> con_h,
> >> + int *engine_w)
> >> +{
> >> + const char *pidname = "PID NAME ";
> >> + int ret, len = strlen(pidname);
> >> +
> >> + if (lines++ >= con_h || len >= con_w)
> >> + return lines;
> >> + printf("\033[7m");
> >> + ret = printf("DRM minor %u", c->drm_minor);
> >> + n_spaces(con_w - ret);
> >> +
> >> + if (lines++ >= con_h)
> >> + return lines;
> >> + printf("\n%s", pidname);
> >> +
> >> + if
[Intel-gfx] [PATCH v3 0/7] drm: fdinfo memory stats
From: Rob Clark Similar motivation to other similar recent attempt[1]. But with an attempt to have some shared code for this. As well as documentation. It is probably a bit UMA-centric, I guess devices with VRAM might want some placement stats as well. But this seems like a reasonable start. Basic gputop support: https://patchwork.freedesktop.org/series/116236/ And already nvtop support: https://github.com/Syllo/nvtop/pull/204 [1] https://patchwork.freedesktop.org/series/112397/ Rob Clark (7): drm: Add common fdinfo helper drm/msm: Switch to fdinfo helper drm/amdgpu: Switch to fdinfo helper drm/i915: Switch to fdinfo helper drm/etnaviv: Switch to fdinfo helper drm: Add fdinfo memory stats drm/msm: Add memory stats to fdinfo Documentation/gpu/drm-usage-stats.rst | 21 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h | 2 +- drivers/gpu/drm/drm_file.c | 115 + drivers/gpu/drm/etnaviv/etnaviv_drv.c | 10 +- drivers/gpu/drm/i915/i915_driver.c | 3 +- drivers/gpu/drm/i915/i915_drm_client.c | 18 +--- drivers/gpu/drm/i915/i915_drm_client.h | 2 +- drivers/gpu/drm/msm/msm_drv.c | 11 +- drivers/gpu/drm/msm/msm_gem.c | 15 +++ drivers/gpu/drm/msm/msm_gpu.c | 2 - include/drm/drm_drv.h | 7 ++ include/drm/drm_file.h | 5 + include/drm/drm_gem.h | 19 15 files changed, 208 insertions(+), 41 deletions(-) -- 2.39.2
[Intel-gfx] [PATCH v3 4/7] drm/i915: Switch to fdinfo helper
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/i915_driver.c | 3 ++-
drivers/gpu/drm/i915/i915_drm_client.c | 18 +-
drivers/gpu/drm/i915/i915_drm_client.h | 2 +-
3 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index db7a86def7e2..37eacaa3064b 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1696,7 +1696,7 @@ static const struct file_operations i915_driver_fops = {
.compat_ioctl = i915_ioc32_compat_ioctl,
.llseek = noop_llseek,
#ifdef CONFIG_PROC_FS
- .show_fdinfo = i915_drm_client_fdinfo,
+ .show_fdinfo = drm_fop_show_fdinfo,
#endif
};
@@ -1796,6 +1796,7 @@ static const struct drm_driver i915_drm_driver = {
.open = i915_driver_open,
.lastclose = i915_driver_lastclose,
.postclose = i915_driver_postclose,
+ .show_fdinfo = i915_drm_client_fdinfo,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index b09d1d386574..4a77e5e47f79 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -101,7 +101,7 @@ static u64 busy_add(struct i915_gem_context *ctx, unsigned
int class)
}
static void
-show_client_class(struct seq_file *m,
+show_client_class(struct drm_printer *p,
struct i915_drm_client *client,
unsigned int class)
{
@@ -117,22 +117,20 @@ show_client_class(struct seq_file *m,
rcu_read_unlock();
if (capacity)
- seq_printf(m, "drm-engine-%s:\t%llu ns\n",
+ drm_printf(p, "drm-engine-%s:\t%llu ns\n",
uabi_class_names[class], total);
if (capacity > 1)
- seq_printf(m, "drm-engine-capacity-%s:\t%u\n",
+ drm_printf(p, "drm-engine-capacity-%s:\t%u\n",
uabi_class_names[class],
capacity);
}
-void i915_drm_client_fdinfo(struct seq_file *m, struct file *f)
+void i915_drm_client_fdinfo(struct drm_printer *p, struct drm_file *file)
{
- struct drm_file *file = f->private_data;
struct drm_i915_file_private *file_priv = file->driver_priv;
struct drm_i915_private *i915 = file_priv->dev_priv;
struct i915_drm_client *client = file_priv->client;
- struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
unsigned int i;
/*
@@ -141,12 +139,6 @@ void i915_drm_client_fdinfo(struct seq_file *m, struct
file *f)
* **
*/
- seq_printf(m, "drm-driver:\t%s\n", i915->drm.driver->name);
- seq_printf(m, "drm-pdev:\t%04x:%02x:%02x.%d\n",
- pci_domain_nr(pdev->bus), pdev->bus->number,
- PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
- seq_printf(m, "drm-client-id:\t%u\n", client->id);
-
/*
* Temporarily skip showing client engine information with GuC
submission till
* fetching engine busyness is implemented in the GuC submission backend
@@ -155,6 +147,6 @@ void i915_drm_client_fdinfo(struct seq_file *m, struct file
*f)
return;
for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
- show_client_class(m, client, i);
+ show_client_class(p, client, i);
}
#endif
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
b/drivers/gpu/drm/i915/i915_drm_client.h
index 69496af996d9..ef85fef45de5 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -60,7 +60,7 @@ static inline void i915_drm_client_put(struct i915_drm_client
*client)
struct i915_drm_client *i915_drm_client_add(struct i915_drm_clients *clients);
#ifdef CONFIG_PROC_FS
-void i915_drm_client_fdinfo(struct seq_file *m, struct file *f);
+void i915_drm_client_fdinfo(struct drm_printer *p, struct drm_file *file);
#endif
void i915_drm_clients_fini(struct i915_drm_clients *clients);
--
2.39.2
[Intel-gfx] [PATCH v4 0/6] drm: fdinfo memory stats
From: Rob Clark Similar motivation to other similar recent attempt[1]. But with an attempt to have some shared code for this. As well as documentation. It is probably a bit UMA-centric, I guess devices with VRAM might want some placement stats as well. But this seems like a reasonable start. Basic gputop support: https://patchwork.freedesktop.org/series/116236/ And already nvtop support: https://github.com/Syllo/nvtop/pull/204 [1] https://patchwork.freedesktop.org/series/112397/ Rob Clark (6): drm: Add common fdinfo helper drm/msm: Switch to fdinfo helper drm/amdgpu: Switch to fdinfo helper drm/i915: Switch to fdinfo helper drm: Add fdinfo memory stats drm/msm: Add memory stats to fdinfo Documentation/gpu/drm-usage-stats.rst | 31 +- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 16 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.h | 2 +- drivers/gpu/drm/drm_file.c | 111 + drivers/gpu/drm/i915/i915_driver.c | 3 +- drivers/gpu/drm/i915/i915_drm_client.c | 18 +--- drivers/gpu/drm/i915/i915_drm_client.h | 2 +- drivers/gpu/drm/msm/msm_drv.c | 11 +- drivers/gpu/drm/msm/msm_gem.c | 15 +++ drivers/gpu/drm/msm/msm_gpu.c | 2 - include/drm/drm_drv.h | 7 ++ include/drm/drm_file.h | 5 + include/drm/drm_gem.h | 30 ++ 14 files changed, 220 insertions(+), 36 deletions(-) -- 2.39.2
[Intel-gfx] [PATCH v4 4/6] drm/i915: Switch to fdinfo helper
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/i915_driver.c | 3 ++-
drivers/gpu/drm/i915/i915_drm_client.c | 18 +-
drivers/gpu/drm/i915/i915_drm_client.h | 2 +-
3 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index db7a86def7e2..0d91f85f8b97 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1696,7 +1696,7 @@ static const struct file_operations i915_driver_fops = {
.compat_ioctl = i915_ioc32_compat_ioctl,
.llseek = noop_llseek,
#ifdef CONFIG_PROC_FS
- .show_fdinfo = i915_drm_client_fdinfo,
+ .show_fdinfo = drm_show_fdinfo,
#endif
};
@@ -1796,6 +1796,7 @@ static const struct drm_driver i915_drm_driver = {
.open = i915_driver_open,
.lastclose = i915_driver_lastclose,
.postclose = i915_driver_postclose,
+ .show_fdinfo = i915_drm_client_fdinfo,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index b09d1d386574..4a77e5e47f79 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -101,7 +101,7 @@ static u64 busy_add(struct i915_gem_context *ctx, unsigned
int class)
}
static void
-show_client_class(struct seq_file *m,
+show_client_class(struct drm_printer *p,
struct i915_drm_client *client,
unsigned int class)
{
@@ -117,22 +117,20 @@ show_client_class(struct seq_file *m,
rcu_read_unlock();
if (capacity)
- seq_printf(m, "drm-engine-%s:\t%llu ns\n",
+ drm_printf(p, "drm-engine-%s:\t%llu ns\n",
uabi_class_names[class], total);
if (capacity > 1)
- seq_printf(m, "drm-engine-capacity-%s:\t%u\n",
+ drm_printf(p, "drm-engine-capacity-%s:\t%u\n",
uabi_class_names[class],
capacity);
}
-void i915_drm_client_fdinfo(struct seq_file *m, struct file *f)
+void i915_drm_client_fdinfo(struct drm_printer *p, struct drm_file *file)
{
- struct drm_file *file = f->private_data;
struct drm_i915_file_private *file_priv = file->driver_priv;
struct drm_i915_private *i915 = file_priv->dev_priv;
struct i915_drm_client *client = file_priv->client;
- struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
unsigned int i;
/*
@@ -141,12 +139,6 @@ void i915_drm_client_fdinfo(struct seq_file *m, struct
file *f)
* **
*/
- seq_printf(m, "drm-driver:\t%s\n", i915->drm.driver->name);
- seq_printf(m, "drm-pdev:\t%04x:%02x:%02x.%d\n",
- pci_domain_nr(pdev->bus), pdev->bus->number,
- PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
- seq_printf(m, "drm-client-id:\t%u\n", client->id);
-
/*
* Temporarily skip showing client engine information with GuC
submission till
* fetching engine busyness is implemented in the GuC submission backend
@@ -155,6 +147,6 @@ void i915_drm_client_fdinfo(struct seq_file *m, struct file
*f)
return;
for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
- show_client_class(m, client, i);
+ show_client_class(p, client, i);
}
#endif
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
b/drivers/gpu/drm/i915/i915_drm_client.h
index 69496af996d9..ef85fef45de5 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -60,7 +60,7 @@ static inline void i915_drm_client_put(struct i915_drm_client
*client)
struct i915_drm_client *i915_drm_client_add(struct i915_drm_clients *clients);
#ifdef CONFIG_PROC_FS
-void i915_drm_client_fdinfo(struct seq_file *m, struct file *f);
+void i915_drm_client_fdinfo(struct drm_printer *p, struct drm_file *file);
#endif
void i915_drm_clients_fini(struct i915_drm_clients *clients);
--
2.39.2
Re: [Intel-gfx] [PATCH v4 4/6] drm/i915: Switch to fdinfo helper
On Thu, Apr 13, 2023 at 6:07 AM Tvrtko Ursulin
wrote:
>
>
> On 12/04/2023 23:42, Rob Clark wrote:
> > From: Rob Clark
>
> There is more do to here to remove my client->id fully (would now be
> dead code) so maybe easiest if you drop this patch and I do it after you
> land this and it propagates to our branches? I'd like to avoid pain with
> conflicts if possible..
That is fine by me
BR,
-R
> Regards,
>
> Tvrtko
>
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/i915/i915_driver.c | 3 ++-
> > drivers/gpu/drm/i915/i915_drm_client.c | 18 +-
> > drivers/gpu/drm/i915/i915_drm_client.h | 2 +-
> > 3 files changed, 8 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_driver.c
> > b/drivers/gpu/drm/i915/i915_driver.c
> > index db7a86def7e2..0d91f85f8b97 100644
> > --- a/drivers/gpu/drm/i915/i915_driver.c
> > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > @@ -1696,7 +1696,7 @@ static const struct file_operations i915_driver_fops
> > = {
> > .compat_ioctl = i915_ioc32_compat_ioctl,
> > .llseek = noop_llseek,
> > #ifdef CONFIG_PROC_FS
> > - .show_fdinfo = i915_drm_client_fdinfo,
> > + .show_fdinfo = drm_show_fdinfo,
> > #endif
> > };
> >
> > @@ -1796,6 +1796,7 @@ static const struct drm_driver i915_drm_driver = {
> > .open = i915_driver_open,
> > .lastclose = i915_driver_lastclose,
> > .postclose = i915_driver_postclose,
> > + .show_fdinfo = i915_drm_client_fdinfo,
> >
> > .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> > .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> > diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
> > b/drivers/gpu/drm/i915/i915_drm_client.c
> > index b09d1d386574..4a77e5e47f79 100644
> > --- a/drivers/gpu/drm/i915/i915_drm_client.c
> > +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> > @@ -101,7 +101,7 @@ static u64 busy_add(struct i915_gem_context *ctx,
> > unsigned int class)
> > }
> >
> > static void
> > -show_client_class(struct seq_file *m,
> > +show_client_class(struct drm_printer *p,
> > struct i915_drm_client *client,
> > unsigned int class)
> > {
> > @@ -117,22 +117,20 @@ show_client_class(struct seq_file *m,
> > rcu_read_unlock();
> >
> > if (capacity)
> > - seq_printf(m, "drm-engine-%s:\t%llu ns\n",
> > + drm_printf(p, "drm-engine-%s:\t%llu ns\n",
> > uabi_class_names[class], total);
> >
> > if (capacity > 1)
> > - seq_printf(m, "drm-engine-capacity-%s:\t%u\n",
> > + drm_printf(p, "drm-engine-capacity-%s:\t%u\n",
> > uabi_class_names[class],
> > capacity);
> > }
> >
> > -void i915_drm_client_fdinfo(struct seq_file *m, struct file *f)
> > +void i915_drm_client_fdinfo(struct drm_printer *p, struct drm_file *file)
> > {
> > - struct drm_file *file = f->private_data;
> > struct drm_i915_file_private *file_priv = file->driver_priv;
> > struct drm_i915_private *i915 = file_priv->dev_priv;
> > struct i915_drm_client *client = file_priv->client;
> > - struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> > unsigned int i;
> >
> > /*
> > @@ -141,12 +139,6 @@ void i915_drm_client_fdinfo(struct seq_file *m, struct
> > file *f)
> >* **
> >*/
> >
> > - seq_printf(m, "drm-driver:\t%s\n", i915->drm.driver->name);
> > - seq_printf(m, "drm-pdev:\t%04x:%02x:%02x.%d\n",
> > -pci_domain_nr(pdev->bus), pdev->bus->number,
> > -PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
> > - seq_printf(m, "drm-client-id:\t%u\n", client->id);
> > -
> > /*
> >* Temporarily skip showing client engine information with GuC
> > submission till
> >* fetching engine busyness is implemented in the GuC submission
> > backend
> > @@ -155,6 +147,6 @@ void i915_drm_client_fdinfo(struct seq_file *m, struct
> > file *f)
> > return;
> >
> > for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
> > - show_client_class(m, client, i);
> > + show_client_class(p, client, i);
> > }
> > #endif
> > diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
> > b/drivers/gpu/drm/i915/i915_drm_client.h
> > index 69496af996d9..ef85fef45de5 100644
> > --- a/drivers/gpu/drm/i915/i915_drm_client.h
> > +++ b/drivers/gpu/drm/i915/i915_drm_client.h
> > @@ -60,7 +60,7 @@ static inline void i915_drm_client_put(struct
> > i915_drm_client *client)
> > struct i915_drm_client *i915_drm_client_add(struct i915_drm_clients
> > *clients);
> >
> > #ifdef CONFIG_PROC_FS
> > -void i915_drm_client_fdinfo(struct seq_file *m, struct file *f);
> > +void i915_drm_client_fdinfo(struct drm_printer *p, struct drm_file *file);
> > #endif
> >
> > void i915_drm_clients_fini(struct i915_drm_clients *clients);
Re: [Intel-gfx] [RFC 3/6] drm: Add fdinfo memory stats
On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> Add support to dump GEM stats to fdinfo.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> Documentation/gpu/drm-usage-stats.rst | 12 +++
> drivers/gpu/drm/drm_file.c| 52 +++
> include/drm/drm_drv.h | 7
> include/drm/drm_file.h| 8 +
> 4 files changed, 79 insertions(+)
>
> diff --git a/Documentation/gpu/drm-usage-stats.rst
> b/Documentation/gpu/drm-usage-stats.rst
> index 2ab32c40e93c..8273a41b2fb0 100644
> --- a/Documentation/gpu/drm-usage-stats.rst
> +++ b/Documentation/gpu/drm-usage-stats.rst
> @@ -21,6 +21,7 @@ File format specification
>
> - File shall contain one key value pair per one line of text.
> - Colon character (`:`) must be used to delimit keys and values.
> +- Caret (`^`) is also a reserved character.
this doesn't solve the problem that led me to drm-$CATEGORY-memory... ;-)
(also, it is IMHO rather ugly)
BR,
-R
> - All keys shall be prefixed with `drm-`.
> - Whitespace between the delimiter and first non-whitespace character shall
> be
>ignored when parsing.
> @@ -105,6 +106,17 @@ object belong to this client, in the respective memory
> region.
> Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
> indicating kibi- or mebi-bytes.
>
> +- drm-memory-^size: [KiB|MiB]
> +- drm-memory-^shared: [KiB|MiB]
> +- drm-memory-^resident: [KiB|MiB]
> +- drm-memory-^purgeable: [KiB|MiB]
> +- drm-memory-^active: [KiB|MiB]
> +
> +Resident category is identical to the drm-memory- key and two should be
> +mutually exclusive.
> +
> +TODO more description text...
> +
> - drm-cycles-
>
> Engine identifier string must be the same as the one specified in the
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 37b4f76a5191..e202f79e816d 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -42,6 +42,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "drm_crtc_internal.h"
> @@ -871,6 +872,54 @@ void drm_send_event(struct drm_device *dev, struct
> drm_pending_event *e)
> }
> EXPORT_SYMBOL(drm_send_event);
>
> +static void
> +print_stat(struct drm_printer *p, const char *stat, const char *region, u64
> sz)
> +{
> + const char *units[] = {"", " KiB", " MiB"};
> + unsigned int u;
> +
> + if (sz == ~0ull) /* Not supported by the driver. */
> + return;
> +
> + for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
> + if (sz < SZ_1K)
> + break;
> + sz = div_u64(sz, SZ_1K);
> + }
> +
> + drm_printf(p, "drm-memory-%s^%s:\t%llu%s\n",
> + region, stat, sz, units[u]);
> +}
> +
> +static void print_memory_stats(struct drm_printer *p, struct drm_file *file)
> +{
> + struct drm_device *dev = file->minor->dev;
> + struct drm_fdinfo_memory_stat *stats;
> + unsigned int num, i;
> + char **regions;
> +
> + regions = dev->driver->query_fdinfo_memory_regions(dev, &num);
> +
> + stats = kcalloc(num, sizeof(*stats), GFP_KERNEL);
> + if (!stats)
> + return;
> +
> + dev->driver->query_fdinfo_memory_stats(file, stats);
> +
> + for (i = 0; i < num; i++) {
> + if (!regions[i]) /* Allow sparse name arrays. */
> + continue;
> +
> + print_stat(p, "size", regions[i], stats[i].size);
> + print_stat(p, "shared", regions[i], stats[i].shared);
> + print_stat(p, "resident", regions[i], stats[i].resident);
> + print_stat(p, "purgeable", regions[i], stats[i].purgeable);
> + print_stat(p, "active", regions[i], stats[i].active);
> + }
> +
> + kfree(stats);
> +}
> +
> /**
> * drm_show_fdinfo - helper for drm file fops
> * @seq_file: output stream
> @@ -900,6 +949,9 @@ void drm_show_fdinfo(struct seq_file *m, struct file *f)
>
> if (dev->driver->show_fdinfo)
> dev->driver->show_fdinfo(&p, file);
> +
> + if (dev->driver->query_fdinfo_memory_regions)
> + print_memory_stats(&p, file);
> }
> EXPORT_SYMBOL(drm_show_fdinfo);
>
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 89e2706cac56..ccc1cd98d2aa 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -35,6 +35,7 @@
> #include
>
> struct drm_file;
> +struct drm_fdinfo_memory_stat;
> struct drm_gem_object;
> struct drm_master;
> struct drm_minor;
> @@ -408,6 +409,12 @@ struct drm_driver {
> */
> void (*show_fdinfo)(struct drm_printer *p, struct drm_file *f);
>
> + char ** (*query_fdinfo_memory_regions)(struct drm_device *dev,
> + unsigned int *num);
> +
> + void (*query_fdinfo_memory_stats)(struct drm_file *f,
> +
Re: [Intel-gfx] [RFC 3/6] drm: Add fdinfo memory stats
On Tue, Apr 18, 2023 at 2:00 AM Tvrtko Ursulin
wrote:
>
>
> On 17/04/2023 20:39, Rob Clark wrote:
> > On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
> > wrote:
> >>
> >> From: Tvrtko Ursulin
> >>
> >> Add support to dump GEM stats to fdinfo.
> >>
> >> Signed-off-by: Tvrtko Ursulin
> >> ---
> >> Documentation/gpu/drm-usage-stats.rst | 12 +++
> >> drivers/gpu/drm/drm_file.c| 52 +++
> >> include/drm/drm_drv.h | 7
> >> include/drm/drm_file.h| 8 +
> >> 4 files changed, 79 insertions(+)
> >>
> >> diff --git a/Documentation/gpu/drm-usage-stats.rst
> >> b/Documentation/gpu/drm-usage-stats.rst
> >> index 2ab32c40e93c..8273a41b2fb0 100644
> >> --- a/Documentation/gpu/drm-usage-stats.rst
> >> +++ b/Documentation/gpu/drm-usage-stats.rst
> >> @@ -21,6 +21,7 @@ File format specification
> >>
> >> - File shall contain one key value pair per one line of text.
> >> - Colon character (`:`) must be used to delimit keys and values.
> >> +- Caret (`^`) is also a reserved character.
> >
> > this doesn't solve the problem that led me to drm-$CATEGORY-memory... ;-)
>
> Could you explain or remind me with a link to a previous explanation?
How is userspace supposed to know that "drm-memory-foo" is a memory
type "foo" but drm-memory-foo^size is not memory type "foo^size"?
BR,
-R
> What tool barfs on it and how? Spirit of drm-usage-stats.pl is that for
> both drm-engine-: and drm-memory-: generic userspace is
> supposed to take the whole as opaque and just enumerate all it finds.
>
> Gputop manages to do that with engines names it knows _nothing_ about.
> If it worked with memory regions it would just show the list of new
> regions as for example "system^resident", "system^active". Then tools
> can be extended to understand it better and provide a sub-breakdown if
> wanted.
>
> Ugly not, we can change from caret to something nicer, unless I am
> missing something it works, no?
>
> Regards,
>
> Tvrtko
>
> >
> > (also, it is IMHO rather ugly)
> >
> > BR,
> > -R
> >
> >> - All keys shall be prefixed with `drm-`.
> >> - Whitespace between the delimiter and first non-whitespace character
> >> shall be
> >> ignored when parsing.
> >> @@ -105,6 +106,17 @@ object belong to this client, in the respective
> >> memory region.
> >> Default unit shall be bytes with optional unit specifiers of 'KiB' or
> >> 'MiB'
> >> indicating kibi- or mebi-bytes.
> >>
> >> +- drm-memory-^size: [KiB|MiB]
> >> +- drm-memory-^shared: [KiB|MiB]
> >> +- drm-memory-^resident: [KiB|MiB]
> >> +- drm-memory-^purgeable: [KiB|MiB]
> >> +- drm-memory-^active: [KiB|MiB]
> >> +
> >> +Resident category is identical to the drm-memory- key and two should
> >> be
> >> +mutually exclusive.
> >> +
> >> +TODO more description text...
> >> +
> >> - drm-cycles-
> >>
> >> Engine identifier string must be the same as the one specified in the
> >> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> >> index 37b4f76a5191..e202f79e816d 100644
> >> --- a/drivers/gpu/drm/drm_file.c
> >> +++ b/drivers/gpu/drm/drm_file.c
> >> @@ -42,6 +42,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >>
> >> #include "drm_crtc_internal.h"
> >> @@ -871,6 +872,54 @@ void drm_send_event(struct drm_device *dev, struct
> >> drm_pending_event *e)
> >> }
> >> EXPORT_SYMBOL(drm_send_event);
> >>
> >> +static void
> >> +print_stat(struct drm_printer *p, const char *stat, const char *region,
> >> u64 sz)
> >> +{
> >> + const char *units[] = {"", " KiB", " MiB"};
> >> + unsigned int u;
> >> +
> >> + if (sz == ~0ull) /* Not supported by the driver. */
> >> + return;
> >> +
> >> + for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
> >> + if (sz < SZ_1K)
> >> + break;
> >> + sz = div_u64(sz, SZ_1K);
> >> + }
> >> +
> >> + drm_printf(p, "drm-memor
Re: [Intel-gfx] [RFC 3/6] drm: Add fdinfo memory stats
On Tue, Apr 18, 2023 at 3:47 AM Tvrtko Ursulin
wrote:
>
>
> On 17/04/2023 17:20, Christian König wrote:
> > Am 17.04.23 um 17:56 schrieb Tvrtko Ursulin:
> >> From: Tvrtko Ursulin
> >>
> >> Add support to dump GEM stats to fdinfo.
> >>
> >> Signed-off-by: Tvrtko Ursulin
> >> ---
> >> Documentation/gpu/drm-usage-stats.rst | 12 +++
> >> drivers/gpu/drm/drm_file.c| 52 +++
> >> include/drm/drm_drv.h | 7
> >> include/drm/drm_file.h| 8 +
> >> 4 files changed, 79 insertions(+)
> >>
> >> diff --git a/Documentation/gpu/drm-usage-stats.rst
> >> b/Documentation/gpu/drm-usage-stats.rst
> >> index 2ab32c40e93c..8273a41b2fb0 100644
> >> --- a/Documentation/gpu/drm-usage-stats.rst
> >> +++ b/Documentation/gpu/drm-usage-stats.rst
> >> @@ -21,6 +21,7 @@ File format specification
> >> - File shall contain one key value pair per one line of text.
> >> - Colon character (`:`) must be used to delimit keys and values.
> >> +- Caret (`^`) is also a reserved character.
> >> - All keys shall be prefixed with `drm-`.
> >> - Whitespace between the delimiter and first non-whitespace
> >> character shall be
> >> ignored when parsing.
> >> @@ -105,6 +106,17 @@ object belong to this client, in the respective
> >> memory region.
> >> Default unit shall be bytes with optional unit specifiers of 'KiB'
> >> or 'MiB'
> >> indicating kibi- or mebi-bytes.
> >> +- drm-memory-^size: [KiB|MiB]
> >> +- drm-memory-^shared: [KiB|MiB]
> >> +- drm-memory-^resident: [KiB|MiB]
> >> +- drm-memory-^purgeable: [KiB|MiB]
> >> +- drm-memory-^active: [KiB|MiB]
> >
> > What exactly does size/shared/active mean here?
> >
> > If it means what I think it does I don't see how TTM based drivers
> > should track that in the first place.
>
> Size is an analogue to process VM size - maximum reachable/allocated
> memory belonging to a client.
>
> Shared could be IMO viewed as a bit dodgy and either could be dropped or
> needs to be better defined. For now I simply followed the implementation
> from Rob's RFC which is:
>
> if (obj->handle_count > 1)
> stats[0].shared += sz;
>
> I can see some usefulness to it but haven't thought much about semantics
> yet.
>
> Similar story with active which I think is not very useful.
> Implementation is like this:
>
> if (!dma_resv_test_signaled(obj->resv, dma_resv_usage_rw(true)))
> stats[0].active += sz;
>
> For me it is too transient to bring much value over the resident
> category. I supposed only advantage is that resident (as does purgeable)
> needs driver cooperation while active can be done like about from DRM
> core. Although I am not a big fan of counting these stats from the core
> to begin with..
Maybe there is a better way to track it, like setting an age/time when
the buffer is last active (which could be made part of dma_resv to
make it automatic). The question I really want to answer is more like
"over the last T ms how many buffers were active". This is a useful
metric esp when you think about a use-case like the browser where you
might have a lot of textures/etc for your 80 different tabs but at any
given time only a small subset is active and the rest can be swapped
out to zram if needed.
BR,
-R
>
> Regards,
>
> Tvrtko
>
> >> +Resident category is identical to the drm-memory- key and two
> >> should be
> >> +mutually exclusive.
> >> +
> >> +TODO more description text...
> >> +
> >> - drm-cycles-
> >> Engine identifier string must be the same as the one specified in the
> >> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> >> index 37b4f76a5191..e202f79e816d 100644
> >> --- a/drivers/gpu/drm/drm_file.c
> >> +++ b/drivers/gpu/drm/drm_file.c
> >> @@ -42,6 +42,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >> #include "drm_crtc_internal.h"
> >> @@ -871,6 +872,54 @@ void drm_send_event(struct drm_device *dev,
> >> struct drm_pending_event *e)
> >> }
> >> EXPORT_SYMBOL(drm_send_event);
> >> +static void
> >> +print_stat(struct drm_printer *p, const char *stat, const char
> >> *region, u64 sz)
> >> +{
> >> +const char *units[] = {"", " KiB", " MiB"};
> >> +unsigned int u;
> >> +
> >> +if (sz == ~0ull) /* Not supported by the driver. */
> >> +return;
> >> +
> >> +for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
> >> +if (sz < SZ_1K)
> >> +break;
> >> +sz = div_u64(sz, SZ_1K);
> >> +}
> >> +
> >> +drm_printf(p, "drm-memory-%s^%s:\t%llu%s\n",
> >> + region, stat, sz, units[u]);
> >> +}
> >> +
> >> +static void print_memory_stats(struct drm_printer *p, struct drm_file
> >> *file)
> >> +{
> >> +struct drm_device *dev = file->minor->dev;
> >> +struct drm_fdinfo_memory_stat *stats;
> >> +unsigned int num, i;
> >> +char **regions;
> >> +
> >> +regions = dev->driver->query_fdinfo_memory_regions
Re: [Intel-gfx] [RFC 3/6] drm: Add fdinfo memory stats
On Tue, Apr 18, 2023 at 7:19 AM Tvrtko Ursulin
wrote:
>
>
> On 18/04/2023 14:49, Rob Clark wrote:
> > On Tue, Apr 18, 2023 at 2:00 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 17/04/2023 20:39, Rob Clark wrote:
> >>> On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
> >>> wrote:
> >>>>
> >>>> From: Tvrtko Ursulin
> >>>>
> >>>> Add support to dump GEM stats to fdinfo.
> >>>>
> >>>> Signed-off-by: Tvrtko Ursulin
> >>>> ---
> >>>>Documentation/gpu/drm-usage-stats.rst | 12 +++
> >>>>drivers/gpu/drm/drm_file.c| 52 +++
> >>>>include/drm/drm_drv.h | 7
> >>>>include/drm/drm_file.h| 8 +
> >>>>4 files changed, 79 insertions(+)
> >>>>
> >>>> diff --git a/Documentation/gpu/drm-usage-stats.rst
> >>>> b/Documentation/gpu/drm-usage-stats.rst
> >>>> index 2ab32c40e93c..8273a41b2fb0 100644
> >>>> --- a/Documentation/gpu/drm-usage-stats.rst
> >>>> +++ b/Documentation/gpu/drm-usage-stats.rst
> >>>> @@ -21,6 +21,7 @@ File format specification
> >>>>
> >>>>- File shall contain one key value pair per one line of text.
> >>>>- Colon character (`:`) must be used to delimit keys and values.
> >>>> +- Caret (`^`) is also a reserved character.
> >>>
> >>> this doesn't solve the problem that led me to drm-$CATEGORY-memory... ;-)
> >>
> >> Could you explain or remind me with a link to a previous explanation?
> >
> > How is userspace supposed to know that "drm-memory-foo" is a memory
> > type "foo" but drm-memory-foo^size is not memory type "foo^size"?
>
> Are you referring to nvtop?
I'm not referring to any particular app. It could even be some app
that isn't even written yet but started with an already existing
kernel without this change. It is just a general point about forwards
compatibility of old userspace with new kernel. And it doesn't really
matter what special character you use. You can't retroactively define
some newly special characters.
BR,
-R
> Indeed that one hardcodes:
>
>static const char drm_amdgpu_vram[] = "drm-memory-vram";
>
> And does brute strcmp on it:
>
>} else if (!strcmp(key, drm_amdgpu_vram_old) || !strcmp(key,
> drm_amdgpu_vram)) {
>
> So okay for that one, if we need to keep it working I just change this in my
> RFC:
>
> """
> Resident category is identical to the drm-memory- key and two should be
> mutually exclusive.
> """
>
> Into this:
>
> """
> Resident category is identical to the drm-memory- key and where the
> categorized one is present the legacy one must be too in order to preserve
> backward compatibility.
> """
>
> Addition to my RFC:
>
> ...
> for (i = 0; i < num; i++) {
> if (!regions[i]) /* Allow sparse name arrays. */
> continue;
>
> print_stat(p, "size", regions[i], stats[i].size);
> print_stat(p, "shared", regions[i], stats[i].shared);
> + print_stat(p, "", regions[i], stats[i].resident);
> print_stat(p, "resident", regions[i], stats[i].resident);
> print_stat(p, "purgeable", regions[i], stats[i].purgeable);
> print_stat(p, "active", regions[i], stats[i].active);
> }
> ...
>
> Results in output like this (in theory, if/when amdgpu takes on the extended
> format):
>
> drm-memory-vram-size: ... KiB
> drm-memory-vram: $same KiB
> drm-memory-vram-resident: $same KiB
> drm-memory-vram-...:
>
> Regards,
>
> Tvrtko
>
> P.S. Would a slash instead of a caret be prettier?
>
> >> What tool barfs on it and how? Spirit of drm-usage-stats.pl is that for
> >> both drm-engine-: and drm-memory-: generic userspace is
> >> supposed to take the whole as opaque and just enumerate all it finds.
> >>
> >> Gputop manages to do that with engines names it knows _nothing_ about.
> >> If it worked with memory regions it would just show the list of new
> >> regions as for example "system^resident", "system^active". Then tools
> >> can be extended to understand it better and provide a sub-breakdown if
> >> wanted.
&g
Re: [Intel-gfx] [RFC 6/6] drm/i915: Implement fdinfo memory stats printing
On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> Show how more driver specific set of memory stats could be shown,
> more specifically where object can reside in multiple regions, showing all
> the supported stats, and where there is more to show than just user visible
> objects.
>
> WIP...
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/i915_driver.c | 5 ++
> drivers/gpu/drm/i915/i915_drm_client.c | 102 +
> drivers/gpu/drm/i915/i915_drm_client.h | 8 ++
> drivers/gpu/drm/i915/i915_drv.h| 2 +
> 4 files changed, 117 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index 6493548c69bf..4c70206cbc27 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -1806,6 +1806,11 @@ static const struct drm_driver i915_drm_driver = {
> .dumb_create = i915_gem_dumb_create,
> .dumb_map_offset = i915_gem_dumb_mmap_offset,
>
> +#ifdef CONFIG_PROC_FS
> + .query_fdinfo_memory_regions = i915_query_fdinfo_memory_regions,
> + .query_fdinfo_memory_stats = i915_query_fdinfo_memory_stats,
> +#endif
> +
> .ioctls = i915_ioctls,
> .num_ioctls = ARRAY_SIZE(i915_ioctls),
> .fops = &i915_driver_fops,
> diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
> b/drivers/gpu/drm/i915/i915_drm_client.c
> index c654984189f7..65857c68bdb3 100644
> --- a/drivers/gpu/drm/i915/i915_drm_client.c
> +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> @@ -12,6 +12,7 @@
> #include
>
> #include "gem/i915_gem_context.h"
> +#include "intel_memory_region.h"
> #include "i915_drm_client.h"
> #include "i915_file_private.h"
> #include "i915_gem.h"
> @@ -112,4 +113,105 @@ void i915_drm_client_fdinfo(struct drm_printer *p,
> struct drm_file *file)
> for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
> show_client_class(p, i915, file_priv->client, i);
> }
> +
> +char **
> +i915_query_fdinfo_memory_regions(struct drm_device *dev, unsigned int *num)
> +{
> + struct drm_i915_private *i915 = to_i915(dev);
> + struct intel_memory_region *mr;
> + enum intel_region_id id;
> +
> + /* FIXME move to init */
> + for_each_memory_region(mr, i915, id) {
> + if (!i915->mm.region_names[id])
> + i915->mm.region_names[id] = mr->name;
> + }
> +
> + *num = id;
> +
> + return i915->mm.region_names;
> +}
> +
> +static void
> +add_obj(struct drm_i915_gem_object *obj, struct drm_fdinfo_memory_stat
> *stats)
> +{
> +struct intel_memory_region *mr;
> + u64 sz = obj->base.size;
> +enum intel_region_id id;
> + unsigned int i;
> +
> + if (!obj)
> + return;
> +
> + /* Attribute size and shared to all possible memory regions. */
> + for (i = 0; i < obj->mm.n_placements; i++) {
> + mr = obj->mm.placements[i];
> + id = mr->id;
> +
> + stats[id].size += sz;
This implies that summing up all of the categories is not the same as
the toplevel stats that I was proposing
BR,
-R
> + if (obj->base.handle_count > 1)
> + stats[id].shared += sz;
> + }
> +
> + /* Attribute other categories to only the current region. */
> + mr = obj->mm.region;
> + if (mr)
> + id = mr->id;
> + else
> + id = INTEL_REGION_SMEM;
> +
> + if (!i915_gem_object_has_pages(obj))
> + return;
> +
> + stats[id].resident += sz;
> +
> + if (!dma_resv_test_signaled(obj->base.resv, dma_resv_usage_rw(true)))
> + stats[id].active += sz;
> + else if (i915_gem_object_is_shrinkable(obj) &&
> + obj->mm.madv == I915_MADV_DONTNEED)
> + stats[id].purgeable += sz;
> +}
> +
> +void
> +i915_query_fdinfo_memory_stats(struct drm_file *file,
> + struct drm_fdinfo_memory_stat *stats)
> +{
> + struct drm_i915_file_private *file_priv = file->driver_priv;
> + struct i915_drm_client *client = file_priv->client;
> + struct drm_gem_object *drm_obj;
> + struct i915_gem_context *ctx;
> + int id;
> +
> + /*
> +* FIXME - we can do this better and in fewer passes if we are to
> start
> +* exporting proper memory stats.
> +*/
> +
> + /* User created objects */
> + spin_lock(&file->table_lock);
> + idr_for_each_entry(&file->object_idr, drm_obj, id)
> + add_obj(to_intel_bo(drm_obj), stats);
> + spin_unlock(&file->table_lock);
> +
> + /* Contexts, rings, timelines, page tables, ... */
> + rcu_read_lock();
> + list_for_each_entry_rcu(ctx, &client->ctx_list, client_link) {
> + struct i915_gem_engines_iter it;
> + struct intel_context *ce;
> +
> + for_each_gem
Re: [Intel-gfx] [RFC 6/6] drm/i915: Implement fdinfo memory stats printing
On Tue, Apr 18, 2023 at 7:58 AM Tvrtko Ursulin
wrote:
>
>
> On 18/04/2023 15:39, Rob Clark wrote:
> > On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
> > wrote:
> >>
> >> From: Tvrtko Ursulin
> >>
> >> Show how more driver specific set of memory stats could be shown,
> >> more specifically where object can reside in multiple regions, showing all
> >> the supported stats, and where there is more to show than just user visible
> >> objects.
> >>
> >> WIP...
> >>
> >> Signed-off-by: Tvrtko Ursulin
> >> ---
> >> drivers/gpu/drm/i915/i915_driver.c | 5 ++
> >> drivers/gpu/drm/i915/i915_drm_client.c | 102 +
> >> drivers/gpu/drm/i915/i915_drm_client.h | 8 ++
> >> drivers/gpu/drm/i915/i915_drv.h| 2 +
> >> 4 files changed, 117 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> >> b/drivers/gpu/drm/i915/i915_driver.c
> >> index 6493548c69bf..4c70206cbc27 100644
> >> --- a/drivers/gpu/drm/i915/i915_driver.c
> >> +++ b/drivers/gpu/drm/i915/i915_driver.c
> >> @@ -1806,6 +1806,11 @@ static const struct drm_driver i915_drm_driver = {
> >> .dumb_create = i915_gem_dumb_create,
> >> .dumb_map_offset = i915_gem_dumb_mmap_offset,
> >>
> >> +#ifdef CONFIG_PROC_FS
> >> + .query_fdinfo_memory_regions = i915_query_fdinfo_memory_regions,
> >> + .query_fdinfo_memory_stats = i915_query_fdinfo_memory_stats,
> >> +#endif
> >> +
> >> .ioctls = i915_ioctls,
> >> .num_ioctls = ARRAY_SIZE(i915_ioctls),
> >> .fops = &i915_driver_fops,
> >> diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
> >> b/drivers/gpu/drm/i915/i915_drm_client.c
> >> index c654984189f7..65857c68bdb3 100644
> >> --- a/drivers/gpu/drm/i915/i915_drm_client.c
> >> +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> >> @@ -12,6 +12,7 @@
> >> #include
> >>
> >> #include "gem/i915_gem_context.h"
> >> +#include "intel_memory_region.h"
> >> #include "i915_drm_client.h"
> >> #include "i915_file_private.h"
> >> #include "i915_gem.h"
> >> @@ -112,4 +113,105 @@ void i915_drm_client_fdinfo(struct drm_printer *p,
> >> struct drm_file *file)
> >> for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
> >> show_client_class(p, i915, file_priv->client, i);
> >> }
> >> +
> >> +char **
> >> +i915_query_fdinfo_memory_regions(struct drm_device *dev, unsigned int
> >> *num)
> >> +{
> >> + struct drm_i915_private *i915 = to_i915(dev);
> >> + struct intel_memory_region *mr;
> >> + enum intel_region_id id;
> >> +
> >> + /* FIXME move to init */
> >> + for_each_memory_region(mr, i915, id) {
> >> + if (!i915->mm.region_names[id])
> >> + i915->mm.region_names[id] = mr->name;
> >> + }
> >> +
> >> + *num = id;
> >> +
> >> + return i915->mm.region_names;
> >> +}
> >> +
> >> +static void
> >> +add_obj(struct drm_i915_gem_object *obj, struct drm_fdinfo_memory_stat
> >> *stats)
> >> +{
> >> +struct intel_memory_region *mr;
> >> + u64 sz = obj->base.size;
> >> +enum intel_region_id id;
> >> + unsigned int i;
> >> +
> >> + if (!obj)
> >> + return;
> >> +
> >> + /* Attribute size and shared to all possible memory regions. */
> >> + for (i = 0; i < obj->mm.n_placements; i++) {
> >> + mr = obj->mm.placements[i];
> >> + id = mr->id;
> >> +
> >> + stats[id].size += sz;
> >
> > This implies that summing up all of the categories is not the same as
> > the toplevel stats that I was proposing
Sorry, I mis-spoke, I meant "summing up all of the regions is not..."
> Correct, my categories are a bit different. You had private and shared as two
> mutually exclusive buckets, and then resident as subset of either/both. I
> have size as analogue to VmSize and resident as a subset of that, analogue to
> VmRss.
>
I split shared because by definition shared buffers can be counted
against multiple d
Re: [Intel-gfx] [RFC 3/6] drm: Add fdinfo memory stats
On Tue, Apr 18, 2023 at 7:46 AM Tvrtko Ursulin
wrote:
>
>
> On 18/04/2023 15:36, Rob Clark wrote:
> > On Tue, Apr 18, 2023 at 7:19 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 18/04/2023 14:49, Rob Clark wrote:
> >>> On Tue, Apr 18, 2023 at 2:00 AM Tvrtko Ursulin
> >>> wrote:
> >>>>
> >>>>
> >>>> On 17/04/2023 20:39, Rob Clark wrote:
> >>>>> On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
> >>>>> wrote:
> >>>>>>
> >>>>>> From: Tvrtko Ursulin
> >>>>>>
> >>>>>> Add support to dump GEM stats to fdinfo.
> >>>>>>
> >>>>>> Signed-off-by: Tvrtko Ursulin
> >>>>>> ---
> >>>>>> Documentation/gpu/drm-usage-stats.rst | 12 +++
> >>>>>> drivers/gpu/drm/drm_file.c| 52
> >>>>>> +++
> >>>>>> include/drm/drm_drv.h | 7
> >>>>>> include/drm/drm_file.h| 8 +
> >>>>>> 4 files changed, 79 insertions(+)
> >>>>>>
> >>>>>> diff --git a/Documentation/gpu/drm-usage-stats.rst
> >>>>>> b/Documentation/gpu/drm-usage-stats.rst
> >>>>>> index 2ab32c40e93c..8273a41b2fb0 100644
> >>>>>> --- a/Documentation/gpu/drm-usage-stats.rst
> >>>>>> +++ b/Documentation/gpu/drm-usage-stats.rst
> >>>>>> @@ -21,6 +21,7 @@ File format specification
> >>>>>>
> >>>>>> - File shall contain one key value pair per one line of text.
> >>>>>> - Colon character (`:`) must be used to delimit keys and values.
> >>>>>> +- Caret (`^`) is also a reserved character.
> >>>>>
> >>>>> this doesn't solve the problem that led me to drm-$CATEGORY-memory...
> >>>>> ;-)
> >>>>
> >>>> Could you explain or remind me with a link to a previous explanation?
> >>>
> >>> How is userspace supposed to know that "drm-memory-foo" is a memory
> >>> type "foo" but drm-memory-foo^size is not memory type "foo^size"?
> >>
> >> Are you referring to nvtop?
> >
> > I'm not referring to any particular app. It could even be some app
> > that isn't even written yet but started with an already existing
> > kernel without this change. It is just a general point about forwards
> > compatibility of old userspace with new kernel. And it doesn't really
> > matter what special character you use. You can't retroactively define
> > some newly special characters.
>
> What you see does not work if we output both legacy and new key with
> extra category? Userspace which hardcode the name keep working, and
> userspace which parses region names as opaque strings also keeps working
> just shows more entries.
well, it shows nonsense entries.. I'd not call that "working"
But honestly we are wasting too many words on this.. we just can't
re-use the "drm-memory-" namespace, it is already burnt.
Full stop.
If you don't like the "drm-$CATEGORY-$REGION" workaround then we can
shorten to "drm-mem-$REGION-$CATEGORY" since that won't accidentally
match the existing "drm-memory-" pattern.
BR,
-R
> Regards,
>
> Tvrtko
>
> >
> > BR,
> > -R
> >
> >> Indeed that one hardcodes:
> >>
> >> static const char drm_amdgpu_vram[] = "drm-memory-vram";
> >>
> >> And does brute strcmp on it:
> >>
> >> } else if (!strcmp(key, drm_amdgpu_vram_old) || !strcmp(key,
> >> drm_amdgpu_vram)) {
> >>
> >> So okay for that one, if we need to keep it working I just change this in
> >> my RFC:
> >>
> >> """
> >> Resident category is identical to the drm-memory- key and two should
> >> be
> >> mutually exclusive.
> >> """
> >>
> >> Into this:
> >>
> >> """
> >> Resident category is identical to the drm-memory- key and where the
> >> categorized one is present the legacy one must be too in order to preserve
> >> backward compatibility.
> >> """
> >>
> >> Addition to my RFC:
> >>
> >> ...
> &
Re: [Intel-gfx] [RFC 3/6] drm: Add fdinfo memory stats
On Tue, Apr 18, 2023 at 9:44 AM Tvrtko Ursulin wrote: > > > On 18/04/2023 17:13, Rob Clark wrote: > > On Tue, Apr 18, 2023 at 7:46 AM Tvrtko Ursulin > > wrote: > >> On 18/04/2023 15:36, Rob Clark wrote: > >>> On Tue, Apr 18, 2023 at 7:19 AM Tvrtko Ursulin > >>> wrote: > >>>> > >>>> > >>>> On 18/04/2023 14:49, Rob Clark wrote: > >>>>> On Tue, Apr 18, 2023 at 2:00 AM Tvrtko Ursulin > >>>>> wrote: > >>>>>> > >>>>>> > >>>>>> On 17/04/2023 20:39, Rob Clark wrote: > >>>>>>> On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> From: Tvrtko Ursulin > >>>>>>>> > >>>>>>>> Add support to dump GEM stats to fdinfo. > >>>>>>>> > >>>>>>>> Signed-off-by: Tvrtko Ursulin > >>>>>>>> --- > >>>>>>>> Documentation/gpu/drm-usage-stats.rst | 12 +++ > >>>>>>>> drivers/gpu/drm/drm_file.c| 52 > >>>>>>>> +++ > >>>>>>>> include/drm/drm_drv.h | 7 > >>>>>>>> include/drm/drm_file.h| 8 + > >>>>>>>> 4 files changed, 79 insertions(+) > >>>>>>>> > >>>>>>>> diff --git a/Documentation/gpu/drm-usage-stats.rst > >>>>>>>> b/Documentation/gpu/drm-usage-stats.rst > >>>>>>>> index 2ab32c40e93c..8273a41b2fb0 100644 > >>>>>>>> --- a/Documentation/gpu/drm-usage-stats.rst > >>>>>>>> +++ b/Documentation/gpu/drm-usage-stats.rst > >>>>>>>> @@ -21,6 +21,7 @@ File format specification > >>>>>>>> > >>>>>>>> - File shall contain one key value pair per one line of text. > >>>>>>>> - Colon character (`:`) must be used to delimit keys and values. > >>>>>>>> +- Caret (`^`) is also a reserved character. > >>>>>>> > >>>>>>> this doesn't solve the problem that led me to drm-$CATEGORY-memory... > >>>>>>> ;-) > >>>>>> > >>>>>> Could you explain or remind me with a link to a previous explanation? > >>>>> > >>>>> How is userspace supposed to know that "drm-memory-foo" is a memory > >>>>> type "foo" but drm-memory-foo^size is not memory type "foo^size"? > >>>> > >>>> Are you referring to nvtop? > >>> > >>> I'm not referring to any particular app. It could even be some app > >>> that isn't even written yet but started with an already existing > >>> kernel without this change. It is just a general point about forwards > >>> compatibility of old userspace with new kernel. And it doesn't really > >>> matter what special character you use. You can't retroactively define > >>> some newly special characters. > >> > >> What you see does not work if we output both legacy and new key with > >> extra category? Userspace which hardcode the name keep working, and > >> userspace which parses region names as opaque strings also keeps working > >> just shows more entries. > > > > well, it shows nonsense entries.. I'd not call that "working" > > > > But honestly we are wasting too many words on this.. we just can't > > re-use the "drm-memory-" namespace, it is already burnt. > > Full stop. > > > > If you don't like the "drm-$CATEGORY-$REGION" workaround then we can > > shorten to "drm-mem-$REGION-$CATEGORY" since that won't accidentally > > match the existing "drm-memory-" pattern. > > I can live with that token reversal, it was not the primary motivation > for my RFC as we have discussed that side of things already before I > sketched my version up. > > But I also still don't get what doesn't work with what I described and > you did not really address my specific questions with more than a > "doesn't work" with not much details. > > Unless for you it starts and ends with "nonsense entries". If so then it > seems there is no option than to disagree and move on. Again, I can > accept the drm-$category-memory-$region. Yeah, it's about "nonsense entries".. and I am perhaps being a bit pedantic about compatibility with old userspace (not like there are 100's of apps parsing drm fdinfo), but it is the principle of the matter ;-) BR, -R
Re: [Intel-gfx] [RFC 4/6] drm: Add simple fdinfo memory helpers
On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> For drivers who only wish to show one memory region called 'system,
> and only account the GEM buffer object handles under it.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/drm_file.c | 45 ++
> include/drm/drm_file.h | 6 +
> 2 files changed, 51 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index e202f79e816d..1e70669dddf7 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -872,6 +872,51 @@ void drm_send_event(struct drm_device *dev, struct
> drm_pending_event *e)
> }
> EXPORT_SYMBOL(drm_send_event);
>
> +static void
> +add_obj(struct drm_gem_object *obj, struct drm_fdinfo_memory_stat *stats)
> +{
> + u64 sz = obj->size;
> +
> + stats[0].size += sz;
> +
> + if (obj->handle_count > 1)
> + stats[0].shared += sz;
> +
> + if (!dma_resv_test_signaled(obj->resv, dma_resv_usage_rw(true)))
> + stats[0].active += sz;
> +
> + /* Not supported. */
> + stats[0].resident = ~0ull;
> + stats[0].purgeable = ~0ull;
Hmm, this kinda makes the simple helper not very useful. In my
version, you get something that is useful for all UMA drivers (which
all, IIRC, have some form of madv ioctl). I was kinda imagining that
for ttm drivers, my print_memory_stats() would just become a helper
and that TTM (or "multi-region") drivers would have their own thing.
BR,
-R
> +}
> +
> +char **
> +drm_query_fdinfo_system_region(struct drm_device *dev, unsigned int *num)
> +{
> + static char *region[] = {
> + "system",
> + };
> +
> + *num = 1;
> +
> + return region;
> +}
> +EXPORT_SYMBOL(drm_query_fdinfo_system_region);
> +
> +void
> +drm_query_fdinfo_system_memory(struct drm_file *file,
> + struct drm_fdinfo_memory_stat *stats)
> +{
> + struct drm_gem_object *obj;
> + int id;
> +
> + spin_lock(&file->table_lock);
> + idr_for_each_entry(&file->object_idr, obj, id)
> + add_obj(obj, stats);
> + spin_unlock(&file->table_lock);
> +}
> +EXPORT_SYMBOL(drm_query_fdinfo_system_memory);
> +
> static void
> print_stat(struct drm_printer *p, const char *stat, const char *region, u64
> sz)
> {
> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> index 00d48beeac5c..dd7c6fb2c975 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -383,6 +383,12 @@ struct drm_fdinfo_memory_stat {
> u64 active;
> };
>
> +char **drm_query_fdinfo_system_region(struct drm_device *dev,
> + unsigned int *num);
> +void drm_query_fdinfo_system_memory(struct drm_file *file,
> + struct drm_fdinfo_memory_stat *stats);
> +
> +
> /**
> * drm_is_primary_client - is this an open file of the primary node
> * @file_priv: DRM file
> --
> 2.37.2
>
Re: [Intel-gfx] [RFC 4/6] drm: Add simple fdinfo memory helpers
On Wed, Apr 19, 2023 at 6:16 AM Tvrtko Ursulin
wrote:
>
>
> On 18/04/2023 18:18, Rob Clark wrote:
> > On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
> > wrote:
> >>
> >> From: Tvrtko Ursulin
> >>
> >> For drivers who only wish to show one memory region called 'system,
> >> and only account the GEM buffer object handles under it.
> >>
> >> Signed-off-by: Tvrtko Ursulin
> >> ---
> >> drivers/gpu/drm/drm_file.c | 45 ++
> >> include/drm/drm_file.h | 6 +
> >> 2 files changed, 51 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> >> index e202f79e816d..1e70669dddf7 100644
> >> --- a/drivers/gpu/drm/drm_file.c
> >> +++ b/drivers/gpu/drm/drm_file.c
> >> @@ -872,6 +872,51 @@ void drm_send_event(struct drm_device *dev, struct
> >> drm_pending_event *e)
> >> }
> >> EXPORT_SYMBOL(drm_send_event);
> >>
> >> +static void
> >> +add_obj(struct drm_gem_object *obj, struct drm_fdinfo_memory_stat *stats)
> >> +{
> >> + u64 sz = obj->size;
> >> +
> >> + stats[0].size += sz;
> >> +
> >> + if (obj->handle_count > 1)
> >> + stats[0].shared += sz;
> >> +
> >> + if (!dma_resv_test_signaled(obj->resv, dma_resv_usage_rw(true)))
> >> + stats[0].active += sz;
> >> +
> >> + /* Not supported. */
> >> + stats[0].resident = ~0ull;
> >> + stats[0].purgeable = ~0ull;
> >
> > Hmm, this kinda makes the simple helper not very useful. In my
> > version, you get something that is useful for all UMA drivers (which
> > all, IIRC, have some form of madv ioctl). I was kinda imagining that
> > for ttm drivers, my print_memory_stats() would just become a helper
> > and that TTM (or "multi-region") drivers would have their own thing.
>
> Hm how? Your version also needed a driver specific vfunc:
Sure, but there is a possibility for a driver specific vfunc ;-)
And arguably we could move madv to drm_gem_object, along with get/put
pages tracking.. since all the UMA drivers pretty much do the same
thing. So maybe the vfunc is a temporary thing.
Anyways, I could go back to my original version where it was a helper
called from the driver to print mem stats. That way, TTM drivers
could do their own thing.
BR,
-R
> +static enum drm_gem_object_status msm_gem_status(struct drm_gem_object *obj)
> +{
> + struct msm_gem_object *msm_obj = to_msm_bo(obj);
> + enum drm_gem_object_status status = 0;
> +
> + if (msm_obj->pages)
> + status |= DRM_GEM_OBJECT_RESIDENT;
> +
> + if (msm_obj->madv == MSM_MADV_DONTNEED)
> + status |= DRM_GEM_OBJECT_PURGEABLE;
> +
> + return status;
> +}
>
> Regards,
>
> Tvrtko
>
> >
> > BR,
> > -R
> >
> >> +}
> >> +
> >> +char **
> >> +drm_query_fdinfo_system_region(struct drm_device *dev, unsigned int *num)
> >> +{
> >> + static char *region[] = {
> >> + "system",
> >> + };
> >> +
> >> + *num = 1;
> >> +
> >> + return region;
> >> +}
> >> +EXPORT_SYMBOL(drm_query_fdinfo_system_region);
> >> +
> >> +void
> >> +drm_query_fdinfo_system_memory(struct drm_file *file,
> >> + struct drm_fdinfo_memory_stat *stats)
> >> +{
> >> + struct drm_gem_object *obj;
> >> + int id;
> >> +
> >> + spin_lock(&file->table_lock);
> >> + idr_for_each_entry(&file->object_idr, obj, id)
> >> + add_obj(obj, stats);
> >> + spin_unlock(&file->table_lock);
> >> +}
> >> +EXPORT_SYMBOL(drm_query_fdinfo_system_memory);
> >> +
> >> static void
> >> print_stat(struct drm_printer *p, const char *stat, const char *region,
> >> u64 sz)
> >> {
> >> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> >> index 00d48beeac5c..dd7c6fb2c975 100644
> >> --- a/include/drm/drm_file.h
> >> +++ b/include/drm/drm_file.h
> >> @@ -383,6 +383,12 @@ struct drm_fdinfo_memory_stat {
> >> u64 active;
> >> };
> >>
> >> +char **drm_query_fdinfo_system_region(struct drm_device *dev,
> >> + unsigned int *num);
> >> +void drm_query_fdinfo_system_memory(struct drm_file *file,
> >> + struct drm_fdinfo_memory_stat *stats);
> >> +
> >> +
> >> /**
> >>* drm_is_primary_client - is this an open file of the primary node
> >>* @file_priv: DRM file
> >> --
> >> 2.37.2
> >>
Re: [Intel-gfx] [RFC 6/6] drm/i915: Implement fdinfo memory stats printing
On Wed, Apr 19, 2023 at 7:06 AM Tvrtko Ursulin
wrote:
>
>
> On 18/04/2023 17:08, Rob Clark wrote:
> > On Tue, Apr 18, 2023 at 7:58 AM Tvrtko Ursulin
> > wrote:
> >> On 18/04/2023 15:39, Rob Clark wrote:
> >>> On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
> >>> wrote:
> >>>>
> >>>> From: Tvrtko Ursulin
> >>>>
> >>>> Show how more driver specific set of memory stats could be shown,
> >>>> more specifically where object can reside in multiple regions, showing
> >>>> all
> >>>> the supported stats, and where there is more to show than just user
> >>>> visible
> >>>> objects.
> >>>>
> >>>> WIP...
> >>>>
> >>>> Signed-off-by: Tvrtko Ursulin
> >>>> ---
> >>>>drivers/gpu/drm/i915/i915_driver.c | 5 ++
> >>>>drivers/gpu/drm/i915/i915_drm_client.c | 102 +
> >>>>drivers/gpu/drm/i915/i915_drm_client.h | 8 ++
> >>>>drivers/gpu/drm/i915/i915_drv.h| 2 +
> >>>>4 files changed, 117 insertions(+)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> >>>> b/drivers/gpu/drm/i915/i915_driver.c
> >>>> index 6493548c69bf..4c70206cbc27 100644
> >>>> --- a/drivers/gpu/drm/i915/i915_driver.c
> >>>> +++ b/drivers/gpu/drm/i915/i915_driver.c
> >>>> @@ -1806,6 +1806,11 @@ static const struct drm_driver i915_drm_driver = {
> >>>> .dumb_create = i915_gem_dumb_create,
> >>>> .dumb_map_offset = i915_gem_dumb_mmap_offset,
> >>>>
> >>>> +#ifdef CONFIG_PROC_FS
> >>>> + .query_fdinfo_memory_regions = i915_query_fdinfo_memory_regions,
> >>>> + .query_fdinfo_memory_stats = i915_query_fdinfo_memory_stats,
> >>>> +#endif
> >>>> +
> >>>> .ioctls = i915_ioctls,
> >>>> .num_ioctls = ARRAY_SIZE(i915_ioctls),
> >>>> .fops = &i915_driver_fops,
> >>>> diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
> >>>> b/drivers/gpu/drm/i915/i915_drm_client.c
> >>>> index c654984189f7..65857c68bdb3 100644
> >>>> --- a/drivers/gpu/drm/i915/i915_drm_client.c
> >>>> +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> >>>> @@ -12,6 +12,7 @@
> >>>>#include
> >>>>
> >>>>#include "gem/i915_gem_context.h"
> >>>> +#include "intel_memory_region.h"
> >>>>#include "i915_drm_client.h"
> >>>>#include "i915_file_private.h"
> >>>>#include "i915_gem.h"
> >>>> @@ -112,4 +113,105 @@ void i915_drm_client_fdinfo(struct drm_printer *p,
> >>>> struct drm_file *file)
> >>>> for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
> >>>> show_client_class(p, i915, file_priv->client, i);
> >>>>}
> >>>> +
> >>>> +char **
> >>>> +i915_query_fdinfo_memory_regions(struct drm_device *dev, unsigned int
> >>>> *num)
> >>>> +{
> >>>> + struct drm_i915_private *i915 = to_i915(dev);
> >>>> + struct intel_memory_region *mr;
> >>>> + enum intel_region_id id;
> >>>> +
> >>>> + /* FIXME move to init */
> >>>> + for_each_memory_region(mr, i915, id) {
> >>>> + if (!i915->mm.region_names[id])
> >>>> + i915->mm.region_names[id] = mr->name;
> >>>> + }
> >>>> +
> >>>> + *num = id;
> >>>> +
> >>>> + return i915->mm.region_names;
> >>>> +}
> >>>> +
> >>>> +static void
> >>>> +add_obj(struct drm_i915_gem_object *obj, struct drm_fdinfo_memory_stat
> >>>> *stats)
> >>>> +{
> >>>> +struct intel_memory_region *mr;
> >>>> + u64 sz = obj->base.size;
> >>>> +enum intel_region_id id;
> >>>> + unsigned int i;
> >>>> +
> >>>> + if (!obj)
> >>>> + return;
> >>>> +
> >>>> + /* Attri
Re: [Intel-gfx] [RFC 4/6] drm: Add simple fdinfo memory helpers
On Thu, Apr 20, 2023 at 6:14 AM Tvrtko Ursulin
wrote:
>
>
> On 19/04/2023 15:32, Rob Clark wrote:
> > On Wed, Apr 19, 2023 at 6:16 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 18/04/2023 18:18, Rob Clark wrote:
> >>> On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
> >>> wrote:
> >>>>
> >>>> From: Tvrtko Ursulin
> >>>>
> >>>> For drivers who only wish to show one memory region called 'system,
> >>>> and only account the GEM buffer object handles under it.
> >>>>
> >>>> Signed-off-by: Tvrtko Ursulin
> >>>> ---
> >>>>drivers/gpu/drm/drm_file.c | 45 ++
> >>>>include/drm/drm_file.h | 6 +
> >>>>2 files changed, 51 insertions(+)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> >>>> index e202f79e816d..1e70669dddf7 100644
> >>>> --- a/drivers/gpu/drm/drm_file.c
> >>>> +++ b/drivers/gpu/drm/drm_file.c
> >>>> @@ -872,6 +872,51 @@ void drm_send_event(struct drm_device *dev, struct
> >>>> drm_pending_event *e)
> >>>>}
> >>>>EXPORT_SYMBOL(drm_send_event);
> >>>>
> >>>> +static void
> >>>> +add_obj(struct drm_gem_object *obj, struct drm_fdinfo_memory_stat
> >>>> *stats)
> >>>> +{
> >>>> + u64 sz = obj->size;
> >>>> +
> >>>> + stats[0].size += sz;
> >>>> +
> >>>> + if (obj->handle_count > 1)
> >>>> + stats[0].shared += sz;
> >>>> +
> >>>> + if (!dma_resv_test_signaled(obj->resv, dma_resv_usage_rw(true)))
> >>>> + stats[0].active += sz;
> >>>> +
> >>>> + /* Not supported. */
> >>>> + stats[0].resident = ~0ull;
> >>>> + stats[0].purgeable = ~0ull;
> >>>
> >>> Hmm, this kinda makes the simple helper not very useful. In my
> >>> version, you get something that is useful for all UMA drivers (which
> >>> all, IIRC, have some form of madv ioctl). I was kinda imagining that
> >>> for ttm drivers, my print_memory_stats() would just become a helper
> >>> and that TTM (or "multi-region") drivers would have their own thing.
> >>
> >> Hm how? Your version also needed a driver specific vfunc:
> >
> > Sure, but there is a possibility for a driver specific vfunc ;-)
>
> Indeed, they are there in both proposals! :)
>
> > And arguably we could move madv to drm_gem_object, along with get/put
> > pages tracking.. since all the UMA drivers pretty much do the same
> > thing. So maybe the vfunc is a temporary thing.
> >
> > Anyways, I could go back to my original version where it was a helper
> > called from the driver to print mem stats. That way, TTM drivers
> > could do their own thing.
>
> I must have missed that. So it was the same idea as in my RFC?
similar, danvet asked for something "more core" ;-)
https://patchwork.freedesktop.org/patch/531403/?series=116216&rev=1
BR,
-R
> Regards,
>
> Tvrtko
>
> > BR,
> > -R
> >
> >> +static enum drm_gem_object_status msm_gem_status(struct drm_gem_object
> >> *obj)
> >> +{
> >> + struct msm_gem_object *msm_obj = to_msm_bo(obj);
> >> + enum drm_gem_object_status status = 0;
> >> +
> >> + if (msm_obj->pages)
> >> + status |= DRM_GEM_OBJECT_RESIDENT;
> >> +
> >> + if (msm_obj->madv == MSM_MADV_DONTNEED)
> >> + status |= DRM_GEM_OBJECT_PURGEABLE;
> >> +
> >> + return status;
> >> +}
> >>
> >> Regards,
> >>
> >> Tvrtko
> >>
> >>>
> >>> BR,
> >>> -R
> >>>
> >>>> +}
> >>>> +
> >>>> +char **
> >>>> +drm_query_fdinfo_system_region(struct drm_device *dev, unsigned int
> >>>> *num)
> >>>> +{
> >>>> + static char *region[] = {
> >>>> + "system",
> >>>> + };
> >>>> +
> >>>> + *num = 1;
> >>>> +
> >>>> + return regio
Re: [Intel-gfx] [RFC 6/6] drm/i915: Implement fdinfo memory stats printing
On Thu, Apr 20, 2023 at 6:11 AM Tvrtko Ursulin
wrote:
>
>
> On 19/04/2023 15:38, Rob Clark wrote:
> > On Wed, Apr 19, 2023 at 7:06 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 18/04/2023 17:08, Rob Clark wrote:
> >>> On Tue, Apr 18, 2023 at 7:58 AM Tvrtko Ursulin
> >>> wrote:
> >>>> On 18/04/2023 15:39, Rob Clark wrote:
> >>>>> On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
> >>>>> wrote:
> >>>>>>
> >>>>>> From: Tvrtko Ursulin
> >>>>>>
> >>>>>> Show how more driver specific set of memory stats could be shown,
> >>>>>> more specifically where object can reside in multiple regions, showing
> >>>>>> all
> >>>>>> the supported stats, and where there is more to show than just user
> >>>>>> visible
> >>>>>> objects.
> >>>>>>
> >>>>>> WIP...
> >>>>>>
> >>>>>> Signed-off-by: Tvrtko Ursulin
> >>>>>> ---
> >>>>>> drivers/gpu/drm/i915/i915_driver.c | 5 ++
> >>>>>> drivers/gpu/drm/i915/i915_drm_client.c | 102
> >>>>>> +
> >>>>>> drivers/gpu/drm/i915/i915_drm_client.h | 8 ++
> >>>>>> drivers/gpu/drm/i915/i915_drv.h| 2 +
> >>>>>> 4 files changed, 117 insertions(+)
> >>>>>>
> >>>>>> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> >>>>>> b/drivers/gpu/drm/i915/i915_driver.c
> >>>>>> index 6493548c69bf..4c70206cbc27 100644
> >>>>>> --- a/drivers/gpu/drm/i915/i915_driver.c
> >>>>>> +++ b/drivers/gpu/drm/i915/i915_driver.c
> >>>>>> @@ -1806,6 +1806,11 @@ static const struct drm_driver i915_drm_driver
> >>>>>> = {
> >>>>>>.dumb_create = i915_gem_dumb_create,
> >>>>>>.dumb_map_offset = i915_gem_dumb_mmap_offset,
> >>>>>>
> >>>>>> +#ifdef CONFIG_PROC_FS
> >>>>>> + .query_fdinfo_memory_regions =
> >>>>>> i915_query_fdinfo_memory_regions,
> >>>>>> + .query_fdinfo_memory_stats = i915_query_fdinfo_memory_stats,
> >>>>>> +#endif
> >>>>>> +
> >>>>>>.ioctls = i915_ioctls,
> >>>>>>.num_ioctls = ARRAY_SIZE(i915_ioctls),
> >>>>>>.fops = &i915_driver_fops,
> >>>>>> diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
> >>>>>> b/drivers/gpu/drm/i915/i915_drm_client.c
> >>>>>> index c654984189f7..65857c68bdb3 100644
> >>>>>> --- a/drivers/gpu/drm/i915/i915_drm_client.c
> >>>>>> +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> >>>>>> @@ -12,6 +12,7 @@
> >>>>>> #include
> >>>>>>
> >>>>>> #include "gem/i915_gem_context.h"
> >>>>>> +#include "intel_memory_region.h"
> >>>>>> #include "i915_drm_client.h"
> >>>>>> #include "i915_file_private.h"
> >>>>>> #include "i915_gem.h"
> >>>>>> @@ -112,4 +113,105 @@ void i915_drm_client_fdinfo(struct drm_printer
> >>>>>> *p, struct drm_file *file)
> >>>>>>for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
> >>>>>>show_client_class(p, i915, file_priv->client, i);
> >>>>>> }
> >>>>>> +
> >>>>>> +char **
> >>>>>> +i915_query_fdinfo_memory_regions(struct drm_device *dev, unsigned int
> >>>>>> *num)
> >>>>>> +{
> >>>>>> + struct drm_i915_private *i915 = to_i915(dev);
> >>>>>> + struct intel_memory_region *mr;
> >>>>>> + enum intel_region_id id;
> >>>>>> +
> >>>>>> + /* FIXME move to init */
> >>>>>> + for_each_memory_region(mr, i915, id) {
> >>>>>> + if (!i915->mm.region_names[id])
> >>>>>> + i915
[Intel-gfx] [PATCH] drm/syncobj: Add deadline support for syncobj waits
From: Rob Clark
Add a new flag to let userspace provide a deadline as a hint for syncobj
and timeline waits. This gives a hint to the driver signaling the
backing fences about how soon userspace needs it to compete work, so it
can addjust GPU frequency accordingly. An immediate deadline can be
given to provide something equivalent to i915 "wait boost".
v2: Use absolute u64 ns value for deadline hint, drop cap and driver
feature flag in favor of allowing count_handles==0 as a way for
userspace to probe kernel for support of new flag
v3: More verbose comments about UAPI
v4: Fix negative zero, s/deadline_ns/deadline_nsec/ for consistency with
existing ioctl struct fields
Signed-off-by: Rob Clark
---
Discussion on mesa MR
(https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2197)
seems to have died down. So resending this as a singlton. This version
has some minor cosmetic cleanups compared to the previous iteration.
There are some other remaining UABI bits, waiting for someone to have a
chance to implement userspace for, such as sync_file SET_DEADLINE ioctl,
which can be found: https://patchwork.freedesktop.org/series/93035/
drivers/gpu/drm/drm_syncobj.c | 64 ---
include/uapi/drm/drm.h| 17 ++
2 files changed, 68 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 0c2be8360525..3f86e2b84200 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -126,6 +126,11 @@
* synchronize between the two.
* This requirement is inherited from the Vulkan fence API.
*
+ * If &DRM_SYNCOBJ_WAIT_FLAGS_WAIT_DEADLINE is set, the ioctl will also set
+ * a fence deadline hint on the backing fences before waiting, to provide the
+ * fence signaler with an appropriate sense of urgency. The deadline is
+ * specified as an absolute &CLOCK_MONOTONIC value in units of ns.
+ *
* Similarly, &DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT takes an array of syncobj
* handles as well as an array of u64 points and does a host-side wait on all
* of syncobj fences at the given points simultaneously.
@@ -973,7 +978,8 @@ static signed long drm_syncobj_array_wait_timeout(struct
drm_syncobj **syncobjs,
uint32_t count,
uint32_t flags,
signed long timeout,
- uint32_t *idx)
+ uint32_t *idx,
+ ktime_t *deadline)
{
struct syncobj_wait_entry *entries;
struct dma_fence *fence;
@@ -1053,6 +1059,15 @@ static signed long drm_syncobj_array_wait_timeout(struct
drm_syncobj **syncobjs,
drm_syncobj_fence_add_wait(syncobjs[i], &entries[i]);
}
+ if (deadline) {
+ for (i = 0; i < count; ++i) {
+ fence = entries[i].fence;
+ if (!fence)
+ continue;
+ dma_fence_set_deadline(fence, *deadline);
+ }
+ }
+
do {
set_current_state(TASK_INTERRUPTIBLE);
@@ -1151,7 +1166,8 @@ static int drm_syncobj_array_wait(struct drm_device *dev,
struct drm_file *file_private,
struct drm_syncobj_wait *wait,
struct drm_syncobj_timeline_wait
*timeline_wait,
- struct drm_syncobj **syncobjs, bool timeline)
+ struct drm_syncobj **syncobjs, bool timeline,
+ ktime_t *deadline)
{
signed long timeout = 0;
uint32_t first = ~0;
@@ -1162,7 +1178,8 @@ static int drm_syncobj_array_wait(struct drm_device *dev,
NULL,
wait->count_handles,
wait->flags,
-timeout, &first);
+timeout, &first,
+deadline);
if (timeout < 0)
return timeout;
wait->first_signaled = first;
@@ -1172,7 +1189,8 @@ static int drm_syncobj_array_wait(struct drm_device *dev,
u64_to_user_ptr(timeline_wait->points),
timeline_wait->count_handles,
timeline_wait->flags,
-timeout, &first);
+
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Implement fdinfo memory stats printing
On Wed, Sep 20, 2023 at 7:35 AM Tvrtko Ursulin
wrote:
>
>
> On 24/08/2023 12:35, Upadhyay, Tejas wrote:
> >> -Original Message-
> >> From: Intel-gfx On Behalf Of
> >> Tvrtko
> >> Ursulin
> >> Sent: Friday, July 7, 2023 6:32 PM
> >> To: Intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> >> Subject: [Intel-gfx] [PATCH 5/5] drm/i915: Implement fdinfo memory stats
> >> printing
> >>
> >> From: Tvrtko Ursulin
> >>
> >> Use the newly added drm_print_memory_stats helper to show memory
> >> utilisation of our objects in drm/driver specific fdinfo output.
> >>
> >> To collect the stats we walk the per memory regions object lists and
> >> accumulate object size into the respective drm_memory_stats categories.
> >>
> >> Objects with multiple possible placements are reported in multiple regions
> >> for
> >> total and shared sizes, while other categories are counted only for the
> >> currently active region.
> >>
> >> Signed-off-by: Tvrtko Ursulin
> >> Cc: Aravind Iddamsetty
> >> Cc: Rob Clark
> >> ---
> >> drivers/gpu/drm/i915/i915_drm_client.c | 85 ++
> >> 1 file changed, 85 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
> >> b/drivers/gpu/drm/i915/i915_drm_client.c
> >> index ffccb6239789..5c77d6987d90 100644
> >> --- a/drivers/gpu/drm/i915/i915_drm_client.c
> >> +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> >> @@ -45,6 +45,89 @@ void __i915_drm_client_free(struct kref *kref) }
> >>
> >> #ifdef CONFIG_PROC_FS
> >> +static void
> >> +obj_meminfo(struct drm_i915_gem_object *obj,
> >> +struct drm_memory_stats stats[INTEL_REGION_UNKNOWN]) {
> >> +struct intel_memory_region *mr;
> >> +u64 sz = obj->base.size;
> >> +enum intel_region_id id;
> >> +unsigned int i;
> >> +
> >> +/* Attribute size and shared to all possible memory regions. */
> >> +for (i = 0; i < obj->mm.n_placements; i++) {
> >> +mr = obj->mm.placements[i];
> >> +id = mr->id;
> >> +
> >> +if (obj->base.handle_count > 1)
> >> +stats[id].shared += sz;
> >> +else
> >> +stats[id].private += sz;
> >> +}
> >> +
> >> +/* Attribute other categories to only the current region. */
> >> +mr = obj->mm.region;
> >> +if (mr)
> >> +id = mr->id;
> >> +else
> >> +id = INTEL_REGION_SMEM;
> >> +
> >> +if (!obj->mm.n_placements) {
> >> +if (obj->base.handle_count > 1)
> >> +stats[id].shared += sz;
> >> +else
> >> +stats[id].private += sz;
> >> +}
> >> +
> >> +if (i915_gem_object_has_pages(obj)) {
> >> +stats[id].resident += sz;
> >> +
> >> +if (!dma_resv_test_signaled(obj->base.resv,
> >> +dma_resv_usage_rw(true)))
> >
> > Should not DMA_RESV_USAGE_BOOKKEEP also considered active (why only "rw")?
> > Some app is syncing with syncjobs and has added dma_fence with
> > DMA_RESV_USAGE_BOOKKEEP during execbuf while that BO is busy on waiting on
> > work!
>
> Hmm do we have a path which adds DMA_RESV_USAGE_BOOKKEEP usage in execbuf?
>
> Rob, any comments here? Given how I basically lifted the logic from
> 686b21b5f6ca ("drm: Add fdinfo memory stats"), does it sound plausible
> to upgrade the test against all fences?
Yes, I think so.. I don't have any use for BOOKKEEP so I hadn't considered it
BR,
-R
>
> Regards,
>
> Tvrtko
>
> >> +stats[id].active += sz;
> >> +else if (i915_gem_object_is_shrinkable(obj) &&
> >> + obj->mm.madv == I915_MADV_DONTNEED)
> >> +stats[id].purgeable += sz;
> >> +}
> >> +}
> >> +
> >> +static void show_meminfo(struct drm_printer *p, struct drm_file *file)
> >> +{
> >> +struct drm_memory_stats stats[INTEL_REGION_UNKNOWN] = {};
> >> +struct drm_i915_file_private *fpriv = file->driver_priv;
> >> +struct i915_drm_client *client = fpriv->client;
>
Re: [Intel-gfx] [PATCH 6/8] drm: Add drm_gem_prime_fd_to_handle_obj
On Fri, Jun 9, 2023 at 7:12 AM Tvrtko Ursulin
wrote:
>
>
> On 09/06/2023 13:44, Iddamsetty, Aravind wrote:
> > On 09-06-2023 17:41, Tvrtko Ursulin wrote:
> >> From: Tvrtko Ursulin
> >>
> >> I need a new flavour of the drm_gem_prime_fd_to_handle helper, one which
> >> will return a reference to a newly created GEM objects (if created), in
> >> order to enable tracking of imported i915 GEM objects in the following
> >> patch.
> >
> > instead of this what if we implement the open call back in i915
> >
> > struct drm_gem_object_funcs {
> >
> > /**
> > * @open:
> > *
> > * Called upon GEM handle creation.
> > *
> > * This callback is optional.
> > */
> > int (*open)(struct drm_gem_object *obj, struct drm_file *file);
> >
> > which gets called whenever a handle(drm_gem_handle_create_tail) is
> > created and in the open we can check if to_intel_bo(obj)->base.dma_buf
> > then it is imported if not it is owned or created by it.
>
> I wanted to track as much memory usage as we have which is buffer object
> backed, including page tables and contexts. And since those are not user
> visible (they don't have handles), they wouldn't be covered by the
> obj->funcs->open() callback.
>
> If we wanted to limit to objects with handles we could simply do what
> Rob proposed and that is to walk the handles idr. But that does not feel
> like the right direction to me. Open for discussion I guess.
I guess you just have a few special case objects per context?
Wouldn't it be easier to just track _those_ specially and append them
to the results after doing the normal idr table walk?
(Also, doing something special for dma-buf smells a bit odd..
considering that we also have legacy flink name based sharing as
well.)
BR,
-R
[Intel-gfx] [PATCH] drm/i915: Move fd_install after last use of fence
From: Rob Clark
Because eb_composite_fence_create() drops the fence_array reference
after creation of the sync_file, only the sync_file holds a ref to the
fence. But fd_install() makes that reference visable to userspace, so
it must be the last thing we do with the fence.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index f266b68cf012..0f2e056c02dd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -3476,38 +3476,38 @@ i915_gem_do_execbuffer(struct drm_device *dev,
err_request:
eb_requests_get(&eb);
err = eb_requests_add(&eb, err);
if (eb.fences)
signal_fence_array(&eb, eb.composite_fence ?
eb.composite_fence :
&eb.requests[0]->fence);
+ if (unlikely(eb.gem_context->syncobj)) {
+ drm_syncobj_replace_fence(eb.gem_context->syncobj,
+ eb.composite_fence ?
+ eb.composite_fence :
+ &eb.requests[0]->fence);
+ }
+
if (out_fence) {
if (err == 0) {
fd_install(out_fence_fd, out_fence->file);
args->rsvd2 &= GENMASK_ULL(31, 0); /* keep in-fence */
args->rsvd2 |= (u64)out_fence_fd << 32;
out_fence_fd = -1;
} else {
fput(out_fence->file);
}
}
- if (unlikely(eb.gem_context->syncobj)) {
- drm_syncobj_replace_fence(eb.gem_context->syncobj,
- eb.composite_fence ?
- eb.composite_fence :
- &eb.requests[0]->fence);
- }
-
if (!out_fence && eb.composite_fence)
dma_fence_put(eb.composite_fence);
eb_requests_put(&eb);
err_vma:
eb_release_vmas(&eb, true);
WARN_ON(err == -EDEADLK);
i915_gem_ww_ctx_fini(&eb.ww);
--
2.38.1
