Comments on: Floating Point Determinism http://gafferongames.com Glenn Fiedler's Game Development Articles and Tutorials Tue, 31 Jan 2012 03:56:23 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: RSG http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/#comment-35516 RSG Mon, 23 Jan 2012 14:26:51 +0000 http://gafferongames.com/?page_id=1351#comment-35516 If you know bounds on the approximate magnitude of all the values before hand, you can apply shifts to avoid overflow (or use C++ templates to make it automatic). I've made a physics intensive fixed point game in C++ before, and it works pretty well. The main problem with this approach is that the code is no longer generic, so it's only useful if you know exactly what you'll be doing ahead of time. If you know bounds on the approximate magnitude of all the values before hand, you can apply shifts to avoid overflow (or use C++ templates to make it automatic). I’ve made a physics intensive fixed point game in C++ before, and it works pretty well. The main problem with this approach is that the code is no longer generic, so it’s only useful if you know exactly what you’ll be doing ahead of time.

]]> By: Glenn Fiedler http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/#comment-32080 Glenn Fiedler Sun, 01 Jan 2012 01:41:02 +0000 http://gafferongames.com/?page_id=1351#comment-32080 Yes it is possible, but consider the situation where the corrective states are too large to send. Then you go for 100% determinism. cheers Yes it is possible, but consider the situation where the corrective states are too large to send. Then you go for 100% determinism. cheers

]]> By: Kevin http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/#comment-32051 Kevin Sat, 31 Dec 2011 21:29:41 +0000 http://gafferongames.com/?page_id=1351#comment-32051 Although the differences exist, would it be possible to use this method and send corrective states over time so that a client could correct itself, or are the differences likely to result in large divergence quickly? Although the differences exist, would it be possible to use this method and send corrective states over time so that a client could correct itself, or are the differences likely to result in large divergence quickly?

]]> By: How are deterministic games possible in the face of floating-point non-determinism? | Q&A System http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/#comment-30921 How are deterministic games possible in the face of floating-point non-determinism? | Q&A System Sun, 25 Dec 2011 15:54:18 +0000 http://gafferongames.com/?page_id=1351#comment-30921 [...] offered that floating-point calculations are non-deterministic in between machines, and even in between numerous compilations in a comparable plan within a [...] [...] offered that floating-point calculations are non-deterministic in between machines, and even in between numerous compilations in a comparable plan within a [...]

]]> By: Glenn Fiedler http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/#comment-27911 Glenn Fiedler Fri, 09 Dec 2011 04:27:26 +0000 http://gafferongames.com/?page_id=1351#comment-27911 Huzzah! Huzzah!

]]> By: Chris Jurney http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/#comment-27845 Chris Jurney Thu, 08 Dec 2011 19:04:58 +0000 http://gafferongames.com/?page_id=1351#comment-27845 It wouldn't help for determinism to determine the largest accurate mantissa on various architectures. A disagreement in a lower bit can propogate to a disagreement in higher bits if the number lands near the edge of rounding. It's probably time to stop depending on floats to be deterministic on PCs, though. No new features on 64 bit CPUs are deterministic across models / manufacturers. All hail the rise of cross platform deterministic int based game and physics engines! It wouldn’t help for determinism to determine the largest accurate mantissa on various architectures. A disagreement in a lower bit can propogate to a disagreement in higher bits if the number lands near the edge of rounding.

It’s probably time to stop depending on floats to be deterministic on PCs, though. No new features on 64 bit CPUs are deterministic across models / manufacturers. All hail the rise of cross platform deterministic int based game and physics engines!

]]> By: Misha http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/#comment-21549 Misha Tue, 11 Oct 2011 18:46:28 +0000 http://gafferongames.com/?page_id=1351#comment-21549 I wonder if there is a way to determine the largest accurate mantissa for common architectures after performing a single float operation? I did a quick search on ISI web of science and didn't find anything. Somebody should really do an investigation! I wonder if there is a way to determine the largest accurate mantissa for common architectures after performing a single float operation? I did a quick search on ISI web of science and didn’t find anything. Somebody should really do an investigation!

]]> By: Chris Jurney http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/#comment-17671 Chris Jurney Fri, 19 Aug 2011 21:43:56 +0000 http://gafferongames.com/?page_id=1351#comment-17671 SSE float ops are not deterministic because the standard specifies a minimum error, not a specific error for some operations like reciprocal. You need to call _set_SSE2_enable(0) at startup on all your threads along with your _controlfp calls. Multithreading won't have any affect on the order of operations for floats. The compiler decides on that ordering at build time, so as long as all threads are running the same code, it won't matter. What will matter is the ordering of results when you merge results, and that can break if you split work, and don't merge it back together based on a fully deterministic ordering. SSE float ops are not deterministic because the standard specifies a minimum error, not a specific error for some operations like reciprocal. You need to call _set_SSE2_enable(0) at startup on all your threads along with your _controlfp calls.

Multithreading won’t have any affect on the order of operations for floats. The compiler decides on that ordering at build time, so as long as all threads are running the same code, it won’t matter. What will matter is the ordering of results when you merge results, and that can break if you split work, and don’t merge it back together based on a fully deterministic ordering.

]]> By: Hamid Mushtaq http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/#comment-16740 Hamid Mushtaq Tue, 09 Aug 2011 13:49:50 +0000 http://gafferongames.com/?page_id=1351#comment-16740 As far as effect of floating point calculations on multithreaded programs is concerned, it is not deterministic, due to the reason that it is neither associative nor distributive, its only commutative. So for example, a + ( b + c ) is not equal to ( a + b ) + c. Therefore if different threads are adding to sums by acquiring a lock, you need to make sure that all replicas acquire the locks in the same order or else the execution will diverge. As far as effect of floating point calculations on multithreaded programs is concerned, it is not deterministic, due to the reason that it is neither associative nor distributive, its only commutative. So for example, a + ( b + c ) is not equal to ( a + b ) + c.

Therefore if different threads are adding to sums by acquiring a lock, you need to make sure that all replicas acquire the locks in the same order or else the execution will diverge.

]]> By: Dimiter "malkia" Stanev http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/#comment-14981 Dimiter "malkia" Stanev Sun, 10 Jul 2011 09:18:31 +0000 http://gafferongames.com/?page_id=1351#comment-14981 Our tools pipeline requires that any asset produced with the same parameters should create the same binary (verified with MD5). This affected us when we switched from one DXT compression library to another, and also limit us not to use the GPU (through CUDA or OpenCL) - there the differences can be even more staggering. Later colleagues from another studio forced all calls to be 64-bit (rather than 80), and I guess that was done (I understood it here), because AMD might not produce the same results as Intel when 80-bit (intermediate) precision is used. All in all this page, and all the research is very useful. What we do in our games is to have ONE machine doing the simulation, eventually migrating itself to another if needed (player quits). But we are FPS so that would be easier. That's what I know from our networking and gameplay folks. Our tools pipeline requires that any asset produced with the same parameters should create the same binary (verified with MD5). This affected us when we switched from one DXT compression library to another, and also limit us not to use the GPU (through CUDA or OpenCL) – there the differences can be even more staggering.

Later colleagues from another studio forced all calls to be 64-bit (rather than 80), and I guess that was done (I understood it here), because AMD might not produce the same results as Intel when 80-bit (intermediate) precision is used.

All in all this page, and all the research is very useful.

What we do in our games is to have ONE machine doing the simulation, eventually migrating itself to another if needed (player quits). But we are FPS so that would be easier. That’s what I know from our networking and gameplay folks.

]]>