Is Unity multi-threaded?

One thing that's been bugging me for a while. Do the internal parts of the Unity engine take advantage of multi-core CPUs? I do know that you can't actually use multi-threading in your scripts but you can fake it using coroutines.

I've heard rumors that new upcoming Android devices next year will have dual-core CPUs, I was wondering if Unity can take advantage of that.

 

No they don't make use of multithreading generally. physics, rendering etc runs all on the same core basically so the Tegra 2 / Qualcomm MSM82xx MSM86xx will have an idling cpu at the current time (as do all windows boxes)

 

IIRC, Unity can only use one core and currently cannot utilise SLI or Crossfire. This seems feasible as technology changes frequently but it would be nice if Unity's architecture could temporarily accommodate such features as they arise.

I don't understand programming and I'm currently under the influence of cold beers, so I'll go ahead and stfu

 

You can use multi-threading in your own scripts no problem, but you can't touch Unity functions, only thread-safe .net functions. (See here for an example script in the third post.) Unity does use a certain amount of multi-threading for other things, such as mesh skinning I believe, though it's not generally going to make a huge difference.

--Eric

 

Since the unity API isn't thread safe you can't say that Unity is multithreaded. (and the things you can do with the mono threadsafe functions is very limited)

 

You can say it, since certain things that Unity itself does outside of scripting are multithreaded, as already noted.

I don't think so. The things where you would generally benefit from multi-threading (basically, computing lots o' data that can be easily parallelized) are all done without Unity-specific functions anyway. Anything Unity-specific is called after you've done your number crunching, as the example I linked to shows.

--Eric

 

Unity does a few things asyncronously, but I wouldn't called them multithreaded as loading asset bundles etc from WWW is not exactly "heavy" nor does it work correctly (still stutters on loading through load...async, which should not happen if it was fully implemented).

WWW is one of the primary things done on an own thread and one of the most common sources for the dreaded thread context error which takes down the whole editor (for me 2 - 10 times per hour on win7 64bit)

 

64bit and multi-core support would be nice for Unity4. What about for the xbox360 and PS3? They have multiple cores(xbox360=3, ps3=6/7?), will the code generated by Unity take advantage of their cores? Or maybe that's what will be big in Unity 3.5 when they release Unity support for those systems? I would think it would be bad to have Unity with only single core operation on those consoles.

 

Unity support for PS3/360 is already done. As to what sort of multicore support they have, somebody who's used them would have to say, but I wouldn't be surprised if there are NDAs involved, so maybe not.

--Eric

 

Just doubled checked and the Unity store page does not show xbox360 or PS3 version for sale. But I did read that you have to contact them for it? I thought I remembered reading about xbox support not coming until spring. I must have gotten it confused with something else. Then perhaps we can hope for better multithreading/multicore support come version 4.

 

Yes, same as the Wii version. There are certain requirements for it so it's not just a checkbox.

In the Unite keynote address they said you can get it now, but they're letting people in slowly so as not to overburden their support.

--Eric

 

...Unity 4...

A couple of days ago was released 3.1 version... I think that Unity 4 for now is only in coders mind.

We are planning to develope a non-game application with unity and I am really interested to know if is planned for near future any multithread updates for windows platform.

I will appreciate a lot an answer from somebody of the unity dev team.
Thanks in advance for any information.

 

