Detect jobs skipped by burst

I have quite a few generic jobs and those are only compiled in the build if i have the concrete job declared somewhere in my code.
I would like to throw some warnings for the jobs that were not burst compiled but i don't know what is the best way to achieve this.
Ideally i would like to manually compile the concrete versions without having to declare them, maybe with an attribute like [RegisterGenericJobType] but for that i don't even know how to begin.

 

I was able to collect all generic jobs that are not compiled by burst using Cecil and traversing through all assemblies discovering if exists any concrete version of that job declared anywhere.
My next step is using Cecil again and add those concrete jobs in the offended assemblies. Not really sure yet if this will work out...

 

I'm now at at the point that i inject the concrete job types into the assemblies but they wont be burst compiled in the build.
What i'm doing is:

1. Scan assembly using Cecil and gather all possible generic jobs paths to a concrete instantiation
2. Recursively resolve those generic types from the concrete instantiation until reach the generic job
3. Inject the resolved generic types into a static method add a call to ToString() to make it detected by burst.

I do all this on CompilationPipeline.assemblyCompilationFinished but it's not working.
I have inspected the newly inject assembly and the new iL code is there.

@xoofx you are the expert here and can probably tell me what i am missing.

My inject static method is suppose to result in something like this for a resolved generic job:

GenericJob

Code (CSharp):

1.   [BurstCompile]
2.   public struct MyJob<Type> : IJob {
3.     public void Execute() {
4.       ...
5.     }
6.   }

Expected result
NOTe: Adding this manually in c# will make the job burst compile

Code (CSharp):

1. class TestConcreteJobs {
2.  
3.   public static void Main() {
4.     new MyNamespace.MyJob<float>().ToString();
5.   }
6. }

Cecil code to inject the type looks like this:

Code (CSharp):

1.     public static void AddTypes(AssemblyDefinition assembly, string name, IEnumerable<TypeReference> types) {
2.       var module = assembly.MainModule;    
3.       var mainType = new TypeDefinition(name, name,
4.         TypeAttributes.Class | TypeAttributes.Public, module.TypeSystem.Object);
5.       module.Types.Add(mainType);
6.       var mainMethod = new MethodDefinition(
7.         "Main",
8.         MethodAttributes.Public | MethodAttributes.Static,
9.         module.ImportReference(typeof(void)));
10.       mainType.Methods.Add(mainMethod);
11.  
12.       var toStringMethod = module.ImportReference(
13.         typeof(object).GetMethod(nameof(object.ToString)));
14.       mainType.Module.ImportReference(toStringMethod);
15.  
16.       var iL = mainMethod.Body.GetILProcessor();
17.       for (var i = 0; i < types.Count(); ++i) {
18.         var typeReference = module.ImportReference(types.ElementAt(i));
19.         var localVar = new VariableDefinition(typeReference);
20.         mainMethod.Body.Variables.Add(localVar);
21.         iL.Emit(OpCodes.Nop);
22.         iL.Emit(OpCodes.Ldloca_S, localVar);
23.         iL.Emit(OpCodes.Dup);
24.         iL.Emit(OpCodes.Initobj, typeReference);
25.         iL.Emit(OpCodes.Constrained, typeReference);
26.         iL.Emit(OpCodes.Callvirt, toStringMethod);
27.         iL.Emit(OpCodes.Pop);
28.       }
29.       iL.Emit(OpCodes.Ret);
30.     }

Thanks

 

