Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Where does the multithreaded renderer really shine?

Discussion in 'Developer Preview Archive' started by NathanWarden, Feb 14, 2012.

  1. NathanWarden

    NathanWarden

    Joined:
    Oct 4, 2005
    Posts:
    663
    Hi all, and hopefully Unity dev team.

    Just had a quick question that's been on my mind for a couple of weeks. In what area(s) does the multithreaded renderer really shine in? I'm going to make a wild guess and say draw calls, but I'm just trying to find out where I can get away with more of X (X being whatever the multithreaded renderer takes advantage of).

    Thanks,
    Loving the cool new stuff in 3.5,
    Nathan
     
  2. Kaspar-Daugaard

    Kaspar-Daugaard

    Unity Technologies

    Joined:
    Jan 3, 2011
    Posts:
    150
    Hi Nathan,

    Unity dev team checking in ;)

    We got a lot better at drawing scenes that are mostly static geometry, i.e. you don't use skinned meshes everywhere or modify vertices and materials on the fly. The reason is that we need to synchronize all changes between the threads. Anything whose properties didn't change, we can just say "hey, draw this like you did last frame" and it gets processed extremely quickly. Most of the time is spent in the video driver and that happens on a thread far away from any game code.

    Skinned meshes are still fine, but they were multithreaded even in 3.4 so you won't notice any difference. Moving static meshes around is fine too, we get the speedup by knowing you didn't change the mesh itself. You want to be a little careful with dynamically created geometry but we've done what we can to make sure it's not slower than before. Fortunately in most games, a lot of geometry never changes.

    Hope this helps,
    Kaspar
     
  3. NathanWarden

    NathanWarden

    Joined:
    Oct 4, 2005
    Posts:
    663
    Thanks Kaspar, so would it be safe to say that the main place it spends it's time is in static batching? Or am I misunderstanding?

    Thanks again,
    Nathan
     
  4. NTDC-DEV

    NTDC-DEV

    Joined:
    Jul 22, 2010
    Posts:
    593
    Hi Kaspar,

    Reading from the release notes... is a multithreaded solution for the webPlayer on the works or we shouldn't have our hopes up?

    With 3.5 out now, the performance disparity between WebPlayer and Standalone has just increased twice fold. When trying to sell the web export option to the client, it's hard to not lose the performance argument.
     
  5. Kaspar-Daugaard

    Kaspar-Daugaard

    Unity Technologies

    Joined:
    Jan 3, 2011
    Posts:
    150
    We do static and dynamic batching on the render thread, as well as communicating with OpenGL or Direct3D. It's hard to say which part is more expensive, and typically it's the main thread that's blocking you anyway. To make the main thread fast, you should stay away from too much updating (from script) of geometry and materials.

    It's possible to start both Unity editor and player in single-threaded mode to do your own comparison. It's a command line switch: -force-gfx-direct
     
  6. Kaspar-Daugaard

    Kaspar-Daugaard

    Unity Technologies

    Joined:
    Jan 3, 2011
    Posts:
    150
    It will take a bit of effort for us to make this work, mostly because of all the different browsers we have to test. I agree it makes sense to support WebPlayer multithreading, so I'm sure we'll get it eventually. We just ran out of time before 3.5 release.

    Kaspar
     
  7. NathanWarden

    NathanWarden

    Joined:
    Oct 4, 2005
    Posts:
    663
    Thanks Kaspar, this'll be super helpful,
    Nathan
     
  8. NTDC-DEV

    NTDC-DEV

    Joined:
    Jul 22, 2010
    Posts:
    593
    Thank you Kaspar. Best of luck for making it work!
     
  9. taumel

    taumel

    Joined:
    Jun 9, 2005
    Posts:
    5,292
    Vicious circle . o O