Directx 12 - Massive Multithreading for Big RTS Battles

OMG WOW!

Ok it's not Unity but it's inspirational what amazing potential power with these new graphics api's can unlock!

So when is DirectX 12 or Vulcan coming to Unity?!

 

Damn NDAs

Cool presentation. I'm just starting to scratch the surface of what threads can do. Scripting for this type of engine is going to become harder before it gets easier. Threads are pretty nasty on rookies under current programming paradigms.

 

Well with Unity's new multithreaded job system under the hood. Unity can handle the Navigation, Rendering and Physics then you only need to multi-thread the AI sub-system to drive the Units.

So we just need Unity to make a Multithreaded version of MonoBehaviour!

 

True. I dunno how to use threads without some kind of static reference to something so they know when something has finished.

Don't you just get this terrible feeling that the multithreading options won't be exposed to us at all and UT will assume what threads should best be used for? Like... the native ai stuff that people abandon in favor of a free A* implementation so there can be procedural / dynamic navigation...

 

My feeling is that we are currently on the edge of a precipice with threads. Some bright student is going to come up with a paradigm that works natively with threads. Then we will have to throw out all our OOP knowledge and start learn programming again. The whole one line at a time thing will disappear. The current solutions I've seen for threading remind me of the GOTO statement. Sure they work, but they just aren't elegant. And its very easy to tie all of your threads into a great big knot.

 

Can't wait for that. In fact, I can't wait for someone to build a computer that operates on visible light instead of just electrons so instead of 1s and 0s we can have groupings of RGB values.

Imagine how networking could benefit from that as well, with the amount of information being delivered per 'bit'.

 

Totally true. Analogue computing is way overdue. Its the core reason the human brain is still vastly superior to a computer. Nueral Nets start down this path. But they are typically pasted on top of a binary structure. Again, GOTO statements.

 

Optical equipment has been in use for a long time for networking...

http://en.wikipedia.org/wiki/Wavelength-division_multiplexing

 

Yay! Now let's see something for a computer / operating system where instead of a bit being 1 or 0, a bit can be anything in the range [0-255][0-255][0-255]

I like GOTOs. They remind me of assembly branch instructions. It also makes my work fun to read, because I have a naming system that is about as generic as Unity's. When I make a label, what's it called? Label:. When I need another label, what is the next one called? Label1:. See? Just like Unity naming lol

As for brains... I have this sad feeling that organics & brains will always be better. Even when computers can out-do organic brains, they still probably won't have the efficiency that brains do. Can you imagine a computer doing what a brain does on 10-20 watts? We'd need to build a brain with artificial chemicals and nerves lol.

Who knows... maybe we're developing neural networks in binary structures because humans are extremely racist and need to remain the superior machine. If we make a breakthrough after pat robertson's generation dies out, I think this would confirm that theory I'm pretty certain that Unity and Unreal both became free only because Fred Phelps died

 

For general purpose massively multithreaded development environment, we essentially need a new language model. Also mutithreading is not always good given the all of the facts considered. For example:
1. Maintaining threads
2. Inherent disability or partial disability of certain algorithm to be worked on multithreaded environment. For example: for a custom trail renderer I used mesh class to generate trail mesh. I tried to implement the algorithm on GPU sothat it would be faster. Then I knew that it will never work unless I change my algorithm to fit multithreading on a claster of completely independent graphics processors.
3. Work load distribution and taking its liability. 10 things can be done on 10 processors, but the ten individual works are small and they are not heavy. I will not use multithreading here as systemOS(in my test case it was windows, for you it could very well be linux, mac, android, ios, xbox360 but not ps3. on ps3, you can directly put your code on specific spu.check cell docs on ibm which is publicly available.) will most likely keep my threads in a low priority list.
I have 3 works to be done on three processor. This three works are tremendously performance intensive. So I will try to use multithreading here, given the fact algorithm is smart and ok, also processors are actually idle or can be used to do this work in stead of current job.

Multithreading with gpu has another problem. With unity, currently only dx11(dx10 too?) renderers are supported. I suspect xbox360 use some sort of managed dx, highly unlikely to support compute shaders; may be xb1? We are narrowed down to pc only. This actually is not the problem I intend to talk.
1. Latency
2. Managment

Unless amd(which ps4 and xbox1 has)'s system, we do not have unified memory architecture. GPU memory needs to talk with cpu memory or system memory. This process takes time. So time sensitive application will suffer. For example a touch gesture library, or fighting game AI, heavily interacting crowd AI(like in prince of persia WW or forgotten sands).

You will have to manage gpu cores into groups, you will have to manage their id yourself and offloading correct works for each one of them. People who have a very little knowledge about gpu architecture(the most shedy area I should say), will have a hard time managing this gpgpu.

I am not demoralizing threading. I am just bringing the facts, many of them I faced myself. Gurus can surely look at this. But asking unity devs to implement multithreaded scripting, looked something like lesser important to me than looking up actual user data wanting multithreaded scripting.

It is not that threading can not be done. It can be done. I did it. You just can not touch unity API(definition plz you could say, another story. int is ok but vector3 is not). The reason I suspect, is the way unity engine is written. There may be a lot of dependencies. You can spawn threads and control them, caculate your data within threads. Then you can pass those data to some public data. Main game thread will use this public data.

 

