Burst job apparently not working on one PC, also where is the jobs package?

Unity Engine
1

Hey everyone.

I’ve made substantial use of Burst + Jobs on my previous project (no other ECS), worked great.

I’m now integrating similar on a new project, which was just upgraded to Unity 2021.1.27F

First of all, where is the Jobs package in the package manager? I see Collections and Burst, but not Jobs. The jobs are present and compiling so I assume something is here, but I thought it would still be a package? Is there some change here that I’m missing?

Second, on my system we’re getting a solid 140+ FPS in the editor, the core simulation all happens in a (burst) job for about 2 ms. Without burst this core job takes ~18ms. We have a second job execute, also with (burst), in about 1 ms. These are scheduled within a FixedUpdate call of about 4 ms on the main thread (the FixedUpdate starts by completing the previous frame, then sets up the new work, and ends by scheduling the jobs). So far so good.

On one of our dev’s machines, i7, we’ve seen a substantial performance drop.

On his PC the FixedUpdate call now takes 22 ms. The second job still shows up for ~1ms, but we cannot find the first in the profiler at all. There are no errors, and the system appears to be running normally other than the performance drop.

If we turn off Burst compilation entirely his performance drops to under 3 fps, so it was clearly doing something.

What this looks like to me is that the core sim job is just executing on the main thread without burst as part of the fixed update call. I honestly don’t know how this could be possible–is this a thing? There’s nothing really special about this job other than a whole lot of simulation math on a large native array of fairly big structs (not great practice, but working fine everywhere else). If I put something non blittable in there we get loud errors, so I’d expect if it failed to compile or such we’d hear something.

Is it possible to have this silent failure of either a job or burst and have it just run on the main thread? The fixed update call (run at 25 fps) should give plenty of time for the scheduler to find a spot, and the jobs foldout in his profiler is a long list of waiting threads with plenty of space.

If its possible to have a complete job/burst failure, is there any means of diagnosing it? Are there any known causes for such an issue? Could this be related to the recent update from 2020.3.1F4 to 2021.1.27?

2

Just to double check - have you added CompileSynchronously = true on that job that you suspect is running with managed?

What you could do to be 100% certain is use a little hack like:

[BurstDiscard]
private static void SetManagedTrue(ref bool b) { b = true; }

private static bool IsManaged() {
  bool b = false;
  SetManagedTrue(ref b);
  return b;
}

// Then in your job
if (IsManaged()) throw new Exception("OH DANG");

This’ll let you be certain whether Burst is running that job or not.

1 Like
3

Hi Sheredom, that is an excellent probe. I’ll get that added and report back.

We have synchronous compiled forced on for all jobs in the toolbar dropdown; asynchronous doesn’t make sense when all the main logic that runs from frame one is burst.

1 Like
4

Is your other developer running Windows 7?

5

Good question, but no, Windows 10