Wiz Impressions, Temper Performance Numbers On Wiz


Exophase

Nothing good will ever come of Exophase.
Joined
Sep 21, 2006
Messages
10,307
Age
41
Location
Cleveland OH
I got a Wiz a little while ago and finally made myself get Temper running on it. No sound yet and probably missing a few other things. First, here are the numbers vs GP2X:

GP2X at 200MHz, default RAM timings:
benchmark took 2821 ms (9.403333 ms per frame)

GP2X at 270MHz, fast RAM timings:
benchmark took 1943 ms (6.476667 ms per frame)

Wiz at 533MHz, default RAM timings, whatever they are:
benchmark took 2471 ms (8.236667 ms per frame)

This was for Bonk's Revenge in the first level shown in the attract mode. Wiz does a decent amount better than the GP2X at 200MHz with default RAM timings, but much worse than the GP2X at 270MHz with fast RAM timings.

This is with no sound being output on the Wiz (but still being computed). Everything is otherwise done like it is on the GP2X - screen layers are being written to directly with quad buffering. If there's a hidden performance penalty (like why we need mmuhack on the GP2X) then I don't know of it yet.

UPDATE:

mmuhack helps a lot. I don't have very concrete numbers - for some reason they're kind of floating a lot (might be something to do with audio being in now, might try without). It seems to be about the same as the 270MHz GP2X like this; I'll do more tests later.

I've also been able to overclock my Wiz up to 850MHz, although it's not perfectly stable at this and I think it might be disrupting UART output (not sure on this one, I still get at least some things out, but it could be due to delays). I'll include some tests with that too when I work out the cause of the fluctuations.

Other things about the Wiz:

EDIT: Originally I wrote here that I found the controls basically unplayable. That seemed true at the time, but I think I was being too hard on it. I was testing with the game in question running at 2x speed, and although I did feel like I was accounting for this at the time I have spent a good amount of time playing it at the correct speed and I have gotten used to it a large amount.

The controls aren't perfect, or anywhere close. Main problem is they're too small and the unit is too rectangular. I have very small hands but even then it's hard to comfortably grip the Wiz and my thumbs are a bit scrunched against the dpad/buttons. Some people seem to prefer to hold handhelds with their fingertips, if you fall under this category you probably won't mind the Wiz. If you like to firmly wrap your hands around it like you would a typical game controller then it might be a little uncomfortable, at least at first. The dpad is a huge improvement over the stick on the F100 GP2X (can't comment on the F200, didn't have one). The small "d-buttons" on the right side make it kind of easy to hit the wrong one, but you get used to it. Actually, after a while I found myself accidentally hitting the select button accidentally more. I mapped this to "run" (start in say, NES) because it's on the right side, but you might want to keep it as select in emulators.

- Screen has perfect viewing angles, like everyone says, and is very bright, etc. It doesn't seem like it'd be too small in the long term.

- Break out board is nicely done and has a bunch of stuff on it.

- The kernel right now is riddled with debug messages that are annoying when you have a shell going over it.

- The USB OTG drivers seem utterly broken and so the only way to get a shell on the thing is via serial (need the BoB), and the only way to get files on the thing is via swapping an SD out or via serial transfer (VERY slow, and I hear the UARTs are capped at 115200 in the kernel, so forget about using fast USB to serial adapters to get 1mbit/sec transfers). Swapping the SD out over and over gets old, especially when the auto unmount causes the Wiz to crash when you're currently in the directory (so get out of the directory)

- As everyone already knows, there's a bug somewhere in 320x240 mode causing a kind of diagonal tearing. It's pretty obvious when the screen is scrolling quickly but you can probably live with it.

I'm going to look into the RAM timings and see if they can be boosted. From what I hear, the i2s (audio) timing is tied to the CPU clock, so overclocking might not be a good way to go. I'd like to look into an mmuhack sort of thing, but unfortunately GPH doesn't want to give us the version of the kernel source that's on the Wiz's they distributed, so we can't build kernel modules against it. Oh well.
 