@kaiyum we might not be able to freely create threads, but do you think it would be possible for unity to expose some variable so in a class you could use something like this.thread = Application.Threads.AI to specify which main thread something runs on?

 

If your smart you can optimize your game a lot in Unity with threads. For our voxel engine we have a queue which adds "update voxel chunks" jobs to the "free" threads. We then calculate everything for our new and optimized meshes before we throw it back at the main thread which creates the meshes. This approach could be used for a lot of things and helps performance a lot.

Actually i am also using threads for my thesis where each AI agent calculates its Monte Carlo Tree Search in its own thread which is very important for the AI to make enough tree iterations without limiting the game performance. Did however write my own collision and raycast system to simulate physics in the threads

 

People are probably tired of hearing that I'm making an RTS -- but I am. And honestly, the bottleneck for my game isn't necessarily the number of units per-say. It's actually animations (even with optimizations in mecanim). I can do thousands of objects moving etc, as long as they don't have any animations (or very basic ones). But as soon as you start animating those objects, that's where it starts hurting the system.

If you notice in those videos, their units either have no animations whatsoever, or extremely basic ones (like say maybe 5 bones or something if skinned). They're probably even doing vertex animation. It's honestly not that impressive. Show me that number of units with even moderately complex animations, and then I'll be impressed.

So, could animations be multi-threaded heavily do you think? At any rate, I am looking forward to the new technologies and API's coming out. I'm hearing so much about Mantle, but it seems to only work with certain graphics cards right now?

Regardless of my misgivings about their lack of animations in the demo, I'm still really excited about what they're doing with it. I hope these new systems allow us to unlock a whole bunch of potential

 

Hey just wanted to say I found more information on this. Apparently, Unity is planning on incorporating dx12 sometime early in the Unity 5.x cycle. They want to have it ready and out by the time Windows 10 rolls around to the masses. I have no idea when that will be though.

At first they're going to make sure it works with standalone builds, then branch out to other platforms it looks like.

I hope Unity is on the ball with this. The potential of dx12 for RTS games specifically (my interest) will be big, if it's allowed to be used well in Unity. I hope Unity implements it in a way that allows us to unlock a lot of of performance from the API.

Here is a Unity blog post about it: http://blogs.unity3d.com/2015/01/22/staying-ahead-with-directx-12/

I can't wait! (And hopefully it won't be years)

 

Windows 10 is scheduled for a Summer 2015 release. Most likely July/August but possibly as late as September.

 

Relatively speaking that would be very quick. Even if it's by September of this year, that would be amazing. The biggest question though is if Unity can actually make dx12 happen that fast in Unity. There's always a disconnect between what you say you want to do, and how long it actually takes to do it Of course, there's no guarantee Windows 10 will be out at a specific time either, but I'm hoping you're right Ryiah.

Thanks for the info. As I said, I'm very excited about new advances and technologies that allow for tons of units on-screen at once. At least now I have a general idea of when Windows 10 might get released. Thank you.

 

Unity is mostly done with the initial DX12 integration and now they have to do some render shuffling and optimizations, they gave a talk on it with Microsoft at GDC.

 

http://www.pcper.com/reviews/Graphics-Cards/3DMark-API-Overhead-Feature-Test-Early-DX12-Performance

 

Wow!

But DirectX 12 makes it sound like we are going to need more cores on our CPU's to get the most out of our GPU's.

I hope Unity are going massively multi-threaded with their IL2CPP technology!?

 

Do you really need to animate your units with Mechanim? Are they humanoid? Why not use simple rotation maths? It can be easily multitreaded btw. I don't think Mechanim is the right choice for a RTS unless you plan to have very few units.

 

agreed, mecanim is an awful choice.

 

My point is that Unity has an in built multi-tasking/threaded job system which I believe spans the physics, animation, sound and rendering aspects of the game engine across available cores. Which is ideal as on a multi-core system you can get a boost in performance.

But the scripting components and API are running on the main thread.

And this is the potential bottleneck of the system, one core or thread being overloaded and lagging the entire game.

The thing is Unity has a great component based scripting system that could be extended with threadsafe elements. What if you could extend from MonoBehaviour_TS (Thread Safe) and use a Thread Safe sub-set of the API which would allow Unity to run your scripts across multiple threads/cores.

This would get around the problem of having to re-create none-threadsafe aspects of the Unity from scratch to get that multi-threading. e.g. Raycasts.

So in a way I agree with the premise that not all Unity games will need to be thread safe, as long as their game logic can fit on the main thread on a single core. But I'm amazed that in the era of Octo core high end CPU's on mobile phones this is not considered to be a limiting factor.

And I think that DirectX 12 could be a great boon to Unity but may also highlight the monocore scripting limitation built into the engine as people start throwing more Units around.

 

Personally I wouldn't mind a callback system with an Enum to specify things like (pre/post) update, lateupdate for things like Raycasts. I thing a bigger win for the majority of people will be a combo DX12 optimizations and IL2CPP boosts topped off with constant polish to the existing multithreaded systems.

 

You mean that specifically for RTSs with thousands of units or for anything?

 

For RTSs games with tons of Units.