Qemuonarm

[ldesnogu]

I found the reason why QEMU was spending so much time in the execution loop. The code to link generated blocks had a nice bug which basically resulted in no block linking...

End result: nbench speed on integer code is 3 times what it was. For floating point, it's much less because FP operations are emulated. This means that on integer code on my 400 MHz board I reached the speed of a Pentium@133.

Though that is nice, much has to be done, so don't get overexcited

If someone with a Pandora board could get in touch with me to run tests...

 

[maiden]

his means that on integer code on my 400 MHz board I reached the speed of a Pentium@133.

sounds like starcraft for the pandora is no longer entirely impossible..

 

[calc84maniac]

I found the reason why QEMU was spending so much time in the execution loop. The code to link generated blocks had a nice bug which basically resulted in no block linking...


End result: nbench speed on integer code is 3 times what it was. For floating point, it's much less because FP operations are emulated. This means that on integer code on my 400 MHz board I reached the speed of a Pentium@133.


Though that is nice, much has to be done, so don't get overexcited


If someone with a Pandora board could get in touch with me to run tests...

Hmm, Age of Empires requires Pentium@90. I wonder if that would work if we did some sort of Wine implementation as well... that would be awesome.

 

[ldesnogu]

The problem with going the Wine road is that it would not help running DOS programs.
So either I write two programs, or I open a poll

 

[greendots]

What would the two programs be? Two versions of qemu, one Linux user mode, one as an emulated guest?
I would vote for having a guest OS like freeDos, win 95 or React OS. At least at first. Most older games had a backup software renderer anyway.

Pentium 133 speed x86 emulation is very impressive, many great games will work at that speed

Thanks for working on this.

Edit: is there any way to check that a program is running at full speed and if not, clock the pandora accordingly?

 

[ldesnogu]

What would the two programs be? Two versions of qemu, one Linux user mode, one as an emulated guest?

Yes.

I would vote for having a guest OS like freeDos, win 95 or React OS. At least at first. Most older games had a backup software renderer anyway.

For hardware emulation, the OS wouldn't matter as long as the simulated platform has driver support in the guest OS.

Pentium 133 speed x86 emulation is very impressive, many great games will work at that speed

Don't forget that it's for user mode, which needs neither MMU or hardware simulation. Adding these will cost a lot (I can't give a credible number, but a x2 slowdown is probably a minimum).

Edit: is there any way to check that a program is running at full speed and if not, clock the pandora accordingly?

Unless the program synchronizes with a timer or Vsync and the emulator is doing hardware simulation (that is, it's not QEMU user mode + Wine) it would be difficult to achieve given how different cycle counting is between various Intel chips. I could implement some approximation, but that'd slow down simulation.

 

[notaz]

If someone with a Pandora board could get in touch with me to run tests...

PM me if you wish.

 

[Enverex]

Assuming I'm reading this properly, this is just the qemu-x86 emulator, not qemu-x86-system right? Which means that games still wont work will they? (as only the processor and not the system are being emulated, so those games will need hardware that doesn't exist).

Just wanting to confirm or debunk the "It'll run Starcraft/AoE/Whatever Windows game!" comments.

 

[arrrgh]

133MHZ PENTIUM!? HOLY SHITJeepers creepers! Age Of Empires' recommended specs is a 120MHz CPU and Simcity 2000 should be easily possible with cycles to spare. Thankyou thankyou thankyou thankyou!

Assuming I'm reading this properly, this is just the qemu-x86 emulator, not qemu-x86-system right? Which means that games still wont work will they? (as only the processor and not the system are being emulated, so those games will need hardware that doesn't exist).

Just wanting to confirm or debunk the "It'll run Starcraft/AoE/Whatever Windows game!" comments.

Well, it will probably be coupled with Wine which will provide for all that.
edit: btw Laurent I would vote for Wine. DOSBox is already there for DOS games and it'd be easier to just have Wine instead of fumbling around with ReactOS or whatever.

 

[ldesnogu]

Assuming I'm reading this properly, this is just the qemu-x86 emulator, not qemu-x86-system right? Which means that games still wont work will they? (as only the processor and not the system are being emulated, so those games will need hardware that doesn't exist).

Just wanting to confirm or debunk the "It'll run Starcraft/AoE/Whatever Windows game!" comments.

You're right and I thought it was clear, but it seems it's not, given some of the replies we get

 

[ldesnogu]

Here are nbench results as measured by notaz (waiting for results from Pickle and Cpasjuste to crosscheck):

