What's The Most Powerfull ? Open Pandora Or Iphone 3Gs ?

[ldesnogu]

There's another thing that might make 3GS faster on top of what has already been said: memory latency. OMAP3 is not very good as far as memory latency is concerned. I couldn't find anything about 3GS. Anyway it remains to be seen how important that is depending on the application of interest to the users

 

[Vlynndar]

There's another thing that might make 3GS faster on top of what has already been said: memory latency. OMAP3 is not very good as far as memory latency is concerned. I couldn't find anything about 3GS. Anyway it remains to be seen how important that is depending on the application of interest to the users

What do I see when memory latency is higher?
Or, what kind of applications are sensitive to it?

 

[ldesnogu]

What do I see when memory latency is higher?
Or, what kind of applications are sensitive to it?

You'd see slower execution of programs that use big amount of data in a way that's not cache-friendly.
I'm sorry I can't see how to explain it better
If you need more information about what a CPU cache is: http://en.wikipedia.org/wiki/CPU_cache

 

[PunchOut]

So Exophase, do you think that N64 fullspeed emulation is possible on iPhone 3GS ? And do you believe that Zodttd will made a fullspeed emulator ?

Thanks, I'm waiting to play OOT on my iPhone with iControlpad !

 

[Exophase]

There's another thing that might make 3GS faster on top of what has already been said: memory latency. OMAP3 is not very good as far as memory latency is concerned. I couldn't find anything about 3GS. Anyway it remains to be seen how important that is depending on the application of interest to the users

Or might make it slower. I haven't actually seen any benchmarks on memory latency for OMAP3, just memory bandwidth. I also contend that those tests are not fully valid unless write-allocating caching in L2 was disabled - tell me if it was, but from what I've seen writes to /dev/fb0 were substantially faster than normal application memory, so if that was returned as uncached... of course, I'm just going by someone else's word for the same code ran on /dev/fb0.

 

[ldesnogu]

Exophase: your PM box is full

 

[rv6502]

Craigx said that the icontrolpad will be released in March.

wow, that's in around two months!

 

[Exophase]

Exophase: your PM box is full

Sorry, I made room again :/ I wish we could get more than 100 messages (including outgoing, meh)

 

[fusion_power]

Craigx said that the icontrolpad will be released in March.

wow, that's in around two months!

He also sayed that the Mass production had started in November/December 09...so...
I also can remember, thet the iControlpad was planed to release in middle 2009 but of course this maybe was really to optimistic.

 

[ari64]

The N64 shader you gave also looks like a worst case, which is probably the point, but it's worth indicating. I would be shocked if N64 games used multitexturing at all more than very infrequently, and the ones that did were probably shooting for a lower framerate since it was hardly free on N64.

OoT does this quite a bit - look at the ground in the Kokiri forest, where there are dirt paths over the grass. Also lots of textures with holes. 20 fps, although the total polygon count is fairly low.

Of course CPU emulation in Dreamcast is the hardest part, but that includes geometry and lighting. drkIIRaziel says that games push upwards of 1 million vertices per second. That's way less than DC is capable of, but still a pretty hefty number when you consider all of them being transformed and lit using CPU issued vector commands. Emulating that in NEON will be a certain handful, although at least it takes away from emulating CPU cycles that could have been used on something else.

200Mhz x 2 instructions per clock, plus a fully pipelined FPU. I'd love to know how drkIIRaziel is planning to emulate that on the Pandora. Not doing TLB emulation is only about 5-10% faster in my experience.

 

[Exophase]

200Mhz x 2 instructions per clock, plus a fully pipelined FPU. I'd love to know how drkIIRaziel is planning to emulate that on the Pandora. Not doing TLB emulation is only about 5-10% faster in my experience.

