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 in 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. v2: * keep drm_fb_helper_damage() (Daniel) * fix function names (Daniel) * clarify comments (Daniel) * split patch #3 (Daniel) [1] https://download.blender.org/peach/bigbuckbunny_movies/big_buck_bunny_1080p_surround.avi Thomas Zimmermann (6): drm/fb-helper: Set damage-clip area in helper drm/fb-helper: Move dirty-fb update into helper function drm/fb-helper: Remove test for fb_dirty callback from deferred-I/O helper 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 | 53 ++++++++++++++++++----------- drivers/video/fbdev/core/fb_defio.c | 16 +++++++++ include/drm/drm_fb_helper.h | 2 -- include/linux/fb.h | 1 + 4 files changed, 51 insertions(+), 21 deletions(-) base-commit: 2cc304afd4967ceffd14940ff73a8beb31778f90 -- 2.38.1
