Re: [PATCH] drm/msm: Avoid dirtyfb stalls on video mode displays

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 19/02/2022 22:39, Rob Clark wrote:
From: Rob Clark <robdclark@xxxxxxxxxxxx>

Someone on IRC once asked an innocent enough sounding question:  Why
with xf86-video-modesetting is es2gears limited at 120fps.

So I broke out the perfetto tracing mesa MR and took a look.  It turns
out the problem was drm_atomic_helper_dirtyfb(), which would end up
waiting for vblank.. es2gears would rapidly push two frames to Xorg,
which would blit them to screen and in idle hook (I assume) call the
DIRTYFB ioctl.  Which in turn would do an atomic update to flush the
dirty rects, which would stall until the next vblank.  And then the
whole process would repeat.

But this is a bit silly, we only need dirtyfb for command mode DSI
panels.  So lets just skip it otherwise.

Signed-off-by: Rob Clark <robdclark@xxxxxxxxxxxx>
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  | 13 +++++
  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h  |  9 ++++
  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  1 +
  drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c |  9 ++++
  drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c  |  1 +
  drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.h  |  1 +
  drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c |  8 +++
  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c  |  1 +
  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h  |  1 +
  drivers/gpu/drm/msm/msm_fb.c              | 64 ++++++++++++++++++++++-
  drivers/gpu/drm/msm/msm_kms.h             |  2 +
  11 files changed, 109 insertions(+), 1 deletion(-)


I have checked your previous dirtyfb patch (and corresponding discussion).

I'm not fond of the idea of acquiring locks, computing the value, then releasing the locks and reacquiring the locks again. I understand the original needs_dirtyfb approach was frowned upon. Do we have a chance of introducing drm_atomic_helper_dirtyfb_unlocked()? Which would perform all the steps of the orignal helper, but without locks acquirement (and state allocation/freeing)?

[skipped]

diff --git a/drivers/gpu/drm/msm/msm_fb.c b/drivers/gpu/drm/msm/msm_fb.c
index 4d34df5354e0..1b0648baeae2 100644
--- a/drivers/gpu/drm/msm/msm_fb.c
+++ b/drivers/gpu/drm/msm/msm_fb.c
@@ -24,10 +24,72 @@ struct msm_framebuffer {
  static struct drm_framebuffer *msm_framebuffer_init(struct drm_device *dev,
  		const struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_object **bos);
+static int msm_framebuffer_dirtyfb(struct drm_framebuffer *fb,
+				   struct drm_file *file_priv, unsigned int flags,
+				   unsigned int color, struct drm_clip_rect *clips,
+				   unsigned int num_clips)
+{
+	struct msm_drm_private *priv = fb->dev->dev_private;
+	struct drm_modeset_acquire_ctx ctx;
+	struct drm_plane *plane;
+	bool needs_flush = false;
+	int ret = 0;
+
+	/*
+	 * When called from ioctl, we are interruptible, but not when called
+	 * internally (ie. defio worker)
+	 */
+	drm_modeset_acquire_init(&ctx,
+		file_priv ? DRM_MODESET_ACQUIRE_INTERRUPTIBLE : 0);
+
+retry:
+	drm_for_each_plane(plane, fb->dev) {
+		struct drm_plane_state *plane_state;
+		struct drm_crtc *crtc;
+
+		ret = drm_modeset_lock(&plane->mutex, &ctx);
+		if (ret)
+			goto out;
+
+		if (plane->state->fb != fb) {
+			drm_modeset_unlock(&plane->mutex);
+			continue;
+		}
+
+		crtc = plane->state->crtc;
+
+		ret = drm_modeset_lock(&crtc->mutex, &ctx);
+		if (ret)
+			goto out;
+
+		if (priv->kms->funcs->needs_dirtyfb(crtc)) {
+			needs_flush = true;
+			break;
+		}
+	}
+
+out:
+	if (ret == -EDEADLK) {
+		ret = drm_modeset_backoff(&ctx);
+		if (!ret)
+			goto retry;
+	}
+
+	drm_modeset_drop_locks(&ctx);
+	drm_modeset_acquire_fini(&ctx);
+
+	if (needs_flush) {

This bit triggers my paranoia. The driver computes the value with the locks being held and then performs some action depending on the computed value after releasing the locks.

I'd prefer to acquire modesetting locks for all the planes (and allocate atomic state), check if the dirtyfb processing is needed, then call drm_atomic_helper_dirtyfb_unlocked() withith the same locks section.

+		ret = drm_atomic_helper_dirtyfb(fb, file_priv, flags,
+						color, clips, num_clips);
+	}
+
+	return ret;
+}
+
  static const struct drm_framebuffer_funcs msm_framebuffer_funcs = {
  	.create_handle = drm_gem_fb_create_handle,
  	.destroy = drm_gem_fb_destroy,
-	.dirty = drm_atomic_helper_dirtyfb,
+	.dirty = msm_framebuffer_dirtyfb,
  };
#ifdef CONFIG_DEBUG_FS
diff --git a/drivers/gpu/drm/msm/msm_kms.h b/drivers/gpu/drm/msm/msm_kms.h
index 2a4f0526cb98..eb870d499d1e 100644
--- a/drivers/gpu/drm/msm/msm_kms.h
+++ b/drivers/gpu/drm/msm/msm_kms.h
@@ -117,6 +117,8 @@ struct msm_kms_funcs {
  			struct drm_encoder *encoder,
  			struct drm_encoder *slave_encoder,
  			bool is_cmd_mode);
+	bool (*needs_dirtyfb)(struct drm_crtc *crtc);
+
  	/* cleanup: */
  	void (*destroy)(struct msm_kms *kms);


--
With best wishes
Dmitry



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux