Question Is unity dots physics deterministic?

Trying to evaluate if ECS Physics is a viable path for a multiplayer game that only syncs inputs into the simulation.

The docs don't seem very clear on this. Is Unity ECS physics 100% deterministic? If so, is it deterministic across different CPU architectures?

if it's only viable on the same CPUs that's probably fine but I couldn't find any direct info about this in the documentation.

 

1. My understanding is the Burst compiled code is not guaranteed to be deterministic under any use cases: aside from on the same physical machine.
2. Unity has not been working on this feature for a long time. After ECS 1.0 is released hopefully they start working again.
3. Determinism with a single target for example x86-64 with AVX2 will wildly outperform a cross platform ieee-754 implementation.
4. You should add a comment that you want this feature on the roadmap Unity does not use this forum to gauge user interest. The roadmap is the only metric they use to prioritize resources. See "Burst Determinism" on the road map and tag it as critical. https://unity.com/roadmap/unity-platform/dots

 

In this video they talk about determinism on a single platform, they had determinism across apple products without any effort:

As for unity physics, it is mentioned actually:
https://docs.unity3d.com/Packages/com.unity.physics@1.0/manual/design.html

 

So, to answer this question, I think yes. If you also want to use rollback, know that right now it seems there are some problems with the built-in serialization functions, so I'm looking at manually serializing what I need.

 

Can you maybe give time stamps? My recollection was that racing game was running on Xbox. All Xboxs run basically similar hardware and OS. Also did they say if it was only on x64 Macs or also on Apple silicon?

The official line is that floating point determinism is only guaranteed on the same physical hardware. It had nothing to do with ECS or Unity Physics this is the state of the Burst compiler. You may find that your particular configuration behaves deterministically, when synchronized with a remote machine, but there is no official support / guarantee that this will be the case.

Everyone should comment on the roadmap in the section "Under Consideration / Burst Determinism"

 

Yes, I was specifically talking about their floating point issue, which wasn't an issue for them because they were only on "one" platform

https://youtu.be/KJOhIhOv2EI?t=3347

and the part of the answer about apple is here:

https://youtu.be/KJOhIhOv2EI?t=3474

In addition he mentions they don't use rollback so they wouldn't be reliant on that for synchronization even if they do have cross-platform with xbox as well.

 

It is a little hard to hear what he is saying at 3474. I don't think he knows what he is taking about, he mumbles something about Mac and iPhone being the same CPU architecture. He never says he tested either. He is just giving a hypothetical use case that he has not tested.

The "one" platform they where on was Xbox. I am not sure if they mentioned that in this video or not.

 

I've written a thread here about determinism in Unity that you might find interesting.

