KSP2 Performance Update

[Lisias]

1 hour ago, runner78 said:

I think you're not quite up to date, Unity itself uses a lot of multithreading on the engine side. Rendering uses its own thread, physics is actually multithreading so far i know. And with Unity's job system, a game developer can implement multithreading quite "easily" and is also used a lot internally by Unity.
But physics is generally not particularly well suited for multithreading and has some limitation.

Nope, I'm very up to date. See this thread (it is less than a year old). I'm talking about the GAME, not the engine.

Additionally:

If you create MonoBehaviour script and do things in any Fixed/Late/Update() function, this runs on main thread. Most of the Unity API's are not thread safe. Meaning you cannot create seperate thread and interact with the engine API's.
Source (April 2022) 

Yep, physics is generally not well suited for multithreading, unless you stop thinking serially and start to think "distributively".  Different crafts on different frames of reference don't interact with each other and, so, dont need to be simulated serially. Even two different crafts in the same frame of reference but not touching themselves can have their physics calculated in parallel - as long your data structures are tailored for that. Detecting collisions are still a problem, tough.

[AmanitaVerna]

18 hours ago, Strawberry said:

It's important to note that we know that the resource system in ksp2 is much higher scope compared to ksp1, according to the dev diary about it, a big part of the design is for colonies such as allowing resources to change while parts aren't in view. This is probably why the lag from these calculations is much worse, its much harder to optimize this with the greater scope of this.

Kerbalism does this as well, and KSP1 with Kerbalism runs on my GTX 750 Ti, so I don't think that's the problem, really. Also, surely, that would be something that would be run on the CPU, not the GPU, and by all accounts I've seen so far, KSP2 is GPU-bound even on high end GPUs?

[tstein]

3 hours ago, Bej Kerman said:

That's what confused me about the idea of floppier parts causing more lag than ones that aren't floppy. However, when I said Juno runs well because it doesn't do joint physics, I really mean it doesn't do joint physics. It's not rigid parts running better than floppier runs like Frog said, rather the game just isn't doing the calculations at all. No matter how reckless you are, your rocket won't bend and parts do not do anything separately until the destruction of a part forces them apart.

YEs and not. Each joint you add  increases the  computational cost.   That is why a RIGID single large tank will have better performance than a stack of tanks. That is why procedural tanks and procedural structs can   reduce the number of joints and improve performance.  Even  that said, Unity performance on this type of simulation is still sub par.  Since the engine does not help, then  it woudl be wise to help the engine and reduce the number of joints.. aka. make EVERYTHING you can procedural.

19 hours ago, Strawberry said:

It's important to note that we know that the resource system in ksp2 is much higher scope compared to ksp1, according to the dev diary about it, a big part of the design is for colonies such as allowing resources to change while parts aren't in view. This is probably why the lag from these calculations is much worse, its much harder to optimize this with the greater scope of this.

No certainly it is not that. This is not the type of thing that requires even a fraction of a CPU capability. Play factorio for a while or Victoria 2 and you will see how much a production chain  can  be fast and complex (thousands of times larger than anything KSP 2 will ever require).

1 hour ago, Lisias said:

Nope, I'm very up to date. See this thread (it is less than a year old). I'm talking about the GAME, not the engine.

Additionally:

If you create MonoBehaviour script and do things in any Fixed/Late/Update() function, this runs on main thread. Most of the Unity API's are not thread safe. Meaning you cannot create seperate thread and interact with the engine API's.
Source (April 2022) 

Yep, physics is generally not well suited for multithreading, unless you stop thinking serially and start to think "distributively".  Different crafts on different frames of reference don't interact with each other and, so, dont need to be simulated serially. Even two different crafts in the same frame of reference but not touching themselves can have their physics calculated in parallel - as long your data structures are tailored for that. Detecting collisions are still a problem, tough.

Detecting collision is  not that problematic  because  KSP agents are very predictable in their trajectory since they accelerate quite slowly. It is not  hard to devise a forward cut  list of what you CAN   intercept in the next  X time .. much easier than in a game there tons of projectiles bound in  walls of a cave for example.

[Lisias]

1 hour ago, tstein said:

