From: use.reply-to.address@domn.net
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] qvm86, kqemu and video speed
Date: Tue, 12 Apr 2005 23:57:55 -0400 [thread overview]
Message-ID: <425C98C3.9030307@domn.net> (raw)
In-Reply-To: <425C21E8.6090306@bellard.org>
Fabrice Bellard wrote:
> 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.
this is just a suggestion , but what about 3dfx voodoo 3 cards ? they
have descent implementation of opengl , probably more complete than sis
, intel or via , and better understood than nvidia tnt/geforce or ati
rage/radeon
they are very well supported with all MS oses and linux (native oss
linux opengl-capable voodoo3 drivers are part of xfree86)
and they also supported the early 3d platform like powerVR so if someday
someone want to emulate that, the guest drivers will already support it
also I guess they were compatible with the dos games that supported 3dfx
card natively (back in those day 3dfx was like soundblaster for sound so
some games your choices are software opengl or 3dfx only , that would
make the voodoo3 a very versatile platform for running pretty much any
3d software pre-2001)
also , I noticed you can have up to 6 network cards emulated , could it
be possible to emulate multiple video cards too ?
that way you could have 2 or more sdl or vnc screens , just like a real
multi-head system
next prev parent reply other threads:[~2005-04-13 3:33 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
2005-04-13 3:57 ` use.reply-to.address [this message]
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=425C98C3.9030307@domn.net \
--to=use.reply-to.address@domn.net \
--cc=qemu-devel@nongnu.org \
--cc=qemu@domn.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.