For your original question, when you do a mono build (and I think il2cpp as well but I don't have that set up at the moment to check), under the plugins folder you can find lib_burst_generated.txt which contains which jobs it compiled or attempted to compile.

I actually solved this problem a completely different way. My first approach was to procedurally generate a new assembly as a custom build step and drop it into the assets folder. I describe the approach here: https://github.com/Dreaming381/Lati...tarted.md#why-is-findpairs-so-slow-in-a-build and the awfully written code that does it is here: https://github.com/Dreaming381/Lati...ysics/Physics.Editor/PatchGenericBurstJobs.cs

However, I wasn't happy with that solution because I wanted to allow interface implementations defined in user code to be defined privately as that's just good programming practice. I also wanted the generated code out of the assets folder. So I tried a different approach and just got it working last night!

The idea is to define an IPostBuildPlayerScriptDLLs class with the callbackOrder set to -1. At this point, the assemblies live in two different locations: Library/PlayerScriptAssemblies and Temp/StagineArea/Data/Managed. I have a dummy assembly definition file and dummy class sit with the package, and during the IPostBuildPlayerScriptDLLs execution, I generate a custom C# file and compile it using this trick: https://www.strathweb.com/2018/10/n...lem-bypassing-c-visibility-rules-with-roslyn/ I then overwrite the dll in the two locations.

I'm not very experienced with Cecil, so this solution might seem stupid. It's definitely not a long-term solution either. But I am getting Burst to compile generic jobs with it where the jobs and the generic argument types are defined in completely different assemblies. Maybe some of this might help unblock you?

 

This really guided me. I was writing the assembly to the wrong folder (/Library/ScriptAssemblies/ instead of /Library/PlayerScriptAssemblies/).
Ended up writing on CompilationPipeline.compilationFinished and it now works fine.
Writting in IPostBuildPlayerScriptDLLs works too but i would have to write to Temp/StagineArea/Data/Managed because at this stage the assemblies were already copied .

That really comes in hand I wasn't aware of that file.

That is a neat trick.

If you use Cecil you can skip that all together because you can inject private jobs/types from other assemblies in your new assembly without any problem.

This sure unlocked me and i thank you for that.
Using cecil you can also work with types defined from completely different assemblies. What i do now i scan all user assemblies and gather the concrete jobs.

I will make my solution available other can use or change to their own needs.

 

Glad you got it working! I look forward to seeing how you did it. I had a heck of a time today switching my code from using reflection on the current AppDomain to using Cecil on the staged assemblies so that I accounted for preprocessor differences. I plan on releasing my solution sometime next month, so it will be interesting to compare speed and flexibility. My gut tells me your solution is a lot better though as I've seen people do some pretty insane stuff with Cecil.

 

Cecil is really great for this.
I'm also a newbie on Cecil and just started using it for this purpose 15 days ago
On my solution i ended up injecting my types in Assembly-CSharp.dll since i don't want to create a dummy package just for injecting stuff. I tried csc.rsp file for referencing a newly assembly but unfortunately that assembly it's not part of the compilation pipeline and doesn't get compiled by burst

 

I haven't seen that dll in over a year. I forgot it existed. All my game code uses 1-5 asmdefs and so I don't actually have that dll show up in my build.

 

Are you using your libraries as standalone (so anyone can use it without using Unity itself)?
I haven't thought about if someone wants to use these libraries as part of their own projects without building a unity player.
Assembly-CSharp.dll will always be be built if one builds project. Unless i'm overseeing something it will always be the main dll for any project so it makes sense to inject into it.

 

Nope!

I just have all my c# files associated with one asmdef or another in my projects, and the assembly-csharp.dll never shows face.

 

Here is how i've approached resolving generic jobs in order to make them burst compile.
If someone want to just use it, here is the link to add on Package manager:

It uses Cecil to scan all player assemblies and resolves any unresolved generic jobs. Then injects those resolved generic jobs now with their concrete parameters into the main assembly of the player.
All this happens in the PostBuildPlayerScriptDLLs right before burst compilation.

 

I am not sure why you need to burstify code that is not used. Sorry I skimmed the thread, what am I missing?

 

I'm not burstifying code that is not used. If the code is picked by my package is because it is used somewhere and uses generics.

 

and what's wrong with generics? I am not sure I understood the problem. Are you saying that generic code is not burstified? (by the way, this thread is really useful as source of information to know how to modify code after compilation, is something I needed a long time ago, but I may need it again in future )

 

In the editor burst is fine because it is JIT, but the standalone player it is AOT so all generic jobs that don't have an explicit concrete call will not be burst compiled.
For example this job:

Code (CSharp):

1.   [BurstCompile]
2.   struct RotateJob<T> : IJobForEachWithEntity<T>
3.     where T : struct, IComponent, IRotator {
4.  
5.     public void Execute(Entity entity, int index, ref T c0) {
6.       ...
7.     }
8.   }

If you have something like this anywhere in your code it will burst compile with no problem:

Code (CSharp):

1.     new RotateJob<MyRotatorComponent>()
2.       .Schedule()

But often you might want to call it from generic systems or call it from another function that takes a generic parameter (i do this a lot for extensions jobs for containers). An there you will have a problem where it wont compile.

Code (CSharp):

1.   public void ScheduleRotation<T>()
2.     where T : struct, IComponent, IRotator {
3.     new RotateJob<T>()
4.     .Schedule();
5.   }

And then

Code (CSharp):

1. ScheduleRotation(MyRotatorComponent);

Well, you could write a concrete version of your generic jobs for every type you need but that is tedious and you are rewriting the same code over and over. Also when this happens on other packages that you can't change you have no other option.
For example even Unity.Entities package has generic jobs that will not be burst compiled due to the reasons mentioned above.
On my project for instance i've found these on Unity packages:

Code (CSharp):

1. Unity.Collections.NativeList`1/DisposeJob<Unity.Entities.BlobAssetPtr>
2. Unity.Collections.NativeSortExtension/SegmentSort`1<Unity.Entities.EntityInChunk>
3. Unity.Collections.NativeSortExtension/SegmentSortMerge`1<Unity.Entities.EntityInChunk>
4. Unity.Collections.LowLevel.Unsafe.UnsafeHashMap`2/DisposeJob<System.UInt64,Unity.Entities.ArchetypeChunk>
5. Unity.Collections.LowLevel.Unsafe.UnsafeHashMap`2/DisposeJob<System.UInt64,System.Int32>
6. Unity.Entities.GatherComponentDataJob`1<Unity.Transforms.LocalToWorld>
7. Unity.Entities.GatherComponentDataJob`1<Unity.Scenes.ResourceGUID>
8. Unity.Entities.GatherComponentDataJob`1<Unity.Scenes.SubSceneGUID>
9. Unity.Entities.GatherComponentDataJob`1<Unity.Entities.SceneReference>
10. Unity.Entities.GatherComponentDataJob`1<Unity.Scenes.LiveLinkPatcher/LiveLinkedSceneState>
11. Unity.Entities.GatherComponentDataJob`1<Unity.Entities.SceneSectionData>
12. Unity.Entities.GatherComponentDataJob`1<Unity.Rendering.WorldRenderBounds>
13. Unity.Entities.GatherComponentDataJob`1<Unity.Transforms.PreviousParent>
14. Unity.Entities.CopyIndexedValues`1<System.Int32>

Sure burst probably will do this at some point in time and there will be no need to use an approach like the one i'm having.

 

ah that's quite interesting, I wonder what @xoofx think about it.

 

The approach i took here on scanning is actually based on some post of his here in the forum.

Have you tried to make a standalone build of your project and profile it to see what jobs are being burst compiled?

 

yes they are, we don't use generic jobs ourselves, we didn't need them yet (the ones you have seen in the other post come from Havok)

 

Hi! Have you published such solution/code? Can I get a link?

 

Yes it is here.
You can add it using package manager Add package from git URL ->

Code (CSharp):

1. git@github.com:GilbertoGojira/DOTS-Stackray.git#com.stackray.burst-latest

 

Thanks!

 

I used Add package from git URL. I get these errors:

 

I added the project as submodule instead and added the package via local folder.

Edit: Editor crashes when trying to build.

 

I just run it on an experimental project i'm working on and had no problem.
What version of Unity + Burst are you using?

Also after you build a log file will be generated at `Logs/burst_injected_jobs.log` with the list of all concrete jobs that were generated.

 

Unity 2019.3.14, Burst 1.3.0 preview 10

 

Ive been trying to follow this thread but it over my head, is there a noob way to check if job are bursted in editor and builds. I always assumed if it was bursted in the editor it was also busrted at build. And my primitive way of checking this is looking in the profiler timeline and looking for (burst). After reading this im feeling a paranoid about what is actually bursted at build

 

You have to make a build and profile it from there to actually know if the job is bursted or not.

In the editor burst will work on generic types because it will compile those types JIT but in an actual build it compiles them AOT making any generic job which the generic type can't be figured not to be complied. This means that any jobs that doesn't have a concrete instantiation to be skipped by Burst.

Here is an example:

Code (CSharp):

1. [BurstCompile]
2. struct MyJob<T> : IJob {
3.   public void Execute() {
4.     // Your job
5.   }
6. }
7.  
8. class GenericSystem<T> : SystemBase {
9.   protected override void OnUpdate() {
10.     Dependency = new MyJob<T>().Schedule(Dependency);
11.   }
12. }
13.  
14. // This system will execute a MyJob<int> but not explicitly
15. // Hence it wont be bust compiled
16. class MyConcreteClass : GenericSystem<int> { }
17.  
18. // If this class is manually added the job will now be  burst compiled
19. // And this is what the the package does behind the scenes using code generation
20. static class MyConcreteJobs {
21.   static void CreateJobs() {
22.     new MyJob<int>();
23.   }
24. }

If you don't use generic systems or generic jobs that don't have a concrete instantiation then you don't need to worry. There is nothing to be paranoid about.
I do use a few generic systems and felt the need to create such package and share it with others. Use it if you need it.
For instance i can see that Physics package also uses quiet a few generic systems and even Entities itself even though they might not be critical they are still not being burst compiled.

Here is a scan of the UnityPhysicsSampes:

Spoiler: Build log for UnityPhysicsSamples

2.254s to inject 55 concrete jobs in assembly 'H:\Projects\EntityComponentSystemSamples\UnityPhysicsSamples\Temp\StagingArea\Data\Managed\Assembly-CSharp.dll'
Unity.Collections.NativeSortExtension/SegmentSort`1<Unity.Entities.EntityInChunk>
Unity.Collections.NativeSortExtension/SegmentSortMerge`1<Unity.Entities.EntityInChunk>
Unity.Collections.NativeStream/ConstructJobList`1<Unity.Mathematics.int2>
Unity.Entities.GatherComponentDataJob`1<Unity.Transforms.LocalToWorld>
Unity.Entities.GatherComponentDataJob`1<Unity.Rendering.WorldRenderBounds>
Unity.Entities.GatherComponentDataJob`1<Unity.Scenes.ResourceGUID>
Unity.Entities.GatherComponentDataJob`1<Unity.Scenes.SubSceneGUID>
Unity.Entities.GatherComponentDataJob`1<Unity.Entities.SceneReference>
Unity.Entities.GatherComponentDataJob`1<Unity.Scenes.LiveLinkPatcher/LiveLinkedSceneState>
Unity.Entities.GatherComponentDataJob`1<Unity.Entities.SceneSectionData>
Unity.Entities.GatherComponentDataJob`1<ModifyNarrowphaseContacts>
Unity.Entities.GatherComponentDataJob`1<CustomCollider>
Unity.Entities.GatherComponentDataJob`1<Unity.Transforms.Translation>
Unity.Entities.GatherComponentDataJob`1<Unity.Transforms.Rotation>
Unity.Entities.GatherComponentDataJob`1<Unity.Physics.PhysicsCustomTags>
Unity.Entities.GatherComponentDataJob`1<CustomVelocity>
Unity.Entities.GatherComponentDataJob`1<Unity.Physics.PhysicsMass>
Unity.Entities.GatherComponentDataJob`1<Unity.Physics.PhysicsDamping>
Unity.Entities.GatherComponentDataJob`1<Unity.Physics.PhysicsGravityFactor>
Unity.Entities.GatherComponentDataJob`1<Unity.Physics.PhysicsJoint>
Unity.Entities.GatherComponentDataJob`1<Unity.Physics.Extensions.MousePick>
Unity.Entities.GatherComponentDataJob`1<Unity.Transforms.PreviousParent>
Unity.Entities.CopyIndexedValues`1<System.Int32>
Unity.Entities.SegmentSort`1<System.Int32>
Unity.Entities.SegmentSortMerge`1<System.Int32>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/CreateBlobAssetsJob<Unity.Physics.Authoring.PhysicsShapeAuthoring>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/CreateBlobAssetsJob<UnityEngine.BoxCollider>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/CreateBlobAssetsJob<UnityEngine.CapsuleCollider>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/CreateBlobAssetsJob<UnityEngine.SphereCollider>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/CreateBlobAssetsJob<UnityEngine.MeshCollider>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/GeneratePhysicsShapeHashesJob<Unity.Physics.Authoring.PhysicsShapeAuthoring>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/GeneratePhysicsShapeHashesJob<UnityEngine.BoxCollider>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/GeneratePhysicsShapeHashesJob<UnityEngine.CapsuleCollider>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/GeneratePhysicsShapeHashesJob<UnityEngine.SphereCollider>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/GeneratePhysicsShapeHashesJob<UnityEngine.MeshCollider>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/DisposeContainerJob`1<Unity.Physics.Authoring.PhysicsShapeAuthoring,Unity.Entities.Hash128>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/DisposeContainerJob`1<UnityEngine.BoxCollider,Unity.Entities.Hash128>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/DisposeContainerJob`1<UnityEngine.CapsuleCollider,Unity.Entities.Hash128>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/DisposeContainerJob`1<UnityEngine.SphereCollider,Unity.Entities.Hash128>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/DisposeContainerJob`1<UnityEngine.MeshCollider,Unity.Entities.Hash128>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/ProduceConvexCollidersJob<Unity.Physics.Authoring.PhysicsShapeAuthoring>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/ProduceConvexCollidersJob<UnityEngine.BoxCollider>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/ProduceConvexCollidersJob<UnityEngine.CapsuleCollider>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/ProduceConvexCollidersJob<UnityEngine.SphereCollider>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/ProduceConvexCollidersJob<UnityEngine.MeshCollider>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/ConvertToHashMapJob`2<Unity.Physics.Authoring.PhysicsShapeAuthoring,Unity.Entities.Hash128,Unity.Entities.BlobAssetReference`1<Unity.Physics.Collider>>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/ConvertToHashMapJob`2<UnityEngine.BoxCollider,Unity.Entities.Hash128,Unity.Entities.BlobAssetReference`1<Unity.Physics.Collider>>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/ConvertToHashMapJob`2<UnityEngine.CapsuleCollider,Unity.Entities.Hash128,Unity.Entities.BlobAssetReference`1<Unity.Physics.Collider>>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/ConvertToHashMapJob`2<UnityEngine.SphereCollider,Unity.Entities.Hash128,Unity.Entities.BlobAssetReference`1<Unity.Physics.Collider>>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/ConvertToHashMapJob`2<UnityEngine.MeshCollider,Unity.Entities.Hash128,Unity.Entities.BlobAssetReference`1<Unity.Physics.Collider>>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/ProduceMeshCollidersJob<Unity.Physics.Authoring.PhysicsShapeAuthoring>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/ProduceMeshCollidersJob<UnityEngine.BoxCollider>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/ProduceMeshCollidersJob<UnityEngine.CapsuleCollider>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/ProduceMeshCollidersJob<UnityEngine.SphereCollider>
Unity.Physics.Authoring.BaseShapeConversionSystem`1/ProduceMeshCollidersJob<UnityEngine.MeshCollider>

My package will not only scan the "user" code but all the other packages code in search for a generic job that has no concrete implementation.

 

Awesome thank so much for this explanation

 

Once the non bursted jobs are known, what can we do to make them burst compiled? I tried adding the concrete types in an AssemblyInfo but doesn't seem to work.

 

The manual way of doing it is to create a class and add a dummy method just to instantiate those concrete versions of non burst compiled jobs.

For example create class like this:

Code (CSharp):

1. static class MyConcreteJobs {
2.   static void CreateJobs() {
3.    // Can't remember if one needs to have a call to any method for it to work
4.     new MyJob<int>().Schedule();
5.   }
6. }

This will allow for Bust to find `MyJob<int>` and compile it.
This can be painful if you have lots of those generics and if third party assemblies have such generic jobs their jobs might not be publicly accessible for you to do this.

 

Sorry. I've missed this.
I have tested using UnityPhysicsSamples project in Unity 2019.3.14f1, Burst 1.3.0 preview 10


My results:
Mono .Net2.0 Build OK Run OK
Mono .Net4.0 Build OK Run OK
IL2CPP .Net2.0 Release c++ compiler Build OK Run OK
IL2CPP .Net4.0 Release c++ compiler Build OK Run OK
IL2CPP .Net2.0 Master c++ compiler Build OK Run FAIL
IL2CPP .Net4.0 Master c++ compiler Build OK Run FAIL

I haven't experience any crash building it in any occasion.
Running with IL2CPP Master c++ compiler seems to crash with or without my package so it is something for Unity to look at.