Re: [Qemu-devel] Re: qemu-system-sparc video problem on 16 bitdisplays

Re: [Qemu-devel] Re: qemu-system-sparc video problem on 16 bitdisplays

[Blue Swirl]

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

>It must be hanging while probing for sound modules, try adding 'blacklist
>snd-sun-cs4231' to /etc/modules.d/blacklist

This patch should fix hanging, unless some program waits until playback is 
finished.

Implementing full audio support for CS4231 would not be too difficult. Is 
this chip used anywhere else? The data sheet mentions some ISA card and 
Windows 3.1.

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

[-- Attachment #2: cs4231.diff.bz2 --]
[-- Type: application/octet-stream, Size: 2620 bytes --]

Re: [Qemu-devel] Re: qemu-system-sparc video problem on 16 bitdisplays

[Stuart Brady]

On Fri, Sep 08, 2006 at 09:26:52PM +0200, Blue Swirl wrote:
> Implementing full audio support for CS4231 would not be too difficult. Is 
> this chip used anywhere else? The data sheet mentions some ISA card and 
> Windows 3.1.

The "Windows Sound System" cards apparently used it.
-- 
Stuart Brady

[Qemu-devel] ARM CPU Speed simulated by Qemu?

[Tieu Ma Dau]

Hi all, 
I found that Qemu ARM system simulates ARM926EJ-S and
ARM1026EJ-S processor. And I found on ARM website that
the speed of these CPUs vary from 266 to 540 MHz.
Could you tell me the exact speed of the ARM926EJ-S
and ARM1026EJ-S processor simulated by Qemu? It's very
important for me to finish my report.
Thanks and best regards,
Tieu

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Qemu-devel] ARM CPU Speed simulated by Qemu?

[nyos]

Tieu Ma Dau wrote:
> Hi all, 
> I found that Qemu ARM system simulates ARM926EJ-S and
> ARM1026EJ-S processor. And I found on ARM website that
> the speed of these CPUs vary from 266 to 540 MHz.
> Could you tell me the exact speed of the ARM926EJ-S
> and ARM1026EJ-S processor simulated by Qemu? It's very
> important for me to finish my report.
> Thanks and best regards,
> Tieu
Hi,

You can guess cpu speed by running some benchmarks, but it's impossible 
to tell exactly.
Qemu translates arm blocks into host cpu instructions dynamically at 
run-time, and executes them. So, the processor doesn't run the same 
instructions, only the instructions whose effect is the same on the 
other architecture.

Nyos

Re: [Qemu-devel] ARM CPU Speed simulated by Qemu?

[Paul Brook]

On Tuesday 12 September 2006 08:20, Tieu Ma Dau wrote:
> Hi all,
> I found that Qemu ARM system simulates ARM926EJ-S and
> ARM1026EJ-S processor. And I found on ARM website that
> the speed of these CPUs vary from 266 to 540 MHz.
> Could you tell me the exact speed of the ARM926EJ-S
> and ARM1026EJ-S processor simulated by Qemu? It's very
> important for me to finish my report.

Qemu is not cycle accurate. There is no particularly meaningful way to 
translate between qemu performance and how fast something will run on real 
hardware.

Modern CPUs are complicated, with many factors effecting execution speed 
(pipeline interlocks, multiple levels of cache). A cycle accurate simulator 
will generally be orders of magnitude slower than qemu.

Paul

Re: [Qemu-devel] ARM CPU Speed simulated by Qemu?

[Markus Schiltknecht]

Paul Brook wrote:
> Modern CPUs are complicated, with many factors effecting execution speed 
> (pipeline interlocks, multiple levels of cache). A cycle accurate simulator 
> will generally be orders of magnitude slower than qemu.

Would it be feasible to just limit the number of instructions qemu 
simulates? Of course that's not very precise and most probably far from 
cycle accurate. But it would allow to easily scale down a virtual 
machine. Which then would allow comparable benchmarks or such.

One step, somewhat more accurate would be to weight all the different 
assembler commands with known (measured) average execution times. Taking 
into account 40% cache misses, for example. (Hm.. but since cache misses 
are very expensive, that might not lead to a much better approximation, 
I guess)

Any documents or discussion threads related to that topic? Other 
projects trying to achieve that?

Since my benchmarking application is mostly disk- and network-I/O bound, 
thus I'll first try to scale that down, which seems far easier to do 
(much less performance penalty for that).

Regards

Markus

Re: [Qemu-devel] ARM CPU Speed simulated by Qemu?

[Paul Brook]

On Tuesday 12 September 2006 14:19, Markus Schiltknecht wrote:
> Paul Brook wrote:
> > Modern CPUs are complicated, with many factors effecting execution speed
> > (pipeline interlocks, multiple levels of cache). A cycle accurate
> > simulator will generally be orders of magnitude slower than qemu.
>
> Would it be feasible to just limit the number of instructions qemu
> simulates? Of course that's not very precise and most probably far from
> cycle accurate. But it would allow to easily scale down a virtual
> machine. Which then would allow comparable benchmarks or such.
>
> One step, somewhat more accurate would be to weight all the different
> assembler commands with known (measured) average execution times. Taking
> into account 40% cache misses, for example. (Hm.. but since cache misses
> are very expensive, that might not lead to a much better approximation,
> I guess)

