[Qemu-devel] What is the bottleneck?

[Qemu-devel] What is the bottleneck?

[Stefan Kombrink]

Hi,

 I'm very impressed by the functionality of qemu at the current state of 
development. It's easier to handle than vmware or win4lin, but still slower.

Running win98 I got the impression that the speed is sometimes limited by 
graphics operations, whichs makes me wonder, because SDL should use the 
hardware acceleration capabilities of the graphics cards.
Will it be possible to speed up graphics simply by improving the driver or are 
memory transfers the bottleneck?

greetings,
  Stefan K. >8^)

Re: [Qemu-devel] What is the bottleneck?

[André Braga]

The bottleneck IS the graphics AFAICT: just try running some Unix-like
OS on console mode, non-framebuffer mode.

I've read on more than one occasion that having better graphics
support is planned, probably emulating a reasonably modern and capable
video card, like the SiS 6326 (IIRC).

If you have some knowledge in that area and is willing to help, you're
more than welcome :)


cheers,


-- 
"A year spent in artificial intelligence is enough to make one believe in God"
Alan J. Perlis



On Wed, 29 Sep 2004 23:03:52 +0200, Stefan Kombrink <katakombi@web.de> wrote:
> Hi,
> 
>  I'm very impressed by the functionality of qemu at the current state of
> development. It's easier to handle than vmware or win4lin, but still slower.
> 
> Running win98 I got the impression that the speed is sometimes limited by
> graphics operations, whichs makes me wonder, because SDL should use the
> hardware acceleration capabilities of the graphics cards.
> Will it be possible to speed up graphics simply by improving the driver or are
> memory transfers the bottleneck?
> 
> greetings,
>   Stefan K. >8^)
>

Re: [Qemu-devel] What is the bottleneck?

[Stefan Kombrink]

On Wednesday 29 September 2004 23:21, André Braga wrote:
> The bottleneck IS the graphics AFAICT: just try running some Unix-like
> OS on console mode, non-framebuffer mode.
>
> I've read on more than one occasion that having better graphics
> support is planned, probably emulating a reasonably modern and capable
> video card, like the SiS 6326 (IIRC).

I had a look at the cirrus rop code, it's not optimized yet, even in CVS.
I think that's the problem.

I don't know the hardware specs of the cirrus, but where's the limit of its 
hardware support?
Is it really necessary to implement a new graphics card?
Area copying and area filling is already possible, although not optimized.

This question might be stupid but why not using 
SDL_FillRect(...) and
SDL_BlitSurface(....).
?

I think SDL accelerates these operations if supported by your driver.

>
> If you have some knowledge in that area and is willing to help, you're
> more than welcome :)

No promises yet....
These lines look diffcult to me >8^)

>
>
> cheers,
 bye
   Stefan K. >8^)

Re: [Qemu-devel] What is the bottleneck?

[André Braga]

On Thu, 30 Sep 2004 19:29:46 +0200, Stefan Kombrink <katakombi@web.de> wrote:
> I had a look at the cirrus rop code, it's not optimized yet, even in CVS.
> I think that's the problem.
> 
> I don't know the hardware specs of the cirrus, but where's the limit of its
> hardware support?
> Is it really necessary to implement a new graphics card?

It's not necessary, but it's desirable if it's done in a "high level"
way, like mapping primitive card instructions to some high-level
acceleration API, like DirectX, OpenGL or Quartz.

> Area copying and area filling is already possible, although not optimized.
> 
> This question might be stupid but why not using
> SDL_FillRect(...) and
> SDL_BlitSurface(....).
> ?
> 
> I think SDL accelerates these operations if supported by your driver.
 
I think it's because at the time nobody bothered to implement those,
and I sincerely don't know how the video emulation is done. I just
observed its effects.

> No promises yet....
> These lines look diffcult to me >8^)

Think of all the good karma you'll get when people start smiling
because of your work to improve QEMU ^_^


cheers,


-- 
"Dealing with failure is easy: Work hard to improve. Success is also
easy to handle: You've solved the wrong problem. Work hard to improve"
Alan J. Perlis

Re: [Qemu-devel] What is the bottleneck?

[Oliver Kopp]

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

On Wed, 2004-09-29 at 23:03, Stefan Kombrink wrote:

Hi,

> I'm very impressed by the functionality of qemu at the current state of 
> development. It's easier to handle than vmware or win4lin, but still slower.

Na endlich sieht man sich auch mal außerhalb der Uni *ggg*

CU

Olly

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]