Detecting collision is  not that problematic  because  KSP agents are very predictable in their trajectory since they accelerate quite slowly. It is not  hard to devise a forward cut  list of what you CAN   intercept in the next  X time .. much easier than in a game there tons of projectiles bound in  walls of a cave for example.

I was talking about a hypothetical concurrent physics engine - if you have many threads simulating different partitions from the world, you need to syncronize them before detecting collisions, otherwise you will get some pretty hard to debug bogus collisions due race conditions.

[runner78]

4 hours ago, Lisias said:

Nope, I'm very up to date. See this thread (it is less than a year old). I'm talking about the GAME, not the engine.

Additionally:

If you create MonoBehaviour script and do things in any Fixed/Late/Update() function, this runs on main thread. Most of the Unity API's are not thread safe. Meaning you cannot create seperate thread and interact with the engine API's.
Source (April 2022) 

Yep, physics is generally not well suited for multithreading, unless you stop thinking serially and start to think "distributively".  Different crafts on different frames of reference don't interact with each other and, so, dont need to be simulated serially. Even two different crafts in the same frame of reference but not touching themselves can have their physics calculated in parallel - as long your data structures are tailored for that. Detecting collisions are still a problem, tough.

The MonoBehavior message methods are called onthe main thread, but it does not mean that you have to calculate everything in it. You can just plan in LateUpdate() an job, and use the result in the Update() on the next frame.
Many API from Unity now have job support, e.g. RaycastCommand.

I do not know exactly to what extent the phsix multihiltering model is used in unity, but even if you calculate two vehicles separately, as soon as they are close to each other, they must be calculated together again so that the collision detection works.

KSP2 actually uses the job system and burst, but it is still surprising why, for example, the fuel System case som problems, I assume that you can  the complete the work in jobs pro vessel/station, and is not dependent on Engine APIs.

[livetalk]

On 2/23/2023 at 7:01 PM, Nerdy_Mike said:

In general, every feature goes through the following steps:

1. Get it working
2. Get it stable
3. Get it performant
4. Get it moddable

It might be advisable to keep new features on an experimental branch until they've reached the 3rd step.

Otherwise (if I understand correctly) the EA build would constantly run into performance problems with every new feature that is in stages 1-2. That might not be a problem for an early access testing program, but I imagine people would like to play the game with descend performance as soon as possible and would become quite frustrated in the long run.

[Lisias]

6 hours ago, runner78 said:

The MonoBehavior message methods are called onthe main thread, but it does not mean that you have to calculate everything in it. You can just plan in LateUpdate() an job, and use the result in the Update() on the next frame.

As long you don't try to create threads for background processing - or, if you do, you don't use any Unity calls.

I'm not talking about lack of parallelism on Unity. I'm talking about threading being not the preferable way to do it - to the point Unity itself is royally screwing you if you have too much cores with too many threads available (see that link of mine about MONO_THREADS_PER_CPU).

 

6 hours ago, runner78 said:

I do not know exactly to what extent the phsix multihiltering model is used in unity, but even if you calculate two vehicles separately, as soon as they are close to each other, they must be calculated together again so that the collision detection works.

My point on my previous post. It can be useful when you have a lot of crafts scattered in the Universe, but managing colliders for near crafts can be slightly more complicated. You will, at very least, need to synchronise the threads before checking for collisions - what probably will waste any savings you got with the stunt on a low craft count gaming.

 

6 hours ago, runner78 said:

KSP2 actually uses the job system and burst, but it is still surprising why, for example, the fuel System case som problems, I assume that you can  the complete the work in jobs pro vessel/station, and is not dependent on Engine APIs.

Now I'm guessing - so taking anything I say here with a considerable grain of (iodized) salt.  

It's my understanding that in the same way the Unity's Update callbacks can be skipped under heavy load, so do the Burst jobs. At least, is what some posts on Unity forum is telling us.

If you built a job to handle the fuel system, and the job is skipped by some reason, well… You have a faulty fuel system with a misbehaviour really hard to diagnose...

[runner78]

Unity's job system only has one worker thread per local CPU, and by the way it's a C++. The C# job system is just a wrapper over it.
Unity also supports async/await, e.g. "async void Update()".
For 2023.1, unity has also implemented its own Awaiter type that has less overhead and is then used for asyncone unity calls.