Your timings are interesting because they reflect exactly what we discovered with the mmsp2+ (the predecessor to the pollox) ie. the GP2X was faster when overclocked.

It's mysterious indeed, some RAM hacking on the Wiz might bring interesting results, but I just don't think MES were designing the pollux or mmsp2+ for speed, more for media playback and GPS applications, thus it makes a strange handheld.
 
Some or all of these numbers could be wrong, but I think they should at least be in the right neighborhood.

GP2X with default RAM timings: Cache miss is 40 cycles.
GP2X with fast RAM timings: Cache miss is 38 cycles.
Wiz with default RAM timings: Cache miss is 72 cycles.

This actually isn't as bad as it sounds - we all knew from day one that Wiz would have much worse memory performance clock for clock.

I tried pushing the RAM timings further - I'm sure I shaved a clock cycle off at one point but I couldn't reproduce it. But it's pretty easy to make Linux crash quickly here, so I don't think there's a ton of headroom.

I did some tests to write to the framebuffer on GP2X and Wiz. As many may recall, on GP2X the framebuffer regions by default are mapped from /dev/mem with write buffering (and caching) turned off when you ask for them. To get around this we used mmuhack. So I looked at Wiz too, and this is what I got:

GP2X: write to stack (write buffering should be on): 1 cycle
Wiz: write to stack (write buffering should be on): 1 cycle
GP2X: write to framebuffer region w/o mmuhack: 10 cycles
Wiz: write to framebuffer region: 15 cycles

Meaning that it's entirely possible that we need a new mmuhack. In fact, with the degraded memory performance per cycle we would need it even more now (unless my numbers are wrong).

Unfortunately we can't make kernel modules right now. At least when Wiz is out GPH will be required to release the source. Or we can try to hack the kernel through physical memory again... I would really not enjoy doing this.
 
Exophase said:
GP2X with default RAM timings: Cache miss is 40 cycles.
GP2X with fast RAM timings: Cache miss is 38 cycles.
Wiz with default RAM timings: Cache miss is 72 cycles.
Just out of interest, what kind of test you performed to get these numbers? I guess they also depend on CPU clock rate?
 
Last edited by a moderator:
notaz said:
Exophase said:
GP2X with default RAM timings: Cache miss is 40 cycles.
GP2X with fast RAM timings: Cache miss is 38 cycles.
Wiz with default RAM timings: Cache miss is 72 cycles.
Just out of interest, what kind of test you performed to get these numbers? I guess they also depend on CPU clock rate?


The test I did was to allocate a 64KB buffer on the stack then find a 32KB one within it that's 32KB aligned. Then I have a loop in ASM which goes through that 32KB buffer circularly and does a load every 32 bytes (beginning of every cache line). I do this for 16 * 1024 * 1024 iterations, and I calculate the difference in microseconds before and after the test is ran. This is then multiplied by a cycle number (fixed at 200 for GP2X and 533 for Wiz, which is what they are running at.. at least roughly) and divided by the iteration number to get the number of cycles per loop. I take out 6 for the number of overhead in the loop, although if critical word first loading is employed it's possible that these are being shadowed for cache misses. I verified 6 cycles with a control loop that was over 16KB (result was 7 cycles per iteration).
 
Last edited by a moderator:
Only some comments:
- I find the controls ok, a lot better than the GP2X ones.
- In my latest compilation MAME in the Wiz (at 533 MHz) is running faster than in the GP2X (at 250 MHz) (depending on the game, 50%-100% faster noticeable).
 
Franxis said:
Only some comments:
- I find the controls ok, a lot better than the GP2X ones.
- In my latest compilation MAME in the Wiz (at 533 MHz) is running faster than in the GP2X (at 250 MHz) (depending on the game, 50%-100% faster).
Any chance of some videos Franxis, maybe Mortal Kombat?
 
