Psp Emulation And Universl Remote

[ari64]

Is 30% just for the recompiler, or the entire emulation? Can you actually quantify "most of its time"? Have you checked the performance counters?

This is pretty bad news, given that I expect the generated x86 code to take more cycles internally... and Cortex-A8's L2 cache should be pretty low latency as far as these things go. I hear that at some Pandora revision there a boost in main RAM performance. OMAP3530 revs have been bumping Cortex-A8 revs, and I heard a long time ago that Cortex-A8 originally didn't perform critical word first on L2 line loads. Maybe the L3 interconnect has been improved too.

The 30% is just the recompiler. The GMA950 is kinda slow. By most of its time, I mean taking 300 million cycles to execute about 100 million instructions. (I didn't count the number of instructions exactly, so that's just a rough estimate.)

Part of the difference is the slow FPU, but that doesn't account for all of it. Also, the ARM code is a bit more efficient than the x86 code, and about 20% smaller overall, mostly due to decreased register shuffling.

I'd love to know exactly what accounts for this speed difference, but I know that the RAM is a big part of it. I have a debugging function which does a checksum over the N64's RAM (8MB) and this takes more than twice as long on the beagleboard.

Compared to N64 emulation JayFoxRox has a slight advantage in not having to emulate 64-bit registers or double precision FPU operations. And a massive disadvantage in having to emulate VFPU operations.

How does the PSP's FPU differ from the N64?

 

[Exophase]

I'd love to know exactly what accounts for this speed difference, but I know that the RAM is a big part of it. I have a debugging function which does a checksum over the N64's RAM (8MB) and this takes more than twice as long on the beagleboard.

Will be curious to see if it takes the same amount of time on the Pandora then. What revision is your Beagleboard? 0.33 instructions per cycle is pretty awful...

How does the PSP's FPU differ from the N64?

It's single precision only. The VFPU is a totally different coprocessor and is a quite sophisticated floating point vector unit capable of something like 4 MACs per cycle and has a lot of support for permutations.

 

[ari64]

Will be curious to see if it takes the same amount of time on the Pandora then. What revision is your Beagleboard? 0.33 instructions per cycle is pretty awful...

Rev C3. It's probably closer to 0.5 instructions per cycle actually. This is based on an assumption of 18 million emulated MIPS instructions per second and 1 million floating point operations. On average, the recompiler generates around 5 or 6 ARM instructions for every MIPS instruction, not counting exception handlers and memory-mapped I/O. gcc -mcpu=cortex-a8 apparently does not generate VFP code, so each floating point operation takes around 40-50 instructions. This works out to about 150 million instructions per second. The 300 million cycles is based on this taking about 60% of the CPU time on the cortex-a8 at 500mhz.

For comparison, an Intel Core2 takes about 150 million cycles (15% @ 1ghz, executing somewhat more integer instructions and somewhat fewer floating point instructions). Of course, the core2 is quad-issue and has a much larger L2.

Some of the 'bloat' in emulating r4300i is sign-extending 32-bit registers to 64-bit. The data flow analysis can eliminate many 64-bit operations if only the lower 32 bits of the result are used, but when writing back cached registers it has to save all 64 bits if it can not predict where the value might be used. So PSP emulation would be somewhat faster in this regard.

It's single precision only. The VFPU is a totally different coprocessor and is a quite sophisticated floating point vector unit capable of something like 4 MACs per cycle and has a lot of support for permutations.

Emulating that on the Pandora is quite ambitious...

 

[hlidegp2x]

Compared to N64 emulation JayFoxRox has a slight advantage in not having to emulate 64-bit registers or double precision FPU operations. And a massive disadvantage in having to emulate VFPU operations.

How does the PSP's FPU differ from the N64?

