Spine-Unity and ECS, the Job System and the Burst Compiler

Cranktrain

Hey! I just want to start a discussion about the pretty major future changes that are eventually coming to Unity, the foreshadowing of which is available in 2018. I can find references to these features as far back as 2013, but the general long-term idea is that there's going to be a fundamental shift in how games are written from the Monobehaviour/OOP to an Entity/DDP over the next few years. The whole point of such a move is to allow Unity to get a lot more performance from optimising compiled code, managing data in memory better, spreading CPU work out among worker threads, etc. The vision doc Unity have written outlines the aims pretty well.

I'm keen to see if Spine is able to soon take advantage of any/all of these performance offerings. My project has hundreds of Spine objects animating every frame and SkeletonAnimator can take up 30%+ of my frame time. Rather than every SkeletonAnimator.Update taking its turn, the idea of spreading them out in parallel jobs sounds good to me!

It's definitely way too early to start any actual work on migrating Spine-Unity to Systems or Jobs: the API is still in-flux, its documentation is pretty sparse, and the ECS doesn't even support Animator/Mecanim yet. But I'd love to see what's possible with Spine!

Helpful links if anyone wants to read through: This is Unity's current docs on the subject, such as they are. I also found this blog post pretty helpful in getting my head around how ECS works. Finally, a video of a parallelised job that sets the vertices of a mesh.

Cranktrain

Pharan

Yep, we have plans of supporting the new Unity job system.

If it turns out that we can't make a solution available with spine-unity out of the box because of some API limitations or non-generalizability, the plan is also, at minimum, to make it so that it's easy for people to write their own solution without having to mangle the spine-unity runtime.

Cranktrain

That's great news! Glad to hear it.

Bringing this thread back to life now that DOTS and the Burst Compiler have moved out of Preview with 2019.1.

Any further thoughts and plans on supporting this future-way-of-doing-things in Unity?

Harald

There is a ticket here regarding performance optimizations, you can subscribe to it to get email notifications upon updates:
https://github.com/badlogic/spine-internal/issues/287

It is part of our roadmap here:
Spine Roadmap

We have to note however, that we are working with high priority on ensuring compatibility of our existing feature set with Unity 2019 and fixing bugs, these optimizations will be tackled thereafter.

tonydongyiqi

Any progress on Unity optimization ?
Spine in Unity runing On DOTS is really needed~

foriero

I guess it will come after Harald is freed from 4.0 release. I see it Autumn. :-)

Harald

Some code reorganization work for 4.0 is already in progress which is also laying the foundation for migrating to DOTS / Unity's job system. Unity's job system integration (parallelization in general) will then be implemented on top of this modified 4.0 codebase.

foriero

That is a great news. Look forward to it.

bklooster

I just want to throw my support and state that we desperately want some multi threading in the spine runtime. I'd say that 70% of our main thread time is purely devoted to SkeletonAnimation.Update (UpdateWorldPosition) and SkeletonAnimation.LateUpdate, and when you're trying to target 60 fps on some rather limited console hardware it is definitely a limiting factor for us to hit 60 fps. We're going through and reducing verts (LateUpdate) and bones (update) but if we could utilize some under-utilized cores to handle this work would help us out a ton. We've upgraded to the 4.0 runtime in hopes that we might be able to either do some work ourselves or be able to eventually pull some work from the runtime down. A lot of this stuff seems like it'd be perfect for jobs/burst since it's so math heavy iterating over a large collection of data. The problem I see is that this is using Spine-csharp which is very class/object heavy instead of array-based struct data that Jobs prefer.

Harald

bklooster escribió
I just want to throw my support and state that we desperately want some multi threading in the spine runtime.
..
The problem I see is that this is using Spine-csharp which is very class/object heavy instead of array-based struct data that Jobs prefer.

Thanks for offering your help. Could you please re-write all of our runtimes using pre-allocated memory and in-place construction upon load-time? Just kidding 😉. We will not get rid of the current "one object per bone/constraint/etc" design until we replace it with a pre-allocated solution, which is planned but will not happen in 4.0 but some later version.

bklooster escribió
The problem I see is that this is using Spine-csharp which is very class/object heavy instead of array-based struct data that Jobs prefer.

You are mixing two things here. Using array based struct data, which actually means using Unity's Entity Component System to automatically re-arrange data of each struct, can improve cache locality. The benefit of using jobs is utilizing multiple cores instead of a single one to distribute workload. While good or bad cache locality will have an additional effect on each core's cache, it is a more or less orthogonal performance improvement. In general, the current object-based structure, with separate instance and shared data, is not expected to perform badly cache-wise in a multithreaded context (in regards to cache thrashing / false sharing).

Regarding using spine-csharp: we will always use the spine core-runtime of the respective language, not using spine-csharp is not an option here 🙂.

In general the best way anyone can assist us is by answering questions on the forums, which helps us devote more time to programming instead of replying to forum postings.