qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Fabrice Bellard <fabrice@bellard.org>
To: alex@fsn.hu
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] qvm86, kqemu and video speed
Date: Tue, 12 Apr 2005 21:30:48 +0200	[thread overview]
Message-ID: <425C21E8.6090306@bellard.org> (raw)
In-Reply-To: <20050412183843.1a3ad827@caprice.artificis.hu>

Alex Beregszaszi wrote:
>>I understand qvm86 and kqemu provide some virtualisation of the host 
>>machine, including allowing the guest some direct memory access. Is it
>>conceivable for these modules to be extended to allow the guest
>>machine to directly write to host video memory, or else to a host
>>memory buffer that is copied into the Qemu window?
> 
> 
> I'm working on such a Direct Host Graphics custom "videocard". I'm
> reusing the common vga code, while adding an mmio and framebuffer range
> for the direct stuff. Also it has a custom pci vendor/device id. It is
> working quiet nicely, however, plenty of guest os drivers are needed
> (preferably for different Windows versions - for Linux I have mine).

You can do that, but there is also a lot of optimisation opportunities 
in the existing Cirrus driver. My feeling is that using a driver for a 
virtual card will add only marginal gains (except in 3d) for a bigger 
amount of work (you need specific drivers in the guest OSes).

For example, in the Cirrus driver, it could be possible for the virtual 
CPU to access the virtual frame buffer (currently a callback is always 
used). A specific virtual CPU support is needed to change dynamically 
the type of a physical memory mapping - that's why I did not implement 
it when I enhanced the Cirrus driver. It will be even more critical soon 
with a more optimized version of kqemu.

Moreover, it could be possible to suppress one memcpy from the virtual 
frame buffer to the SDL/X11 frame buffer, and another memcpy if full 
screen mode is used (in this case, the virtual CPU accesses directly the 
host frame buffer).

Finally, the Cirrus bitblt operations could be redirected to the 
corresponding X11 DGA operations in full screen mode.

If you want to do 3d, emulating a SiS or Intel VGA card could suffice 
too as they are documented. I believe most of their 3d operations can be 
directly remapped to host OpenGL calls.

Another project would be to write a driver to use the host card in full 
screen mode. The QEMU support would depend on the host VGA card, but 
supporting only one type of card in the beginning (for example ATI 
Radeon cards) would suffice. The QEMU driver would swap the VGA memory 
frame buffer and the mmio registers when switching between the host and 
guest displays. It would need to do a host PCI probe to find the host 
VGA memory areas. Note that I think such a project should be separated 
from the generic host PCI card usage for which patches already exist. 
Supporting host PCI VGA cards need specific quirks and there is little 
gain in merging the two features.

Fabrice.

  reply	other threads:[~2005-04-12 19:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-11 14:07 [Qemu-devel] qvm86, kqemu and video speed Struan Bartlett
2005-04-11 15:01 ` James Mastros
2005-04-11 15:17   ` Paul Brook
2005-04-11 15:35     ` Struan Bartlett
2005-04-11 21:51       ` Struan Bartlett
2005-04-15  8:54       ` Struan Bartlett
2005-04-12  3:13     ` Darryl Dixon
2005-04-11 21:53   ` Struan Bartlett
2005-04-12 16:38 ` Alex Beregszaszi
2005-04-12 19:30   ` Fabrice Bellard [this message]
2005-04-13  3:57     ` use.reply-to.address
2005-04-13  8:06     ` Struan Bartlett
2005-04-13 18:12     ` Hetz Ben Hamo
2005-04-13 19:24       ` Leonardo E. Reiter
2005-04-13 20:09         ` Leonardo E. Reiter
2005-04-14  9:42       ` Thomas Steffen
2005-04-18  7:32         ` Oliver Gerlich
2005-04-19  6:15           ` emuls
2005-04-13 21:12 ` Jim C. Brown

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=425C21E8.6090306@bellard.org \
    --to=fabrice@bellard.org \
    --cc=alex@fsn.hu \
    --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).