500Mhz
TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          46.065  :       1.18  :       0.39
STRING SORT         :          2.9255  :       1.31  :       0.20
BITFIELD            :      1.0906e+07  :       1.87  :       0.39
FP EMULATION        :          7.6441  :       3.67  :       0.85
FOURIER             :          244.64  :       0.28  :       0.16
ASSIGNMENT          :         0.84459  :       3.21  :       0.83
IDEA                :          138.29  :       2.12  :       0.63
HUFFMAN             :          62.814  :       1.74  :       0.56
NEURAL NET          :         0.17612  :       0.28  :       0.12
LU DECOMPOSITION    :          6.9756  :       0.36  :       0.26
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 1.994
FLOATING-POINT INDEX: 0.305
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
MEMORY INDEX        : 0.404
INTEGER INDEX       : 0.582
FLOATING-POINT INDEX: 0.169
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38

800Mhz
TEST                : Iterations/sec.  : Old Index   : New Index
                    :                  : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT        :          72.781  :       1.87  :       0.61
STRING SORT         :          4.7207  :       2.11  :       0.33
BITFIELD            :      1.7458e+07  :       2.99  :       0.63
FP EMULATION        :          12.292  :       5.90  :       1.36
FOURIER             :          394.37  :       0.45  :       0.25
ASSIGNMENT          :          1.3571  :       5.16  :       1.34
IDEA                :          221.48  :       3.39  :       1.01
HUFFMAN             :           100.6  :       2.79  :       0.89
NEURAL NET          :         0.27771  :       0.45  :       0.19
LU DECOMPOSITION    :          11.212  :       0.58  :       0.42
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 3.194
FLOATING-POINT INDEX: 0.488
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
MEMORY INDEX        : 0.649
INTEGER INDEX       : 0.930
FLOATING-POINT INDEX: 0.271
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38

 

[arrrgh]

Assuming I'm reading this properly, this is just the qemu-x86 emulator, not qemu-x86-system right? Which means that games still wont work will they? (as only the processor and not the system are being emulated, so those games will need hardware that doesn't exist).

Just wanting to confirm or debunk the "It'll run Starcraft/AoE/Whatever Windows game!" comments.

You're right and I thought it was clear, but it seems it's not, given some of the replies we get

I think we were posting what we would do if this was used with Wine.

 

[greendots]

How is the nbench benchmark to be read... is it a percentage of what a Pent 90 and K6 could do? ie. floating point emulation would be 30.5% that of a pent 90 @ 500MHZ?

Can\has floating point been optimized?

 

[cb88]

How is the nbench benchmark to be read... is it a percentage of what a Pent 90 and K6 could do? ie. floating point emulation would be 30.5% that of a pent 90 @ 500MHZ?

Canhas floating point been optimized?

No it is normalized to a P 90 meaning that the P 90 score for every thing is 1  greater than 1 is faster less than is slower for example a score of .5 would be half as fast as a P 90 
The same goes for the K6/233 normalized results 

This is just a guess on my part but sound in games might be a problem with qemu + wine ... wouldn't they need fast fourier transforms or the like though I guess most games back then wouldn't be using codecs with much compression I wonder if it would run math blaster decent (I need to dig up that disc and try it in wine )

 

[ldesnogu]

cb88 correctly explained how to read the nbench results. And indeed floating-point is an issue at the moment; QEMU doesn't natively handle FP, so it's bound to be slow; it's on my TODO list

