Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Exercises in Emulation: Xbox 360’s FMA Instruction

randomascii.wordpress.com

Post reply on HN
Print view View original

11–20 of 50 posts

Re: Exercises in Emulation: Xbox 360’s FMA Instruction

#11

Post by jacobush »

chrisseaton wrote: post #5
robbiet480 wrote: post #2

> If you apply for a mortgage when your job title is emulation ninja then you are in a quandary. If you write that on the mortgage application then you look like a lunatic. If you write “software engineer” then you get in trouble when the mortgage broker calls your employer. You know. Hypothetically.

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

Looking at the events that lead up to the financial crash, not much you'd think. What with people putting mortgages on their dogs and whatnot.

Re: Exercises in Emulation: Xbox 360’s FMA Instruction

#12

Post by chrisseaton »

colechristensen wrote: post #7
chrisseaton wrote: post #5

Earlier quoted context omitted.

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

Verifying the things you put on your mortgage application are true, like employment details.

I’ve never had that happen - they just looked at my bank account. I wouldn’t want a mortgage provider talking to my employer.

Re: Exercises in Emulation: Xbox 360’s FMA Instruction

#13

Post by pedrocr »

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?

And wouldn't the solution on x86 be to use the more than double precision floats that are available in the platform?

https://en.wikipedia.org/wiki/Extended_precision

Re: Exercises in Emulation: Xbox 360’s FMA Instruction

#14

Post by kevingadd »

pedrocr wrote: post #13

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? And wouldn't the solution on x86 be to use the more than double precision floats that are available in the platform? https://en.wikipedia.org/wiki/Extended_precision

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.

Re: Exercises in Emulation: Xbox 360’s FMA Instruction

#15

Post by pascal_cuoq »

Bruce Dawson always does an excellent job of explaining subtle floating-point behaviors simply, but there is one sentence I do not agree with in this particular post:

> However, for any rounding rule that you might come up with there is a case where the double rounding will give you a different answer from a true FMA.

For every “directed” rounding (up, down, towards zero), rounding the result of one operation first to higher precision and then to the intended precision is identical to rounding directly to the intended precision. For this reason, computing the FMA as “first compute the multiplication in higher precision so that no rounding happens in this step, then add the third operand at the same precision, then round to the nominal precision” does not suffer from double-rounding issues in all these rounding modes (which are all the rounding modes defined by IEEE 754 other than “round to nearest”).

So you do not even need to “come up with” them. They already exist, they are all the standardized rounding modes other than “round to nearest”.

Note: the reasoning above assumes the result of the multiplication is representable as a normal number in the higher-precision format. It is a property of IEEE 754 formats that the next more precise one can always represent the result of the multiplications of two finite numbers from the format below it as a normal number.

Re: Exercises in Emulation: Xbox 360’s FMA Instruction

#16

Post by pedrocr »

kevingadd wrote: post #14
pedrocr wrote: post #13

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? And wouldn't the solution on x86 be to use the more than double precision floats that are available in the platform? https://en.wikipedia.org/wiki/Extended_precision

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…

> This turned out to be because the rounding behavior on the 360 was different and the algorithm is fundamentally unstable using floats.

That sounds like a bug though but I guess that's the point. Unless you're bug for bug compatible a reasonable amount of code will fail a significant amount of time...

Re: Exercises in Emulation: Xbox 360’s FMA Instruction

#17

Post by pascal_cuoq »

lifthrasiir wrote: post #4

As far as I know, a correct emulation of FMA involves the double-double approach [1], that is to split a logical mantissa potentially larger than the native mantissa and merge them later. This is of course expensive and probably not a good fit for the OP's purpose anyway. [1] https://hal-ens-lyon.archives-ouvertes.fr/inria-00080427v2/d... has a verified proof.

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.

Re: Exercises in Emulation: Xbox 360’s FMA Instruction

#18

Post by forrestthewoods »

chrisseaton wrote: post #12
colechristensen wrote: post #7

Earlier quoted context omitted.

Verifying the things you put on your mortgage application are true, like employment details.

I’ve never had that happen - they just looked at my bank account. I wouldn’t want a mortgage provider talking to my employer.

If you live in the US then it has almost certainly happened. Whether you know it or not.

Employers won’t verify salary. But they will verify employment. I’m not sure if they’ll verify length of employment or not.

Re: Exercises in Emulation: Xbox 360’s FMA Instruction

#19

Post by olaulaja »

pedrocr wrote: post #13

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? And wouldn't the solution on x86 be to use the more than double precision floats that are available in the platform? https://en.wikipedia.org/wiki/Extended_precision

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

Re: Exercises in Emulation: Xbox 360’s FMA Instruction

#20

Post by pascal_cuoq »

SlowRobotAhead wrote: post #6

The whole time I was reading I was interested in what they chose to do... a lot of build up and no solution :/ Maybe they did recompile the games for backwards compatibility, maybe they do have an emulator, IDK, but I want to know how they would have fixed this issue.

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.
Post reply on HN