qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] qvm86, kqemu and video speed


From: Fabrice Bellard
Subject: Re: [Qemu-devel] qvm86, kqemu and video speed
Date: Tue, 12 Apr 2005 21:30:48 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913

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 via email to

[Prev in Thread] Current Thread [Next in Thread]