The day that unity become thread safe, a man's dream

But why are we still raycasting on the CPU, shouldn't anything to do with physics be moving onto the GPU?

And some massively parallel jobs could be done on the GPU in a fraction of the time it would take the CPU.

 

Heck yeah. I totally agree with "make games not engines", it's the entire reason I use Unity myself. I also agree entirely with doing it yourself once because the learning there is epic.

Isn't that exactly what was suggested, though? Sounds like an async raycast to me....

 

Because typically CPU time, you have a lot of. You don't generally have a lot of GPU time.

Doing things in compute shaders isn't a magical free thing. It slows the GPU down since it's still having to render the entire game. This is why particles on GPU isn't always desired.

 

My point is just that this is a pretty trivial amount of code to write - you could get it down to like 10 lines or something including the request object if you really want. So it's not like this stuff is impossible, it's actually trivially easy.

From unity's perspective though, encouraging their user base to write multi threaded code is just going to increase support requests - for them, it'll just make more problems. So why encourage it? It's pretty trivial to just make your own asynch request, and if you can't - then maybe making your game multi threaded is not the right solution for you after all.

 

The point isn't to make things arbitrarily asynchronous, it would be to take advantage of internal threading and load balancing etc. when you have bulk tasks. Being asynchronous is a side effect, not the goal.

 

Most load balancing systems have non deterministic timing, which let's be realistic is for the -vast- majority of games less desirable than deterministic approaches. That's really a whole new can of worms.

I'm sure there are some edge cases where it's preferable. But.... I donno dude

 

By "load balancing" I'm purely referring to physics jobs being performed whenever is most performant for the physics system, etc. As long as the result is ready before the next scripting tick who cares at what stage the calculations were performed?

 

I guess. But for that stuff you really don't need multithreading. I'm sure you're aware that asynch != multithread. And multithreading is sort of the topic here.

That said, I'll give, appropriate internal threading models of a modern 3d engine like unity is super specialized and is admittedly beyond me.

But if I were on the unity team, I'd just be terrified of even remotely promoting multithreading in the unity public api. The support nightmare there just has epic potential.

 

Yes, like I said the asynchronous nature of queued tasks would be a side effect. The purpose would be to take advantage of potentially faster internal job queueing/threading, as a pie-in-the-sky alternative to opening things up so we could access stuff willy nilly from all over the joint.

 

