Dive further into the upcoming performance optimizations coming to Unity. This talk covers the continued development on delivering high performance C# scripts with a look at the upcoming C# Job System and newly revealed Entity Component System.
Sign up for the Unity Technical Preview of the C# Job System:
New and exciting technologies are coming to Unity in the form of Job System, C# Compute Compiler and a new Entity-Component System. Nordeus engineers provide a walkthrough of how they created the epic battle from the Unite Austin keynote and explore working with these new systems first hand.
Iâm glad they chose to go with the best performance first, then figure out how to make it easy rather than just do all these half assed compromises.
It looks a bit overwhelming at first but itâs just a matter of getting your feet wet. Iâll probably start by using it for any slow parts that bring me under 60fps on target device (assuming Iâm aiming at that), then as I get used to it, expand it out to the rest.
From what Iâm seeing, the overhead of the existing unity component stuff, monobehaviour etc is still slower than processing 1 job so itâs a no brainer to use where you can, I guess.
I already know that itâs basically impossible to adopt my AI (which does a lot of state stuff with delegates) to this pattern, but that does not mean I canât use it. For example I can continue doing my AI as it is, close up but in the distance, I could be doing this vague automated behaviour.
Iâm also seeing it quite challenging to adopt this for AI, with tons of states and dependencies and whatnot. It will be an interesting exercise to figure out if and what parts can be replaced with the new system without sacrificing code maintainability/complexity too much.
I do see where the new system would be highly applicable in my project though, but mostly on âlower level systemsâ. But thatâs fine to me!
I have, whatâs interesting is the code is all C# code just some of it has a IJob tag so instead of being run through mono it goes to the Job Compiler. For the current version the Job Compiler builds multi-threaded CPU code.
In theory the Job Compiler could build GPU code (e.g. target CUDA, DX Compute, GPUOpen).
The Job code is already set up to be batch based and parallel so there is the ideal future opportunity to allow for it to be compiled and run on a GPU.
After all modern GPUâs are amazing at batch based small/simple jobs, although I think bandwidth between CPU/GPU can be a problem.
And if Unity are already using HLSL style syntax and features, it would be crazy for them not to also be working on a CPU and GPU Job system.
Also in the big RTS demo it is mentioned that they are using a GPU animation system, surely if you were working on that you would be tempted to write a GPU Job System?
I believe a lot of GPU Compute solutions have a C/C++ to GPU build path so in theory adding a C# Job > IL2CPP > GPU path should be possible.
If the shown demo which manages about 40,000 units at playable frame rates were to run on both CPU and GPU could it do way more?
Iâm assuming that every frame the game processes itâs updates on the CPU and then passes them to the GPU so for 16ms the GPU is sitting there waiting for input.
Now consider that a modern GPU can have 1000 cores, although not as complex they would be much more powerful for simple batch calculations than 10/20 cores on a CPU.
Arowx, in theory weâve colonized Alpha Centauri already. In practice we are not even close.
âin theoryâ discussions give no practical benefits. Practical part that is available right now is the only one that matters. Talking about what is âpossibleâ âin theoryâ is a waste of time and nothing more.
And for the love of Cthulhu, do some gpu programming yourself so you familiarize yourself with its limitations.
Itâs great to see focus on performance. Itâs a bit frustrating to watch some of the direction they are going in though.
One of the fundamental design flaws of ECS is that it forces the batching paradigm up to high. You always have to make a trade off here, but basically you want to avoid coding in this paradigm unless you actually need the performance gains it gives. Which means 90%+ of your game logic is going to be better off outside of their ECS system.
Which is ok if you understand that. Itâs selling this like this is a great higher level abstraction that rubs me the wrong way. Because itâs not. They donât even try to address some of the more well known shortcomings of ECS like dependency handling and how this plays havoc with data at the database level and make querying data generally a pain. I think the reason for that is because as engine developers, those are not things they would ever encounter really. But most of them are well known by anyone who has tried to use ECS on a substantial game.
Yes, and getting an explanation and the accompanying examples in a format that isnât a video. Unfortunately my brain is the type that focuses on typos, grammatical errors, and presenters that are not trained speakers making it very difficult to really understand after the first viewing despite waiting till I was wide awake after a good nightâs sleep.
It depends on the level of performance and number of game objects you are dealing with, ECS is fine on modern hardware at scales of 1-10s to 100s of objects.
If you need 1000s to 10,000s of game objects then you need a more batch based or multi-threaded system.
Unity ECS and Job System are systems that you can choose to use or not use depending on your projects needs.
Hopefully the addition of the Job System will open up more Unity systems e.g. Navigation, Physics, Occlusion so you can roll your own system.
PS you mention databases to my knowledge this is not a topic raised in most game development discussions, so what types of games tend to use DBâs?
Its not intended to be used by beginners though.
Itâs a way to implement high-end optimizations, not a new way to do literally everything.
I can only speak for myself here but I think the video gives a great overview of what will be possible, and is half a tutorial in itself already.
For me at least it wonât be hard to use, and for the few limited sub-systems where it actually makes sense to use this, it will work great.
I couldnât get through this. This wouldâve been 30 minutes shorter if they got someone to present it that is actually capable of speaking in front of people.
From what I understood this is something nearly nobody will use. Itâs just too much of a hassle to build your game around this system, but when you actually need that extra performance, youâll probably want to take a look at it.
I can agree with that to a point. Itâs clearly not meant hobbyists or rapid dev cycles. I doubt Iâll find myself using it much since Iâve spent quite a lot of time building a library of code that is focused on rapid-iteration of design and is not at all thread or cache friendly. Iâve tried the âthousands of mobsâ thing before and there were so many factors beyond mere programming that limited me that this wouldnât have helped at all.
That being said I can see this being very useful for large-budget games to really push the boundaries of Unity. With some specialists that can focus on just these parts of the system they can really leverage a lot. Some smaller devs might be able to try some smaller but unique ideas that were impractical before. As well, Unity Team themselves can use it under the hood for some performance boosts that come to us for free.
For instance I write a game using the Jobs system and build it on my 8 core FX8320 CPU get it running well and with all the enemies/hordes particles and effects I want at 60Hz.
Then someone runs it on a 2, 4, 6 or 16 core machine, what happens?
Or in my dynamic game I take advantage of the Job system and as in the RTS example allow players to have archers, only some player will opt for an army of only fire archers (more particles and damage radius) and two players both use this strategy.
How can I balance the load on the Job system or will my game need to be dynamically scaled in army size based on the users CPU cores, and what impact will there be for multi-player games?
Or is there a way to do Job LODâing, where I can dynamically reduce the precision or logic applied to game objects based on the CPU and GPU* load?
e.g. Level of Detail of Unit Navigation/Collision Avoidance
*The flip side of this Multi-threaded job system is the potential maximum load a systems GPU can render.
