Exercises in Emulation: Xbox 360’s FMA Instruction

Recompiling alone wouldn't help if the game engine's floating point were tuned for behavior of the PPC.

EDIT: I don't know if they did emulation or not - I always believed they did but only managed to certify some games.

That is weird. The paper was published in 2009 by Microsoft Research, and the Xbox One entered development in early 2011 according to Wikipedia (https://en.wikipedia.org/wiki/Xbox_One). So when the author started working on the problem for Microsoft, Microsoft already knew how to solve the problem.

double-double or quad precision is necessary to emulate double-precision FMA. The article is talking about emulating single-precision FMA with double-precision. The relevant paragraph is:

> Luckily the vast majority of floating-point math in games is done to float (32-bit) precision, and I was quite happy to use double (64-bit precision) instructions in the emulation of FMA.

One big difference between quad-precision and double-double is that quad-precision has a much wider exponent range. If you use double-double, you need to worry that the result of the multiplication may underflow a double. In the article you cited:

> First, the value ul has to be the error term of the multiplication a · b, in order to avoid some degenerate underflow cases: the error term becomes so small that its exponent falls outside the admitted range. […] The algorithm will behave correctly even if some computed values are not normal numbers, as long as ul is representable.

… implying that the algorithm may not compute the FMA if the error of the multiplication is not representable, which can happen when it is below the normal range.

Do mortgage brokers call your employer? What’s your mortgage got to do with your employer?

As an employed "software engineer" who has recently applied for a mortgage (house closing tomorrow!), I'm highly interested in this statement. I've encountered no trouble whatsoever, and I'm honestly surprised that its gone as smoothly and quickly as it has.

I cannot tell you if it is the solution they chose, but the fastest known implementation for single-precision FMA using double-precision multiplication and addition on conventional hardware is to use “round-to-odd” for the intermediate result. Any libc implementing “fmaf” for an architecture that doesn't have it has the same problem, and the solution looks like:

https://github.com/lattera/glibc/blob/b4d5b8b02133e0c317e6c8...

“round-to-odd” is not a standardized rounding mode, even though it is so useful that some argue it should be. It can be emulated by the following sequence:

    /* Reset rounding mode and test for inexact simultaneously.  */
    int j = libc_feupdateenv_test (&env, FE_INEXACT) != 0;

    if ((u.ieee.mantissa1 & 1) == 0 && u.ieee.exponent != 0x7ff)
      u.ieee.mantissa1 |= j;

The sequence has the drawback of not pipelining well on modern processors, but it's still faster than any known alternative, and at least the code is short.

They ended up shipping processors that support FMA on the xbone, so they probably just used that.

They do. Slight problems with floating point behavior are the cause of many historical problems with GameCube and Wii games in the Dolphin emulator (which also has to emulate PPC on x86/x64)

For a simpler example from personal experience, I had a textbook implementation of triangulation via ear clipping to turn polygons into a list of triangles I could send to the GPU. On Windows it worked great but when I ran it on an XBox 360 it looped infinitely. This turned out to be because the rounding behavior on the 360 was different and the algorithm is fundamentally unstable using floats.

We have pieces of code at (gaming related) work that have very tight, and carefully thought out, error bounds (think 4 ULP) and can certainly break if float rounding doesn't work as expected. I'd expect a physics engine to contain plenty of similar code, particularly related to collision detection. Rendering and gameplay logic are probably a bit less picky

They do. A trivial example is input recording for replays -- if you don't have a very similar FP implementation, the replays will desync: https://www.youtube.com/watch?v=XxGg1TCpYrc

Collision detection is sometimes also very FP sensitive. See https://www.youtube.com/watch?v=9hwuz2U1JV8 fixed by https://github.com/dolphin-emu/dolphin/pull/390

https://www.youtube.com/watch?v=eEbmrwnYaXs has a few more examples we've documented.

Yep. IIRC, this was why several of the Sonic Adventure ports from Dreamcast has issues where the player character could fall through tiny seams in the floor.

> Do games really rely on the rounding behaviors of floats to not break? Seems like there should always be plenty of margin around that. But maybe something does a loop with these instructions over and over and the error compounds?

I remember that in PearPC the sin function of cocoa (IIRC) would crash if the FMA instructions did not provide enough accuracy. It would access a table of precomputed values out of bounds or so.

A lack of precision is not the problem. The problem is that at some point the game logic makes a decision such as whether a bullet hit a target, whether a player made a jump, or many others.

These decisions sometimes end up right on a cusp, where a single unit in the last place determines the behavior. In a sensitive physics engine these happen more often than you might think. And when the result changes, all future events are impacted.

This is crucial for replays, it may be crucial for multiplayer, and it can result in unexpected behavior in ways that you only find when writing an emulator.

A slight change in floating-point math may also result in a slightly larger-than-expected number which may then result in a slightly negative number which may result in a NaN (sqrt(-1e39) perhaps) which then results in the poisoning of all future math that uses that number.