From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HVWSJ-0002zy-ON for qemu-devel@nongnu.org; Sun, 25 Mar 2007 13:24:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HVWSG-0002xs-02 for qemu-devel@nongnu.org; Sun, 25 Mar 2007 13:24:35 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HVWSF-0002xi-Hi for qemu-devel@nongnu.org; Sun, 25 Mar 2007 12:24:31 -0500 Received: from wx-out-0506.google.com ([66.249.82.229]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HVWQ4-00032D-Pv for qemu-devel@nongnu.org; Sun, 25 Mar 2007 13:22:17 -0400 Received: by wx-out-0506.google.com with SMTP id i30so2820654wxd for ; Sun, 25 Mar 2007 10:22:05 -0700 (PDT) Message-ID: <4606AFBA.7000804@codemonkey.ws> Date: Sun, 25 Mar 2007 12:22:02 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] Reducing X communication bandwidth, take 2 References: <200703140152.01319.jseward@acm.org> <200703162053.02198.jseward@acm.org> <45FB077A.3080407@codemonkey.ws> <200703162138.35410.paul@codesourcery.com> <45FEB52F.7080008@charter.net> In-Reply-To: <45FEB52F.7080008@charter.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Brian Johnson wrote: > Paul Brook wrote: >>>> Will this work also for the CL542x adaptor? (Does that fall in the >>>> category of vga?) My current hack works for with/without -std-vga >>>> and I >>>> think that's because it lives "underneath" both, in the connection to >>>> SDL. >>> Each adapter will have to do it's own minimization but that's sort of >>> the write thing anyway IMHO. How granular each update is really only >>> depends on the adapter. For instance, the VMware adapter really >>> shouldn't need to do any minimization at all. >> >> It would be nice if we could share the framebuffer blitting routines. >> We've currently got 3 different implementations (vga/cirrus, tcx and >> pl110) of basically the same framebuffer rendering routines. > > Take a look at the video code in BasiliskII / SheepShaver, a 68k/PPC > classic MacOS emulator written by Gwenolé Beauchesne: > > http://gwenole.beauchesne.info/projects/sheepshaver/ > > It contains optimized code (source level) for blitting between various > bit depths and endiannesses. See > SheepShaver-2.3/src/Unix/video_blit.{h,cpp} in the sources. > > It also uses a technique called "video on segfault" (VOSF) to improve > performance on platforms which support it: This is what QEMU already does. In fact, it's an exceedingly common technique. Regards, Anthony Liguori > rather than testing each store to see if it modifies the framebuffer, > it keeps the framebuffer write-protected (via mprotect(), or the > equivalent on non-POSIX systems) and uses a SIGSEGV handler to catch > stores to the buffer. When a page receives a store, the handler > unprotects the page and updates a bitmap of modified pages. Every so > often a display update thread wakes up, consults the bitmap, > calculates the updated region, blits it to the screen (using the > optimized blitters), and clears the bitmap. See > SheepShaver-2.3/src/Unix/video_vosf.h, > SheepShaver-2.3/src/Unix/video_x.cpp, and other files. > > The emulators also have alternative techniques for tracking update > regions on systems for which VOSF is not supported. But VOSF is > almost always a big win. And most modern OSes can support it without > trouble. > > The code is in C++ so it can't be dropped in directly, but Some of the > techniques may be useful in qemu. > > > Brian J. Johnson > > >