On 04.06.2011, at 17:34, Sasha Levin wrote: > On Sat, 2011-06-04 at 17:21 +0200, Alexander Graf wrote: >> 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 <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 :). >>> >>> 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 :). > > I we use coalesced MMIO we only exit when the shared page is full. Yes, which will be very often for full redrawing guests. Remember, we're talking about megabytes of graphics data. Plus you still need to call your internal MMIO handler for every single access then. And I hope I don't even have to mention read performance (which is abysmal on real graphics cards too though). > If we mark a memory region as log dirty we won't get MMIO exits on it? Exactly, hence the periodic check. If you mark a memory region as coalesced you also don't get MMIO exits on it. So unless you introduce a timer similar to the dirty log one that takes you out of ioctl(VCPU_RUN) you'll end up with coalescing FB updates. So something like this inside the guest would be very much screwed: $ while true; do echo -n x; done But I won't keep you from doing it. Implement it and see how it performs. This whole project is about trying to find out what is fast for yourselves, no? :) Just make sure to also implement the dirty log way so you can actually compare the numbers. 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