Last edited by a moderator:
Franxis said:
In my latest compilation MAME in the Wiz (at 533 MHz) is running faster than in the GP2X (at 250 MHz) (depending on the game, 50%-100% faster).
So what is the difference exactly between a Wiz running at 533 mhz, and a GP2X running at 250mhz, apart from one being about twice as fast as the other?

I'd have been very worried indeed if the Wiz had not gained at least 50% improvement :)

D.
 
Last edited by a moderator:
Dunny said:
Franxis said:
In my latest compilation MAME in the Wiz (at 533 MHz) is running faster than in the GP2X (at 250 MHz) (depending on the game, 50%-100% faster).
So what is the difference exactly between a Wiz running at 533 mhz, and a GP2X running at 250mhz, apart from one being about twice as fast as the other?

I'd have been very worried indeed if the Wiz had not gained at least 50% improvement :)

D.


I get the feeling like you read his post and didn't read the ones I made in this thread. If you're expecting such performance increases across the board on Wiz then maybe you should be at least a little worried, because it's certainly not 2x faster for what I've ported, and I know this goes for what various other people have done too. The CPU might be in raw integer processing but the memory subsystem is a big bottleneck and with the small amount of cache on both machines this plays a huge factor.

Wiz's memory is hurt not just by being only 16bit on a 133MHz bus, but also because it has a tiny burst length of 2. On a PC it's typical for a single DDR burst read to fill a cacheline, but on Wiz you need 8 of them.

I'm a little skeptical of anyone claiming 100% improvement over a 250MHz GP2X given that the GP2X probably has faster memory timings than the Wiz at that point, to have such an improvement the program would have to be running almost entirely out of cache, proportionately speaking, and the framebuffer penalties I mentioned must somehow not be coming into play (maybe the GP2X version isn't mmuhacked), or the playing field isn't totally level somehow, like some optimization on one that isn't on the other.
 
Last edited by a moderator:
craigix said:
Any chance of some videos Franxis, maybe Mortal Kombat?
I expected better results, anyway here they are:

Mortal Kombat:
GP2X: 250 MHz, mmuhack+ramtweaks, 16 bit color, frameskip 0, 23 fps
WIZ: 533 MHz, none+none, 16 bit color, frameskip 0, 30 fps
WIZ: 650 MHz, none+none, 16 bit color, frameskip 0, 36 fps

Knights of the Round:
GP2X: 250 MHz, mmuhack+ramtweaks, 8 bit color, frameskip 0, 46 fps
WIZ: 533 MHz, none+none, 8 bit color, frameskip 0, 55 fps
WIZ: 650 MHz, none+none, 8 bit color, frameskip 0, 66 fps

Hammerin' Harry:
GP2X: 250 MHz, mmuhack+ramtweaks, 8 bit color, frameskip 0, 35 fps
WIZ: 533 MHz, none+none, 8 bit color, frameskip 0, 35 fps
WIZ: 650 MHz, none+none, 8 bit color, frameskip 0, 35 fps

