First off let me say, I’m having a lot of fun with Unity 5.0 so far. I’m really liking it Of course, that’s usually the case when I’m getting things to work correctly.
So I was wondering how to use the job scheduler. Is there any rudimentary documentation on it yet? For instance, how do I call it, and put things into it? What types of things can go into the scheduler. Because I heard that some things (like Physics functions) cannot be “multi-threaded” – for instance Physics.Raycast or Physics.OverlapSphere and things of that nature. Is that correct?
I’m wanting to do a simple Vector3.Distance check in a separate thread and then use the value calculated every frame, or almost every frame. I’m assuming that’s okay to do in the job scheduler?
Right now it’s strictly internal to the engine’s C++ code. We run various “tasks” (animation, culling, skinning, etc.) on it. To be fair, Unity 3 & 4 also had a “job scheduler” internally, just in 5.0 it’s much more efficient & flexible.
You can do multithreading with System.Threading, it’s pretty easy. But Vector3.Distance should be faster without, since you have more overhead than actual calculation time
Even though it does not add any public APIs, you can see the new Job Scheduler in action if you have a scene with many multi-threadable tasks (for instances skinning, animation, physics, particles), and then open the profiler, and switch to the new Timeline profiler (click the popup which defaults to “Hierarchy”). This lets you see what all threads are doing over the time of a frame, and you can see how other tasks are being finished on worker threads while new tasks are being started simultaneously (which Unity 4 could not do, it would always finish one set of tasks before starting the next).
So I guess, we still can’t use Unity’s API on separate threads? Is there chance for this in 5.x ?
Im also curios about Physx multithreading, as from what I see physx engine still use only 30% of CPU time( on Unity’s thread of course ) even if scene is really loaded with physx elements.
I can’t have even 500 kinematic box triggers on scene without really long physx time on profiler, it’s ridiculous imho( I have I5 4670k ), funny is when I change them to non-triggers, physx calculations almost dissapear. Looks like triggers much harder on physx I guess?
Correct, nothing has changed about Unity APIs in this respect.
5.x is a going to cover a long time, but at this point, I am not aware of specific plans to change this.
Check the timeline profiler. If you have a scene with lots of physics objects, you should see a lot of Physics.Job items across all threads.
Not sure about triggers being specifically expensive, I never heard about this. What is “really long physx times”? You can file a bug report with a test scene for us to check it out.
I mean that on profiler physx takes more than 8-10ms per frame.
However I must admit, I didn’t even know there is threading timeline profiler, which is very interesting and I’ll take a look at this when I’ll be at home for sure.
I guess it’s okay that it does everything automatically/internally. I mean, it’s less work for me to have to do I guess. I have to say, I do see better performance so far in terms of skinning in particular, just giving it a little bit of stress in terms of skinned mesh renderers and just in general overall. I havn’t tested much with Physics yet, but I’m assuming it will be much better as well – at least I hope mesh colliders in particular are faster.
Performance is huge to me, and I’m glad you guys are making improvements in that area.
Of course, that’s usually the case when I’m getting things to work correctly.