[Qemu-devel] qvm86, kqemu and video speed

[Qemu-devel] qvm86, kqemu and video speed

[Struan Bartlett]

Hi,

I've run some Windows 2000 performance tests on Qemu using a program 
called PassMark PerformanceTest. You can find some results here - 
http://www.praguespringpeople.org/Struan/Software/QEMU/Performance/2005-03-29/ 
- I'll put more there when I make them.

The results seem to me to suggest that emulated performance is weakest 
on video operations - which doesn't surprise me if it is necessary for 
every pixel change to be emulated - and while this won't be an issue for 
some Qemu users it will I expect be a major issue for others.

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?

Struan

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

[James Mastros]

Struan Bartlett wrote:
> Hi,
> 
> I've run some Windows 2000 performance tests on Qemu using a program 
> called PassMark PerformanceTest. You can find some results here - 
> http://www.praguespringpeople.org/Struan/Software/QEMU/Performance/2005-03-29/ 
> - I'll put more there when I make them.
> 
> The results seem to me to suggest that emulated performance is weakest 
> on video operations - which doesn't surprise me if it is necessary for 
> every pixel change to be emulated - and while this won't be an issue for 
> some Qemu users it will I expect be a major issue for others.

One thing that could be done as a fairly quick hack would be to call 
SDL's bitblit function for bitblits that are simple copies.  These are 
rather common, and SDL already knows how to optimize them well -- we're 
just missing a bit of glue.  I got about halfway through doing this in a 
few hours of hacking, but realized that the video struct was completely 
undocumented, and I wasn't sure how to map from a pointer into the LFB 
back into xy coords.

After that, I think the best thing to do is to move from emulating a 
standard video card to defining our own that maps from the operations 
that the OS calls its video driver on to the operations that SDL 
implements, leaving any that do not map simply for the OS to emulate, on 
the theory that it probably knows how to better then we do.  However, 
this is a much larger undertaking, as it requires learning the driver 
model of the guest OSes.

	-=- James Mastros

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

[Paul Brook]

On Monday 11 April 2005 16:01, James Mastros wrote:
> After that, I think the best thing to do is to move from emulating a
> standard video card to defining our own that maps from the operations
> that the OS calls its video driver on to the operations that SDL
> implements, leaving any that do not map simply for the OS to emulate, on
> the theory that it probably knows how to better then we do.  However,
> this is a much larger undertaking, as it requires learning the driver
> model of the guest OSes.

I agree that emulating a "custom" driver model should give better performance 
than emulating real hardware (VMware does this). However I think you should 
provide all the functionality you possibly can, even if the host doesn't 
provide native acceleration for it. It's always going to be faster to do 
something in software on the host than it is on the guest.

Paul

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

[Struan Bartlett]

[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]

I agree with both views: Qemu should provide the Cirrus emulation option 
for those who need full emulation, and if we manage to emulate a 
"custom" driver model, that would be an option for those who need speed.

This has come up before, and it will come up again. Apparently, we don't 
know whether Diego's BochsVGA source is open. However we do know Filip 
Navarra's is (and I've posted what I have on 
http://www.praguespringpeople.org/Struan/Software/QEMU/Drivers/ for the 
interested).

Struan

Paul Brook wrote:

>On Monday 11 April 2005 16:01, James Mastros wrote:
>  
>
>>After that, I think the best thing to do is to move from emulating a
>>standard video card to defining our own that maps from the operations
>>that the OS calls its video driver on to the operations that SDL
>>implements, leaving any that do not map simply for the OS to emulate, on
>>the theory that it probably knows how to better then we do.  However,
>>this is a much larger undertaking, as it requires learning the driver
>>model of the guest OSes.
>>    
>>
>
>I agree that emulating a "custom" driver model should give better performance 
>than emulating real hardware (VMware does this). However I think you should 
>provide all the functionality you possibly can, even if the host doesn't 
>provide native acceleration for it. It's always going to be faster to do 
>something in software on the host than it is on the guest.
>
>Paul
>
>
>_______________________________________________
>Qemu-devel mailing list
>Qemu-devel@nongnu.org
>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>  
>