As noted, Unity Physics (ECS physics, whatever it's called now) is internally deterministic, with the only issues being the determinism of float arithmetic. As well, like Monarch says, Burst is not yet guaranteed to produce deterministic arithmetic yet. I'm not sure if Unity has ever stated why this is, but I'm guessing it's due to the substitution of some System.Math operations for SIMD hardware functions (sin, cos, etc), which are not guaranteed to produce consistent results between architectures or brands x86 and ARM.

...not that you'd do much better without these substitutions, since System.Math isn't written in managed C#; instead, it hooks up to a per platform C library that again may or may not produce identical results. You can read a GitHub issue thread on the topic here.

Okay, so what if you still really want cross platform float determinism in Unity? There's no proven way to do this, so let's look at unproven ways. As a solution to the above problem, you can just reimplement all of System.Math either in C# or a native library where you can control the float mode during compilation. This reduces our problem to ensuring cross platform determinism between the IEEE float operations (arithmetic, casting). You could then write a bunch of tests that run in Unity that take in a ton of float numbers (including edge cases), in byte form, and perform a bunch of operations, comparing the results against some ground truth. I made a repo doing this here, though it's pretty rough and not nearly comprehensive enough for any final conclusions.

With your tests prepared, you could then run it on various platforms with each of Unity's available ways to create runtime code: Mono, IL2CPP and Burst. Mono I have no idea, though I know that for CoreCLR's RyuJIT compiler it does default to some sort of precise/strict float mode (though CoreCLR still uses Mono's JITer for Mono iirc). Run some tests and find out I guess!

IL2CPP is a bit better of a candidate, since it uses LLVM to perform the final compilation of C++ to native (again, I think? Hard to find documentation on the entire pipeline). Unity does also expose compiler arguments for it, so it can be configured. I'm also assuming Unity uses the same generated C++ code to compile regardless of target platform.

Lastly, we have Burst. Like IL2CPP, it uses LLVM, though with a bit of a different pipeline. I don't know a ton about whether Burst performs any per-platform optimizations on basic float operations, but if it did that would be where issues would arise. Interestingly, the VR game Nock uses ECS/Burst for their deterministic netcode, though currently it is only available on a Oculus Quest (Android). It has a coming soon page on Steam, but dunno if they ran into cross platform float issues that are preventing the port (or maybe PCVR just isn't lucrative enough to bother).

Now, even if any of these do turn out to work, you still have the issue of Unity being a closed source tool, which means that anything can change with future updates. This might then make it a bit worrying to commit to a project where your fundamental tools may become unstable eventually.

 

There is a misconception on the internet that SIMD is inherently indeterministic. I think this was instigated by articles written years ago by Gaffer On Games. SIMD is actually the best way to guarantee determinism. All x86-64 CPUs support SSE2 making this easier then in the past. The Spring RTS Engine uses low level SSE2 for determinism; on the other hand, a developer from Bevy ECS told me that only AVX2 is fully deterministic. My impression is that most SIMD instructions are deterministic across x86 microarchitectures, still it is something that needs to be tested to get a definite answer. Some instructions may need to be restricted. SIMD runs into big problems when one computer is running SSE2 optimized code, and another computer is running AVX2.

True cross-platform determinism will greatly reduce performance. You cannot use any SIMD. I would prefer that Unity focus on AVX2 platforms Windows, PS5 and Xbox. Unity as a company is still very invested in Mac / iPhone, for decades they have stayed on Mono to facilitate cross-platform, so I doubt they will want to go that route.

 

Yea sorry, I should have specified there that SIMD likely lacks determinism between ARM and x86, since as you said afaik it has no issues solely on x86.

 

For fun I updated my float determinism test project over the weekend, cleaning it up a ton and extending the tests. I ran the tests on the devices/platforms I had access to (PC, Android and WebGL, Intel and AMD) with IL2CPP and the results were more or less as expected; anything involving arithmetic, comparisons or casting is cross platform consistent, while calls to System.Math are not. Looking for someone with access to Apple devices who is familiar with the build pipeline to run the tests there. XCode uses Clang iirc, so results may depend on what defaults Unity has set for the generated project.

There are a couple options why System.Math is not consistent, but either way a simple solution would be to either compile something like openlbm yourself for the targeted platforms, or port it to C# or something (since all arithmetic is deterministic). It uses a lot of esoteric operations like bitshifting, so those may need to be tested to.

@TheOtherMonarch the current setup wouldn't necessarily answer your question about Burst, since that side is built using a different compiler (and some Unity.Mathematics calls are replaced with intrinsics), but it wouldn't be too difficult to set up some tests using Burst/Jobs. (And then test it on consoles, as those seem like your targets).

 

I am actually only targeting windows x64. I have a dependency on Unity.Burst.Intrinsics.X86.Sse4_2.crc32 for sum checking. So, I am targeting at least SSE 4.2 hardware.

I am definitely very interested in your results. For the last three years I have been porting a RTS game to ECS. I was originally under the impression that Burst was deterministic, and it may well be. When I get my code unbroken, I will do a large-scale test and share my results. I hope we can have multiplayer since the game was designed with that in mind. It is all very stressful and frustrating.