Will Unity 5 be multi-core?

Will Unity 5 be multi-core, that is will the engine use all available cores and will the Unity Engine scripting components be thread safe?

 

Yes?

 

So if those jobs are scripted then the core scripting components will need to be thread safe.

The question is what is a job?

 

I guess it will be similar to the .Net Task class where you assign a method/delegate to the Task/Job manager instead of starting a thread on your own

 

A job is a piece of computation you need to do. Typically, you can only touch core API (like input, graphics, etc.) from the main thread. When you have large chunks of parallel computation to do (say physics, particles, flocking, simulation, mesh manipulation, etc) you package them into jobs and send them to the scheduler. You don't want jobs that are too big or too small; there is some overhead for too many small jobs and too many big jobs might be harder to efficiently schedule. Once the scheduler runs all your jobs you get the results back on the main thread, and can update your meshes, textures, transforms, etc.

I wouldn't expect everything to automatically be multithreaded, but you should be able to offload most of the heavy lifting to helper threads.

 

I was hoping for a multi-core/threaded version of Unity that would automatically run scripts/components on separate cores as batches of jobs.

This just sounds like a wrapper to the .Net threading system, where the developer has to manually launch jobs.

 

Do you have any idea how hard that would be to implement?

 

Not to mention undesirable in most cases. Ignoring all the other issues, if you somehow had a bunch of script instances all running their own threads all at once, it would drag performance down since threading isn't free and most people only have 2-4 cores.

--Eric

 

I have 1548 threads running on my computer... does that mean I have a 1548 core processor?

Sorry, being sarcastic, but it made me laugh.

Considering the physics will be multithreaded (read it in another thread) that sounds pretty nice by itself. Making all of Unity multithreaded could be nice, but honestly... I don't know how much help it'd be. You can already create your own thread to do something in the background if needed. While annoying at times, I like knowing the main thread is threadsafe. It seriously solves so many issues that could occur.

 

Nearly all of those threads are idle the vast majority of the time...check out the CPU time that each thread has. I wrote what I wrote quite precisely, for a reason.

--Eric

 

Rendering gets its own thread, culling can be threaded, physics are already mentioned... that should speed up things a bit.
Furthermore, Lightmapping and pre-baked culling could be threaded (lightmapping is already).

The multithreaded job sceduler is marked as "editor performance boost" in the unity 5 promo video, so maybe physics would be the most sped up thing.

 

Then why do the Frostbite, Unreal and Crytek engines all use multi-core technology.

And todays 2-4 cores will be tomorrows 6-8 cores.

Combined with AMD Mantle / DirectX 12 and OpenGL all moving to multi-core rendering as well as CPU/GPU processing, it's Unity's call and their business but IMHO they should be building a highly competitive engine that can hold it's own on multi-core processors.

Moore's Law waits for no one.

 

So does Unity, and it has for a long time. Asking for scripts to be automagically multi-threaded shows a fundamental lack of understanding of what multi-threading actually is, though. It's not magic pixie dust where you flip a switch and suddenly everything just goes faster. There are areas where it makes sense to be multi-threaded and other areas where it does not. Scripting does not, except under explicit user control, which is already possible and has been forever. Even though Unity already makes use of multiple cores, they could improve some areas and it seems that in fact they are.

--Eric

 

Happy to see the multithreaded physics. That's one place that really needs it, especially in my game (getting big profiler spikes due to the physics system at the moment).

Another place that could use it is procedural mesh building, but I'm not sure what would be involved in making that support multithreading.

 

Procedural mesh building should be easily threadable, since you don't have to Change anything unity related to calculate it. Calculate your mesh, return it to your main thread and put it in the scene...

 

I do calculate all the vertices/etc in another thread already. But I still have to do the

mesh.Clear();

mesh.vertices = newVertices.ToArray();
mesh.uv = newUV.ToArray();
mesh.triangles = newTriangles.ToArray();

mesh.Optimize();
mesh.RecalculateNormals();

stuff in the main thread.

So I suppose a better question is: do those have much of a performance cost? Maybe that's not a real issue. It doesn't seem to be in terms of profiling. The physics mesh collider building is the destructive one. So having that multithreaded should really solve my issues.

PS: not sure how to format code on here, maybe I need to 'go advanced'...

 

You can use [ code ] your code [ /code ]

Physics mesh collider building may not be related to physics but to unity internal methods. Are you calculating a convex mesh? Assigning a mesh collider without calculating its convex hull is not the fastest thing to do, but it isn't the slowest either.

