All of lore.kernel.org
 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: Wed, 13 Apr 2005 10:06:08 +0200	[thread overview]
Message-ID: <425CD2F0.2030400@praguespringpeople.org> (raw)
In-Reply-To: <425C21E8.6090306@bellard.org>

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

  parent reply	other threads:[~2005-04-13  8:15 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
2005-04-13  8:06     ` Struan Bartlett [this message]
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=425CD2F0.2030400@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 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.