[-- Attachment #2: Type: text/html, Size: 2280 bytes --]

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

[Struan Bartlett]

[-- Attachment #1: Type: text/plain, Size: 1754 bytes --]

Struan Bartlett wrote:

> This has come up before, and it will come up again. Apparently, we 
> don't know whether Diego's BochsVGA source is open. However we do know 
> Filip Navarra's is (and I've posted what I have on 
> http://www.praguespringpeople.org/Struan/Software/QEMU/Drivers/ for 
> the interested).

P.S. I'm no expert Windows programmer - does anyone know what tools you 
need to compile this?

> Paul Brook wrote:
>
>>On Monday 11 April 2005 16:01, James Mastros wrote:
>>  
>>
>>>After that, I think the best thing to do is to move from emulating a
>>>standard video card to defining our own that maps from the operations
>>>that the OS calls its video driver on to the operations that SDL
>>>implements, leaving any that do not map simply for the OS to emulate, on
>>>the theory that it probably knows how to better then we do.  However,
>>>this is a much larger undertaking, as it requires learning the driver
>>>model of the guest OSes.
>>>    
>>>
>>
>>I agree that emulating a "custom" driver model should give better performance 
>>than emulating real hardware (VMware does this). However I think you should 
>>provide all the functionality you possibly can, even if the host doesn't 
>>provide native acceleration for it. It's always going to be faster to do 
>>something in software on the host than it is on the guest.
>>
>>Paul
>>
>>
>>_______________________________________________
>>Qemu-devel mailing list
>>Qemu-devel@nongnu.org
>>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>  
>>
>------------------------------------------------------------------------
>
>_______________________________________________
>Qemu-devel mailing list
>Qemu-devel@nongnu.org
>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>  
>

[-- Attachment #2: Type: text/html, Size: 2818 bytes --]

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

[Struan Bartlett]

James Mastros wrote:

> Struan Bartlett wrote:
>
>> The results seem to me to suggest that emulated performance is 
>> weakest on video operations - which doesn't surprise me if it is 
>> necessary for every pixel change to be emulated - and while this 
>> won't be an issue for some Qemu users it will I expect be a major 
>> issue for others.
>
>
> One thing that could be done as a fairly quick hack would be to call 
> SDL's bitblit function for bitblits that are simple copies.  These are 
> rather common, and SDL already knows how to optimize them well -- 
> we're just missing a bit of glue.  I got about halfway through doing 
> this in a few hours of hacking, but realized that the video struct was 
> completely undocumented, and I wasn't sure how to map from a pointer 
> into the LFB back into xy coords. 

I'm curious. Could you post your code somewhere I could look at it?

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

[Darryl Dixon]

[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]

Interestingly, one of the things that enamours me of Qemu over VMWare is
the video.  Because the Cirrus card that Qemu emulates has DirectDraw
compatible drivers for Windows, it is possible to play 2D DirectDraw
games in Qemu (eg, Age of Empires II, Civ III, etc).  This is impossible
in VMWare, despite the fact that the video operations in VMWare are
actually faster.

An illustration of the speed of video update in Qemu (and how much room
is left for improvement :) is the fact that in Civ III, all the sprites
are rendered with parts of them in a 'base colour' (blue, IIRC), which
then has your team colour overlaid on top.  In Qemu this process is
visible as a slow flashing back and forth between the 'base' colour and
the 'team' colour.  In VMWare, of course, it might be faster, except
that you can't even start it :)


D



On Mon, 2005-04-11 at 16:17 +0100, Paul Brook wrote:

>On Monday 11 April 2005 16:01, James Mastros wrote:
>> After that, I think the best thing to do is to move from emulating a
>> standard video card to defining our own that maps from the operations
>> that the OS calls its video driver on to the operations that SDL
>> implements, leaving any that do not map simply for the OS to emulate, on
>> the theory that it probably knows how to better then we do.  However,
>> this is a much larger undertaking, as it requires learning the driver
>> model of the guest OSes.
>
>I agree that emulating a "custom" driver model should give better performance 
>than emulating real hardware (VMware does this). However I think you should 
>provide all the functionality you possibly can, even if the host doesn't 
>provide native acceleration for it. It's always going to be faster to do 
>something in software on the host than it is on the guest.
>
>Paul
>
>
>_______________________________________________
>Qemu-devel mailing list
>Qemu-devel@nongnu.org
>http://lists.nongnu.org/mailman/listinfo/qemu-devel

[-- Attachment #2: Type: text/html, Size: 2909 bytes --]

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

[Alex Beregszaszi]

Hi,

> 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).

-- 
Alex Beregszaszi 			e-mail: alex@fsn.hu
Free Software Network			cell: +36 70 3144424

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

[Fabrice Bellard]

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.

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

[use.reply-to.address]

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

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

[Struan Bartlett]

Fabrice Bellard wrote:

> Alex Beregszaszi wrote:
>
>>> Struan Bartlett 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".
>
> 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.

Thanks Fabrice for Qemu and for your input to this question. What you 
describe sounds like the sort of thing I was imagining. Are you 
suggesting your next version of kqemu will provide the "specific virtual 
CPU support" needed to do this? If so, please keep us posted.

> 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.

Or, do you think, as James Mastros suggested, the corresponding SDL 
operations in non-full-screen mode?

Struan

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

[Hetz Ben Hamo]

> 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.

Anyone thought about using XFree's Xv extension? last time I heard, it
works with all the cards, supported well under XFree, and I think it
will be better working rather with DGA..

At least with my experience with regarding Video players, Xv was much
better than DGA.

Thanks,
Hetz

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

[Leonardo E. Reiter]

Just a couple of quick thoughts:

1. we too have discovered that the VGA routines are a huge bottleneck, 
even if KQEMU is used.  As Fabrice points out, this is clearly because 
there is virtually no blitting optimization going on, along with the 
memory copies, etc.

2. I think any solution has to be broad enough to be portable to other 
architectures, such as Solaris, or Linux on other platforms.  It would 
be nice to have it conditionally compile optimizations that only work on 
Linux, or only with KQEMU, or only with XFree86, etc.  But it would also 
be great if some basic optimization could be done on the pixel 
translation routines that would be portable to any platform/X server 
combination.

3. I think a really simple optimization may be to inline the glue 
functions in vga_template.h, cirrus_vga_rop.h, and cirrus_vga_rop2.h, 
which is very trivial.  We tried that a while back and it did improve 
performance a bit - for instance, it shaved 1.5 seconds off the boot 
time of a Windows 2000 session.  Windows 2000 likes to display heavy 
graphics, like marquees, etc., while booting in its status dialog boxes, 
which is why the improvement was there I think.  Maybe Fabrice or 
someone else can comment as to the possible consequences, other than the 
obvious code size increase of using inline functions (which is not much 
in this case) of inlining those functions.  We didn't notice anything 
adverse, but perhaps we weren't looking closely enough :)  We will keep 
testing over here, and if all goes well, post a patch that does this 
simple optimization.  That is, unless anyone can chime in with a good 
reason not to do this of course.

4. optimizations which require SDL should be conditionally configured in 
case SDL is not used.  For example, in the future there may be GTK-based 
GUIs, etc.  I think there is enough basic optimization that can be done 
in the VGA routines themselves to gain good performance even without 
SDL-specific hacks.  Of course SDL-specific hacks can (and probably 
should) still be used if SDL is configured in, since this is the default 
way to run QEMU.

My $0.02,

Leo Reiter

Hetz Ben Hamo wrote:
> Anyone thought about using XFree's Xv extension? last time I heard, it
> works with all the cards, supported well under XFree, and I think it
> will be better working rather with DGA..
> 
> At least with my experience with regarding Video players, Xv was much
> better than DGA.
> 
> Thanks,
> Hetz
> 

-- 
Leonardo E. Reiter
Vice President of Engineering

Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com

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

[Leonardo E. Reiter]

Well the proof is in the pudding as they say.  Running the display 
adapter benchmark with the Fresh Diagnose program under Windows 2000, 
inlining the glue functions actually slows some things down a slight 
bit, while improving others by a small margin.  Overall there is no 
measurable performance gain when the glue functions are inlined.  So I 
suppose there is no sense in doing that.

Processors these days are so smart, that perhaps the inlining actually 
causes cache optimization problems in some cases and has a negative 
(instead of the expected positive) performance effect.

- Leo Reiter

Leonardo E. Reiter wrote:
> 3. I think a really simple optimization may be to inline the glue 
> functions in vga_template.h, cirrus_vga_rop.h, and cirrus_vga_rop2.h, 
> which is very trivial.  We tried that a while back and it did improve 
> performance a bit - for instance, it shaved 1.5 seconds off the boot 
> time of a Windows 2000 session.  Windows 2000 likes to display heavy 
> graphics, like marquees, etc., while booting in its status dialog boxes, 
> which is why the improvement was there I think.  Maybe Fabrice or 
> someone else can comment as to the possible consequences, other than the 
> obvious code size increase of using inline functions (which is not much 
> in this case) of inlining those functions.  We didn't notice anything 
> adverse, but perhaps we weren't looking closely enough :)  We will keep 
> testing over here, and if all goes well, post a patch that does this 
> simple optimization.  That is, unless anyone can chime in with a good 
> reason not to do this of course.
-- 
Leonardo E. Reiter
Vice President of Engineering

Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com

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

[Jim C. Brown]

On Mon, Apr 11, 2005 at 04:07:44PM +0200, Struan Bartlett 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?
> 

This is doable, however I personally think that it is better to keep this all
userspace. Even for fast 3d graphics, you dnt have to use kernel mechanisms,
you could get away with using a custom videocard (or careful emulation of an
existing 3d card) and mapping it to, say, OpenGL calls. Most optimizations
can be done in userspace.

There was a patch sent a while back (the pci-proxy patch) that in theory would
allow qemu guest to use a host PCI video card (such as a PCI Voodoo3 card). This
was never actually tested, and I don't remeber if this patch has been updated
to work against the current version of qemu.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

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

[Thomas Steffen]

On 4/13/05, Hetz Ben Hamo <hetzbh@gmail.com> wrote:

> Anyone thought about using XFree's Xv extension? last time I heard, it
> works with all the cards, supported well under XFree, and I think it
> will be better working rather with DGA..

Xv has its denefits, but I am not sure that it is the right tool for
the job here. Xv does hardware colorspace expansion, from the color
compression usually done in JPEG/MPEG to the RGB. This is the main
reason that it works better for video, but obviously we don't need
this (unless we want to play videos inside of QEMU).

And most graphics cards support only one Xv area, which is treated as
an overlay. That would be a serious restriction, because you could not
use Xine and QEMU together on one screen.

So I would think that DGA is the way to go first.

Thomas

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

[Struan Bartlett]

[-- Attachment #1: Type: text/plain, Size: 2732 bytes --]

For your information, I received a response from Diego to my query about 
the status of the source code of his driver.

Unfortunately he has had a hard drive crash, and with the crash, lost 
the source.  He reported that the drivers were delevoped after the 
sample driver for the ET4000 chip, with minor changes made to make it 
work with bochs, like the bank switching and VGA screen mode.  His 
BXVGA.DLL was develop after the VGA.DLL sample that came with the 
Windows NT developer kit.  He said he is trying to remake the source 
from a version of the ET4000 source that he found but that will be when 
he gets some time, because it takes a long time just to boot and debug 
bochs VGA drivers.  I hope this is helpful.

In the meantime, Filip Navarra's driver is apparently the only 
open-source Windows 32-bit video driver available.

Struan Bartlett wrote:

> I agree with both views: Qemu should provide the Cirrus emulation 
> option for those who need full emulation, and if we manage to emulate 
> a "custom" driver model, that would be an option for those who need speed.
>
> This has come up before, and it will come up again. Apparently, we 
> don't know whether Diego's BochsVGA source is open. However we do know 
> Filip Navarra's is (and I've posted what I have on 
> http://www.praguespringpeople.org/Struan/Software/QEMU/Drivers/ for 
> the interested).
>
> Struan
>
> Paul Brook wrote:
>
>>On Monday 11 April 2005 16:01, James Mastros wrote:
>>  
>>
>>>After that, I think the best thing to do is to move from emulating a
>>>standard video card to defining our own that maps from the operations
>>>that the OS calls its video driver on to the operations that SDL
>>>implements, leaving any that do not map simply for the OS to emulate, on
>>>the theory that it probably knows how to better then we do.  However,
>>>this is a much larger undertaking, as it requires learning the driver
>>>model of the guest OSes.
>>>    
>>>
>>
>>I agree that emulating a "custom" driver model should give better performance 
>>than emulating real hardware (VMware does this). However I think you should 
>>provide all the functionality you possibly can, even if the host doesn't 
>>provide native acceleration for it. It's always going to be faster to do 
>>something in software on the host than it is on the guest.
>>
>>Paul
>>
>>
>>_______________________________________________
>>Qemu-devel mailing list
>>Qemu-devel@nongnu.org
>>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>>  
>>
>------------------------------------------------------------------------
>
>_______________________________________________
>Qemu-devel mailing list
>Qemu-devel@nongnu.org
>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>  
>

[-- Attachment #2: Type: text/html, Size: 3753 bytes --]

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

[Oliver Gerlich]

Thomas Steffen schrieb:
> On 4/13/05, Hetz Ben Hamo <hetzbh@gmail.com> wrote:
> 
> 
>>Anyone thought about using XFree's Xv extension? last time I heard, it
>>works with all the cards, supported well under XFree, and I think it
>>will be better working rather with DGA..
> 
> 
> Xv has its denefits, but I am not sure that it is the right tool for
> the job here. Xv does hardware colorspace expansion, from the color
> compression usually done in JPEG/MPEG to the RGB. This is the main
> reason that it works better for video, but obviously we don't need
> this (unless we want to play videos inside of QEMU).
> 
> And most graphics cards support only one Xv area, which is treated as
> an overlay. That would be a serious restriction, because you could not
> use Xine and QEMU together on one screen.
> 
> So I would think that DGA is the way to go first.
>
> Thomas
>

Please no DGA :)

This is one of the reasons why I don't use VMWare - it needs DGA for
fullscreen mode, and my %&§&% ATI 9200 with this &§$/$%&/% fglrx driver
doesn't like DGA (yes, ok, ATI does make progress: at least dga doesn't
now crash the whole system with the current drivers...)

So I hope that qemu won't use DGA for faster graphics - I think
optimizing the current driver and maybe adding some host-OpenGL support
would be quite an improvement. Besides, such changes would also improve
Qemu on MacOS or Windows, not only on Linux.

Oliver

> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 
> 

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

[emuls]

Hello,

DGA as a option will be OK, in BOCHS you can choose what you use
for Video background driver.

I use a DGA and VMware a lot. I use on all my computers ATI cards
for long time without not problems.

DGA problem on ATI is not related only to ATI drivers, but also
to card producers and MB AGP drivers. ATI as Nvidia give chips to
third side producers and they overtune chips.

You are also forget then VMware use its special driver inside
GUEST OS, for many of us is important to use some sort of native
GUEST OS driver. Othervise we cant use as a Guest OS systems like
Solaris and so on.

Rudolf 

  

----- PŮVODNÍ ZPRÁVA -----
Od: "Oliver Gerlich" <olig9@gmx.de>
Komu: "Thomas Steffen"
<steffen.list.account@gmail.com>,qemu-devel@nongnu.org Předmět:
Re: [Qemu-devel] qvm86, kqemu and video speed
Datum: 18.4.2005 - 9:43:15

> Thomas Steffen schrieb:
> > On 4/13/05, Hetz Ben Hamo <hetzbh@gmail.com> wrote:
> > 
> > 
> >>Anyone thought about using XFree's Xv extension? last
> >>time I heard, it
> >>works with all the cards, supported well under XFree,
> >>and I think it
> >>will be better working rather with DGA..
> > 
> > 
> > Xv has its denefits, but I am not sure that it is the
> > right tool for
> > the job here. Xv does hardware colorspace expansion,
> > from the color
> > compression usually done in JPEG/MPEG to the RGB.
> > This is the main
> > reason that it works better for video, but obviously
> > we don't need
> > this (unless we want to play videos inside of QEMU).
> > 
> > And most graphics cards support only one Xv area,
> > which is treated as
> > an overlay. That would be a serious restriction,
> > because you could not
> > use Xine and QEMU together on one screen.
> > 
> > So I would think that DGA is the way to go first.
> >
> > Thomas
> >
> 
> Please no DGA :)
> 
> This is one of the reasons why I don't use VMWare - it
> needs DGA for
> fullscreen mode, and my %&§&% ATI 9200 with this
> &§$/$%&/% fglrx driver
> doesn't like DGA (yes, ok, ATI does make progress: at
> least dga doesn't
> now crash the whole system with the current drivers...)
> 
> So I hope that qemu won't use DGA for faster graphics -
> I think
> optimizing the current driver and maybe adding some
> host-OpenGL support
> would be quite an improvement. Besides, such changes
> would also improve
> Qemu on MacOS or Windows, not only on Linux.
> 
> Oliver
> 
> > 
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
> > 
> > 
> 
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 


-- 
Zkoušejte vysokorychlostní nonstop internet VOLNÝ ADSL 14 dní
ZDARMA! Již déle neváhejte! Prvních 500 zákazníků navíc získá
tričko.
Více informací na http://adsl.volny.cz/adsl-na-zkousku/