I start saying that this is the first time I am having this problem on our project. So far we used the job system and burst only for few things, mostly related to Physic ECS and Havok. I spent the last 3 weeks to jobify/burstify a considerable amount of code (much more must be done) and I learned a lot from it. What I didn’t want to learn was to find out that the code that works fine in the editor, is not burstified once the client is built. I checked the log and I don’t see anything wrong with it, but when I profile the code, all the jobs result not burstified.
Log:
D:\RobocraftX\Library\PackageCache\com.unity.burst@1.2.0-preview.11.Runtime\bcl.exe exited after 27630 ms.
stdout:
Creating library C:\Users\Seb-e-Sam\AppData\Local\Temp\burst-aototqbdch2.qf5\lib_burst_generated.lib and object C:\Users\Seb-e-Sam\AppData\Local\Temp\burst-aototqbdch2.qf5\lib_burst_generated.exp
Compile and Link 442 methods successful in 26891ms: D:\RobocraftX\Temp\StagingArea\Data\Plugins\lib_burst_generated.dll
those jobs are burstified in the editor and they have been previously burstified on a standalone client too. I didn’t change the burst version nor that code during the last three weeks, they were previously working as expected in the client. I need direction to understand what’s going on. On Monday I will continue this investigation.
By the looks of the timeline profiler it doesn’t seems like it.
Try deleting BurstAotSettings_StandaloneWindows.json and the other possible platform json files in project setting folder. I’ve seen people having problems with that not resetting properly.
I am back to the office and my colleague reminded me that this is actually an old problem. It’s a bug that it happens with some Havok jobs that arises ONLY when a dev client is built (which I need to profile it). I forgot about it, as it works fine when a release client is built.
I have this problem with explicitly typed generic jobs. They were working on Burst 1.1 as far as I remember, but not anymore so I was wondering if what you have said about non dev build can be verified.
It’s not so simple, but I am doing it. The reason is because (as I remembered while doing it) generic structs are not considered unmanaged, so they cannot be used by Burst. What people do to solve this, is a semi-ugly work-around which is probably the culprit of the issue. They use a combination of CreateJobReflectionData and JobScheduleParameters.
I created a test, but it has a slightly different side effect. The job is burstified and runs in the editor, but if I build a client it doesn’t run at all. It runs when I stop using [BurstCompile]. Do you think it’s good enough?
Edit: I have a better understand of what’s going on now. First it’s not true that generic jobs cannot be burstified (I wonder what problem I hit at the begin of this test now), second the pattern using CreateJobReflectionData and JobScheduleParameters is used actually to introduce a new kind of Job interface (akin to IJob, IJobParallelFor and so on).
I am spending more time on it because I am finding out that some previous understanding of mine were wrong (it’s not true that generic jobs cannot be burstified per se), can you show me the code of the jobs that are not working for you?
[BurstCompile]
public unsafe struct FieldChangeDetectionJob<T1> : IJobChunk where T1 : unmanaged, IComponentData
{
The job wrapper class. That later on will be instantiated via Activator.
public class FieldChangeDetector<T1> : FieldChangeDetector where T1 : unmanaged, IComponentData
{
public unsafe override JobHandle Schedule(JobComponentSystem jobComponentSystem, JobHandle jobHandle)
{
return new FieldChangeDetectionJob<T1>
{
Explicitly typed job so it is visible in Burst inspector and included during AOT.
public unsafe struct TestingEntityArchetype1 : IReplicatable<Health>
{
public ReplicationTypeModel ReplicationTypeModel => new ReplicationTypeModel
{
PriorityConstant = 1000,
PriorityDistanceMultiplier = 3000
};
public FieldChangeDetectionJob<Health> FieldChangeDetectionJob => new FieldChangeDetectionJob<Health>();
}
Above will work on earlier version of Burst 1.0. But not on the current.
To ensure that Burst sees the job I use Burst inspector to see if it is compiled. If it is then it should be Bursted in build. At least that was the behavior with Burst 1.0
I don’t think that’s true.
Any job in editor that is executed will be bursted (that can) as it’s JIT but only jobs that can be determined by the AOT compiler will be bursted in a build. This is why generic jobs don’t work unless explicitly specified because the AOT is not smart enough to figure out what generic versions are required.
They are explicitly typed in my property. Hence they work. They are not working if they are not visible in Burst Inspector. I tested it multiple times and made generic works. It broke with Burst update. I tested it in in dev build on Burst 1.0 and they were Bursted. But they are no longer Burst ed with the new Burst update and I do not know why. The jobs are even included in lib_burst_generated.dll, I can see their tokens.
public FieldChangeDetectionJob<Health> FieldChangeDetectionJob => new FieldChangeDetectionJob<Health>();
If you can share that it’d be grand!