Re: [PATCH] kvm tools, ui: Optimize SDL updates

[Sasha Levin <levinsasha928@gmail.com>]

On Sat, 2011-06-04 at 13:53 +0200, Ingo Molnar wrote:
> * Alexander Graf <agraf@suse.de> 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.

-- 

Sasha.