On 6/7/22 01:43, Alexander Graf wrote:
This patch set speeds up graphics output on ARM by a factor of 60x.
On most ARM SBCs, we keep the frame buffer in DRAM and map it as cached, but need it accessible by the display controller which reads directly from a later point of consistency. Hence, we flush the frame buffer to DRAM on every change. The full frame buffer.
Isn't a similar problem already solved by CONFIG_VIDEO_COPY?
Leaving the frame buffer uncached would convert the ARM problem into the X86 case?
Unfortunately, with the advent of 4k displays, we are seeing frame buffers that can take a while to flush out. This was reported by Da Xue with grub, which happily print 1000s of spaces on the screen to draw a menu. Every printed space triggers a cache flush.
This patch set implements the easiest mitigation against this problem: Damage tracking. We remember the lowest common denominator region that was touched since the last video_sync() call and only flush that.
If by "lowest common denominator region" you should mean a rectangle, drawing a point in the upper left corner and another in the lower right corner would require a full flush. So nothing gained in this case.
With this patch set applied, we reduce drawing a large grub menu (with serial console attached for size information) on an RK3399-ROC system at 1440p from 55 seconds to less than 1 second.
Alternatives considered:
Lazy sync - Sandbox does this. It only calls video_sync(true) ever so often. We are missing timers to do this generically.
Double buffering - We could try to identify whether anything changed at all and only draw to the FB if it did. That would require maintaining a second buffer that we need to scan.
Text buffer - Maintain a buffer of all text printed on the screen with respective location. Don't write if the old and new character are identical. This would limit applicability to text only and is an optimization on top of this patch set.
Hash screen lines - Create a hash (sha256?) over every line when it changes. Only flush when it does. I'm not sure if this would waste more time, memory and cache than the current approach. It would make full screen updates much more expensive.
Alexander Graf (6): dm: video: Add damage tracking API dm: video: Add damage notification on display clear vidconsole: Add damage notifications to all vidconsole drivers video: Add damage notification on bmp display efi_loader: GOP: Add damage notification on BLT video: Only dcache flush damaged lines
We need documentation describing the difference between CONFIG_VIDEO_COPY and CONFIG_VIDEO_DAMAGE.
Best regards
Heinrich
drivers/video/Kconfig | 15 ++++++ drivers/video/console_normal.c | 10 ++++ drivers/video/console_rotate.c | 18 +++++++ drivers/video/console_truetype.c | 12 +++++ drivers/video/video-uclass.c | 89 +++++++++++++++++++++++++++++--- drivers/video/video_bmp.c | 2 + include/video.h | 39 +++++++++++++- lib/efi_loader/efi_gop.c | 11 ++++ 8 files changed, 187 insertions(+), 9 deletions(-)