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.
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.
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.
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.
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):
Thread(MyCoolFunction).Start();
function MyCoolFunction () {
// do some stuff
}
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.
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
Right now unity does multithreaded mesh skinning (uses as many cores as there are); also audio, network, and some smaller things are on separate threads. We have more multithreaded stuff in the works (like some noticed, that’s quite important on Xbox 360 / PS3).
What? I totally did not understand that part about OS X confused
Are you CPU limited? Multithreading won’t do anything for performance unless you’re CPU limited (*) and your target market has multicore CPUs.
(*) Other stuff that might be bottlenecks: GPU (various bottlenecks on it) or system memory bandwidth / latency.
I don’t want to commit to any actual promises, because usually something unexpected happens, ship date slips, or we have something else to do, and then people complain “bbbbut you promised!”. More multithreading is in the plans, that’s all I can say.
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).