You should discuss that in a seperate thread

 

Is the physics mesh collider thing being done as a static or dynamic (with a Rogodbody) collider? Adding, removing or changing static colliders is really expensive because it implies changes to a dataset that's assumed to be, well... static*.

* In the sense that it's assumed not to change, as opposed to what the keyword 'static' means in code.

 

It's for a voxel game. It's not convex (because that doesn't work well), it's not static and it doesn't have a rigidbody on it (that gives tons of errors).

I just use MeshCollider.sharedMesh = (the one I made in the other thread for visuals).

And the hit comes from the Mesh.Bake PhysX CollisionData in the profiler (97% in the profiler from that).

Sorry for getting off topic, though. It just came up because I feel like multithreading in Unity 5 will solve this problem. I hope so!

 

Well, my understanding is that as far as Unity's version of PhysX is concerned, if there's no Rigidbody on a collider then it is treated as if it is static (ie: not moving). Furthermore, the data representing the set of static colliders is optimised for a write-once-query-often access pattern. As a result, adding, removing or modifying non-Rigidbody colliders is expensive because it changes the static collision data, which triggers it to be re-optimised internally for fast future access, which I would assume is a part of that BakePhysxCollisionData method call that's chewing up 97% of your CPU time.

As for whether multi-threading will fix that... no idea. My hunch is that multi-threading would benefit the "query-often" part of the usage more than the "write-once" part, though.

 

I don't think it was that expensive, but I suppose it depends on the amount of colliders.

A quick question, if in C# I have a thread, and do something super expensive on it(Like say it would lag the computer up for 2 seconds) what happens? Does it just keep going normally on the main thread and that one just slows down? What about the same situation but with a coroutine?

 

If you lag the computer you lag the computer, threading won't help you.

However if all your are dealing with is a thread doing a lot of computation then with threading the OS can do two things:

1) Timeshare a core. Just because it takes 2 seconds to process, doesn't mean that 2 seconds has to be contiguous - the OS can share time between threads (e.g 15ms here, 15ms there...).

2) Balance threads between cores, so even if a thread that completely hogs one core, there may be more unused resources available that other threads can take advantage of.

With coroutines one can manually timeshare a core.

 

I think that's exactly the case.

 

Multi-threading will not fix that, but upgraded PhysX will.

 

Well, at least assigning the mesh in another thread would make it less noticeable to the player? I'm not really sure what they mean when they say physics supports multithreading, to be honest.

 

As I said on another thread with a similar issue - if you have X that you want improved, ask for X to be improved. Randomly asking for 'multithreading' as magic simply hides your issue, and in the unlikely event that your wish is granted, may not actually help (in some cases might hinder) the actual issue.

 

I think the Unity Object / Component based system would be ideal for Multi-threading, each component scripts functions are small jobs that could run on any core, they just need to run against a thread-safe core engine.

Imagine how many objects Unity could throw around if it shared these jobs out.

 

Err... Unity's Object/Component system is a great example how how *not* to do multithreading.

Lots of small bits of code... all working on the same, shared mutable state... lots of direct links between code..

The similarities between Unity's model and say the Actor model are only superficial at best.

Furthermore, as I explained in the last multithreading thread - thread safe means very little.

Why imagine? Why not do the hard maths? What code do you have that's slow? How much of that slowness is due to CPU? How many currently free cores could you potentially use, assuming 100% multi-threaded efficiency? That should get you an immediate upper limit. Then start to factor in the costs, inefficiencies and complexities...

 

For the most part, powerhouses like those will thread out stuff like Audio, rendering, physics, and certain CPU tasks. Like run an animation job for example or cloth sims

