Search Unity

  1. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

The job scheduler

Discussion in 'Unity 5 Pre-order Beta' started by Velo222, Nov 2, 2014.

  1. Velo222

    Velo222

    Joined:
    Apr 29, 2012
    Posts:
    1,437
    First off let me say, I'm having a lot of fun with Unity 5.0 so far. I'm really liking it :D 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?

    Anyone have some experience with it yet?
     
  2. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    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.
     
  3. Carpe-Denius

    Carpe-Denius

    Joined:
    May 17, 2013
    Posts:
    842
    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
     
  4. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    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).
     
    elbows likes this.
  5. Roni92

    Roni92

    Joined:
    Nov 29, 2013
    Posts:
    225
    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?
     
  6. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,666
    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.
     
  7. Roni92

    Roni92

    Joined:
    Nov 29, 2013
    Posts:
    225
    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.
     
  8. Velo222

    Velo222

    Joined:
    Apr 29, 2012
    Posts:
    1,437

    Thanks for the info and the heads up guys :)

    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.