Mupen64Plus

[ari64]

Bit OT, but does Cortex-A8 default to Thumb-mode on? I assume for this (an other emus, floating point work) you'd want it off?

Thumb really isn't too useful for this sort of emulator. There was some prior discussion of this:

http://www.gp32x.de/board/index.php?/topic/49358-mupen64plus/page__view__findpost__p__753642
http://www.gp32x.de/board/index.php?/topic/48445-neon-ized-math-h-like-library/

Unfortunately this thread is getting really long, and it's hard to find posts.

 

[God Ginrai]

Bit OT, but does Cortex-A8 default to Thumb-mode on? I assume for this (an other emus, floating point work) you'd want it off?

Thumb really isn't too useful for this sort of emulator. There was some prior discussion of this:

http://www.gp32x.de/board/index.php?/topic/49358-mupen64plus/page__view__findpost__p__753642
http://www.gp32x.de/board/index.php?/topic/48445-neon-ized-math-h-like-library/

Unfortunately this thread is getting really long, and it's hard to find posts.

The Search Topic function doesn't fit your needs?

Anyways, what exactly will the NEON code be replacing? (once it is implemented)

-God Ginrai

 

[silver]

Bit OT, but does Cortex-A8 default to Thumb-mode on? I assume for this (an other emus, floating point work) you'd want it off?

Sorry, but your question makes no sense

Why would you want to disable Thumb exactly? What would it bring?

Thumb is just another instruction set and with Thumb2 you can do more or less the same things as in ARM mode.
You can switch to Thumb mode and switch back to ARM whenever you want (for instance, by using bx with lower bit set to 1 or 0).

Sorry, my post was not clear.

I believe the Cortex-A8 has compile-time options for generating Thumb or ARM code (or a mixture). I believe both can do FP operations on the Cortex-A8. However, I have read that for FP intensive programs, using Thumb opcodes can have a significant negative impact on performance. I am unclear if there is a penalty switching the CPU from 16-bit Thumb opcodes to 32-bit ARM opcodes, or if it is simply the ARM code is faster for FP.

Anyway, I realise this is probably too off-topic for this thread (apologies Ari64).

 

[ari64]

The Search Topic function doesn't fit your needs?

Well, a lot of the same questions come up again and again, so I guess people are not able to find things using search.

Anyways, what exactly will the NEON code be replacing? (once it is implemented)

It's not useful for R4300i emulation, but could be used for some of the 3D code.

However, I have read that for FP intensive programs, using Thumb opcodes can have a significant negative impact on performance.

Thumb code has a negative impact on performance in several ways, not just floating point.

 

[Exophase]

Thumb code has a negative impact on performance in several ways, not just floating point.

On Cortex-A8 Thumb means Thumb-2. The concept of using original Thumb instructions only makes as much sense as not using ARMv2 or higher instructions in ARM code. Thumb-2 can do most things that ARM can and some that it can't. There are other plusses like better code density and minuses like increased BTB misses due to another significant bit in the target PCs and having conditional blocks instead of per-instruction conditions (by the way, ARM11 DID fold the condition prefix, but apparently not Cortex-A8). It's also a well known fact that Laurent hates Thumb-2 and would like for no one to use it ;p

 

[God Ginrai]

Anyways, what exactly will the NEON code be replacing? (once it is implemented)

It's not useful for R4300i emulation, but could be used for some of the 3D code.

Ah, I see, thanks.

-God Ginrai

 

[ldesnogu]

On Cortex-A8 Thumb means Thumb-2. The concept of using original Thumb instructions only makes as much sense as not using ARMv2 or higher instructions in ARM code. Thumb-2 can do most things that ARM can and some that it can't. There are other plusses like better code density and minuses like increased BTB misses due to another significant bit in the target PCs and having conditional blocks instead of per-instruction conditions (by the way, ARM11 DID fold the condition prefix, but apparently not Cortex-A8). It's also a well known fact that Laurent hates Thumb-2 and would like for no one to use it ;p

Nice summary, including the last remark

However, I'm considering generating Thumb2 code for QEMU to get some hard facts for ARM vs T2, not only gut feelings.

 

[Adventus]

I have updated the gles2n64 SVN with NEON optimisations. Just compile with -D__NEON_OPT for optimisations that i've mainly just lifted from math-neon, they should be pretty stable. Compile with -D__NEON_OPT2 for some additional optimisations i've not tested.

It's not useful for R4300i emulation, but could be used for some of the 3D code.

Do you mean there's bigger optimizations elsewhere or that you won't get any speed up?

 

[ldesnogu]

R4300i has no SIMD instructions, and IIRC Ari64 uses software emulation for FP, so NEON is of no use.
Also note that mapping FP instructions from one processor to another while being accurate is very complex.

 

[Exophase]

R4300i has no SIMD instructions, and IIRC Ari64 uses software emulation for FP, so NEON is of no use.
Also note that mapping FP instructions from one processor to another while being accurate is very complex.

Ari64 has expressed that he would like to use NEON for FP, and where feasible he probably should. At least he wants to move away from relying on the compiler functions.

Indeed NEON won't help you over VFPlite as much if your goal is to accurately emulate IEEE754 floats (especially 64bit ones), but we're talking about N64 emulation, where an entire fully programmable vector processor is being emulated at a high level. So naturally it depends on the games. StrmnNrmn has reported that the games he has tested don't even mind having their 64bit float operations turned into 32bit ones. That should tell you something. My guess is that for a number of floating point utilizing games the IEEE754 state side-effects are not relied open at any point whatsoever, but I could of course be totally wrong.

