It is very hard to emulate the floating-point calculations of the R5900 FPU and the Vector Units on an x86 CPU because the Playstation 2 does not follow the IEEE standard. Multiplying two numbers on the FPU, VU, and an x86 processor can give you 3 different results all differing by a couple of bits! Operations like square root and division are even more imprecise.

Originally, we thought that a couple of bits shouldn't matter, that game developers would be crazy to rely on such precise calculation. Floating points are mostly used for world transformations or interpolation calculations, so no one would care if their Holy Sword of Armageddon was 0.00001 meters off from the main player's hand. To put it shortly, we were wrong and game developers are crazier than we thought. Games started breaking just by changing the floating point rounding mode!

While rounding mode is a problem, the bigger nightmare is the floating-point infinities. The IEEE standard states that when a number overflows (meaning that it is larger than 3.4028234663852886E+38), the result will be infinity. Any number multiplied by infinity is infinity (even 0 * infinity = infinity). That sounds great until you figure out that the VUs don't support infinities. Instead they clamp all large numbers to the max floating point possible. This discrepancy breaks a lot of games!

For example, let's say a game developer tries to normalize a zero vector by dividing by its length, which is 0. On the VU, the end result will be (0,0,0). On x86/IEEE, the result will be (infinity, infinity, infinity). Now if the game developer uses this vector to perturb some faces for artificial hair or some type of animation, all final positions on the PS2 will remain the same. All final positions on x86 will go to infinity... and there goes the game's graphics, now figure out where the problem occurred.

The simplest solution is to clamp the written vector of the current instruction. This requires 2 SSE operations and is SLOW; and it doesn't work sometimes. To top it off, you can never dismiss the fact that game developers can be loading bad floating-point data to the VUs to begin with! Some games zero out vectors by multiplying them with a zero, so the VU doesn't care at all what kind of garbage the original vector's data has, x86 does care.

These two problems make floating-point emulation very hard to do fast and accurate. The range of bugs are from screen flickering when a fade occurs, to disappearing characters, to spiky polygon syndrome (the most common problem and widely known as SPS).

In the end Pcsx2 does all its floating-point operations with SSE since it is easier to cache the registers. Two different rounding modes are used for the FPU and VUs. Whenever a divide or rsqrt occur on the FPU, overflow is checked. Overflow is checked much more frequently with the VUs. The fact that VUs handle both integer and floating-point data in the same SSE register makes the checking a little longer. In the future, Pcsx2 will read the rounding mode and overflow settings from the patch files. This is so that all games can be accomodated with the best/fastest settings.

Moral of the blog When comparing two floating point numbers a and b, never use a == b. Instead use something along the lines of


where epsilon is some very small number.

It never ceases to amaze me how accurate you have to be when writing emulators, especially the CPU instruction set. Even something like a Gameboy would require almost every single instruction to be emulated near flawlessly, this is what astounds me about the PCSX2. This is also what attracts me to emulation, it is such an exact science

Well don't get too much of that idea for the PS2 and PSP emulation. One of the bigger challenges in emulating the PS2 and PSP is getting away from the "exact emulation" paradigm, due to them being multi-cpu systems where "exact" emulation isn't really effective.

Programming for multi-core and multi-cpu systems (ala 'parallel programming') requires a different way of thinking and, likewise, efficiently emulating them does as well. It is possible to do "exact" emulation, but it would result in an emulator that would be incredibly slow -- as recompiler strategies (aka binary translation) would be pretty much useless, and the actual compatibility wouldn't be any better than by using more clever strategies that utilize the concepts of parallel programming.

(03-01-2010 04:22 PM)Air Wrote:  Well don't get too much of that idea for the PS2 and PSP emulation. One of the bigger challenges in emulating the PS2 and PSP is getting away from the "exact emulation" paradigm, due to them being multi-cpu systems where "exact" emulation isn't really effective.

Programming for multi-core and multi-cpu systems (ala 'parallel programming') requires a different way of thinking and, likewise, efficiently emulating them does as well. It is possible to do "exact" emulation, but it would result in an emulator that would be incredibly slow -- as recompiler strategies (aka binary translation) would be pretty much useless, and the actual compatibility wouldn't be any better than by using more clever strategies that utilize the concepts of parallel programming.

Yes, although I have not (as yet) learnt all that much about binary translation, but I am aware that their is a trade off between accuracy and speed. As far as I know, a recompiler should maintain the fastest working state of the emulator as possible, even leaving out certain things if it can afford too. I guess the problem is figuring out what needs to be exactly (or as precisely as possible) emulated and what doesn't.

With regard to my previous comment, I would say that at the level I am at in writing emulators, speed is obviously far less of an issue so I can pretty much afford to be as accurate as possible. But you are completely correct, I shouldn't apply my way of thinking to other emulators like the PCSX2 for example, it clearly requires other ways of thinking and problem solving. Optimization for speed is obviously a very important part of PS2 emulation, and a very challenging one.

Anyway, I think the work you all do is incredible, thats really what I am really trying to express here