From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LPev1-0004Vw-Ae for qemu-devel@nongnu.org; Wed, 21 Jan 2009 10:23:03 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LPev0-0004VW-QX for qemu-devel@nongnu.org; Wed, 21 Jan 2009 10:23:03 -0500 Received: from [199.232.76.173] (port=39803 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LPev0-0004VN-Ia for qemu-devel@nongnu.org; Wed, 21 Jan 2009 10:23:02 -0500 Received: from caffeine.csclub.uwaterloo.ca ([129.97.134.17]:42810) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LPev0-0001Zc-1x for qemu-devel@nongnu.org; Wed, 21 Jan 2009 10:23:02 -0500 Date: Wed, 21 Jan 2009 10:23:00 -0500 Subject: Re: [Qemu-devel] Re: Extremely slow graphic updates Message-ID: <20090121152259.GG29175@csclub.uwaterloo.ca> References: <20090119162633.GO29175@csclub.uwaterloo.ca> <4975B3F6.6050706@eu.citrix.com> <200901201811.19920.paul@codesourcery.com> <200901210150.17344.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200901210150.17344.paul@codesourcery.com> From: lsorense@csclub.uwaterloo.ca (Lennart Sorensen) Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org, Stefano Stabellini On Wed, Jan 21, 2009 at 01:50:15AM +0000, Paul Brook wrote: > > Steps to reproduce: > > - Start qemu (doesn't matter which target or guest OS). > > - Press c-a-2 to switch to the monitor. > > - type "help" > > - Watch the output slowly appear over the next 30 seconds > > > > Running qemu over a forwarded X connection from a different machine (i.e. > > ssh -X) suffers a marked slowdown. With this configuration the early x86 > > boot stages are visibly much slower, in addition to the virtual console > > slowness mentioned above. > > I've applied a patch to fix this. > > The problem was that we were incorrectly using SDL_Flip in sdl_update. > > This is fundamentally wrong because the blit immediately above has only > updated the recently changes section of the image. With a flipped surface the > contents will be the frame before last (if not the one before that), so we'd > actually need to blit everything that has changed in the last 2 (or 3) > frames. > > However we don't set SDL_DOUBLEBUFFER when SDL_SetVideoMode, so SDL_Flip this > is just a confusing way of writing SDL_UpdateRect(real_screen, 0, 0, 0, 0); > On systems where copying to the front buffer is expensive (in particular > remote connections, or primitive Xorg drivers), needlessly refreshing the > whole display has a huge effect on the cases mentioned above. > > I've applied a patch to use the correct SDL_UpdateRect call instead. > This gets us almost back where we started. > > The virtual consoles are still slow over a remote connection. The text > terminal code generates a lot of small redundant update. It appears that > these now require an X server round trip, where they didn't before. > I'm not sure why, I can only guess that the blit rather than direct > framebuffer access is foiling some internal SDL/X dirty region tracking. I just tried running with '-serial /dev/null -parallel /dev/null' and the slow down problem disappeared. I am suspicious of this part of the 6336 commit: @@ -1360,12 +1352,137 @@ void qemu_console_copy(QEMUConsole *console, int src_x, int src_y, int dst_x, int dst_y, int w, int h) { if (active_console == console) { - if (console->ds->dpy_copy) - console->ds->dpy_copy(console->ds, - src_x, src_y, dst_x, dst_y, w, h); - else { - /* TODO */ - console->ds->dpy_update(console->ds, dst_x, dst_y, w, h); - } + dpy_copy(console->ds, src_x, src_y, dst_x, dst_y, w, h); } } To me this looks like what used to do a copy if the console was active, and an update if it was not, has turned into a copy at all times. This sounds like potentially doing expensive work on inactive consoles. This is what made me think of trying to disable the parallel and serial consoles. I made this little patch for console.c: --- qemu-0.9.1.14778c2064166a8d1d07b22f0af9eee4fa490e60/console.c 2009-01-21 09:26:06.000000000 -0500 +++ qemu-0.9.1.14778c2064166a8d1d07b22f0af9eee4fa490e60.new/console.c 2009-01-21 10:12:29.000000000 -0500 @@ -1433,7 +1433,11 @@ int dst_x, int dst_y, int w, int h) { if (is_graphic_console()) { - dpy_copy(ds, src_x, src_y, dst_x, dst_y, w, h); + if(active_console->ds == ds) { + dpy_copy(ds, src_x, src_y, dst_x, dst_y, w, h); + } else { + dpy_update(ds, dst_x, dst_y, w, h); + } } } And then it is back to proper speed for me across ssh. Does it make sense? -- Len Sorensen