qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Leonardo E. Reiter" <lreiter@win4lin.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] qvm86, kqemu and video speed
Date: Wed, 13 Apr 2005 15:24:21 -0400	[thread overview]
Message-ID: <425D71E5.3050807@win4lin.com> (raw)
In-Reply-To: <41e41e7a0504131112678e6f08@mail.gmail.com>

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

  reply	other threads:[~2005-04-13 19:03 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
2005-04-13 18:12     ` Hetz Ben Hamo
2005-04-13 19:24       ` Leonardo E. Reiter [this message]
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=425D71E5.3050807@win4lin.com \
    --to=lreiter@win4lin.com \
    --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).