Trust that these engines aren't just going to multithread every single Actor Tick, etc. Plus, like others have mentioned, if you profile your code you should determine if you are CPU or GPU bound. For 60 fps, you want to come under 16.6 ms. Break apart your frame and look for bottlenecks. I've worked on projects that had slow VMs (much slower than C# I'm sure) and we were mostly GPU bound with only the occasional CPU spikes from particles and explosions bringing us down. So we had to work in a little extra buffer to account for worse case scenario. This was a fighting game so the client required 60 fps smooth gameplay with no drops

 

Nope. For one, it's easier to multi-thread large tasks than small ones, or rather it's harder to multi-thread time sensitive tasks. The most optimistic outlook you can have for any task that is spooled into a different thread is that it will be done when it's done. You would have to assume all the update, fixed update, and late update type of time specific functions wouldn't even be remotely relevant anymore when it's likely one object hasn't been updated in five frames.

 

@npsf3000: I'll admit that my understanding of multithreading is pretty limited as I've only recently gotten into it (haven't been coding for that long).
My understanding of it is that the point is: when you have performance intensive work to do (such as creating mesh colliders and "baking PhysX data") then you can use other threads to get the work done in parallel to the main thread which the player's controls are on. That way the performance intensive calculation won't happen on the thread that will lag the player and it should get done faster.

So therefore I see this multithreading on Unity 5 as a fix for the issue that physics lags the main thread right now in my game, and the player can see that.

Do I have some wrong idea about it?

Yes, obviously having that workload lessened would be nice. I'll take that. I was assuming that this work naturally takes a lot of computational power because there's just a lot to do, and putting it in my secondary thread I already have for mesh calculation seems like a good idea.

 

There is a difference between working in parallel and working in tandem.

In a real time environment, if you have to wait for something to finish before everything else can continue, then there won't be any benefit to threading and it may even end up hurting things more.

 

Yes, that makes sense. Though, that's not really an issue in my situation. Due to how my game works, the player couldn't ever be in a situation where a mesh isn't loaded when it needs to be and the player would fall through the world. The 'wait' here is roughly 50 milliseconds, which isn't a huge deal if it can happen on another thread and won't affect the player. If you do that 50 ms on the main thread, you can feel some choppiness when the mesh colliders are being created.

 

The problem is that the physics system would be left in an indeterminate state if you allowed mesh colliders to finish computing "whenever". Without a fundamental change it kind of has no choice but to wait until the colliders are complete before it can compute another physics frame. Possibly you could use multi-threading to speed up the collider generation itself, if it's something that lends itself to parallelization.

Fun fact: Unity used to allow everything to be done in separate threads regardless of thread-safety, so you could indeed generate mesh colliders on another thread and it would randomly sometimes even work, which was pretty neat. The rest of the time it would crash.

--Eric

 

I calculate the mesh in another thread, then I use MeshCollider.sharedMesh to set the mesh collider to the already calculated mesh. In this way, the mesh is already made from another thread but it seems to spike when I use the 'meshCollider.sharedMesh = null' and then 'meshCollider.sharedMesh = (already calculated mesh)'.

So my thought was: how about calculate the mesh in the other thread, set it up in the main thread by giving the mesh the vertices, triangles, and UVs that I calculated in the other thread, then assigning collider.sharedMesh in the thread that calculated the mesh data.

So are you saying this would crash the game / not work too well? Because if that won't work too well, then I hope that PhysX upgrade improves the performance of this operation. Otherwise I'll have to write my own physics system... yikes.

 

Funnily enough, I was trying to implement a dynamic mesh collider system and my first thought was to try this until I realised that there's no way to do it now.

Now I'm not so bothered by that fact.

 

When you assign the mesh as a collider, PhysX has to do some pretty heavy pre-processing to make it work in the physics system. That's the part that can't be run on another thread...even if you don't actually need it done the next frame, the physics system does. (Or it used to; don't know about recent versions.)

--Eric

 

At this point you don't even know you've got performance intensive work to do.

What happens if after spending millions of dollars on improving multi-threading, it turns out that completely different simple fix - maybe they could have refined the algorithm, batches changes, made the changes async? Maybe the approach you're taking is wrong? Maybe you're right in that it's a real problem, but the best solution is to use a different physics system entirely - no quantity of threading will help?

If you have a problem, ask for the problem to be fixed. Don't focus on presumed solutions, especially if you're not sure the solution is practical solution let alone the best.

 

Well, except that in this case it's clear that multi-threading, if possible, would be the solution. I ran into this several years ago myself where I wanted a mesh collider to be computed without bringing the engine to a temporary halt. I didn't actually care whether the collider finished computing by the next frame, or 50 frames from now, because the player wouldn't be able to interact with it for longer than that anyway. So I figured that if assigning the mesh collider could be done in a separate thread, that would solve the issue completely. As I mentioned, at the time Unity didn't prevent you from attempting to use threads for everything, thread-safe or not.

Since that particular physics stuff is not thread-safe, it would randomly crash. But when it worked at all, it worked great and was exactly what I wanted.

--Eric

 

@npsf3000: I'm not really sure what point you're trying to make. Are you saying I shallowly looked at the fact it was lagging and decided I'd need multithreading without doing any further thought? That is far from the truth. I've considered all my options, and the only one there is at the moment is writing my own physics system. Sure, I could spend a lot of time doing that. But do I need to, if the Unity 5 upgrade that is [already going to support multithreading] (and will have a faster physics system) is coming up soon?

Most of your post there seems to be regarding their internal physics engine. Sure, maybe they could have improved their algorithm rather than doing multithreading. I'm not making them support multithreading - that's something they've decided to do, and I decided that a. since they're doing it and b. since it could help me, I would make use of it.

If I'm supposed to ask for them to fix my problem and wait years for them to do it... I can't do that. I have to work with what I have and with what's coming up.

 

It does look something like that to me, I've seen what appears to be several different possible problems with several different possible solutions.

First post is about physics performance in general, and procedural mesh generation.

Then your second post, relating to mesh generation you assert you need to make some calls on the main thread (which I'm not sure is true, and if it is true the solution may not be multithreading of Unity) and state that you're actually not sure of whether or not this is a performance issue.

Then in the third post concerns are raised by others that you're dynamically changing a static mesh... which is going to be considerably slow not because of threading, but because you're working against the paradigm.

On on your fourth post, where I jump in, you talk about assigning the mesh in a separate thread (though assigning is typically a cheap operation) and state you're not sure what UT mean in regards to multithreading physics.

I may be reading this wrong, but I'm not convinced you are sure what your problem is, let alone whether or not threading is a solution.

Do you need faster physics? How much faster does the physics need to be? In a best case scenario, say UT speeds up physics by a factor of say 200% will this be enough to support your needs?

To put things into perspective, I've done work with custom physics where even if UT had managed a 4x performance increase by threading it still would have been too slow - because the problem wasn't how many cycles they were throwing at the problem, but how they were spending the cycles.

 

Really? I must of missed it, could you explain further?

I love this example... except it sounds like you needed async assignment, not threading. This is further illustrated by the crashes you faced when you tried to multithread the solution.

 

It's not, at all...assigning mesh colliders is CPU-intensive because PhysX has to do quite a bit of pre-processing. It's not like you're just uploading a mesh to the GPU. When I tried to use threading, another CPU core happily computed the mesh collider without slowing down the rest of the engine until such time that the collider was done, and then:

Code (csharp):

1. if (Random.value < 0.5) {
2.     AddMeshColliderToSceneAndCarryOn();
3. }
4. else {
5.     CrashUnity();
6. }

--Eric

 

Okay, what I said was the problem is this one single line:

col.sharedMesh = mesh;

where col = Mesh Collider object and mesh = Mesh object calculated in another thread. That's what the problem is. When I commented that line out, everything performed well. Except that there weren't mesh colliders on my chunks and so the player fell through.

That's the line causing the huge spike in the profiler. So what am I supposed to do about that line? I need a mesh collider or I need my own physics system.

You can't use rigidbodies on objects that are flat, like planes, or you get errors. This is a voxel engine. That means I procedurally generate faces of cubes to build blocks. Faces are flat, they're 2D. They have no depth. So there isn't any way to get around this problem that I know of, and that I've seen through research.

Well, I need faster mesh collider creation. Or I need to put the creation of the collider on another thread so the player at least isn't lagged by it. Or... I need to find some creative way to reduce the amount of meshes I need to build at any given time.

There was something about a 'greedy' algorithm that could potentially help me (but then I couldn't use that sharedMesh line... not sure if that performs better than manually making the mesh again for colliders... would think it would). And maybe I can find a way to not generate meshes unless they're real close to the player...

So I've got some thinking to do there, but it is definitely that sharedMesh line causing the problem at least.

But this is kind of off topic, isn't it... I made a thread to discuss this but no one is responding

 

But that's not an assignment issue - that's behind the scenes mesh optimisation (or quad-tree updating or whatever is happening). It's entirely possibly to make the assignment multithreaded but not solve any of those issues resulting in no improvement.

Okay this is much better. Now my only questions would be how slow is this currently (e.g. in ms) and what do you need?

I assume then you've considered putting rigidbodies on the 3d representation of a 2d object? For example, instead of a 'plane' have a rectangle with small, but non-zero depth?

Why are you making faces physics objects? Why not make the cubes physics objects?

Putting creation of the collider on a different thread doesn't magically mean the player is not going to be lagged. For example, if X takes one second and you put it on another thread... it's likely to still take about one second. If you can spread the load evenly over four threads, it's still going to take 250ms. Either way, with the current system you're going to have lag.

Threading is *not* the same as making something async.

Quite possibly.

Linky?