qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Struan Bartlett <struan@praguespringpeople.org>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] qvm86, kqemu and video speed
Date: Mon, 11 Apr 2005 17:35:08 +0200	[thread overview]
Message-ID: <425A992C.4080208@praguespringpeople.org> (raw)
In-Reply-To: <200504111617.29191.paul@codesourcery.com>

[-- 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 --]

  reply	other threads:[~2005-04-11 15:12 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 [this message]
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
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=425A992C.4080208@praguespringpeople.org \
    --to=struan@praguespringpeople.org \
    --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).