I'd be surprised if you managed to get any sort of reliable results.
Most of what you described can be achieved with profiling and static analysis.

You could maybe get order-of-magnitude estimates (ie. do you need a 20MHz cpu 
or a 2GHz cpu), but I certainly wouldn't trust the results for deciding 
between eg. 500MHz and 200MHz cores.

IMHO a benchmarking setup that doesn't reliably correspond to real system 
performance is worse than useless.

Paul

Re: [Qemu-devel] ARM CPU Speed simulated by Qemu?

[Markus Schiltknecht]

Paul Brook wrote:
> IMHO a benchmarking setup that doesn't reliably correspond to real system 
> performance is worse than useless.

Agreed. So let's see what's needed to get a reliably corresponding 
system. I'm interested in three layers: CPU, hard disk and network.

Networking is the simplest, I think. I would need to be able to define 
throughput and latency and be able to simulate network collisions (i.e. 
packet loss percentage).

Emulating a hard disk is already more complicated. One could likewise 
define throughput and latency (= avg. seek time). But in most cases that 
would not be sufficient, because depending on the head position, seek 
time may vary wildly. Thus more like a rotation speed and head position 
emulation is necessary. Most disks today also have different zones with 
varying data density (more sectors on the outer tracks). And last but 
not least, there are caches in most drives...

Now, CPUs is where I have only a vague idea of what would be needed to 
simulate. I know there are up to three levels of caches and main memory, 
which all have different access times. The CPU itself has a pipeline and 
branch prediction and such which could invalidate the contents of 
pipeline up to a given point (of branching).

I think the most time consuming operation which should be properly 
simulated is memory access. For this to work properly, all levels of 
caches must be emulated, too.

How much do misses on the branch prediction level cost? How much 
pipeline interlocks? I don't think those would be _that_ dramatic. Since 
today's compilers are said to be optimizing quite well...

I agree that implementing all of that would be a significant amount of 
work, already. What else do I miss?

Regards

Markus

Re: [Qemu-devel] ARM CPU Speed simulated by Qemu?

[Paul Brook]

> How much do misses on the branch prediction level cost? How much
> pipeline interlocks? I don't think those would be _that_ dramatic. Since
> today's compilers are said to be optimizing quite well...

It all depends on the code you're running. Certainly branch prediction can 
have a major effect if the hardware consistently gets it wrong. Even arm 
hardware has 5/7 stage pipelines that need flushing on a mispredict.

Pipeline interlocks are likely to be relatively small, for most Arm hardware 
at least (ia64 is a completely different story :-). As a compiler author I'd 
generally expect a few % performance improvement from a good scheduling 
model.

I wouldn't assuming the compiler gets everything right, as it's quite common 
for systems to be built for the lowest common denominator target.

Paul

Re: [Qemu-devel] Re: qemu-system-sparc video problem on 16 bitdisplays

[Blue Swirl]

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

Digging old bugs, I found this problem.

Maybe this patch helps? I can't test it here (can't get display to 16 bit 
somehow).