They are not good :( .
 
Last edited by a moderator:
Franxis said:
craigix said:
Any chance of some videos Franxis, maybe Mortal Kombat?
I expected better results, anyway here they are:

Mortal Kombat:
GP2X: 250 MHz, mmuhack+ramtweaks, 16 bit color, frameskip 0, 23 fps
WIZ: 533 MHz, none+none, 16 bit color, frameskip 0, 30 fps
WIZ: 650 MHz, none+none, 16 bit color, frameskip 0, 36 fps

Knights of the Round:
GP2X: 250 MHz, mmuhack+ramtweaks, 8 bit color, frameskip 0, 46 fps
WIZ: 533 MHz, none+none, 8 bit color, frameskip 0, 55 fps
WIZ: 650 MHz, none+none, 8 bit color, frameskip 0, 66 fps

Hammerin' Harry:
GP2X: 250 MHz, mmuhack+ramtweaks, 8 bit color, frameskip 0, 35 fps
WIZ: 533 MHz, none+none, 8 bit color, frameskip 0, 35 fps
WIZ: 650 MHz, none+none, 8 bit color, frameskip 0, 35 fps

They are not good :( .


Thanks for posting these Franxis, we will try the Pandora and see how it compares.
 
Last edited by a moderator:
notaz said:
Looks like wiz needs "new" mmuhack and ram tweaks badly.
The RAM timings are not going to get much better, you can't push them that far before the kernel crashes. The main factor, CAS latency, is at 2.0 anyway, which is the lowest the Wiz supports (it's the same story on GP2X I think, it's being sat at CAS 2 which is the lowest). But this is just with regards to me testing cache miss penalty - if RAM banks are changed a lot, which I suppose would have at least some impact in a real world program, especially if you're working in multiple banks at the same time, then the other timing factors could make some difference. I wouldn't expect anything massive.

But yes, mmuhack please :/

I think Franxis is getting better results than I am because the code must be spending a lot more time (proportionately) doing stuff that doesn't have to do with writing to the framebuffer. Temper's framerates are 2-4x or so, so the framebuffer write impact and the unavoidable cache misses in the system are going to be more obvious.
 
Last edited by a moderator:
craigix said:
Thanks for posting these Franxis, we will try the Pandora and see how it compares.
I don't want Wiz Vs Pandora wars, i'm absolutely sure the Pandora numbers will be 3x better.

Exophase said:
I think Franxis is getting better results than I am because the code must be spending a lot more time (proportionately) doing stuff that doesn't have to do with writing to the framebuffer. Temper's framerates are 2-4x or so, so the framebuffer write impact and the unavoidable cache misses in the system are going to be more obvious.
Yes, for my tests i don't use the upper memory at all, i only use it to write the framebuffer with the asm optimized memcpy(), i have seen the performance is about 1/2 of this using the upper memory as primary memory to avoid lack of memory (like in the GP2X).
 
Last edited by a moderator:
It's not a war, it's just a curiosity. The Wiz and Pandora are very different machines but we are curious about the power of each system that's all.

The CPU speeds (533mhz vs. 600mhz) seem so different when we actually test them that we need an alternative measure, MAME could be a good comparison.
 
Exophase said:
But yes, mmuhack please :/
Yes, mmuhack please!. Notaz, i saw in PicoDrive an mmuhack for the Wiz. Did you got it working?

It's not working for me:
CODE

Using ./mmuhack.ko
mmuhack: version magic '2.6.20-pollux mod_unload ARMv5 ' should be '2.6.24 mod_unload ARMv5 '
insmod: cannot insert `./mmuhack.ko': Invalid module format (-1): Exec format error



And modifying the binary file changing the version:
CODE

Installing NK's kernel module for Squidge MMU Hack (/sbin/insmod ./mmuhack.ko)... Not Support command done (-1)
 
Last edited by a moderator:
Franxis said:
GP2X: 250 MHz, mmuhack+ramtweaks, 16 bit color, frameskip 0, 23 fps
Since when was the GP2X a 250MHz machine? :p
Clock for clock it may be faster than a Wiz once it has all its tweaks applied, but remember that you are still getting a decent performance boost over a GP2X without having to overclock and cut the battery life in half in the process.
 
Last edited by a moderator:
Orkie said:
Since when was the GP2X a 250MHz machine? :p
Clock for clock it may be faster than a Wiz once it has all its tweaks applied, but remember that you are still getting a decent performance boost over a GP2X without having to overclock and cut the battery life in half in the process.
I agree with this :) .
 
Last edited by a moderator:
Franxis, I know we have your MAME running already, but still I'd like to send you a Pandora so you can push the hardware even more, is it possible we could send you a cased unit?
 
Back
Top