PSP is MIPS32R2 + VFPU. That means there is no 64-bit computation at all, so no fancy trick. FPU is pretty easy to emulate with SSE/SSE2 so why not with NEON. There is no need to emulate low level interrupts at all (just some userland interpetrer handlers which doesn't ask great precision). You only need to interpret userland code. The kernel land code being native, unlike N64 or PSX. No need to interpret a firmware unlike N64 or PSX. And so on. VFPU is a little more complicated to optimize out without a smart dynamic or static recompiler. Yes you can use a static recompiler unlike N64 or PSX. I'm not saying a fullspeed emulator is 100% possible on Pandora. But we can expect it for next generation devices having a 1Ghz dual-core.

EDIT: for your information, someone is making a linux port of pcsp right now, and he plans an Android port for Nexus One.

 

[Exophase]

No offense, but I'm waiting for a proof of concept on static recompilation that really accomplishes a high level of compatibility with commercial games, before I believe that it's as compatible as dynarec or even a viable solution. I know you have some examples of it, but I feel that it has a long way to go before it's really proven. I'd also like to know specifically what the advantages are in static over dynamic, in this case.

HLEing kernel space code is only as good as the percentage of time games actually spend in kernel space code. Even if some spend a lot I doubt all do.

Re-Beagleboard: looks like C3 is using OMAP ES3.0; the only newer revision is ES3.1 and that doesn't up the Cortex-A8 revision. I don't see anything else that would improve performance.

I expect another big strength the Core2 would have is being out of order, giving the CPU the chance to do something else during those cache misses. It'll be interesting to see how this performs on Cortex-A9.

 

[hlidegp2x]

No offense, but I'm waiting for a proof of concept on static recompilation that really accomplishes a high level of compatibility with commercial games, before I believe that it's as compatible as dynarec or even a viable solution. I know you have some examples of it, but I feel that it has a long way to go before it's really proven. I'd also like to know specifically what the advantages are in static over dynamic, in this case.

I mean static recompilation where you output C/C++ source to delegate registers allocation and optimization to compiler. No other advantage. Static recompiler is possible because a psp program is a userland code (alike unix one) and I doubt SMC is common on psp programs.

HLEing kernel space code is only as good as the percentage of time games actually spend in kernel space code. Even if some spend a lot I doubt all do.

I wasn't speaking about performance but about the fact that cycle counting and interrupt emulation are not necessary to achieve emulation on PSP in comparison with N64 or PSX emulation where you cannot ascertain the game would not do tricky things that PSP forbids.

 

[ari64]

Re-Beagleboard: looks like C3 is using OMAP ES3.0; the only newer revision is ES3.1 and that doesn't up the Cortex-A8 revision. I don't see anything else that would improve performance.

I expect another big strength the Core2 would have is being out of order, giving the CPU the chance to do something else during those cache misses. It'll be interesting to see how this performs on Cortex-A9.

I did some quick tests, to see how much CPU time was needed to run Super Mario 64 on various CPUs, without graphics or sound.

OMAP3530 @500MHz: 65%
OMAP3530 @750MHz: 46%
Atom N270 @800MHz: 37%
Atom N270 @1600MHz: 19%
Core2 T7200 @1000MHz: 15%

Not entirely rigorous, but should give some idea of the relative CPU requirements for MIPS emulation.

 

[Exophase]

Hm, so this gives us:

OMAP3530 @500MHz: 325M cycles
OMAP3530 @750MHz: 345M cycles
Atom N270 @800MHz: 296M cycles
Atom N270 @1600MHz: 304M cycles
Core2 T2700 @1000MHz: 150M cycles

You can see some degradation due to fixed memory clock on the OMAP, but nothing so substantial as to suggest you're spending most of your cycles in memory stalls. The Atom @800MHz is 16.5% more efficient per cycle than the OMAP3530 @750MHz, about half what you suggested.

The OMAP3 memory clock should be at 166MHz, so I guess we should have (very) roughly:

325 = CPU_cycles + (mem * 500 / 166)
345 = CPU_cycles + (mem * 750 / 166)

(325 - (mem * 500 / 166)) = (345 - (mem * 750 / 166))
(325 * 166) - (mem * 500) = (345 * 166) - (mem * 750)
-(mem * 500) = (20 * 166) - (mem * 750)
(mem * 250) = 20 * 166
mem = 13.28M cycles (in 166MHz units), or 40M and 60M cycles at 500MHz and 750MHz respectively.

Of course, that isn't the time spent waiting on L2 misses. There are at least 20 CPU cycles in overhead (per line), according to the Cortex-A8 TRM.

I don't remember what percentage of memory loads are from locations that can be determined constant at compile time, but if it's more than a few percent then I wonder if L2 preloads would help any. The graphics and audio plugins at least would probably benefit from some preloading.

I wonder what's the biggest win for the Atom: its 2x larger L1 dcache, 2x larger L2 cache, faster main memory bandwidth, or maybe lower main memory latency. Probably all four >_> If you're averaging 5-6 ARM instructions per MIPS integer instruction then I would expect the x86 code to increase that by one or two. On x86 are you balancing register access between allocation and memory operands? Memory operands perform really well on Atom; if you can keep the trends towards one operand in memory and one in a register, biased towards destinations in register, then I think you'd have pretty favorable performance.

This isn't related, but do you have an x86-64 emitter?

 

[ari64]

Super Mario 64 probably isn't the best benchmark. It's relatively small and doesn't cause a lot of L2 misses. Repeating the same test with Ocarina of Time:

OMAP3530 @500MHz: 55.5%
OMAP3530 @750MHz: 40.1%
Atom @800MHz: 25.5%
Atom @1600MHz: 14.2%

Still, around 70M cycles in main memory wait for the OMAP3 at 750MHz, and an unknown amount in L2 cache wait. I'm not sure what accounts for the large difference between the A8 and Atom here, but it's probably the larger L1 and L2 caches.

I don't remember what percentage of memory loads are from locations that can be determined constant at compile time, but if it's more than a few percent then I wonder if L2 preloads would help any. The graphics and audio plugins at least would probably benefit from some preloading.

I've experimented with preloads, but the problem is that the preload itself costs at least two cycles, so it can actually make things slower if it ends up preloading a lot of locations that were already in the cache. It's also difficult to predict the instruction flow well enough to optimally schedule the preloads, which would be about 50-100 cycles in advance.

If you're averaging 5-6 ARM instructions per MIPS integer instruction then I would expect the x86 code to increase that by one or two. On x86 are you balancing register access between allocation and memory operands? Memory operands perform really well on Atom; if you can keep the trends towards one operand in memory and one in a register, biased towards destinations in register, then I think you'd have pretty favorable performance.

The x86 code generation is very similar to the ARM code generation. If a particular register is needed by the next instruction and is not already cached, then it will load it one instruction prior. This is to avoid the load-use penalty on the A8. Atom doesn't have a load-use penalty, the load is done earlier in the pipeline so it has a 3-cycle address generation interlock instead.

This isn't related, but do you have an x86-64 emitter?

I made an x86-64 emitter for testing purposes, but it's basically the same as the 32-bit code generator and doesn't use any 64-bit instructions. The only things I changed were the stack alignment and rip-relative instructions.

 

[willrandship]

I'm glad to see this turn into a technical thread rather than one or two people spreading misinformation. :lol:

Isn't N64 harder to emulate than PSP? Even considering that, N64 emulation is farther along as of yet, and can run commercial games, while (unless I missed a post) PSP only runs a few tech demos.

 

[Exophase]

Isn't N64 harder to emulate than PSP? Even considering that, N64 emulation is farther along as of yet, and can run commercial games, while (unless I missed a post) PSP only runs a few tech demos.

Look at it this way: N64 was released in mid-1996 and in early 1999 an emulator was released which could play several of the most popular games at fullspeed on computers of that era. In 1999 and 2000 several other N64 emulators were released which could do the same.

PSP was released in late 2004, and while there have been a few emulators in the past few years they could only show bits and pieces of some commercial games at the most. The most advanced one out now, JPCSP, still doesn't have the performance and compatibility of the early N64 emulators.

Does that answer your question? HLE on N64 involved recreating relatively simple "ucode" interpreters. HLE on PSP involves recreating an entire multithreaded OS.

 

[kingoddball]

Just buy a PSP. As for home brew, it is mostly open source so it could be ported easily (maybe).

 

[Jourdy288]

Who needs processing power when you've got a community like this? :lol:
Seriously, I'm pretty sure PSP emulation will occur, it's bound to happen. I'm sure of it. No promises, but....

 

[kingoddball]

It will probably happen - BUT as a proof of concept. I don't think that the Pandora will be powerful enough to run anything other than PSP homebrew at fullspeed (If any retail game: Lumines.. IF ANY).

Dreamcast (which has some similarities with Pandora hardware, if I'm not mistaken) is not even running at fullspeed and it might not even happen.