KSP 2 - Multi-core optimization?

[saxappeal89129]

I'm a long time Kerbal fan, going back to the early beta days of the game and enjoyed every updated along the way...

However, I'm hoping that the game will be running on an updated engine, as well as multi-thread/core optimization so we can see some truly stunning visuals along with game mechanics that seem(ed) to be limited in KSP 1 (enter the Kraken). Anyone have any information on their game engine, and/or ideas for optimization?

The project seems very ambitious with all of the off-world building that's described. Even with my current i7 9800x on an X299 I can run into some flakey physics once I start building on Duna or other planets. I'm hoping that they are able to rectify this and keep (if not upgrade) the physics and realism.

Regardless... the vids and diaries that I've had the time to read look great; can't wait to get back into the KSP mood and play v.2.0

[MechBFP]

I think the plan is to multithread as much as is reasonably possible. 
There will be likely be some limitations based on both what Unity allows as an engine, and how the physics is being handled, but I expect much smoother performance overall. 

[saxappeal89129]

Thank you... I was hoping that they'd pass on Unity and go with a different engine but multithreading should help significantly, as well as retooling from the bottom up.

[DStaal]

1 minute ago, saxappeal89129 said:

Thank you... I was hoping that they'd pass on Unity and go with a different engine but multithreading should help significantly, as well as retooling from the bottom up.

What engine do you think would do better?  Note that I do think they'll have rewritten large portions of the physics engine.

[Incarnation of Chaos]

The physics LOD's will likely be handled on seperate threads until they need to be merged into one for actual calculations, but i don't think that's the only threaded optimization they'll do.

Honestly wish i knew more about threaded code tbh..

[GoldForest]

Going multi-core might not be such a good idea. Splitting the load up among multi-cores might actually hinder physics handling. Physics handling loves single cores, because now all the calculations are in a single place. If you split up the physics load to multiple cores, now the cores have to piece together the physics calculations, which means there's room for error. 

Going single-core might be best, just like with KSP 1.

Also, even if they choose single-core and multi-core, you're still going have to rely on your CPU speed. Physics LOVES speed. A 4.5ghz to 5ghz cpu does way better than a 3.5 ghz to 4 ghz cpu. I should know. I went from a X99 to Z370 and KSP suddenly performed better for me. 

[NoMrBond]

Hopefully they're using DOTS (and HAVOK stateful physics too)

[Incarnation of Chaos]

54 minutes ago, GoldForest said:

Going multi-core might not be such a good idea. Splitting the load up among multi-cores might actually hinder physics handling. Physics handling loves single cores, because now all the calculations are in a single place. If you split up the physics load to multiple cores, now the cores have to piece together the physics calculations, which means there's room for error. 

Going single-core might be best, just like with KSP 1.

Also, even if they choose single-core and multi-core, you're still going have to rely on your CPU speed. Physics LOVES speed. A 4.5ghz to 5ghz cpu does way better than a 3.5 ghz to 4 ghz cpu. I should know. I went from a X99 to Z370 and KSP suddenly performed better for me. 

I really don't envy people who have to program thread-safe physics systems....

That being said the tools are there; it's just a question of if they're actually worth it performance wise. Holding up everything just to force two threads to agree on a previous calculation would introduce stutter, and potentially hurt far more than help. But that's the brute-force approach, and wouldn't be considered by professional programmers in this case.

Actual physics calculations (Collisions, Acceleration etc.) won't get off one thread without them completely tearing out and replacing the way Unity handles physics. Universe Sandbox accomplishes Multithreaded Physics by using an assortment of custom C++ code that they jack into Unity's API's; written by specialists in the field (An astrophysics major if i'm not mistaken actually).

And that still has it's limits; due to precision of the data types available. Forcing most simulations past a few bodies to run barely faster than real-time.

But the majority of 6 and 8 core CPU's today are within 4.5 to 5.0 Ghz, and there's not much of a discrepancy with IPC until you get to about <5 year old hardware for intel. Anything Bulldozer/Kavari pretty much belongs in the garbage though, and that's despite their high clocks stock.

But no; they're not going single core for KSP2. Even KSP1 isn't "Truly" single-threaded, as it uses spare threads to handle out-of-focus vessels and draw calls.

