From: Thomas Zimmermann <tzimmermann@suse.de>
To: daniel@ffwll.ch, airlied@gmail.com, javierm@redhat.com,
mripard@kernel.org, maarten.lankhorst@linux.intel.com
Cc: Thomas Zimmermann <tzimmermann@suse.de>, dri-devel@lists.freedesktop.org
Subject: [PATCH 0/5] drm/fb-helper: Remove damage worker
Date: Thu, 10 Nov 2022 14:55:14 +0100 [thread overview]
Message-ID: <20221110135519.30029-1-tzimmermann@suse.de> (raw)
The fbdev emulation runs a separate worker that collects all changes
to the framebuffer and runs DRM damage handling. But this can also be
performed by the worker of fbdev's deferred-I/O code. Move damage
handling there, remove the damage worker and reduce the latency.
I ran a simple benchmark with mplayer and Big Buck Bunny [1] on the
console to look for any changes to performance.
mplayer -nosound -vo fbdev -benchmark big_buck_bunny_1080p_surround.avi
On my test system (i7-4790, simpledrm, 1024x768), this command always
takes around 95 seconds (57% VC, 36% VO, 7% sys). The difference in
internal scheduling appears to have no impact on performance.
[1] https://download.blender.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_surround.avi
Thomas Zimmermann (5):
drm/fb-helper: Set damage-clip area in helper
drm/fb-helper: Move dirty-fb update into helper function
drm/fb-helper: Perform damage handling in deferred-I/O helper
drm/fb-helper: Schedule deferred-I/O worker after writing to
framebuffer
drm/fb-helper: Remove damage worker
drivers/gpu/drm/drm_fb_helper.c | 116 +++++++++++++++++++---------
drivers/video/fbdev/core/fb_defio.c | 16 ++++
include/drm/drm_fb_helper.h | 2 -
include/linux/fb.h | 1 +
4 files changed, 95 insertions(+), 40 deletions(-)
base-commit: 3aa97a74d622aa26fe79cf4bd819b6a4fd176e90
--
2.38.0
next reply other threads:[~2022-11-10 13:55 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-10 13:55 Thomas Zimmermann [this message]
2022-11-10 13:55 ` [PATCH 1/5] drm/fb-helper: Set damage-clip area in helper Thomas Zimmermann
2022-11-11 9:15 ` Daniel Vetter
2022-11-10 13:55 ` [PATCH 2/5] drm/fb-helper: Move dirty-fb update into helper function Thomas Zimmermann
2022-11-11 9:18 ` Daniel Vetter
2022-11-10 13:55 ` [PATCH 3/5] drm/fb-helper: Perform damage handling in deferred-I/O helper Thomas Zimmermann
2022-11-11 9:23 ` Daniel Vetter
2022-11-10 13:55 ` [PATCH 4/5] drm/fb-helper: Schedule deferred-I/O worker after writing to framebuffer Thomas Zimmermann
2022-11-10 14:28 ` Daniel Vetter
2022-11-11 9:28 ` Daniel Vetter
2022-11-15 10:05 ` Thomas Zimmermann
2022-11-16 9:21 ` Daniel Vetter
2022-11-10 13:55 ` [PATCH 5/5] drm/fb-helper: Remove damage worker Thomas Zimmermann
2022-11-11 9:42 ` Daniel Vetter
2022-11-15 11:30 ` Thomas Zimmermann
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=20221110135519.30029-1-tzimmermann@suse.de \
--to=tzimmermann@suse.de \
--cc=airlied@gmail.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=javierm@redhat.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
/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: link
Be 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.