On 04.06.2011, at 16:19, Sasha Levin wrote: > On Sat, 2011-06-04 at 15:48 +0200, Alexander Graf wrote: >> On 04.06.2011, at 14:04, Sasha Levin wrote: >> >>> On Sat, 2011-06-04 at 13:53 +0200, Ingo Molnar wrote: >>>> * Alexander Graf <[email protected]> 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 :). > > I might be missing something here, but if every single pixel changes due > to scrolling, doesn't it mean that all the pages will be marked as > 'dirty' anyway?
Sure, but you don't need to exit to user space for every single pixel, but instead process the whole thing asynchronously. Just run kvm_stat while running your current implementation and you'll pretty soon realize what I'm talking about :). Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
