From: Rob Clark <robdclark@gmail.com> To: dri-devel@lists.freedesktop.org Cc: Rob Clark <robdclark@chromium.org>, Abhinav Kumar <abhinavk@codeaurora.org>, Bernard <bernard@vivo.com>, freedreno@lists.freedesktop.org (open list:DRM DRIVER FOR MSM ADRENO GPU), Hongbo Yao <yaohongbo@huawei.com>, Kalyan Thota <kalyan_t@codeaurora.org>, linux-arm-msm@vger.kernel.org (open list:DRM DRIVER FOR MSM ADRENO GPU), linux-kernel@vger.kernel.org (open list), Maxime Ripard <maxime@cerno.tech>, Qinglang Miao <miaoqinglang@huawei.com>, Stephen Boyd <swboyd@chromium.org> Subject: [PATCH 0/2] drm: Fix atomic helper dirtyfb stalls Date: Sat, 8 May 2021 12:56:37 -0700 [thread overview] Message-ID: <20210508195641.397198-1-robdclark@gmail.com> (raw) From: Rob Clark <robdclark@chromium.org> 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. Rob Clark (2): drm: Fix dirtyfb stalls drm/msm/dpu: Wire up needs_dirtyfb drivers/gpu/drm/drm_damage_helper.c | 8 ++++++++ drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 14 ++++++++++++++ include/drm/drm_modeset_helper_vtables.h | 14 ++++++++++++++ 3 files changed, 36 insertions(+) -- 2.30.2
WARNING: multiple messages have this Message-ID (diff)
From: Rob Clark <robdclark@gmail.com> To: dri-devel@lists.freedesktop.org Cc: Rob Clark <robdclark@chromium.org>, Bernard <bernard@vivo.com>, "open list:DRM DRIVER FOR MSM ADRENO GPU" <linux-arm-msm@vger.kernel.org>, Hongbo Yao <yaohongbo@huawei.com>, open list <linux-kernel@vger.kernel.org>, Abhinav Kumar <abhinavk@codeaurora.org>, Stephen Boyd <swboyd@chromium.org>, Qinglang Miao <miaoqinglang@huawei.com>, Maxime Ripard <maxime@cerno.tech>, Kalyan Thota <kalyan_t@codeaurora.org>, "open list:DRM DRIVER FOR MSM ADRENO GPU" <freedreno@lists.freedesktop.org> Subject: [PATCH 0/2] drm: Fix atomic helper dirtyfb stalls Date: Sat, 8 May 2021 12:56:37 -0700 [thread overview] Message-ID: <20210508195641.397198-1-robdclark@gmail.com> (raw) From: Rob Clark <robdclark@chromium.org> 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. Rob Clark (2): drm: Fix dirtyfb stalls drm/msm/dpu: Wire up needs_dirtyfb drivers/gpu/drm/drm_damage_helper.c | 8 ++++++++ drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 14 ++++++++++++++ include/drm/drm_modeset_helper_vtables.h | 14 ++++++++++++++ 3 files changed, 36 insertions(+) -- 2.30.2
next reply other threads:[~2021-05-08 19:52 UTC|newest] Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-08 19:56 Rob Clark [this message] 2021-05-08 19:56 ` [PATCH 0/2] drm: Fix atomic helper dirtyfb stalls Rob Clark 2021-05-08 19:56 ` [PATCH 1/2] drm: Fix " Rob Clark 2021-05-08 19:56 ` Rob Clark 2021-05-10 16:14 ` Daniel Vetter 2021-05-10 16:14 ` Daniel Vetter 2021-05-10 16:16 ` Daniel Vetter 2021-05-10 16:55 ` Rob Clark 2021-05-10 16:55 ` Rob Clark 2021-05-10 17:43 ` Daniel Vetter 2021-05-10 17:43 ` Daniel Vetter 2021-05-10 19:06 ` Rob Clark 2021-05-10 19:06 ` Rob Clark 2021-05-11 16:44 ` Daniel Vetter 2021-05-11 16:44 ` Daniel Vetter 2021-05-11 17:19 ` Rob Clark 2021-05-11 17:19 ` Rob Clark 2021-05-11 17:21 ` Daniel Vetter 2021-05-11 17:21 ` Daniel Vetter 2021-05-11 17:42 ` Rob Clark 2021-05-11 17:42 ` Rob Clark 2021-05-11 17:50 ` Daniel Vetter 2021-05-11 17:50 ` Daniel Vetter 2021-05-12 8:23 ` Pekka Paalanen 2021-05-12 8:23 ` Pekka Paalanen 2021-05-12 8:44 ` Daniel Vetter 2021-05-12 8:44 ` Daniel Vetter 2021-05-12 9:46 ` Pekka Paalanen 2021-05-12 9:46 ` Pekka Paalanen 2021-05-12 10:35 ` Daniel Vetter 2021-05-12 10:35 ` Daniel Vetter 2021-05-12 14:57 ` Rob Clark 2021-05-12 14:57 ` Rob Clark 2021-05-14 7:54 ` Pekka Paalanen 2021-05-14 7:54 ` Pekka Paalanen 2021-05-14 14:43 ` Rob Clark 2021-05-14 14:43 ` Rob Clark 2021-05-08 19:56 ` [PATCH 2/2] drm/msm/dpu: Wire up needs_dirtyfb Rob Clark 2021-05-08 19:56 ` Rob Clark 2021-05-09 15:38 ` Tested houdek.ryan 2021-05-09 15:38 ` Tested houdek.ryan 2021-05-10 15:26 ` Tested Alex Deucher 2021-05-10 15:26 ` Tested Alex Deucher 2021-05-09 16:28 ` [PATCH 2/2] drm/msm/dpu: Wire up needs_dirtyfb Rob Clark 2021-05-09 16:28 ` Rob Clark
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210508195641.397198-1-robdclark@gmail.com \ --to=robdclark@gmail.com \ --cc=abhinavk@codeaurora.org \ --cc=bernard@vivo.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=freedreno@lists.freedesktop.org \ --cc=kalyan_t@codeaurora.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=maxime@cerno.tech \ --cc=miaoqinglang@huawei.com \ --cc=robdclark@chromium.org \ --cc=swboyd@chromium.org \ --cc=yaohongbo@huawei.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.