All the more reason to open source certain aspects of the internal physics engine, Raycast intersect algorithms are not exactly a unique thing to unity. Stick the multithreading in it(if it doesn't already have it hidden away), open source it and let us have at it (UE4 style) and your support burden will be greatly reduced. Even being able to batch multiple raycasts into one external call would save CPU time.

 

As a totally off topic comment, there may be a day soon when someone develops a new programing paradigm that has multi threading at its core, rather then tacked on. Has the potential to be as game changing as OOP was over procedural programming. Or the rise of the method over the goto statement. (I'm betraying my total lack of knowledge of computer science or programming history here with these examples. But you get the picture.)

You may resume the discussion about threading in Unity now.

 

Functional programming.

The real trick with multithreaded is get as close to stateless as possible, and functional gets you there naturally.

 

I think it's pretty much desired nowdays imo.

 

I think C# could have AMP/Cudafy like features built in. Most of the time you don't really need or want to get into the boilerplate code that handles threads for the CPU or GPU. And where multithreading could give you the best optimisations tends to be in areas of nested loops (which can be unrolled into arrays of parallel threads).

So what if C# or C# for Unity had an [Accelerate] tag. You use the tag to bracket sections of code that can benefit from multithreading on the CPU or GPU. e.g. Loops, Inner Loops.

Then Unity could build out those sections of code for multi-threading on the CPU or GPU and run them in it's multi-threaded task system.

There would be overhead to this as code would be generated to manage the threads or GPU threads and data would have to pass between the two. But we could have a very user friendly multi-threaded system that could boost the performance of critical code paths.

If you were to add a 'Analyse for Acceleration' option on the profiler it could even point you in the direction of where these performance critical blocks are.

Then if Unity had a feature to run A - B test cases for these optimisations and report on the results! WOW!

Just my 2c worth.

PS also depending on the calculations and platform SIMD instructions might be another valid optimisation.

 

This really depends on your goal. Sometimes you are performing tasks that your other threads don't depend on. Logging is a good example of this as you will fire off a message to your logging thread and forget it as the logging thread will take care of the rest.

Sometimes, however, you are multithreading to divide heavy workload. In this instance, the units of work you divide up are somewhat independent of eachother, though not necessarily autonomous. Data in ThreadB doesn't depend on data from ThreadC, but ThreadA may use the results from both B and C. Furthermore, ThreadA may actually even wait for B and C to both finish so you are still blocking the main thread, however you are breaking up the processing amongst multiple other threads so you reduce that wait time. In this case, you're not aiming to be stateless at all but to rather cut the processing time for a large unit of work by parallel processing it.

 

You could potentially have a high degree of inaccuracy here. This could be totally dependent on the input. You could analyze the code and maybe it is iterating over a collection of 500,000 elements, but the next time it is only iterating over a collection of 5,000... or maybe the 500k was a one off... so that block would be optimized to execute multi-threaded when at runtime it may actually end up with poorer performance because the time spent allocating threads outweighs the savings of processing the data. There is no good way to compile-time check this... and even at runtime is highly dependent on data which could (the CLR has no way to know) be variable.

Edit: This may be able to be determined in some cases via static code analysis where it can determine whether or not an object has the potential to be changed.

 

Good point so the profiler would look for recurring performance bottlenecks, and with an A / B build/test feature you could determine if the optimisation is valid for your target platform.

 

Exactly, there would still need to be that manual intervention.

 

Dude this is some bulshit. I understand its extremely hard to programm a game engine to utilize infinate amount of cores, but this S*** has to be done sooner or later. Clock speeds on cpus are staying the same and even DECREASING... But what we have seen is the core count increase. Id 5 engine is written to utilize all cores so theoreticaly it could work extremely fast on a 100 core cpu. I think unity should use parallel threading internaly so anything the user does is even. So even if all the processing is script intensive... the rendering and scrips are split up evenly among all the cores to maintain even core usage apposed to having scripts on one core and rendering on another. Just my 2 cents to take a big leap forward. Besides... this way users wouldnt have to wory about threading themselves.

 

Sorry but you went off the deep end of ridiculousness there. The engine is multithreaded, it just can't be accessed from other threads. And the only way to ache e parallelism in scripting would be at some point to impose thread locks and joining to keep things in sync. You would drown in a sea of concurrency issues and you'd never know when a script could ever depend on work done by another script if you don't even know if they're executing within the same thread context.

 

You can use multiple threads of your own. I do it all the time for procedural terrain. The engine itself is multi threaded, and will do all sorts of stuff in the background.

Where you can't use threads is in the interaction between your threads and the engine. There are some specific places where this would be useful, but in general its not that big of a bottle neck. I'd be surprised if the increase in performance from making the API thread safe outweighs the performance cost of making the API thread safe.

 

I am very aware. This is where parallel threading comes in to play. If you look at your cpu cores in a third party program you will notice only one core is lit on fire while others are barely touched. And besides, I wouldnt have a problem if unitys api was thread safe, but using parallel would eliminate the need for us to bother with threads.

 

I would be happy if Unity could just add some extra thread-safe versions of certain api methods. Our main bottleneck at the moment is assigning mesh-colliders to procedural meshes.

We make non-game apps where third party content is read at runtime, and therefore we cant get around creating complex colliders for interaction at the same time.

I use threads wherever possible, but our clients are complaining about the places where its not possible.
A freeze for up to ten seconds due to PhysX processing colliders is hard to hide. Especially since we cant even have a spinner or similar animating at the same time to show that the app is working.

I've managed to delay the processing until a specific collider is visible for the first time, but thats just trading a long freeze while switching content for a lot of shorter freezes while the user is navigating the content.