Wii is actually mention on the store, but you need to drop sales a mail due to the nintendo licensee requirement. In U2 days the price was fixed and known, now it seems they are more flexible on that end (which can mean it costs less but also more though I doubt that as Unity isn't that genius that they can go beyond what other top notch known console engines cost and hope to get away with it )

But X360 and PS3 are indeed not mentioned at all, they are in beta right now from what mentioned and you can drop sales a mail as well on them (requirement for platform licensee likely applies there too) to see if you can get in

 

Hmm, i haven't written multithreaded stuff in Unity on my own yet.

I made a few experiments in BlitzMax some weeks ago which resulted into speedbumps about 60-70% with the tests i did.

So just to get some information:

Where is the best way to look for a start how to do it in Unity?

So generally you can only multihtread logic which doesn't call Unity's functionaliy, except certain parts of Unity which are supposed to be threaded by Unity on it's own, right?

Which parts are those?

Does it exclude all gfx functionality?

I thought stuff like the physics engine for instance would run on a seperate core/thread.

 

Probably the MSDN docs for System.Threading. The simplest format is (assuming you're including the System.Threading namespace):

Code (csharp):

1. Thread(MyCoolFunction).Start();
2.  
3. function MyCoolFunction () {
4.    // do some stuff
5. }

If you need to pass parameters it's a little more complicated.

You can't call any Unity APIs from your code at all. If it's in the Unity docs, it's a no-no, if it's in the MSDN docs and noted as thread-safe, it's OK.

--Eric

 

Nope, runs on the main thread actually, at least on Windows. (on osx such stuff is impossible to detect as OSX parallizes stuff that wouldn't be so it can use more than processor although Unity would push it all into 1)

Generally, touching anything thats within UnityEngine.* in a distinct thread is a no go
You can touch only stuff thats listed in System.* and mentioned in MSDN / go-mono as thread-safe

 

Hello Aras

Any "rumor" about future improvement for multithread or PhysX (hw acceleration)?

 

Aras, thank's for your answer, I understand your position and totally agree with you about development problems related to release dates.

We are designing a non-game application with high level graphics features that will run on special PC (more or less with dream-machines configuration).

Multithreading, 64bit and physics (http://forum.unity3d.com/threads/67865-Unity-3-Cloth) are under our observation....

 

@Eric5h5
Thanks, hmmm, well i would need to pass parameters and return values as well, otherwise i wouldn't be funky at all.

Is this done by call by reference or call by value?

 

See here.

--Eric

 

passing and returning is no problem. it just must not call into unity functions and objects nor instances of classes that extend by them (the easiest way to kill unity is accessing extends of monobehaviour, thats rather commonly a crash. Not only when you use threads but already asyncronous callbacks from plugins are enough)

 

Unity 3 doesn't let you access the Unity API in threads anymore, so it won't crash. The only downside is that it doesn't give any error messages if you try to do that either, so it just silently doesn't work.

--Eric

 

Doesn't it through errors / warnings at you in the editor?

Also, thread access is one thing, but plugin callback usage likely still works and still leaves you with totally meaningless error that come from the dark black deeps of mono. took me back then quite some time to realize that unity is not even callback safe (so basically just as broken as BM was prior threading addition) and therefor had some problems with a direct and performant implementation of NetDog

 

@Aras

...no any word about any possible physic improvements?

 

@Eric5h5
What would i do without my Unity hero! :O)

 

Nope:

Code (csharp):

1. function Start () {
2.     System.Threading.Thread(Test).Start();
3. }
4.  
5. function Test () {
6.     transform.Translate(Vector3.right * 100);
7. }

Nothing happens with that code...no errors, no movement. It's definitely better than Unity 2, where that code does run (except when it crashes), but ideally some user feedback would still be nice.

--Eric

 

Dear UT,

Please make a Resources.LoadAsync so Unity doesn't lag when I try to load an asset that is too big for certain hardware (i.e. old iPhones).

 

Not knowing what's going on behind the scenes, it would appear to me that "Importing Assets" could stand to be multi-threaded. Our projects tend to be quite large, and I'm currently trying to get latest from our asset server. In Windows it's importing all the fbx mesh and animation files with processor 1 of 4 maxed at 100% and the remaining 3 idling, as well using 1/4 of the total page file. It would be nice if it were capable of using at least 75% of the available resources to speed this process along.

 

import assets is multithreaded but that has no impact on the player at all, thats all editor stuff.

 

Am I doing something wrong? I don't see "importing assets" as multi-threaded. Attached is a screenshot, the only modification I've done to it is to paste a copy of the performance tab to the right side to show the processor activity I'm seeing.

I realise this is only in-editor as opposed to the webplayer or standalone build, but anything that would make even developing faster I would think is something that should be implemented. I can't get to the 'making stuff' if it takes me forever to get the assets imported at the onset, right?

 

potentially the new assets that are meant to be imported can't be parallelized. I get it primarily on full reimports and similar large reimports.
you don't get main on the parallel end if its only very few models or largely code for example.

 

This is quite possibly the best quote I have ever seen on these forums. It truly made me LOL.

Some of my best work has been CUI (Coding Under the Influence). Haha

 

Actually Unity 3 crashes a hell of a lot with even basic MIMD multithreading that's isolated and not working on unity data (and has been tested to be safe elsewhere), it just seems to not play well with many system functions, for instance any attempt to access or use many members of System.Diagnostics within or outside of the main thread results in a crash in Unity. Now some of that might just be issues with the version of Mono used, but it does make it feel pretty flakey when stepping off the well trodden path.

The other issues are that you have no way of setting the compile/command line flags currently. I'm sure that some of these issues occur because of that (and it sure would be nice to be able to use unsafe sometimes).

Of course to be fair in UT's defense this is not really relevant to 99.999999999% of game scripting. I'm sure that UT plan on continuing to improve the robustness of the app and integration with Mono and it's libraries too. I'm just looking forward to the point where it's seamless and there aren't any conflicts between the two (though there might need to be a few bits of renaming done in the main Unity library) especially with MP, and where we have a little deeper access to set the compile flags etc.

 

Meh, well, I know Unity "GAME LOOP" is single threaded, networking is in its own thread wrapped around the Unity game loop thread and is also single threaded, all actions must completed before a new game loop, nothing new there. Unity works well with parallel processing through, something to think about. I have used threading in my games, even my XVaders game on the Apple Store uses multithreading calls, I have a single EGO which controls the entire game and has threads for monitoring assets. (FYI the game was built as is so that my kids could play it easily, sure it was built with a 7 year old in mind at the time I made the game)

I am not sure what the problem here is, you can do your own game load balancing across CPU's if you know how.

 

It just crashes like crazy here, but I am looking at getting a bit more optimal performance than C# would like me to have by default, it's scheduler makes it nice and easy but in terms of raw performance it's frankly pants and seems to be based on the XP scheduler with it's schizophrenic core distribution that loses you at least 10% and up to 30% of the potential MP advantage.

Trying to manually set thread affinity in order to override this and get a little closer to approaching parity in a basic non-locked MP block calculation test is perfectly possible in C# using System.Diagnostics.ProcessThread, however any attempt to access this from a script in Unity results in instaboom regardless of the thread it's running in here. Considering this is with libraries that are included with the Unity Mono installation and so we have to assume are meant to work (unlike e.g. Mono.SIMD which is part of Mono 2.2 but isn't included with Unity so you're likely to assume it's pretty unlikely to work) all in all it makes it feel like you really shouldn't go outside of the Unity library and most basic of C# functions, and that it's not currently geared up for more intensive app development and even moderate CPU thread optimization.

However like I said to be fair to UT looking to do this sort of optimization is more relevant to non-game apps and so probably slightly unfair with Unity which is always going to be first and foremost a game engine. Round peg square hole sort of thing.

 

going outside the Unity library is no problem

Going outside and trying to use threading and async functionality though can become a major troublemaker.

worst is that you might assume it works cause it works on windows, drop it on osx and get ot bomb around your head right away and alike as there are major differences in the behavior and we've found Unity 3 to be much more picky and troublesome on osx than on windows especially when it comes to async / thread offloaded functionality, even unity own ones

 

Hmm.. this is interesting... so when it was "Importing Assets" on fbx files it could only use a single processor, but as soon as it got to textures or scripts it was able to max all processors... very strange.

 

@ Greymarch - probably because the FBX importer is part of Unity and all unity access is threadlocked while the text and bitmap loading may well just use system functions (or they may a. have specifically set it up this way or b. missed those ones).

@dreamora - That's disappointing then. I'd love to be able to use and trust Unity and Mono for rapid cross platform prototyping (though maybe Mono is still an option), and avoid C++ which while it makes threading a doddle for all platforms the whole wrapping everything up for cross platform development and general speed of dev using C++ is much less fun.

 

Well, just a few suggestions as a starting point, OpenCL is a native framework as of 10.6 on the Mac, and is cross platform to Windows, however, you are required to own Pro for this to work, understand how to write using COCOA and have a firm grasp of the Pro Plugin feature (not managed code aka C# or MCPP) unfortuntately this does not work for Android and I have the original iPhone so I haven't bothered to push anything for it out to that device. Here is a few links for research to help get you started:

http://www.khronos.org/opencl/
http://developer.apple.com/library/...L_MacProgGuide/Introduction/Introduction.html
http://software.intel.com/en-us/articles/download-intel-opencl-sdk/
http://developer.amd.com/gpu/AMDAPPSDK/Pages/default.aspx


Nothing worth while is ever easy, and this has its uses, but you have to decide if it is something you really need for your game. Typically speaking, a single threaded game is fine 99% of the time, where you want multi-threading and parallel processing is CPU intensive work. That said, this is good for headless server mode or if you write your own server to work cross platform. Now in truth, Unity is multi-threaded just single processer, it has child threads each for their own purpose, but doesn't span CPU's. I have never really bothered monitoring the GPU use since I only have one machine with multiple GPU's and sadly that one is stuck on a research project right now so I can't use it for testing.

Start out by pulling up XCode and get yourself familiar with the OpenCL library set, how it works, etc, repeat on Windows in what ever flavor of C++ you like writing in, create a simple library and test in Unity while monitoring your CPU's, if you code it right, you should see workload across the cpu's, you can even have messages sent from each library module or each method that states what CPU it is running on with percentage of CPU use.

Play with it some.

 

I could be wrong, but I believe that the FBX importer is a closed library available from AutoDesk, which would make it pretty unsafe, unwise, and/or impossible to use it in multiple threads.

I couldn't find any open source for it or any documentation for reading an FBX, but again, I may be wrong, can anyone confirm this?

edit: When I say "no documentation", I mean very specific documentation detailing how to read in an FBX without using the AutoDesk Library (IE. creating your own independent FBX importer). I know the library itself is documented as to loading/saving an FBX through it.

 

I will disappoint if 64bit and multi-core only available in Unity 4, that means there are 2 to 3 years to wait, it 2011 now while other engine can offer that, why Unity can't?

http://www.pcgameshardware.com/aid,704779/Assassins-Creed-2-PC-is-DX9-only/News/

And more here:

Multithreaded Game Engine Architectures
Designing the Framework of a Parallel Game

 

They have been working on making the engine solid in other areas. 64-bit is still relatively new as well. Only within the past year or so have I seen the majority of consumer pc's sold defaulting to 64 bit OS's. The average consumer will still be using their old 32 bit machines for a while. It wouldn't have been wise for the young company of Unity to jump into 64bit without much of a need for it. 64bit Unity is currently in the works I believe. Remember, the people we make games for have to have the hardware/OS to run 64bit software. If the majority of consumers don't have it, then we don't really need to focus on making 64bit games available.

Unity is gaining strength and market share though so I wouldn't worry. I would bet that in 5 years time they will be on par with all other major engines. I mean, just look at how fast it currently is evolving, and have you seen those Ninja Camp videos on the blog? That's some impressive work.

I would also like to note that Unity makes game developing much easier than other engines. The folks at UT put a lot of time and effort into making their game engine accessible and easy to use, which takes away dev time from other areas.

 

Feel free to go to any other engine

I have, and found them so complex to be unusable - UDK not only has it's own language, but even when following paid video tutorial's I couldn't get the 'hello world' script to work.

It would be nice for unity to have a lot of features other engines have - but don't forget the (crucial) features that it has that the other engines don't.

 

No, not spread it over multiple threads, but to put it in a single thread separate from the main one, so you're not stalled waiting for the importing to be done while doing other stuff that are not relevant to that fbx file.

 

Unity3D 3.5 Feature

 

You do have a point there. If they could do it without having to rewrite the import pipeline that would be wonderful, but , if they have to do code gymnastics to get this to work, I'd much rather them spend time where it counts the most, in the run-time portion of the engine.

 

Just a quick FYI, I started a thread here to hopefully get people to start writing their own multithreaded code. Because there are many areas in Unity where you can use it. It would be next to impossible to get the folks at UT to make sure your code is using all CPUs. If you don't have an ultra GPU intensive game, your code may just be what takes up the most time in a game anyway.

http://forum.unity3d.com/threads/90676-Multithreading-Solutions