Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice

2D Use Multithreading does not work as expected

Discussion in '2D' started by URocks, May 23, 2018.

  1. URocks

    URocks

    Joined:
    May 1, 2014
    Posts:
    159
    I have system when i am emitting and jointing circles so they are forming wobbly stream, but the limit on android is maximum 300 circles, after that the frame rate drops significantly. With use multi-treading on options i could emit more circles to have same frame rate but the physics behave completely different. The wobbliness completely stops and the stream is super stable (and not affected by gravity like in no multi-treading scene) which is bad in this scenario. Is it possible to fix this , so the result will be more consistent between multi-threaded and no multi-threaded versions?

    Thanks a lot.
    PS: I can even post sample scene but i dont know where
     
  2. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,409
    Is this with useConsistencySorting set to true? Do you get different results inside the editor or only on Android?

    I'll be honest though, I'd need to see a video comparison because it's not clear what "wobbliness completely stops" means in real terms.
     
  3. URocks

    URocks

    Joined:
    May 1, 2014
    Posts:
    159
    i tryed with use ConsistencySorting on and off but its not different. There is different behaviour between non multithreaded and multithreaded version. The joints are very strong or something..

     
    Deeeds likes this.
  4. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,409
    Is there any chance I could get this test project? It may be the default parameters for the island solver cost threshold. This limits how many items can be contained within a single island but I could find out exactly what the difference is.

    Projects like these are gold while this is in the experimental state!

    In the meantime, I would check the profiler to see how many islands are produced in MT and non-MT. From looking at it you'd mostly have 1 large island in non-MT but potentialyl lots in multithreaded.

    A little explanation though might help. In theory, there are only two things that can change the behaviour in the MT solver:
    1. Not sorting contacts
    2. Limiting how large contact islands can be
    Both of these can be controlled using those settings. To allow for more parallel processing, limiting island sizes is good because each island can be solved separately. Even a single island can perform solving across threads so it's still possible to effectively remove the limit from those settings. Sorting can potentially take time and restores the determinism of the non-multithreaded code (although even that is not deterministic in all cases).
     
    Last edited: May 23, 2018
  5. URocks

    URocks

    Joined:
    May 1, 2014
    Posts:
    159
    I can send it to you but can you give me some address, because i dont want to post it here. The difference is mostly in diferent behaviour of joints, with multithreading they are super stiff, but the gameplay would not work anymore in that case
     
  6. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,409
    A good way would be to send it attached to a bug report from the editor and send me the case number. That way we can both track it and any work can be done and reported against the case.
     
  7. URocks

    URocks

    Joined:
    May 1, 2014
    Posts:
    159
    I just submitted it it is Case 1041509
    Thaks a lot for helping
     
    MelvMay likes this.
  8. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,409
    Just to say that I can duplicate the issue here and will investigate shortly.
     
    Deeeds likes this.
  9. URocks

    URocks

    Joined:
    May 1, 2014
    Posts:
    159
    Perfect, thanks a lot
     
  10. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,409
    Just a heads-up to say that I managed to narrow this down to a much simpler test with fewer joints which makes things much easier to isolate, especially as it's multi-threaded too.

    It's most certainly an issue when calculating position constraints during iteration. I've yet to isolate which part yet though but closing in. I'll keep you updated.
     
    Deeeds likes this.
  11. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,409
    LiterallyJeff, hippocoder and BusyCat like this.
  12. URocks

    URocks

    Joined:
    May 1, 2014
    Posts:
    159
    Amazing, thanks a lot!
     
  13. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,409
    Thank you for providing a really useful reproduction case, certainly helped finding the issue which was annoyingly subtle.
     
    BusyCat and URocks like this.
  14. URocks

    URocks

    Joined:
    May 1, 2014
    Posts:
    159
    Hi Melv i tryed new version (2018.2.5f1) where this bug is fixed, but when i build and run it on my android phone (samsung galaxy s6 edge) it will crash after unity logo screen, version without checked multitreading works fine
     
  15. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,409
    Hmm, that is very odd indeed given the changes. This doesn't crash in the editor, only on the player? Does this happen with your original submitted test case? Only on Android?
     
  16. URocks

    URocks

    Joined:
    May 1, 2014
    Posts:
    159
    In the editor everythink works without problem, when i run it on android it crash, you can try it with the original submitted test case, it is crushing also there on android. I didnot tryed different platforms so for now only android is bad
     
  17. URocks

    URocks

    Joined:
    May 1, 2014
    Posts:
    159
    Should i make new bug report?
     
  18. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,409
    No need, I've scheduled to look at this in the morning using the old bug report however if you'd like another bug report to track this then go ahead and let me know the issue.
     
  19. URocks

    URocks

    Joined:
    May 1, 2014
    Posts:
    159
    I can wait till tomorrow, if you will have same behaviour, please let me know. Thanks a lot
     
  20. URocks

    URocks

    Joined:
    May 1, 2014
    Posts:
    159
    Hi Melv, did you experienced the crashing on android after multithreading was turned on?
     
  21. URocks

    URocks

    Joined:
    May 1, 2014
    Posts:
    159
    I reported the bug it is Case 1077387
     
  22. any_user

    any_user

    Joined:
    Oct 19, 2008
    Posts:
    374
    I also experience a reproducible crash since 2018.2.5 with multithreading on, in a project that worked without problems in earlier versions until 2018.2.4. The crash happens in the editor and in builds. If I switch multithreading off everything works fine. Let me know if an additional bug report would be useful.
     
  23. any_user

    any_user

    Joined:
    Oct 19, 2008
    Posts:
    374
    @MelvMay Here's another bug report: 1082697

    In this case it just freezes the editor as soon as a rigidbody is active. Seems to be connected to manually simulating.
     
  24. any_user

    any_user

    Joined:
    Oct 19, 2008
    Posts:
    374
    @MelvMay I found another issue that seems related to this one.

    Hinge joints seem to not connect to each other at their anchor positions when multithreading is enabled. They just keep their current world offset, while without multithreading they try to move to match the anchor points.

    When I checked this with older unity versions, I noticed that it worked fine in 2018.2.4, but stopped working before 2018.2.12 (where the crash bug was fixed).

    here's the report: 1109272

    The report is sent with 2018.2.19 but it's also reproducible in 2018.3.0f2
     
  25. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,409
    Thanks for the report!
     
  26. NobleRobot

    NobleRobot

    Joined:
    Jan 14, 2016
    Posts:
    56
    I am having similar problems with Multithreading when using HingeJoint2Ds. In my game, I have hanging ropes/cables (with pieces connected with HingeJoint2Ds) that come apart out when Multithreading is enabled, and reconnect when Multithreading is disabled. Here is an example video, where you can see the difference as I turn MT on and off

    (I'm using 2018.2.13, and for separate reasons am unable to upgrade the project to 2018.3.x)



    In the video, you can see the pieces are stretched out. At 0:06 I turn off Multithreading, and the rope starts to "pull itself together" until it behaves normally. At 0:24 I turn MT back on, and as I interact with the object, the pieces start coming apart again. The Collider2Ds on each piece are set as Triggers in the video, but they totally freak out if they're set as Colliders, as seen below:



    I've tried various solutions to this, including putting distance joints on each piece, all connected to the rope's origin point. This seems to work somewhat (it's not perfect, but it seems "shippable"), and it lets me set the colliders as colliders, but I worry it creates a lot of overhead.



    In other areas of my game, having Multithreading enabled simply prevents batches of physics objects with Joint componants from being simulated at all, and my only solution is to disable MT at runtime in those areas. I know that MT is "experimental," so I shouldn't rely on it, but it's been a huge performance boost in other areas of my game where I don't need to worry about objects with 2D Joints.
     
  27. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,409
    The joint issue (case 1109272) reported above has been fixed and is being backported to previous versions. The fix hasn't landed in a public release yet but has been verified against new tests on our build farm and a PR is in progress for several release versions.

    It related to an incorrect early-out in the multi-threaded solver which solves contacts/joint constraints; it was skipping the joint constraints if there were no contacts which is incorrect. For contact islands where contacts are happening you wouldn't see it.
     
    any_user likes this.
  28. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    170
    We've noticed that the overhead cost of managing the jobs or whatever is going on for multithreaded physics 2d is measurably greater than the performance savings of getting things off the main thread.

    This is true in the general case on both android and windows. This is especially true when nothing interesting is going on.

    Even when jamming a bunch of circles together to make sure the island solver is getting a good workout, multithreaded physics2d generally performs worse than old vanilla threaded physics2d. We've tried playing with the tuning variables a bit, but nothing has made a marked improvement. This could be the nature of our project, YMMV.

    If you are having troubles with multithreaded physics2d, I would advise making some performance measurements and making sure it's even worth pursuing.
     
  29. NobleRobot

    NobleRobot

    Joined:
    Jan 14, 2016
    Posts:
    56
    For me, it's absolutely worth it. Multithreading improves performance in our game by 15-20%, in the editor and on our various target hardware. There doesn't seems to be a single scenario in our game where the overhead of spinning up and managing extra jobs/threads is greater than the gains made when splitting the workload among them.

    As you say, this is likely to vary project to project, but for us, it's like a magic "make go faster" button.

    If only its behavior were more reliable! :p
     
  30. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,409
    I agree and there's a couple of things at play here. Firstly, there seems to be a huge difference in how jobs are scheduled on different platforms and projects. This comes from the job-system scheduler and in a handful of cases we see tasks split into multiple-jobs but running consecutive on a few cores whilst others are idle as opposed to it going fully wide on many cores. This is the case with jobs taking upwards of 1ms.

    The other aspect is the contact islands. Island traversal and production should take the same amount of time as it's done on the main thread however when an island is produced, it's then scheduled as a job. The size of the island (which can be controlled via the "island threshold" properties) can vary wildly. Contact islands of a few up to thousands. Controlling this has proven to be "interesting". In many games, the island solver brings little benefit so it was something to be looked at i.e. running without it making the production of jobs easier to split. Certainly, ensure that you use the threshold to ensure those islands are kept small.

    Unfortunately this had little work beyond a few fixes during the last few releases.
     
  31. jhoffman0x

    jhoffman0x

    Joined:
    Nov 4, 2015
    Posts:
    2
    How do you manage to split one large island in non-MT into potentially lots of islands in MT?

    Since all bodies in an island are connected to each other through contacts and joints, the resulting islands after a split would need to share at least one dynamic body. The islands would have local copies of any shared body's velocity and position, which would be out of sync after solving. You could average the results at the end but this would definitely affect the quality of the simulation.
     
  32. MelvMay

    MelvMay

    Unity Technologies

    Joined:
    May 24, 2013
    Posts:
    11,409
    We don't, we only merge smaller islands until a threshold is reached. Each island is solved wide.
     
  33. jhoffman0x

    jhoffman0x

    Joined:
    Nov 4, 2015
    Posts:
    2
    Yeah that's what I thought. I think you meant the opposite when you said "you'd mostly have 1 large island in non-MT but potentially lots in multithreaded," or I misunderstood the context.

    Either way thanks for the clarification.