On 04.06.2011, at 14:04, Sasha Levin wrote: > On Sat, 2011-06-04 at 13:53 +0200, Ingo Molnar wrote: >> * Alexander Graf <agraf@xxxxxxx> wrote: >> >>> Why would you need panning/scrolling for a fast FB? It's really an >>> optimization that helps a lot with VNC, but on local machines or >>> SDL you shouldn't see a major difference. >> >> Qemu's fb console scrolling graphics is pretty slow to me even >> locally so i assume that the dirty bitmap trick is not enough. >> >> VirtualBox graphics is very fast, but it probably has its own console >> abstraction and scrolling/2D/3D acceleration. >> >> Also, since tools/kvm/ is really also about learning interesting >> stuff, smooth scrolling was the historic first 'acceleration' usecase >> that video graphics cards added - before they evolved more complex 2D >> acceleration and then started doing 3D. >> >> Walking that path would allow us to do a gradual approach, while >> still having relevant functionality and enhancements at every step. >> >>> Unless you use the FB as MMIO. Qemu just maps the FB as RAM and >>> checks for dirty bitmap updates periodically. That way you don't >>> constantly exit due to MMIO and are good on speed. The slowness you >>> describe sounds a lot as if you don't do that trick. >> >> Correct, and i assumed we already do the dirty-bitmap trick: >> >> KVM_MEM_LOG_DIRTY_PAGES >> KVM_GET_DIRTY_LOG >> >> But you are right, we do not actually do that! >> >> Pekka, i think this should be the next step. We'll need scrolling >> after that ... >> >> In theory it would also be nice to tunnel the VGA text frame buffer >> over to the KVM tool - as serial console is not supported by most >> installers and default distro images. We could actually do a rather >> good job of emulating it via Slang/Curses. > > I doubt we could use dirty pages because unless guest VESA driver > supports panning, it will redraw the entire FB - which means that all > pages will be dirty. Please recheck the math and compare 60 dirty bitmap checks+flushes per second to a few million MMIO exits for every single pixel :). If your concern is about whether dirty bitmapping makes sense, it does. If you check say 60 times a second for updates and you don't do anything during that second, no screen updates happen, so the dirty log is empty. Without dirty log, you end up refreshing/recomparing/resending the full screen multiple times a second. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