So even in the worst case; we're looking at these same threads being used more by also putting "Culled" groups of parts that physics LOD has handled onto them. Along with KSP1's current optimizations with unloaded/out of focus vessels, along with the complete rewrite that comes with a new team and a newer version of unity.

I don't think we'll see physics on multiple cores though; since Physics LOD isn't splitting the actual calculations up (Just treating groups of parts not doing much as a single one). So you're correct that Physics will remain Single-threaded, but KSP2 will be a multi-threaded game from day one. Which also bodes well; since KSP1's threading occurred well after release.

 

[GoldForest]

4 hours ago, Incarnation of Chaos said:

I really don't envy people who have to program thread-safe physics systems....

That being said the tools are there; it's just a question of if they're actually worth it performance wise. Holding up everything just to force two threads to agree on a previous calculation would introduce stutter, and potentially hurt far more than help. But that's the brute-force approach, and wouldn't be considered by professional programmers in this case.

Actual physics calculations (Collisions, Acceleration etc.) won't get off one thread without them completely tearing out and replacing the way Unity handles physics. Universe Sandbox accomplishes Multithreaded Physics by using an assortment of custom C++ code that they jack into Unity's API's; written by specialists in the field (An astrophysics major if i'm not mistaken actually).

And that still has it's limits; due to precision of the data types available. Forcing most simulations past a few bodies to run barely faster than real-time.

But the majority of 6 and 8 core CPU's today are within 4.5 to 5.0 Ghz, and there's not much of a discrepancy with IPC until you get to about <5 year old hardware for intel. Anything Bulldozer/Kavari pretty much belongs in the garbage though, and that's despite their high clocks stock.

But no; they're not going single core for KSP2. Even KSP1 isn't "Truly" single-threaded, as it uses spare threads to handle out-of-focus vessels and draw calls.

So even in the worst case; we're looking at these same threads being used more by also putting "Culled" groups of parts that physics LOD has handled onto them. Along with KSP1's current optimizations with unloaded/out of focus vessels, along with the complete rewrite that comes with a new team and a newer version of unity.

I don't think we'll see physics on multiple cores though; since Physics LOD isn't splitting the actual calculations up (Just treating groups of parts not doing much as a single one). So you're correct that Physics will remain Single-threaded, but KSP2 will be a multi-threaded game from day one. Which also bodes well; since KSP1's threading occurred well after release.

 

I never said anything about threads, only cores. I never said KSP wouldn't be multi-threaded. Even single core games run multiple threads. Thousands of them in fact.... Threads are the most confusing thing in the computer world. "Multi-threaded" can be a 4 core acts like an 8 core, or it can mean the system is processing "threads." 

Anyway,

Also yes, most CPUs today are 4.5 to 5.0 ghz, but the majority of people are still actually on old hardware running 2.5 to 3.5 ghz CPUs such as the 2000 or 3000 series Intels. Of course, you do have overclockers that are getting 4 to even 4.5 ghz out of those 2000/3000 series. 

 

  

4 hours ago, NoMrBond said:

Hopefully they're using DOTS (and HAVOK stateful physics too)

DOTS didn't come out until after production was far down the line. KSP2 will more than likely not be using DOTS. KSP2 started production around 2017 to 2018. DOTS came out mid 2019(?).

Edited February 29, 2020 by GoldForest

[Incarnation of Chaos]

15 minutes ago, GoldForest said:

I never said anything about threads, only cores. I never said KSP wouldn't be multi-threaded. Even single core games run multiple threads. Thousands of them in fact.... Threads are the most confusing thing in the computer world. "Multi-threaded" can be a 4 core acts like an 8 core, or it can mean the system is processing "threads." 

Anyway,

Also yes, most CPUs today are 4.5 to 5.0 ghz, but the majority of people are still actually on old hardware running 2.5 to 3.5 ghz CPUs such as the 2000 or 3000 series Intels. Of course, you do have overclockers that are getting 4 to even 4.5 ghz out of those 2000/3000 series. 

 

And this again

KSP2 will be a game using multiple CPU cores at the same time, KSP 1 does this already. Though KSP1 only loads the additional cores about ~30 percent.

And yeah, but those are....*Looks up i5-3570k's release date*....April 2012....8 years......wow i feel old now.....

