Hi Daniel, Daniel Vetter <daniel@xxxxxxxx> writes: > On Thu, Jan 13, 2022 at 10:46:03PM +0100, Sven Schnelle wrote: >> Helge Deller <deller@xxxxxx> writes: >> > Maybe on fast new x86 boxes the performance difference isn't huge, >> > but for all old systems, or when emulated in qemu, this makes >> > a big difference. >> > >> > Helge >> >> I second that. For most people, the framebuffer isn't important as >> they're mostly interested in getting to X11/wayland as fast as possible. >> But for systems like servers without X11 it's nice to have a fast >> console. > > Fast console howto: > - shadow buffer in cached memory > - timer based upload of changed areas to the real framebuffer > > This one is actually fast, instead of trying to use hw bltcopy and having > the most terrible fallback path if that's gone. Yes drm fbdev helpers has > this (but not enabled on most drivers because very, very few people care). Hmm.... Take my Laptop with a 4k (3180x2160) screen as an example: Lets say on average the half of every line is filled with text. So 3840/2*2160 pixels that change = 4147200 pixels. Every pixel takes 4 bytes = 16,588800 bytes per timer interrupt. In another Mail updating on vsync was mentioned, so multiply that by 60 and get ~927MB. And even if you only update the screen ony 4 times per second, that would be ~64MB of data. I'm likely missing something here.