As far as Wine goes, it takes its toll on all programs. We did an experiment with a friend on a PC (well he did most of the job): move the OpenGL DLL wrapper to its own thread and desynch it from the rest. This doubled the frame rate for WoW (in areas where you're not CPU bound of course), and this was with very powerful graphics cards that are not a bottleneck to a game like WoW. Too bad OMAP3 isn't dual-core

Again, what this means is that no matter how good the results might look, they are not good enough.

 

[Exophase]

Something to bear in mind is that the reference nbench results were done with a 15 year old Watcom C compiler and a version of GCC at least 10 years old. I don't know what Laurent used to compile the x86 nbench that was used but I'm sure it was with a much more recent version of GCC. How much of a difference this makes I can't really tell you but I'd fully expect the quality of the code produced now to be much better than what was produced then. How much of a difference this would actually make, who knows.

As far as Wine goes, it takes its toll on all programs. We did an experiment with a friend on a PC (well he did most of the job): move the OpenGL DLL wrapper to its own thread and desynch it from the rest. This doubled the frame rate for WoW (in areas where you're not CPU bound of course), and this was with very powerful graphics cards that are not a bottleneck to a game like WoW. Too bad OMAP3 isn't dual-core

Again, what this means is that no matter how good the results might look, they are not good enough.

So that's with OpenGL translation. How many games in the 133MHz PC requirements range are going to require Direct3D or OpenGL? The few 3D accelerated games would probably be using Glide, and would probably be in DOS for that matter.

I don't think you can look at the OpenGL translation overhead in Wine and say that everything is going to be that impacted. An older 3D game will be making tons of calls to the API that have to go through the drivers. A 2D game, on the other hand, will probably only have a few per frame.

 

[dentrado]

How is the nbench benchmark to be read... is it a percentage of what a Pent 90 and K6 could do? ie. floating point emulation would be 30.5% that of a pent 90 @ 500MHZ?

Canhas floating point been optimized?

No it is normalized to a P 90 meaning that the P 90 score for every thing is 1  greater than 1 is faster less than is slower for example a score of .5 would be half as fast as a P 90 
The same goes for the K6/233 normalized results 

I think that's exactly what greendots mean:
FLOATING-POINT INDEX: 0.305 == 30.5%

 

[greendots]

Yes same result, different ways to look at it

It sounds like any 3D game is going to have so much overhead it will be too slow to run.
game -> qemu -> wine -> opengl to es wrapper

Doesn't the sgx530 support directX 9? Was the GPU driver the one that craigix has the sourcecode to but few could look at it and must sign nda to look at and alter?
The opensource driver would help this project a lot.

 

[mcobit]

Doesn't the sgx530 support directX 9? Was the GPU driver the one that craigix has the sourcecode to but few could look at it and must sign nda to look at and alter?
The opensource driver would help this project a lot.

I think it supports the features of Direct3d but the problem is, that you need to install the d3d driver in windows, that is running on qemu or in wine, that's running on linux, thats running on qemu AND qemu has to translate the d3d code to ogl-code, that is wrapped into ogles-code.

Sounds pretty complicated and slow to me.

 

[ldesnogu]

Something to bear in mind is that the reference nbench results were done with a 15 year old Watcom C compiler and a version of GCC at least 10 years old. I don't know what Laurent used to compile the x86 nbench that was used but I'm sure it was with a much more recent version of GCC. How much of a difference this makes I can't really tell you but I'd fully expect the quality of the code produced now to be much better than what was produced then. How much of a difference this would actually make, who knows.

I took the oldest compiler I could put my hands on: gcc 2.96. The previous results that were posted are using gcc 4.1.2.
Results on my machine:

nbench gcc 4.1.2
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 1.866
FLOATING-POINT INDEX: 0.262
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
MEMORY INDEX        : 0.380
INTEGER INDEX       : 0.543
FLOATING-POINT INDEX: 0.145
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38


nbench gcc 2.96
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX       : 1.267
FLOATING-POINT INDEX: 0.257
Baseline (MSDOS*)   : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
MEMORY INDEX        : 0.270
INTEGER INDEX       : 0.356
FLOATING-POINT INDEX: 0.143
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38

nbench results I found that use 2.96

Pentium MMX (Tillamook) Ampro LittleBoard P5x   266 MHz	512 KB	Linux-2.4.7-10	gcc 2.96 glibc-2.2.4-13  0.743 0.818 1.381
Pentium 233MMX(Tillamook) Ampro LittleBoard P5e 233 MHz	256 KB	Linux-2.2.16-22	gcc 2.96 glibc-2.1.92-14 0.633 0.698 1.128

I'd much prefer to use real programs rather than nbench. But that'd be stupid: adding complexity should only be done once I'm happy with my improvements. You'll note I've been careful not to raise people expectations, but I probably wasn't enough by giving some equivalence against real Intel scores, so I'll stop doing that.

So that's with OpenGL translation. How many games in the 133MHz PC requirements range are going to require Direct3D or OpenGL? The few 3D accelerated games would probably be using Glide, and would probably be in DOS for that matter.

I don't think you can look at the OpenGL translation overhead in Wine and say that everything is going to be that impacted. An older 3D game will be making tons of calls to the API that have to go through the drivers. A 2D game, on the other hand, will probably only have a few per frame.

You're stating the obvious. Is that to make it clear to others, or do you think I'm utterly stupid (which I am sometimes)?
My point was just to show that Wine cost isn't necessarily small. And the OpenGL example isn't that stupid: the layer is extremely thin when compared to some others Windows libraries, since you basically get a one-to-one mapping of the API (although of course OpenGL has its own cost moving data around which might be a problem for OpenGL, but in that case, it was not thanks to the use of VBO).

Anyway as I wrote above: I'll see how bad things are once I'm happy with QEMU generated code.