So anyone on a 2 series or 3 series is due for a upgrade anyway, and still has a CPU which won't make the game anywhere near unplayable in the meantime given a decent GPU.

[mcwaffles2003]

25 minutes ago, GoldForest said:

DOTS didn't come out until after production was far down the line. KSP2 will more than likely not be using DOTS. KSP2 started production around 2017 to 2018. DOTS came out mid 2019(?).

Is this kind of change far too much to accommodate or later upgrade to in time? Would the performance difference be drastically better? And if the game has been delayed to Q4 2020 or Q1 2021 would that be sufficient time (if it IS worth it) to convert to using a system like this?

[GoldForest]

Just now, mcwaffles2003 said:

Is this kind of change far too much to accommodate or later upgrade to in time? Would the performance difference be drastically better? And if the game has been delayed to Q4 2020 or Q1 2021 would that be sufficient time (if it IS worth it) to convert to using a system like this?

I'm not the person to be asking this. 

[mcwaffles2003]

Just now, GoldForest said:

I'm not the person to be asking this. 

Just throwing it out there for someone who it

The things I've seen about DOTS look cool/promising so that leads me to asking it, but as a non-programmer maybe I'm a fool and it is snake oil

[Incarnation of Chaos]

5 minutes ago, mcwaffles2003 said:

Just throwing it out there for someone who it

The things I've seen about DOTS look cool/promising so that leads me to asking it, but as a non-programmer maybe I'm a fool and it is snake oil

I think it's more of a case of dependencies with this; if you already decided to implement an alternate physics system then moving to DOTS would require rewriting any and all code using the functions of the previous system. Which also means all of your saves, craft or anything else are incompatible, and when you're in the middle of development just trying to get a product out the door you eventually just have to stick with one build and move. Otherwise you'd never get a game out because it would break literally every few weeks/days due to some new tech being pushed to the live build, and never stop.

This also means that once the game goes live; it only becomes increasingly more difficult to make the switch over time.

As for performance i have no clue, so hopefully someone will see it and know like you're wanting.

[mcwaffles2003]

Just now, Incarnation of Chaos said:

I think it's more of a case of dependencies with this; if you already decided to implement an alternate physics system then moving to DOTS would require rewriting any and all code using the functions of the previous system. Which also means all of your saves, craft or anything else are incompatible, and when you're in the middle of development just trying to get a product out the door you eventually just have to stick with one build and move. Otherwise you'd never get a game out because it would break literally every few weeks/days due to some new tech being pushed to the live build, and never stop.

This also means that once the game goes live; it only becomes increasingly more difficult to make the switch over time.

As for performance i have no clue, so hopefully someone will see it and know like you're wanting.

That's about what I've figured but so far when it comes to the physics system we haven't seen much yet outside the pre-alpha footage from september (which didn't look anywhere close to finished). So I'm hoping that wasn't the first thing they started working on and it is still under development. My assumption is that though the physics system is core to our gameplay, maybe it isn't the core base of the code in the game. So changing it wouldn't require a rewrite of the game as a whole, but instead a part of the code followed by hooking it into the rest of the code.

[Curveball Anders]

17 hours ago, saxappeal89129 said:

Thank you... I was hoping that they'd pass on Unity and go with a different engine but multithreading should help significantly, as well as retooling from the bottom up.

Are volunteering to rewrite the game from scratch using a different game engine?

Ain't gonna happen, ever.

Edited February 29, 2020 by Curveball Anders
oops

[Guest]

5 hours ago, Curveball Anders said:

Are volunteering to rewrite the game from scratch using a different game engine?

Also, which one, and why?

 

[Chilkoot]

14 hours ago, GoldForest said:

Going single-core might be best, just like with KSP 1.

"Best" is a stretch when you look at the physics performance of KSP 1.  Physics calcs have been - by far and away - the single most limiting factor for game performance since day 1 in KSP and arguably the reason a KSP 2 is needed at all.

Even with the challenges of multi-core physics programming, the entire CPU industry is rushing headlong into more and more cores, and it would be foolish to program the game not to move with the industry.  When you consider the fact that KSP 2 will be built ground-up for console performance (GPU physics offload, anyone?) and the *possibility* it will be ported to ARM architecture for the tablet industry, I would suggest there is essentially zero chance the physics in KSP 2 will be single-core.  I can't imagine the publisher being so short-sighted as to permit this.