9 hours ago, Lisias said:

My point on my previous post. It can be useful when you have a lot of crafts scattered in the Universe, but managing colliders

Only crafts within your vicinity will be loaded, at least the visual/part-physics. All others craft no longer play a role when it comes to local physics.

 

10 hours ago, Lisias said:

It's my understanding that in the same way the Unity's Update callbacks can be skipped under heavy load, so do the Burst jobs. At least, is what some posts on Unity forum is telling us.

I've never heard of Update() or job being skipped. The thread is about burst not compiling a job, but that only means  the C# JIT is executed as a fallback. The job is always executed.

[Lisias]

8 hours ago, runner78 said:

I've never heard of Update() or job being skipped.

I got a misbehaviour that could be explained by skipped Updates on my old potato running Unity 2019 under heavy load - what's, frankly, all the time. I considered placing a log on the Update in question, but rapidly realised that doing disk I/O on it will induce huge latencies, screwing up the test I wanted to do at first place.

Interestingly, things got incredibly smoother once I set MONO_THREADS_PER_CPU=1 on my rig. Now I can run KSP >= 1.8 on my old patato, and I can even enjoy it a bit as long the craft is under 40 or 50 parts. Without the MONO_THREADS_PER_CPU stunt, I got a slideshow already on the Main Menu, what to say flying something.

My suspicion of Updates being skipped, however, is not due the stuttering, but due some exploratory code of mine failing under heavy load - and the most plausible explanation for it is the Update not being called.

(and, yeah, the MonoBehaviour.enabled was set to true!).

 

8 hours ago, runner78 said:

The thread is about burst not compiling a job, but that only means  the C# JIT is executed as a fallback. The job is always executed.

That was a major bork on mine. I had googled for the subject, ended up finding what I wanted to find and got myself trapped on confirmation bias. I should had read that thread way further than I did, but failed on it and ended up wasting your time. My apologies.

[eberkain]

On 2/23/2023 at 12:10 PM, camacju said:

Fuel flow has been an issue for a long time. Did you just use the exact same system as in KSP 1?

with wobbly rockets, overcorrecting stabilization, even that jerk when you transition from surface to orbit frame reference.  Pretty sure its the same engine with a new paintjob. 

[HebaruSan]

4 minutes ago, eberkain said:

with wobbly rockets, overcorrecting stabilization, even that jerk when you transition from surface to orbit frame reference.  Pretty sure its the same engine with a new paintjob. 

Or convergent evolution, the most obvious way to implement certain things results in the same problems.

[luc]

Hello !
Thanks for the infos !
One question tho, will ksp 2 support multi-GPU ? I have 2 gtx 760 on my computer right now but only one is used.
Cheers!

[eberkain]

11 hours ago, HebaruSan said:

Or convergent evolution, the most obvious way to implement certain things results in the same problems.

Typically when you recreate something complex like a physics simulation, you would identify the biggest issues with the current system and build the new system in a way that resolves those issues. 

[OlloLikesKerbal]

is ksp2 going to be on mac?

[lude]

Hey could you as a team please have a look at the tessellation of things, I have the feeling that some objects that do not require very high tessellation have it extremely high as well as the general game world.

Overall this could improve performance quite drastically GPU side wise.

People with AMD GPUs could test this, because they have an option to restrict tessellation, for example NVIDIA's hair physics were once upon a time a reason why some GPUs (AMD and outdated NVIDIA) tanked extremely in performance if faced with such hair physics or extreme tessellation, that setting would allow many old cards to run those hair physics with marginal to no quality loss but extreme performance boost (tanking means it was somewhere around 10-15fps and recovered to 40-60ish)

I don't have a state of the art rig right now, but even the best out there wouldn't be near double in performance and I wonder a little about the frame rate at 1080p and it being GPU related for me.

Tho will update my drivers soon, something I barely ever do.

Also perhaps do a performance assessment of certain things over others, which you could then split into further options in gameplay, graphics and so on, there might be minor things that just eat a lot of cpu or gpu time due to minor flaws or oversights adding up.

 

