We are pleased to release a new version of Burst 1.1.1 with the following fixes, new features and improvements:
Many bug fixes, please upgrade from 1.0.x which is no longer updated/supported
Improve performance when detecting if a method needs to be recompiled at JIT time
Add support for SharedStatic<T> to allow sharing mutable static data between C# and HPC# (not yet activated in this version, will be available in 1.1.2)
Add support for FunctionPointer<T> usable from Burst Jobs. Compile your function in C# via BurstCompiler.CompileFunctionPointer<T> and use it from an HPC# Job
Add support for structs with explicit layout (see known issues)
Add support for BurstCompiler.Options to allow controlling/enabling/disabling Burst jobs (compilation/run) at runtime
Add support for BurstRuntime.GetHashCode32<T> and GetHashCode64<T> to allow generation of a hash code for a specified type from a HPC# job
Add support for reporting a compilation error when writing to a [ReadOnly] container/variable (preview)
Add support for new math.bitmask(bool4)
This new version of Burst relies on a new version of Unity.Mathematics 1.1.0.
Our documentation is still not entirely up-to date with these latest features but we are going to update it in the coming weeks.
With this version, Burst also becomes a verified package for the upcoming Unity 2019.3! A verified package implies that the Unity’s Quality Assurance team has officially verified that this package works with a specific version of the Editor.
For this version, we have known issues that you should be aware of:
Burst is compatible with Unity versions 2018.4 and up. However, see note immediately below (also see the documentation for additional notes for specific platforms)
For the new 2019.3 version of the editor our support starts from 2019.3.0a8 (already available); using this version of Burst with prior alpha versions will give an error
When upgrading to a new version of Burst via the package manager (or even when changing your manifest.json), Burst can’t be unloaded, so the upgrade will fail. You need to close and re-open the editor, and in some cases remove the old Burst package from the Package Cache before opening the editor again
While upgrading from a previous 1.0.x version, you might encounter an error saying that the assembly Unity.Burst cannot be found and the GUID for the assembly doesn’t match. We actually unintentionally broke this GUID while moving from 1.0.x to 1.1.x, our apologies for this breaking change. In order to fix this, you need to manually edit your asmdef in case it is using the GUID. The most common case is while you reference Unity.Burst, you need to use GUID 2665a8d13d1b3f18800f46e256720795
We have also updated the known issues in the package documentation.
Let us know what you think about this new release!
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.
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.
Hello! @tertle we are trying to reproduce the issue with some test projects we have without success unfortunately.
Could you please provide some details about the jobs you are trying to burst?
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.
Hi! @tertle thank you very much for checking. Compiling asynchronously means that you are at the mercy of whatever workload is going on at the time (burst may not get time, if heavy cpu usage for instance, it’s a thread and will time slice) so, the time fluctuations you are experiencing are very likely due to this.
@davenirline we just checked whether there are compatibility issues between the new burst package and entities package preview.30 version and there are no apparent incompatibilities on our side.
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.
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
“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
I’m having trouble getting BurstCompiler.CompileFunctionPointer to work. Here’s a simple test case:
using UnityEngine;
using Unity.Burst;
delegate void D();
public static class C
{
public static void F()
{
}
}
class TestScript : MonoBehaviour
{
void Start()
{
BurstCompiler.CompileFunctionPointer<D>(C.F);
}
}
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()
@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 as generics to reduce the amount of code.
using System;
using UnityEngine;
using Unity.Burst;
public static class C {
[BurstCompile]
public static void F() { }
}
class TestScript : MonoBehaviour {
void Start() {
var functionPointer = BurstCompiler.CompileFunctionPointer<Action>(C.F);
}
}