To be fair, that's not really different from claiming N64 emulation means 90 million instructions per second, when you have it capped to emulate no more than 1/5th that. The actual potential for superscalar issue aren't as high as in most other in-order dual-issue designs (like Cortex-A8) because there's only one ALU. Moreover, the memory subsystem isn't strong - both the 16KB dcache and 8KB icache are direct mapped, kind of like N64's swapped (although SH4 16bit instructions does mean higher code density so the decision makes sense). The SDRAM (afaik 100MHz) is probably not as high latency as the RDRAM on N64 but I'm sure cache misses aren't trivially fast. Is the FPU on R4300i not pipelined? If so, what's the issue rate like?

SH4 emulation has another few things working in its favor over R4300i - there are fewer registers (16 vs 32) making a static allocation approach more reasonable, immediates are smaller, and the architecture is two address giving way to propagation techniques. nullDC pulls one other substantial trick; constant propagation is performed over the very common PC-relative loads, which are in particular often used for branches. Memory protection is used to detect modification to these locations.

What I have seen from other DC emulator authors is that 2 cycles per operation is a "safe spot", or 100 million instructions per second. Still far more than what Mupen64 deals with, so it's fair to remain skeptical.

 

[notaz]

nullDC pulls one other substantial trick; constant propagation is performed over the very common PC-relative loads, which are in particular often used for branches. Memory protection is used to detect modification to these locations.

Memory protection? I also thought about that, but sometimes get those literal pools reside in the same 4K page with local variables. One game even reads it's local valiable through PC relative (and writes using other means) on 32X

 

[kingoddball]

YaY!

Technical talk again!

I think we missed all the technical talk half way through threads.

 

[Exophase]

Memory protection? I also thought about that, but sometimes get those literal pools reside in the same 4K page with local variables. One game even reads it's local valiable through PC relative (and writes using other means) on 32X

Memory protection to detect the first X accesses or false positives, after which the offending store is recompiled into something else. It's the usual "trap and patch" strategy.

Given the memory restrictions and the changes in compiler technology and increased adaptation of high level languages for game programming, not to mention the increased difficulty in hand scheduling for SH4, I'm going to guess that Dreamcast code is quite different from 32X code.

 

[ari64]

SH4 emulation has another few things working in its favor over R4300i - there are fewer registers (16 vs 32) making a static allocation approach more reasonable, immediates are smaller, and the architecture is two address giving way to propagation techniques.

Many instructions on SH4 are register moves, due to the limitations of its 16-bit instructions. These could possibly be merged with other instructions. Still, 100 million/sec is about 5x more than mupen64plus.

nullDC pulls one other substantial trick; constant propagation is performed over the very common PC-relative loads, which are in particular often used for branches. Memory protection is used to detect modification to these locations.

Memory protection? I also thought about that, but sometimes get those literal pools reside in the same 4K page with local variables. One game even reads it's local valiable through PC relative (and writes using other means) on 32X

You have to protect the page anyway to detect self-modifying code, so there isn't much difference between modifying the instructions versus modifying the adjacent data.

YaY!

Technical talk again!

What were you expecting in a thread about CPU performance?

 

[Exophase]

Many instructions on SH4 are register moves, due to the limitations of its 16-bit instructions. These could possibly be merged with other instructions.

That's what I meant by propagation techniques: you mentioned copy propagation, also applicable are constant propagation and shift propagation. Shifts by non-powers of 2 (and I think 8) have to go through variable shifts, so those are a pretty good area for constant propagation in addition to the more obvious ones.

 

[PunchOut]

And what about N64 emulation on iPhone and Pandora ?

Fullspeed is possible on these devices ?

 

[mindlord]

And what about N64 emulation on iPhone and Pandora ?

Fullspeed is possible on these devices ?

The reason no one has given you a straight answer is because no one is entirely sure. We've see Mario64 at really really close to (maybe actually) fullspeed on the Pandora in videos already. It's promising, but not guaranteed that we will see 100% fullspeed N64 emulation on the Pandora for most of the system's library of games. There are some games for the N64 that are nasty to emulate and may never see fullspeed. It's fair to assume that if N64 reaches real playable speeds on the Pandora, the iPhone can get there too, but no one knows for absolute certain one way or the other at this point. Even Ari64 and Exophase can't tell you, there's still too many variables.

You can wait and see... just like the rest of us.