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
