Floating point determinism.

Huh?

Are you talking about precision differences between different hardware platforms, specifically, different CPUs?

He missed a quote in his post, this is the rest of his post:

Quote:

Streflop seemed to be my solution. A friend of mine I'm working on the project with noticed it is used by TA Spring. Thats the solution to the problem we had - keeping all clients in game totally in sync - its an RTS so sending across every units position was not a good solution for us. Anyone else found any other neat solutions?

Good to know

As long as you stick to a single compiler, and a single CPU instruction set, it is possible to make floating point fully deterministic. The specifics vary by platform (i e, different between x86, x64 and PPC).

Quote:

Original post by hplus0603 As long as you stick to a single compiler, and a single CPU instruction set, it is possible to make floating point fully deterministic. The specifics vary by platform (i e, different between x86, x64 and PPC).

I've already tested this, and it isn't always the case. Same exe, different machines. My Athlon x2 matches my friends Core Duo 2 - but I considered myself lucky in that case. Had the same problem with networking at work too - was remoting another another machine with a different CPU to mine and getting different results with the same inputs. The differences were very tiny - but there.

I'd be interested to know which compiler settings to use to make it actually work though [smile] one less dependancy then!

You might want to try this:
http://msdn.microsoft.com/en-us/library/e7s85ffb.aspx

Though I've read conflicting reports, the ODE team states this flag doesn't help keep their physics calculations deterministic.

On my code I just send resynchronization packets, and don't worry about determinism.

Quote:

Same exe, different machines.

That means it's a problem with the exe. You have to make sure that the internal precision is set to 64 bits (not 80, because only Intel implements that), and that the rounding mode is consistent. Furthermore, you have to check this after calls to external DLLs, because many DLLs (Direct3D, printer drivers, sound libraries, etc) will change the precision or rounding mode without setting it back.

Also, you can't use SSE or SSE2 for floating point, because it's too under-specified to be deterministic.

Of course, there's always the possibility of something like this! :)

Quote:

Original post by hplus0603 Quote: Same exe, different machines. That means it's a problem with the exe. You have to make sure that the internal precision is set to 64 bits (not 80, because only Intel implements that), and that the rounding mode is consistent. Furthermore, you have to check this after calls to external DLLs, because many DLLs (Direct3D, printer drivers, sound libraries, etc) will change the precision or rounding mode without setting it back. Also, you can't use SSE or SSE2 for floating point, because it's too under-specified to be deterministic.

Do you know of an extensive study of this to see to what degree chip makers comply with the IEEE standard? This is obviously not the sort of thing you'd risk basing the network model for a large game project on without a great deal of testing.
One might easily imagine a slight bug in a transcendental function on a VIA processor might go undetected for a long time. Or (more likely) an emulator skimping a bit on the floating point precision for performance reasons, e.g. if the Itanium had taken off, PS2 backwards-compatibility on the PS3, or a PPC Mac user running Virtual PC.
But then again perhaps they test these sort of things extensively nowadays, at least I don't see Intel forgetting the whole Pentium FDIV debacle anytime soon.

Quote:

Do you know of an extensive study of this to see to what degree chip makers comply with the IEEE standard? This is obviously not the sort of thing you'd risk basing the network model for a large game project on without a great deal of testing.

The ISA is IEEE compliant. If your x87 implementation isn't IEEE, it's not x87.

The technology we license to various customers is based on determinism of floating point (in 64-bit mode, even) and has worked that way since the year 2000.

Quote:

Original post by hplus0603 Quote: Same exe, different machines. That means it's a problem with the exe. You have to make sure that the internal precision is set to 64 bits (not 80, because only Intel implements that), and that the rounding mode is consistent. Furthermore, you have to check this after calls to external DLLs, because many DLLs (Direct3D, printer drivers, sound libraries, etc) will change the precision or rounding mode without setting it back.

I hate to ask as usually a google will suffice - but I've had no luck with this one. How do you go about setting the internal precision to 64 bits? Would be greatly appreciated!

Quote:

I hate to ask as usually a google will suffice - but I've had no luck with this one. How do you go about setting the internal precision to 64 bits? Would be greatly appreciated!

in C/C++ i think the command is _controlfp_s() which takes a couple of bit masks where you can set different floating point settings.

http://msdn.microsoft.com/en-us/library/c9676k6h(VS.80).aspx should tell you what you need to know.

I think I'm in the same position as you at the moment. Apparently the VC++ implementation of the C/C++ math library uses processor-specific optimizations, so you'll need another math library anyway, making STREFLOP the best option.

EDIT: ...unless you're using MSVC++.

[Edited by - Baiame on July 7, 2008 11:22:31 PM]