Bug / Crash Burst not working at all

[manurocker95]

Hi! I'm using Unity 2020.1.7f1 + Burst 1.3.7 + Jobs 0.5.0-preview 14 and when setting any solver to Burst, Unity completely freezes. This is common to all Obi assets. In case of Softbody, Oni mode works just fine excepting the scene "Deformable Barrels" that runs at 3fps after instancing. 

Any idea? Should I downgrade Jobs package?

Thanks in advance

[josemendez]

Hi! I'm using Unity 2019.1.7f1 + Burst 1.3.7 + Jobs 0.5.0-preview 14 and when setting any solver to Burst, Unity completely freezes. This is common to all Obi assets. In case of Softbody, Oni mode works just fine excepting the scene "Deformable Barrels" that runs at 3fps after instancing. 

Any idea? Should I downgrade Jobs package?

Thanks in advance

Unity 2019.1 is not supported by Obi 5.5, 5.6, or the Burst backend, as there were several deal-breaking bugs with collections and Burst in pre-2019.3 (NativeQueue in particular -which is used extensively in Obi- was really broken). You should use Unity 2019.3 or above, as indicated on the store.

[manurocker95]

Unity 2019.1 is not supported by Obi 5.5, 5.6, or the Burst backend, as there were several deal-breaking bugs with collections and Burst in pre-2019.3 (NativeQueue in particular -which is used extensively in Obi- was really broken). You should use Unity 2019.3 or above, as indicated on the store.

Sorry, I meant 2020.1.7f1 (Editing OP) xD

Edit:

This is also happening on 2019.4.11

[josemendez]

Sorry, I meant 2020.1.7f1 (Editing OP) xD

Edit:

This is also happening on 2019.4.11

I can't seem to reproduce this (2019.4.11 or 20201.7f1), also I've had no other reports of Burst crashing or Oni exhibiting bad performance. Are there any errors/info shown in the editor logs after crashing?

[manurocker95]

I can't seem to reproduce this (2019.4.11 or 20201.7f1), also I've had no other reports of Burst crashing or Oni exhibiting bad performance. Are there any errors/info shown in the editor logs after crashing?

Nope, it doesn't crash with a report. It freezes and Unity doesn't respond anymore. This is common to every scene with Burst backend.

[josemendez]

Nope, it doesn't crash with a report. It freezes and Unity doesn't respond anymore. This is common to every scene with Burst backend.

I can't reproduce this. Is this on a fresh project, or a pre-existing one that got updated? If the latter, do you get the same results on a fresh project with just Obi installed?

[whitexroft]

josemendez
I can't reproduce this. Is this on a fresh project, or a pre-existing one that got updated? If the latter, do you get the same results on a fresh project with just Obi installed?
 
The freeze can be reproduced by:
 1. Set your rope with Burst backend.
 2. Add an empty game object with OniColliderWorld
 3. run this

The forever freeze happens when "Oni.UpdateColliderGrid();" is called in it.
I mean sure, why would you add OniColliderWorld manually. 
But then it doesnt matter, it neednt freeze.

On another topic:
How come my FPS is super low when running Burst backend in build, but it is fine in editor?

Unity: 2019.4.12f
Obi: 5.6
Burst 1.3.6
Collections: 0.9.0 preview 6
Jobs 0.2.10 preview 12

[josemendez]

The freeze can be reproduced by:
 1. Set your rope with Burst backend.
 2. Add an empty game object with OniColliderWorld
 3. run this

The forever freeze happens when "Oni.UpdateColliderGrid();" is called in it.
I mean sure, why would you add OniColliderWorld manually. 
But then it doesnt matter, it neednt freeze.

Thanks for reporting! I will try to reproduce this. We're about to release an update in a bout a week or so, will see if I can squeeze the fix in.

On another topic:
How come my FPS is super low when running Burst backend in build, but it is fine in editor?

Unity: 2019.4.12f
Obi: 5.6
Burst 1.3.6
Collections: 0.9.0 preview 6
Jobs 0.2.10 preview 12

This is called death spiraling (aka well of despair, fixed timestep spiral, and many other names). It has been discussed in this forum a lot. We even have a video on it:
https://www.youtube.com/watch?v=sUVqa-72-Ms

Basically, this is an inherent limitation of the fixed timestep scheme used by Unity and many other game engines. Physics steps have a fixed duration in seconds. If a frame takes a long time to render for whatever reason (including physics calculation itself), to keep up with rendering it might not be enough to simulate physics just once during the next frame. Two, three or more physics updates might be necessary in a single frame. Updating physics isn't free though, so this might make the current frame to take even longer to render than the previous one, worsening the situation. This causes a downwards performance loop that will only stop once you reach Unity's max fixed timestep setting. However the game might not be able to recover from it at this point. The hallmark of death spiraling is FixedUpdate() appearing more than once per frame in the profiler, just like in your pic (x10). This means physics are being updated ten times per frame, which will bring performance down to a crawl.

Long story short: use a longer timestep or reduce your max fixed timestep.

As to why there's a difference in Burst performance in editor vs standalone of a single FixedUpdate() call, it's hard to tell. There shouldn't be any at all, as long as Burst is enabled (and supported) in your target platform. See: https://docs.unity3d.com/Packages/com.un...er-support

It also goes without saying that if your target hardware isn't as powerful as your desktop computer (for instance, if you're building for iOS or Android), performance there won't be as good as performance in the editor.

[whitexroft]

Just so you know. These screenshots are taken from the editor and a build on the same PC with the following specs

i7-7700 3.60 Ghz
RAM 16 GB
NVidia GeForce GTX 1070

So thank you for explaing that Fixed updates are accumulating, but that doesnt answer the question
Try explaining why Burst is not executing the same way between the two


Regarding the freezes and reproducing them. So we have noticed that your system spawns these OniColliderWorld game objects on its own in Editor time. Yesterday I thought it was in Play only. So it spawns, and then we (without knowing it) save them to the scene. Imagine, after that I decide to run Burst instead, and enforce it through all Ropes like this:

/*[SerializeField]*/ private BackendType m_Backend = BackendType.Burst;
ObiSolver.cs, line 101

This is where the freeze happens once you try loading a scene with a rope.

[josemendez]

So thank you for explaing that Fixed updates are accumulating, but that doesnt answer the question
Try explaining why Burst is not executing the same way between the two

Have you checked that Burst is enabled for builds, as I suggested? https://docs.unity3d.com/Packages/com.un...er-support

On the same pc, with Burst compilation enabled for standalone, the standalone build is about 5-10% faster than the editor for me. The build should never be slower than the editor, unless your code isn't being compiled by Burst.

Note: you should enable SSE4 to take full advantage of vectorization. SSE2 is a much older extension, and AVX2 isn't as widely supported, so chances are your build is falling back to SSE2.

Regarding the freezes and reproducing them. So we have noticed that your system spawns these OniColliderWorld game objects on its own in Editor time. Yesterday I thought it was in Play only. So it spawns, and then we (without knowing it) save them to the scene.

Imagine, after that I decide to run Burst instead, and enforce it through all Ropes like this:

/*[SerializeField]*/ private BackendType m_Backend = BackendType.Burst;
ObiSolver.cs, line 101

This is where the freeze happens once you try loading a scene with a rope.

I'm unfortunately unable to reproduce this :/. I've created a solver that uses Oni, saved the scene, then switched the solver to Burst programmatically, but it runs fine.

The Oni/BurstColliderWorld object lifetime is managed by the solvers using lazy initialization: in the case you outline, since the world already exists in the scene it won't be created again on first use: the existing instance would be used.