Calling burst code directly from C#? (2021.2)

Hi. I found that Unity 2021.2 supports calling burst function from C# without FunctionPointer.

Here is part of release notes:
https://unity3d.com/jp/unity/alpha/2021.2.0a5

But I can't find any details for this in Burst's documentation. Any information yet?

 

It is transparent to the developer. You just call the functions normally. The magic/difficulty is ensuring that the target code is compiled with burst (Use the BurstCompile attribute, make sure burst is on, etc)

However, there is additional marshaling overhead calling C++ from C#. So you should not make high-frequency calls to the burst compiled code. Just call it once per update, etc.

 

Doc page here: https://docs.unity3d.com/Packages/c...ang.html#directly-calling-burst-compiled-code

@sheredom The docs don't mention any marshaling / performance costs. Given the math examples is it "fine" to call burst code like this at high frequency? Or better to stick in managed land? Or does it not matter under certain circumstances, like if your code is compiled via IL2CPP?

Code (CSharp):

1.     [BurstCompile]
2.     public static void BurstCompiled_MultiplyAdd(in float4 mula, in float4 mulb, in float4 add, out float4 result)
3.     {
4.         result = mula * mulb + add;
5.     }

 

I took a look and some surprising results from running the code example here: https://github.com/keijiro/BurstDirectCallTest

fyi I am new to Unity, but a basic IL2CPP compile with unity's built-in profiler shows the following timings:

NoiseTexture.Update() timings:

• Burst Enabled (the code in github): 18.5ms
• Burst Disabled: 97ms
• Burst Enabled, Inline Unsafe: 16.8ms

The "Burst Enabled, Inline Unsafe" was done by passing the texture directly (as a NativeArray<Uint>) via a uint*. main code rewritten to:

Code (CSharp):

1.     [BurstCompile]
2.     public unsafe static void FillTexturePtrInline(float time, int _size, uint* buffer)
3.     {
4.         var offs = 0;
5.  
6.         for (var y = 0; y < _size; y++)
7.             for (var x = 0; x < _size; x++)
8.             {
9.                 //buffer[offs++] = TextureGenerator.GetPixel(x, y, time);
10.                 var pos = math.float3(x, y, time) * math.float3(0.008f, 0.008f, 0.5f);
11.                 var f32 = noise.snoise(pos) * 0.4f + 0.5f;
12.                 var un8 = (uint)(math.saturate(f32) * 255);
13.                 buffer[offs++] = un8 | un8 << 8 | un8 << 16 | 0xff000000;
14.             }
15.     }

with main code:

Code (CSharp):

1.         //optimized
2.         unsafe
3.         {
4.             var temp = _texture.GetRawTextureData<uint>();
5.             var p_texture = (uint*)temp.GetUnsafePtr();
6.             TextureGenerator.FillTexturePtrInline(time, _size, p_texture);
7.             _texture.Apply();
8.         }

I am surprised that the "Inline Unsafe" is only slightly faster. putting the loop in the burst function seems to have no effect. Basically this is saying don't bother with unsafe nor high-frequency inlining.

PS: something I learned: "using" the NativeArray disposes it at the end of the function.

 

Thanks for sharing information! It looks cool.

 

I'm not sure that's true. Given that 18ms is more time than you have to update the whole frame, shaving 2ms off that sounds like a pretty good deal That said, the body of the bursted function is quite heavy, and the ~65k bursted calls probably don't have a huge overhead.

From my testing it appears that calling bursted functions is fast enough that it's often worth it to burst-compile even small math utilities (eg. float3/quaternion SmoothDamp funcs). Obviously, the larger block you're burst-compiling the better, but low-hanging fruit optimizations are always nice.

 

Switching to Burst resulted in a drop from 97ms to 18ms and was basically "free".

The main problem I see is to shave off that 2ms you need to drop into unsafe and rewrite your code.

Sure having unsafe+inline as a tool of last resort is great, but there is almost always another way of vastly improving performance without resorting to unsafe.

In this example's circumstance, better time investment would be in:

• Update half of the pixels ever frame (further 50% perf improvement!)
• Decrease resolution / Interpolate pixels
• do in a ParallelFor job
• do all of the above