Burst 1.1.1 new release

So do the explicit layout fixes mean it now plays nice with BlobAssetReference? So we can burstify Unity.Physics collider creation?

 

This version will just not work for me. None of my jobs will burst compile in editor.

going to try a full re-import.

-edit-

yep even after clearing cache and re-importing none of my jobs (or any jobs form unity packages) will burst compile. 2019.3a8

-edit2-

turning on synchronous compilation causes jobs to burst again.
turning it off causes jobs not to burst compile.
So yeah issue is something to do with the async burst compiler i guess.

Side note, shows how important burst is
No burst

Burst

Just a casual, 18-39x faster.

-edit3-

downgraded project to 2019.2b9, issue still exists.

TLDR: if anyone else has issues, turn on Synchronous Compilation.

 

Hmm works fine for me even without turning on Synchronous Compilation (Burst 1.1.1 and Unity 2019.3a8).

I double-checked the profiler and the Burst inspector, all the jobs are indeed burst-compiled.

Only thing I noticed was that upon first upgrading to Burst 1.1.1 (from 1.1.0p4), there was some error about not being able to load file or assembly Smash. It fixed itself after I exited+reopened the project.

 

Hi! BlobAssetReferenceData is now Burst compatible with this fix. However note that some of the collider factory methods in Unity Physics still take e.g., managed arrays. Those ones still need to be ironed out in the physics package, but we expect everything else should be fine now. Let us know if you see something different.

 

Just want to clarify. Will this work even with a not up to date Unity.Entities? Still stuck with preview.30.

 

OK I kind of got to the bottom of it after toggling this a bunch of times and doing some testing, I noticed after one attempt when I resumed playing after taking a sample all the jobs are finally burst compiled.

After testing I realized it's taking much longer for burst jobs to asynchronously compile than I expected, over 20 seconds after playing.

