From: Brian Johnson <bjj4@charter.net>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [PATCH] Reducing X communication bandwidth, take 2
Date: Mon, 19 Mar 2007 11:07:11 -0500 [thread overview]
Message-ID: <45FEB52F.7080008@charter.net> (raw)
In-Reply-To: <200703162138.35410.paul@codesourcery.com>
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: 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
next prev parent reply other threads:[~2007-03-19 16:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-14 1:52 [Qemu-devel] [PATCH] Reducing X communication bandwidth, take 2 Julian Seward
2007-03-14 3:39 ` Anthony Liguori
2007-03-14 4:57 ` Mark Williamson
2007-03-14 10:53 ` Julian Seward
2007-03-14 12:29 ` Johannes Schindelin
2007-03-16 18:40 ` Anthony Liguori
2007-03-16 20:53 ` Julian Seward
2007-03-16 21:09 ` Anthony Liguori
2007-03-16 21:38 ` Paul Brook
2007-03-19 16:07 ` Brian Johnson [this message]
2007-03-25 17:22 ` [Qemu-devel] " Anthony Liguori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45FEB52F.7080008@charter.net \
--to=bjj4@charter.net \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).