Great game! Looks awesome and feels good, never expected that a KSP game could load that fast, switching between scenes in not even seconds and I can feel the love to detail and better usability a lot.

[tstein]

On 2/24/2023 at 4:17 PM, Lisias said:

I was talking about a hypothetical concurrent physics engine - if you have many threads simulating different partitions from the world, you need to syncronize them before detecting collisions, otherwise you will get some pretty hard to debug bogus collisions due race conditions.

But that is my point. This is NOT  a problem , not really  YOU  can  easily predict ahead spheres of  risk of collision, and since kerbal ships   do not change direction   frequently you will NOT have real race conditions unless these spheres touch (and then and only then you make some sync) YEs there is the issue of the game engine not being made for that.. but well there is a reason no one uses unity for a flight sim. KSP is clsoer to a flight sim than  to any other type of game, they shoudl have seeked an engine with tools and optimizations  like of  flight sims.

[AtomicTech]

On 2/23/2023 at 12:01 PM, Nerdy_Mike said:

In general, every feature goes through the following steps:

1. Get it working
2. Get it stable
3. Get it performant
4. Get it moddable

The sooner, the better please

[Indig07]

Is there a eta on when we are to start expecting big fixes and updates?

[radimov]

I support the game and the developers, I have a lot of faith in this project. I can enjoy the game at a correct frame rate and I'm not really in a hurry for the patch to come out, but I do think that constant communication between the developers and the community is essential and it's not happening at least not the way it should right after the early access release. It seems to me that they are failing very badly at this point.

 

[scivirus]

On 2/23/2023 at 8:59 PM, Bej Kerman said:

Much cheaper. That's what this means.

not with DLSS but KSP2 does not support it 

[dumptruck]

Not sure if anybody needs performance reports in the sea of complaints but I figure since I have the min spec. gpu and exceed the rec spec. on everything else people might be interested:

Ryzen 9 5900 / Radeon RX5600 6GB / 32GB DDR4 / NVME HDD
40-20 FPS just viewing the HQ at 1080p. Getting 47 FPS avg. but that's because I spent half the time in the VAB and it's fairly smooth in there. Graphics quality settings don't seem to make much difference. Before turning off Super Resolution scaling to 4k I was getting 20 FPS even at 720p, so I guess that's a tip for AMD users (I use it for most other games without issue).

[TheHallMonitor]

On 2/23/2023 at 11:11 AM, sh1pman said:

An obvious solution to this is to use a pre-built reasonably sized rocket (e.g. Kerbal X) and test how well it performs on various PC hardware during launch.

Idk if KSP 1 runs on the same engine as KSP 2, but the main problem with running a craft from Kerbal X on KSP 2 is that all the parts on KSP 1 are not on KSP 2. Those parts are not optimized to run on KSP 2 because they revamped  everything. Wings are procedural, fuel tanks arent the same, even pods are completely different. I understand that people are upset with how the game is currently running, but the devs have been very transparent with the fact that if you're not happy with it's current state to wait to buy or play the game. I mean, it's still a beta build. They pushed it to early access so they can optimize the game before it goes to full release.

[Lupi]

3 hours ago, TheHallMonitor said:

Idk if KSP 1 runs on the same engine as KSP 2, but the main problem with running a craft from Kerbal X on KSP 2 is that all the parts on KSP 1 are not on KSP 2. Those parts are not optimized to run on KSP 2 because they revamped  everything. Wings are procedural, fuel tanks arent the same, even pods are completely different. I understand that people are upset with how the game is currently running, but the devs have been very transparent with the fact that if you're not happy with it's current state to wait to buy or play the game. I mean, it's still a beta build. They pushed it to early access so they can optimize the game before it goes to full release.

this person means the stock craft named the Kerbal X, not the craft sharing website ALSO named KerbalX

[LordCorwin]

Hi

Given the problems in the last years to be provided with a good graphic card at an adjusted price, could you please consider optimization?

If not, investing in this game would not only be the game prize, but also the graphic card.

Thanks

Edited February 28, 2023 by LordCorwin

[DarkAngelnath]

Running mine on AMD 3600 16gb Ram with a 1650 super. not running massive rockets but just made it to Jool. Runs fine on mine so far, a few glitches but no big issues.