I downgraded to 1.0.4 with same code base to compare, and it did take nearly as long (was around 15 seconds but this wasn't exactly a scientific test so could be the same) so there is probably no regression here and it appears to be working fine.

So I apologize if I wasted anyone's time. It looks like it simply takes much longer than I remember since I last checked and after I upgraded and went through did some tests to make sure new version was working and jumped the gun.

 

I don't recall updating any package, but is this causing https://forum.unity.com/threads/unity-physics-discussion.646486/page-13#post-4746608

 

Projects with Unity Physics and Burst are still not working on Android devices...

 

FYI the Android issue is not about Burst. The was an alignment issue on the jacobians that crashed on Android. We have a fix that will be in the next release.

Spoiler

If you want to fix this locally then

- in com.unity.physics/Unity.Physics/Dynamics/Jacobians/Jacobian.cs
and the

ReadJacobianHeader

functions, change all references of

short

to

int

.

- in com.unity.physics/Unity.Physics/Dynamics/Solver/Solver.cs and the

InitModifierData 

function change

short jacobianSize = (short)JacobianHeader.CalculateSize 

to

int jacobianSize = JacobianHeader.Calculatesize

 

hey @xoofx once you told me:

"We have known issues with function pointers that will require more work on our side to make it possible for a public release (e.g exceptions in a burst compiled function are not handled at all as they are handled in the burst job system)"

is the reason of calling the CompileFunctionPointer inside jobs that there is not handling of exception otherwise, which would result in a hard crash, or is there something else? I would like to see an example too, not sure about its reason to exist

 

@xoofx Can you make FunctionPointer._ptr accessible via a property, please?

Code (csharp):

1. public IntPtr Ptr {
2.    get { return _ptr; }
3. }

This would be enough.

 

I'm having trouble getting

BurstCompiler.CompileFunctionPointer

to work. Here's a simple test case:

Code (CSharp):

1. using UnityEngine;
2. using Unity.Burst;
3.  
4. delegate void D();
5.  
6. public static class C
7. {
8.     public static void F()
9.     {
10.     }
11. }
12.  
13. class TestScript : MonoBehaviour
14. {
15.     void Start()
16.     {
17.         BurstCompiler.CompileFunctionPointer<D>(C.F);
18.     }
19. }

When I run this with Unity 2019.1.10f1 and Burst 1.1.1, I get the following error:

InvalidOperationException: Burst failed to compile the given delegate: Void F()

Unity.Burst.BurstCompiler.Compile[T] (T delegateObj) (at Library/PackageCache/com.unity.burst@1.1.1/Runtime/BurstCompiler.cs:120)
Unity.Burst.BurstCompiler.CompileFunctionPointer[T] (T delegateMethod) (at Library/PackageCache/com.unity.burst@1.1.1/Runtime/BurstCompiler.cs:78)
TestScript.Start () (at Assets/TestScript.cs:17)
​

Does anyone know how to get this to work?

 

Any progress on getting EntityCommandBuffer to work with Burst?

 

https://forum.unity.com/threads/pow...-in-early-access-vr-game.610750/#post-4763774

 

@jacksondunstan To compile functions with Burst, they should be marked with the appropriate attribute, so put [BurstCompile] to your F() and it will work. Also, instead of declaring delegates, you can use Action and Func<TResult> as generics to reduce the amount of code.

Code (csharp):

1. using System;
2. using UnityEngine;
3. using Unity.Burst;
4.  
5. public static class C {
6.    [BurstCompile]
7.    public static void F() { }
8. }
9.  
10. class TestScript : MonoBehaviour {
11.    void Start() {
12.        var functionPointer = BurstCompiler.CompileFunctionPointer<Action>(C.F);
13.    }
14. }

 

Cool! How is the function pointer used after that?

 

You can pass it to a job with the same generic FunctionPointer<Action> as any other structure an then call Invoke().

 

Good afternoon Alexandre,

Do you have a moment? I would like to ask a question regarding BurstRuntime.GetHashCode32<T>. Is it deterministic across all the platforms? For instance, difference in Endianness on Mac. Assuming that some of the CPU works only with Big Endian hence the byte order of the Type.AssemblyQualifiedName might be different.
Also, would you be able to add the 16 bit support for the hashcode?

I am gladly appreciate your work.
Thank you.

 

This doesn't answer your question but i think it adds relevant information:
https://forum.unity.com/threads/reading-data-with-pointer-operation.584584/#post-3908620

[]'s

 

Thanks for pointing out that I needed to add the [BurstCompile] attribute. It now works in the editor, but errors in a standalone build. Here's the error I get when using your above source code with Unity 2019.2.0f1 and Burst 1.1.2 on macOS 10.14.6:

InvalidOperationException: Burst failed to compile the given delegate: Void F()
attribute: Unity.Burst.BurstCompileAttribute

at Unity.Burst.BurstCompiler.Compile[T] (T delegateObj) [0x00000] in <00000000000000000000000000000000>:0
(Filename: currently not available on il2cpp Line: -1)​

Is there something else I need to do to make this feature work?

 

Looks like an issue with the Burst itself since it works fine in the editor.

 

Yes i have same problem and i was not able to fix it.
I've tested many approach but FunctionPointer fail all time on Build.

"InvalidOperationException: Burst failed to compile the given delegate"

 

Thank you. I have faced an issue on the current version of Burst 1.1.2 with generic calls of a job. A generic job compiles and runs fine in Editor mode but not in the build mode. Is there a possible fix for it?

https://forum.unity.com/threads/burst-job-inside-of-generic-class.614737/

 

Hey guys, following the conversation with Joachim here Scheduling jobs from NOT a MainThread I would like to ask for help with compiling and launching this job outside the JobSystem using CompileFunctionPointer<T>:

Code (CSharp):

1. [BurstCompile]
2. struct OceanJob2 : IJob
3. {
4.     public NativeArray<Vector3> vertices;
5.  
6.     public float time, rippleStrength, scale;
7.  
8.     public void Execute()
9.     {
10.         for (int i = 0; i < vertices.Length; i++)
11.         {
12.             float3 vertex = vertices[i];
13.             float2 offset = new float2(vertex.x, vertex.z);
14.             float ripple = math.sin(time + math.length(offset));
15.             vertex.y = ripple * rippleStrength;
16.             vertices[i] = vertex;
17.         }
18.     }
19. }

Thanks!