With liveness analysis you can at least get a few wins where a floating point register becomes dead before side effects can be taken.

 

[ari64]

R4300i has no SIMD instructions, and IIRC Ari64 uses software emulation for FP, so NEON is of no use.
Also note that mapping FP instructions from one processor to another while being accurate is very complex.

Ari64 has expressed that he would like to use NEON for FP, and where feasible he probably should. At least he wants to move away from relying on the compiler functions.

Indeed NEON won't help you over VFPlite as much if your goal is to accurately emulate IEEE754 floats (especially 64bit ones), but we're talking about N64 emulation, where an entire fully programmable vector processor is being emulated at a high level. So naturally it depends on the games. StrmnNrmn has reported that the games he has tested don't even mind having their 64bit float operations turned into 32bit ones. That should tell you something. My guess is that for a number of floating point utilizing games the IEEE754 state side-effects are not relied open at any point whatsoever, but I could of course be totally wrong.

With liveness analysis you can at least get a few wins where a floating point register becomes dead before side effects can be taken.

VFPlite would certainly improve performance, but I'm not looking forward to trying to debug it.

I am skeptical of the claim that you can reduce FP precision and still have everything work. I suspect most things will work, and it will be a real pain in the ass to track down the few cases that don't. Every game I've looked at contains floating point compares and BC1F/BC1T, so there will likely be edge cases where small things might make a difference.

At the very least I'd need to make a 'fast mode' and a 'compatibility mode', and if something goes wrong in 'fast mode' hopefully it will be possible to track it down.

 

[Exophase]

At the very least I'd need to make a 'fast mode' and a 'compatibility mode', and if something goes wrong in 'fast mode' hopefully it will be possible to track it down.

You should, and possibly make the fast mode an option that defaults off. Then it'd be the user's problem/fault where it goes bad. Not that it'd really stop people from complaining or reporting it.

I've actually wondered this for a while.. does anyone know if it's at all realistic to emulate doubles with floats faster than you could with ints? I'd like to see some algorithms if it is indeed worth anything.

 

[ldesnogu]

I've actually wondered this for a while.. does anyone know if it's at all realistic to emulate doubles with floats faster than you could with ints? I'd like to see some algorithms if it is indeed worth anything.

I don't think it's doable efficiently. In one case the mantissa is 23+1 and in the other it is 52+1. So it's more than double the number of bits. Plus you'd have to handle the exponent (8 bits versus 11).

OTOH perhaps one could be creative with NEON integer instructions. But I don't think in the end you'd be faster than VFPlite...

 

[Exophase]

I don't think it's doable efficiently. In one case the mantissa is 23+1 and in the other it is 52+1. So it's more than double the number of bits. Plus you'd have to handle the exponent (8 bits versus 11).

Yeah, that's what I was thinking. The only reason the thought has crossed my mind is because I read about the Longsoon processor being capable of performing 2 float operation per cycle or chaining them to do 1 double operation. Obviously there's way more glue logic and probably wider precision ALUs at work here than would be directly exposed in a single precision FPU.

OTOH perhaps one could be creative with NEON integer instructions. But I don't think in the end you'd be faster than VFPlite...

You're almost definitely right. You could probably beat pure integer emulation though, not that it matters.

 

[ldesnogu]

Yeah, that's what I was thinking. The only reason the thought has crossed my mind is because I read about the Longsoon processor being capable of performing 2 float operation per cycle or chaining them to do 1 double operation. Obviously there's way more glue logic and probably wider precision ALUs at work here than would be directly exposed in a single precision FPU.

I guess it's done the other way around: you have a wide-enough ALU for handling double precision that can be split in two for handling single precision (I say so because as I wrote above DP prec is more than twice SP prec).

 

[Exophase]

I guess it's done the other way around: you have a wide-enough ALU for handling double precision that can be split in two for handling single precision (I say so because as I wrote above DP prec is more than twice SP prec).

Yep, that makes a lot more sense. They just didn't word it like that. I can't really fault it, since it was a Chinese publication written in English. Wasn't really very bad though, not compared to others I've seen.

 

[juniorm33]

I have updated the gles2n64 SVN with NEON optimisations. Just compile with -D__NEON_OPT for optimisations that i've mainly just lifted from math-neon, they should be pretty stable. Compile with -D__NEON_OPT2 for some additional optimisations i've not tested.

It's not useful for R4300i emulation, but could be used for some of the 3D code.

Do you mean there's bigger optimizations elsewhere or that you won't get any speed up?

Any sort of stats to the performance difference between the different versions?

 

[ari64]

However, I'm considering generating Thumb2 code for QEMU to get some hard facts for ARM vs T2, not only gut feelings.

I suspect that the more complex instruction decoding (due to variable-length instructions) is going to hurt performance, but it'd be nice to see some actual numbers.

 

[Pickle]

I have updated the gles2n64 SVN with NEON optimisations. Just compile with -D__NEON_OPT for optimisations that i've mainly just lifted from math-neon, they should be pretty stable. Compile with -D__NEON_OPT2 for some additional optimisations i've not tested.

Adventus,
Ive tried the neon additions and the plugin runs for a bit and then seg faults. No 3d is displayed, I did get the mario kart background of the intro to display.
Can I also please give you a patch for minor changes to Opengl.cpp that get the current code to run on the pandora? It would help if the changes made it into the svn.

 

[Exophase]

I suspect that the more complex instruction decoding (due to variable-length instructions) is going to hurt performance, but it'd be nice to see some actual numbers.

The Thumb-2 instruction decoding is free on Cortex-A8. If anything averaging more instructions per fetch improves throughput.