>On 8/9/06, Anthony Liguori <anthony@codemonkey.ws> wrote:
>>On Thu, 10 Aug 2006 00:32:20 +0200, Juergen Lock wrote:
>>
>> > Hi!
>> >
>> >  I was made aware of this by a FreeBSD user, but i suspect the
>> > problem is not specific to FreeBSD hosts:  If run on a 16 bit display,
>> > qemu-system-sparc' video is messed up like shown here:
>> >       http://img320.imageshack.us/img320/3807/qemusparckd1.png
>> > (pink, and uses only half of the window's width...)  It looks okay on 
>>24
>> > bit displays.
>>
>>Looks you're telling QEMU that you've got a 16 bit buffer when it's really
>>a 32 bit buffer.
>>
>>Perhaps we're mixing up bits-per-pixel with depth?
>>
>>Regards,
>>
>>Anthony Liguori
>>
>> >  Thanx,
>> >       Juergen
>>
>>
>>
>>
>
>Perhaps this in tcx.c?
>
>    switch (ts->ds->depth) {
>    case 32:
>    f = tcx_draw_line32;
>    break;
>    case 24:
>    f = tcx_draw_line24;
>    break;
>    default:
>    case 8:
>    f = tcx_draw_line8;
>    break;
>    case 0:
>    return;
>    }

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

[-- Attachment #2: tcx-fix.diff.bz2 --]
[-- Type: application/octet-stream, Size: 481 bytes --]

Re: [Qemu-devel] Re: qemu-system-sparc video problem on 16 bitdisplays

[WaxDragon]

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

On 9/6/06, Blue Swirl <blueswir1@hotmail.com> wrote:
> Digging old bugs, I found this problem.
>
> Maybe this patch helps? I can't test it here (can't get display to 16 bit
> somehow).
>

Seems like it works, booting aurora-2.0-sparc-disc1.iso gives me the
penguin at least.  Then it hangs and burns CPU as usual.

WD

-- 
22:38 <@WaxDragon> false ^ true
22:39 < false> :(
22:39 < false> dont you think you can XOR me and get away with it! I
always return!

[-- Attachment #2: aurora.png --]
[-- Type: image/png, Size: 9783 bytes --]

Re: [Qemu-devel] Re: qemu-system-sparc video problem on 16 bitdisplays

[Blue Swirl]

>Seems like it works, booting aurora-2.0-sparc-disc1.iso gives me the
>penguin at least.  Then it hangs and burns CPU as usual.

So early? I get to 'Running anaconda..' etc. Before AIO, install almost 
finished.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: [Qemu-devel] Re: qemu-system-sparc video problem on 16 bitdisplays

[Igor Kovalenko]

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

On 9/6/06, Blue Swirl <blueswir1@hotmail.com> wrote:
>
> >Seems like it works, booting aurora-2.0-sparc-disc1.iso gives me the
> >penguin at least.  Then it hangs and burns CPU as usual.
>
> So early? I get to 'Running anaconda..' etc. Before AIO, install almost
> finished.


It still cannot decide on console device; linux console=/dev/tty0 works fine


-- 
Kind Regards,
Igor V. Kovalenko

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

Re: [Qemu-devel] Re: qemu-system-sparc video problem on 16 bitdisplays

[Blue Swirl]

>> >Seems like it works, booting aurora-2.0-sparc-disc1.iso gives me the
>> >penguin at least.  Then it hangs and burns CPU as usual.
>>
>>So early? I get to 'Running anaconda..' etc. Before AIO, install almost
>>finished.
>
>
>It still cannot decide on console device; linux console=/dev/tty0 works 
>fine

Now I see, I'm using the current SVN version (82) of OpenBIOS, not Qemu's. 
Console selection works fine in the current version.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: [Qemu-devel] Re: qemu-system-sparc video problem on 16 bitdisplays

[WaxDragon]

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

On 9/6/06, Igor Kovalenko <igor.v.kovalenko@gmail.com> wrote:
>
> On 9/6/06, Blue Swirl <blueswir1@hotmail.com> wrote:
> > >Seems like it works, booting aurora-2.0-sparc-disc1.iso gives me the
> > >penguin at least.  Then it hangs and burns CPU as usual.
> >
> > So early? I get to 'Running anaconda..' etc. Before AIO, install almost
> > finished.
>
>
> It still cannot decide on console device; linux console=/dev/tty0 works fine
>

I found "console=tty0" works a little better, thanks for the hint.

Specifying the console allows aurora to get farther, even starting X.
Mouse doesn't seem to work though. ;0)

Gentoo 2004.0 shows me a mangled penguin, but otherwise boots.

 WD
-- 
22:38 <@WaxDragon> false ^ true
22:39 < false> :(
22:39 < false> dont you think you can XOR me and get away with it! I
always return!

[-- Attachment #2: aurora4.png --]
[-- Type: image/png, Size: 153954 bytes --]

[-- Attachment #3: gentoo2.png --]
[-- Type: image/png, Size: 31964 bytes --]

Re: [Qemu-devel] Re: qemu-system-sparc video problem on 16 bitdisplays

[Blue Swirl]

>Specifying the console allows aurora to get farther, even starting X.
>Mouse doesn't seem to work though. ;0)

Mouse should work with Igor Kovalenko's patch, which I resent some days ago.

But I can't get to X with aurora-2.0, it just hangs much earlier.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: [Qemu-devel] Re: qemu-system-sparc video problem on 16 bitdisplays

[Igor Kovalenko]

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

>
> >Specifying the console allows aurora to get farther, even starting X.
> >Mouse doesn't seem to work though. ;0)
>
> Mouse should work with Igor Kovalenko's patch, which I resent some days
> ago.
>
> But I can't get to X with aurora-2.0, it just hangs much earlier.


It must be hanging while probing for sound modules, try adding 'blacklist
snd-sun-cs4231' to /etc/modules.d/blacklist

-- 
Kind Regards,
Igor V. Kovalenko

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

Re: [Qemu-devel] Re: qemu-system-sparc video problem on 16 bitdisplays

[Juergen Lock]

On Wed, Sep 06, 2006 at 06:59:39PM +0200, Blue Swirl wrote:
> Digging old bugs, I found this problem.
> 
> Maybe this patch helps? I can't test it here (can't get display to 16 bit 
> somehow).
> [...]

Thanx, that seems to fix the 16 bit display problem. (I just had to set
	DefaultDepth 16
in Section "Screen" in xorg.conf to test it...)

 Fabrice, please apply. :)

 thanx + cheers,
	Juergen