From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HTKPi-0008P0-2G for qemu-devel@nongnu.org; Mon, 19 Mar 2007 12:08:50 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HTKPe-0008OY-NL for qemu-devel@nongnu.org; Mon, 19 Mar 2007 12:08:48 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HTKPe-0008OV-HA for qemu-devel@nongnu.org; Mon, 19 Mar 2007 11:08:46 -0500 Received: from netops-testserver-4-out.sgi.com ([192.48.171.29] helo=netops-testserver-4.corp.sgi.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HTKOA-0003vg-UC for qemu-devel@nongnu.org; Mon, 19 Mar 2007 12:07:15 -0400 Received: from estes.americas.sgi.com (estes.americas.sgi.com [128.162.236.10]) by netops-testserver-4.corp.sgi.com (Postfix) with ESMTP id D789061B4E for ; Mon, 19 Mar 2007 08:07:11 -0800 (PST) Received: from [128.162.232.243] (pc-bjohnson.americas.sgi.com [128.162.232.243]) by estes.americas.sgi.com (Postfix) with ESMTP id 5235870001DC for ; Mon, 19 Mar 2007 11:07:11 -0500 (CDT) Message-ID: <45FEB52F.7080008@charter.net> Date: Mon, 19 Mar 2007 11:07:11 -0500 From: Brian Johnson MIME-Version: 1.0 References: <200703140152.01319.jseward@acm.org> <200703162053.02198.jseward@acm.org> <45FB077A.3080407@codemonkey.ws> <200703162138.35410.paul@codesourcery.com> In-Reply-To: <200703162138.35410.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: [PATCH] Reducing X communication bandwidth, take 2 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 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 an= d 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. >=20 > It would be nice if we could share the framebuffer blitting routines. W= e've=20 > currently got 3 different implementations (vga/cirrus, tcx and pl110) o= f=20 > basically the same framebuffer rendering routines. Take a look at the video code in BasiliskII / SheepShaver, a 68k/PPC=20 classic MacOS emulator written by Gwenol=E9 Beauchesne: http://gwenole.beauchesne.info/projects/sheepshaver/ It contains optimized code (source level) for blitting between various=20 bit depths and endiannesses. See=20 SheepShaver-2.3/src/Unix/video_blit.{h,cpp} in the sources. It also uses a technique called "video on segfault" (VOSF) to improve=20 performance on platforms which support it: rather than testing each=20 store to see if it modifies the framebuffer, it keeps the framebuffer=20 write-protected (via mprotect(), or the equivalent on non-POSIX systems)=20 and uses a SIGSEGV handler to catch stores to the buffer. When a page=20 receives a store, the handler unprotects the page and updates a bitmap=20 of modified pages. Every so often a display update thread wakes up,=20 consults the bitmap, calculates the updated region, blits it to the=20 screen (using the optimized blitters), and clears the bitmap. See=20 SheepShaver-2.3/src/Unix/video_vosf.h,=20 SheepShaver-2.3/src/Unix/video_x.cpp, and other files. The emulators also have alternative techniques for tracking update=20 regions on systems for which VOSF is not supported. But VOSF is almost=20 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=20 techniques may be useful in qemu. Brian J. Johnson