[Guest]

47 minutes ago, Chilkoot said:

Even with the challenges of multi-core physics programming, the entire CPU industry is rushing headlong into more and more cores, and it would be foolish to program the game not to move with the industry.  When you consider the fact that KSP 2 will be built ground-up for console performance (GPU physics offload, anyone?) and the *possibility* it will be ported to ARM architecture for the tablet industry, I would suggest there is essentially zero chance the physics in KSP 2 will be single-core.  I can't imagine the publisher being so short-sighted as to permit this.

I'm not a domain expert in this either, but my understanding is that a multithreaded physics engine would be a really hard thing to write. Such things exist in professional engineering applications with licenses that cost thousands or tens of thousands of dollars. 

In other words I'm pretty certain that KSP2 will use Unity's built-in physics engine. If that's single-threaded, then KSP2's physics will be single-threaded too.

[GoldForest]

53 minutes ago, Chilkoot said:

"Best" is a stretch when you look at the physics performance of KSP 1.  Physics calcs have been - by far and away - the single most limiting factor for game performance since day 1 in KSP and arguably the reason a KSP 2 is needed at all.

Even with the challenges of multi-core physics programming, the entire CPU industry is rushing headlong into more and more cores, and it would be foolish to program the game not to move with the industry.  When you consider the fact that KSP 2 will be built ground-up for console performance (GPU physics offload, anyone?) and the *possibility* it will be ported to ARM architecture for the tablet industry, I would suggest there is essentially zero chance the physics in KSP 2 will be single-core.  I can't imagine the publisher being so short-sighted as to permit this.

A lot of games made are still single or dual core performance optimized. Intel and AMD are pushing multi core cpus so they can raise prices. It has nothing to do with the video game industry.

3 minutes ago, Brikoleur said:

I'm not a domain expert in this either, but my understanding is that a multithreaded physics engine would be a really hard thing to write. Such things exist in professional engineering applications with licenses that cost thousands or tens of thousands of dollars. 

In other words I'm pretty certain that KSP2 will use Unity's built-in physics engine. If that's single-threaded, then KSP2's physics will be single-threaded too.

Multi-core physics is a can of worms that needs time and money that Take Two probably isn't willing to shill out. After all, KSP 2 is still considered an indie title. 

I foresee KSP 2 physics being single core optimized, just like KSP 1. Simple and easy. Maybe a future update might bring better physics down the line.

[DStaal]

41 minutes ago, GoldForest said:

A lot of games made are still single or dual core performance optimized. Intel and AMD are pushing multi core cpus so they can raise prices. It has nothing to do with the video game industry.

I'd say it's more because they're trying to design more powerful chips, while they've basically already hit the limit of how fast silicon can cycle.  However they can add more transistors to the same area of silicon - so to make a more powerful chip they need to figure out how to make use of that to allow more operations per cycle.  Obvious answer is to build more operations pipelines.

[Incarnation of Chaos]

9 hours ago, GoldForest said:

A lot of games made are still single or dual core performance optimized. Intel and AMD are pushing multi core cpus so they can raise prices. It has nothing to do with the video game industry.

The section in bold is one of the most absurd things iv'e seen tonight, and that's saying something.

https://www.anandtech.com/show/4083/the-sandy-bridge-review-intel-core-i7-2600k-i5-2500k-core-i3-2100-tested/2

Normally i wouldn't use a 3rd party site, but Intel seems to have misplaced the "Recommended consumer price" for their older CPU's on ARK.

So here's a review  from 2011, and the i7- 2600k was a quad core with hyper-threading. MSRP was 317 for a 32nm chip

https://ark.intel.com/content/www/us/en/ark/products/97129/intel-core-i7-7700k-processor-8m-cache-up-to-4-50-ghz.html

And here's the 7700k almost 6 years later with the same configuration on 14nm with a MSRP of 339- 350, and 350 was the much more common number. So intel made the same CPU for 6 years and pricing only went up it seems; this is especially interesting considering that as the process size decreases the # of CPU's you can fit on a wafer increases making them cheaper for them to produce.

Yes the 7700K is a better chip with better IPC, but that's not what you're paying for. It's all margin bby, and if you want even better proof of that?

https://www.newegg.com/intel-core-i3-9th-gen-core-i3-9100/p/N82E16819118022

That's a quad core without HT (The markup for HT is purely segmentation, and doesn't actually increase the price of a chip by a hundred dollars +)

137.00 USD, and it's still on 14nm.

And while games have been slow to move to more cores; it's been a steady process for the last few years. And more and more applications that aren't games are using more than 2 threads, and running in the background with them.

So while it's debatable if the Video Game industry is playing a role; Software as an industry is certainly doing so. 

10 hours ago, Chilkoot said:

"Best" is a stretch when you look at the physics performance of KSP 1.  Physics calcs have been - by far and away - the single most limiting factor for game performance since day 1 in KSP and arguably the reason a KSP 2 is needed at all.

Even with the challenges of multi-core physics programming, the entire CPU industry is rushing headlong into more and more cores, and it would be foolish to program the game not to move with the industry.  When you consider the fact that KSP 2 will be built ground-up for console performance (GPU physics offload, anyone?) and the *possibility* it will be ported to ARM architecture for the tablet industry, I would suggest there is essentially zero chance the physics in KSP 2 will be single-core.  I can't imagine the publisher being so short-sighted as to permit this.

GPU Physics acceleration is not happening for the same reason that it's not going to be on multiple threads on the CPU; they'd have to actually write completely custom code and change their physics system to handle it. AND doing ANYTHING on a GPU is much harder than the CPU programing wise; this means they'd need to hire specialists in the field to do so.

Also KSP2 isn't hitting mobile; don't know where you got that from even.

Bottom line it's not the publishers being lasy or the studios being lasy; it's that at the end of the day they have to get a product out the door with the tools available to them at that moment. And hiring a team of astrophysics majors just to write custom code for a video game is a losing proposition financially and from a publisher standpoint; especially since there's plenty of optimization that'll be done just by starting from a clean slate.

KSP2 will likely perform much better than KSP1 given time, but it won't be due to exotic algorithms or bespoke implementation of physics on the GPU. It'll be the developers using clever code to reduce the number of objects that have to be calculated from the start, and many sleepless nights chasing bugs.

 

[wumpus]

18 hours ago, Brikoleur said:

I'm not a domain expert in this either, but my understanding is that a multithreaded physics engine would be a really hard thing to write. Such things exist in professional engineering applications with licenses that cost thousands or tens of thousands of dollars. 

In other words I'm pretty certain that KSP2 will use Unity's built-in physics engine. If that's single-threaded, then KSP2's physics will be single-threaded too.

I've heard that a surprising amount of professional engineering applications (mostly electrical design and simulation, but I wouldn't be surprised if it was the same in other disciplines) are single threaded.  The people who are plunking down thousands or more dollars want accurate results, and it getting remaining bugs out of multi-threaded code is wildly harder than single threaded code.  As a side note, they also use double precision, something Unity (and any other game engine) avoids.  This is the whole point of the "floating origin" was to kill the Kraken that using single point "floats" created.

Unless Unity does some massive work on their physics engine, expect similar results as KSP1.  We might hope for double precision, but unless they expect more "physics/science heavy simulations" (car racing won't cut it) don't expect Unity to bother.

[Starman4308]

I'm under the impression that the style of rigid-body physics KSP employs is particularly nasty if you want to parallelize and optimize it, as it requires self-consistent solution of a series of mutually interacting constraints.

What I suspect KSP 2 will be doing is much smarter than trying to optimize the rigid-body physics engine: I suspect they're going in for some form of parts welding. If it keeps the total rigid-body-element count in the 100-200 range, that should keep the rigid-body physics from being the limiting factor for KSP 2 performance.

From there, you can keep the per-vessel physics single-threaded, reducing the chances of bugs and the difficulty of implementation. Parallelization efforts can be focused on more loosely coupled items like "have each vessel's physics on a separate thread" and "have a thread for the on-rails vessels".

[Guest]

4 minutes ago, Starman4308 said:

I suspect they're going in for some form of parts welding. If it keeps the total rigid-body-element count in the 100-200 range, that should keep the rigid-body physics from being the limiting factor for KSP 2 performance.

Yep, that's my bet too. A physics LOD system should be much easier than multithreaded physics, and if done well you really wouldn't notice.