[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: spring and -march=i686

Randomly joining the thread...

I would not just persuade them to go fixed point. There just needs to be a canonical source to decide letscallem disputes. In effect, a host whose calculations would be canonical.

Possibility of game falling apart due to desync? Heck, even someone with very modest skills, like me, wouldn't design a protocol prone to that. I hope hypertalented folks behind Spring stop depending on game instances having to perform exact same calculations. Processors can have hardware mistakes in FPU, too (Pentium bug).

Ivan Vucica
via phone

On 26. sij. 2010., at 17:25, Simon McVittie <smcv@debian.org> wrote:

People seem to be treating the SSE requirement as a performance
consideration, but I think it's really about getting the same rounding
errors on all hosts:

From http://springrts.com/wiki/Build_from_source#Desync_in_game:
Spring only send the commands and not the result over the network, so
it needs to run all math in a repeatable manner, so all other clients
in a multiplayer match get the same results. So some CPU specific
features have to enabled/disabled. If you desync you either have a CPU
that isn't SSE capable or you set the wrong -march /-mtune compiler

The i387 FPU (or whatever emulation of it actually exists in a modern
CPU) normally works in 80-bit precision internally and truncates to 32-
or 64-bit when writing into memory, whereas SSE always works in IEEE
32-bit/64-bit precision (for float/double respectively), as far as I
understand it?

So, SSE and non-SSE Spring executables, when fed the same data, can
potentially get different rounding errors and hence different results;
compound that over a whole game and you'll find you and your opponent
disagree about where your squad of robots/goblins/whatever have ended up.

If this is the problem, then it might be sufficient to use gcc - mpc64 or gcc -mpc32, possibly with -mno-fused-madd, on i386... or not. (I am not a compiler ninja, those are just the options that info gcc said affected
rounding.) To be honest, it might be best to have spring/i386 require
SSE and check for it on startup.

In theory this shouldn't be a problem for most of Debian's architectures
because i386 is the unusual one here - I believe powerpc uses IEEE
32-bit floats and 64-bit doubles anyway - but I don't know whether there
are other subtle differences. -mfpmath=sse is probably a good idea on
amd64 as well as i386.

(To be honest this sounds like a recipe for portability disaster to
me... I wonder how well i686, amd64, ppc Spring interoperate, and I
wonder whether upstream could be persuaded to use fixed-point (i.e.
integer) mathematics for network-relevant calculations in future versions?)


To UNSUBSCRIBE, email to debian-devel-games-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: