Jump to content

Allow players to stage another scene on another computer core so that changing scenes would be nearly instantaneous.


Recommended Posts

4 minutes ago, darthgently said:

I don't know about Windows, but mono/KSP on linux pegs one of my 12 CPUs and that is about it.  I've been trying to hunt down more detailed info on persuading mono to maybe be smarter and found a few tricks.  But it was my understanding that KSP, on windows, or linux, only ran in a single process and definitely only on a single core.  Maybe that is Steam stuff you are seeing?  Or I was misinformed

On Windows KSP uses > 1 core, Linux scheduler should be a heck of a lot better though. So idk

Physics in KSP is the only thing that can only be on a single core, and even then you'd have the main thread and the physics thread. So no, I'm sure it wasn't just steam (Those show up as their own process).

Link to post
Share on other sites

As for the physics engine, I'd hope it wouldn't unloaded/reloaded when switching to a craft out of physics range.  But the delay in the case of switching to an unloaded craft tells me it is "rebooted" unless the two craft are already loaded within physics range.  Of course this is all black boxing from the outside.  I don't know.  I could easily imagine a decision to unload/reload the engine whenever feasible if only to tame the Kraken by way of getting a fresh start, clearing rounding errors, etc

Link to post
Share on other sites
2 minutes ago, darthgently said:

As for the physics engine, I'd hope it wouldn't unloaded/reloaded when switching to a craft out of physics range.  But the delay in the case of switching to an unloaded craft tells me it is "rebooted" unless the two craft are already loaded within physics range.  Of course this is all black boxing from the outside.  I don't know.  I could easily imagine a decision to unload/reload the engine whenever feasible if only to tame the Kraken by way of getting a fresh start, clearing rounding errors, etc

Only vessels in the same scene are calculated, this is why you have a "Range" for physics. So only vessels in the same scene, and within the current physics range are calculated.

Link to post
Share on other sites
1 minute ago, Incarnation of Chaos said:

Only vessels in the same scene are calculated, this is why you have a "Range" for physics. So only vessels in the same scene, and within the current physics range are calculated.

Um, yeah, I know that.  Not sure what you are referring to.  I'm talking about when switching to another craft that is out of physics range it may make sense to keep the physics engine in memory and just give it a new scene, but it seems like they reboot it in that case.  Maybe I wasn't clear enough

Link to post
Share on other sites
2 minutes ago, darthgently said:

Um, yeah, I know that.  Not sure what you are referring to.  I'm talking about when switching to another craft that is out of physics range it may make sense to keep the physics engine in memory and just give it a new scene, but it seems like they reboot it in that case.  Maybe I wasn't clear enough

I know they came up with "Krakensbane" for FP errors, but i don't know if that involves resetting/reloading the physics engine itself. I also know they use PhysX, which comes with Unity (Running on the CPU). So you might find an answer digging into those. I don't know enough about how KSP works at that low of a level to give you an answer tbh.

Link to post
Share on other sites
9 hours ago, darthgently said:

I don't know about Windows, but mono/KSP on linux pegs one of my 12 CPUs and that is about it.  I've been trying to hunt down more detailed info on persuading mono to maybe be smarter and found a few tricks.  But it was my understanding that KSP, on windows, or linux, only ran in a single process and definitely only on a single core.  Maybe that is Steam stuff you are seeing?  Or I was misinformed.  I would like to see some technical cites as to Unity/KSP/Mono and mods using more than one core.  I've been told by mod devs that it simply isn't so.  Don't get me wrong, my mind can be changed subject to evidence; and it may be platform dependent I suppose

Since version 1.1, multiple vessels within physics range will be run on separate CPU cores. At least I think so. So few people remember and use this feature that it's hard to believe it's real anymore. To be fair it's not practical to have things like fleets (though there is a mod called Burn Together that helps facilitate this) but it can be good to bear in mind for bases (ie. don't actually connect the modules together).

Edited by Rocket Witch
Link to post
Share on other sites
22 minutes ago, Rocket Witch said:

Since version 1.1 or 1.2, multiple vessels within physics range will be run on separate CPU cores. At least I think so.

You might think wrongly, there.  Or remember something different than what it sounds like you said. Give us a link to information on that change if you can remember where it was.

The way KSP lets any part  potentially interact with any other part in any craft in the scene, lets us build crazy devices (someone even made working clocks) but also prevents the division among craft to be an easy way separating the physics into different threads.

Link to post
Share on other sites

 

31 minutes ago, OHara said:

You might think wrongly, there.  Or remember something different than what it sounds like you said. Give us a link to information on that change if you can remember where it was.

The way KSP lets any part  potentially interact with any other part in any craft in the scene, lets us build crazy devices (someone even made working clocks) but also prevents the division among craft to be an easy way separating the physics into different threads.

Can't find a direct changelog note or news post about it from Squad, but it was discussed at the time as a result of whatever they did officially say.

https://www.reddit.com/r/KerbalSpaceProgram/comments/4na407/

https://steamcommunity.com/app/220200/discussions/0/412448158152361720/

From sal_vager's link:

Quote

PhysX3 is now prepared to run on multicores as the internal computation model is organised in tasks that can be executed on different cores. The SDK does all the multithreading, taking care of all the dependencies itself and granting optimal job decomposition.

From what we’ve seen so far, it’s reasonable to expect a doubling in performance generally just as a result of having a better code base and improved multithreading. In some instances, the improvement is dramatic, with up to tenfold improvements.

In KSP's case, vessels probably aren't entirely offloaded to other threads/cores, but some component of the physics is done separately.

Edited by Rocket Witch
Link to post
Share on other sites
22 minutes ago, Rocket Witch said:

it [multiple threads/cores for physics simulation] was discussed at the time as a result of the move from Unity 4 to 5.

Reddit said  'word on the street' is one core per craft in KSP, linking to the marketing material from Unity, linking to a 12-page blog post that finally says on the last page "and I haven't even talked about multithreading yet." 

If I had to guess, after reading that blog, how he tries to do things in parallel, it would be analysis of the physics situation, like raycasting over all parts to find potential collisions.  The PhysX engine seems to see things as a bunch of independent parts, with joints and potential collisions between them, and I don't see any mention of trying to divide those parts into discrete sets without interconnecting joints (i.e., craft).

Link to post
Share on other sites
On 1/6/2021 at 3:22 AM, SpaceFace545 said:
On 1/6/2021 at 3:16 AM, darthgently said:

Allow players to stage another scene on another computer core so that changing scenes would be nearly instantaneous.  Always keep the last scene frozen on another core for quick back and forth.  Think the button on the TV remote that toggles between current and last channel.  But best to let the player designate scenes that should be preloaded given conditions current scenes.  Available RAM would be a big factor also of course.  But having 64GB of RAM and 12 cores at 4Ghz it just seems really silly I have to wait 45 seconds to go from the VAB to the Space Center

Oh no, you had to wait 45 seconds

If you were to review Sonic '06, would you put the silly loading times under pros rather than cons?

Link to post
Share on other sites
15 hours ago, OHara said:

Reddit said  'word on the street' is one core per craft in KSP, linking to the marketing material from Unity, linking to a 12-page blog post that finally says on the last page "and I haven't even talked about multithreading yet." 

If I had to guess, after reading that blog, how he tries to do things in parallel, it would be analysis of the physics situation, like raycasting over all parts to find potential collisions.  The PhysX engine seems to see things as a bunch of independent parts, with joints and potential collisions between them, and I don't see any mention of trying to divide those parts into discrete sets without interconnecting joints (i.e., craft).

Just to clarify, i never thought vessels on the same scene would be on different threads.

Only things not in scene and "On Rails", because that's what i had heard and seen.

The vessels themselves would be a pain to thread, good discussion about it in another thread.  You'd honestly be better off moving to a different way of handling the ships than trying to multithread the existing implementation.

Link to post
Share on other sites

Yeah, I started this not to redesign the physics of ships in the same scene.  I'm talking about pre-staging things like the Tracking Station.  Only things OUTSIDE of physics range or completely unrelated to the physics of the current vessel.  I've realized from the start that there were limitations in the engine that informed that aspect of KSP.  I'm not talking about the physics.  I'm talking about scenes, scene pre-staging and caching.  But I'm learning some interesting stuff; mostly about how little we really truly know about how Unity and KSP work for certain without a dash of error-bars thrown in

Link to post
Share on other sites
23 hours ago, darthgently said:

Yeah, I started this not to redesign the physics of ships in the same scene.  I'm talking about pre-staging things like the Tracking Station.  Only things OUTSIDE of physics range or completely unrelated to the physics of the current vessel.  I've realized from the start that there were limitations in the engine that informed that aspect of KSP.  I'm not talking about the physics.  I'm talking about scenes, scene pre-staging and caching.  But I'm learning some interesting stuff; mostly about how little we really truly know about how Unity and KSP work for certain without a dash of error-bars thrown in

I honestly feel like you might have unintentionally found a bug in the Linux version, going back and forth from the VAB, runway, tracking station and even things in orbit takes literal seconds for me. (I'm on windows mind you)

But there's plenty here who run Linux and they seem to be fine. So I'm scratching my head over this tbh

Link to post
Share on other sites
1 hour ago, Incarnation of Chaos said:

I honestly feel like you might have unintentionally found a bug in the Linux version, going back and forth from the VAB, runway, tracking station and even things in orbit takes literal seconds for me. (I'm on windows mind you)

But there's plenty here who run Linux and they seem to be fine. So I'm scratching my head over this tbh

Absolutely possible.  I've found that the largest hurdle to solving install issues for KSP is that every one else's install is so completely different.  Even among linux users there are several different ways Mono can be configured and how the graphics card is integrated in can be very different also; NVidia alone as at least 3 fairly different ways to "get it working" permuting across proprietary or open source drivers, etc.  Thow in the permutations of mod combinations/versions, KSP versions, linux distros/kernels, and occasionally mangled GameData data files, sporadic module manager glitches,  and the Kraken, and it becomes very unlikely any other player can relate much to what is going on in one's own install.  As much as I love Environmental Visual Enhancements, I have to say that many of the slowness issues go away when I'm not running it.  It is a shame though because my gut tells me there is plenty of horsepower here to handle it in theory given my graphics card performance, clock speed, etc

 

I am very tempted to build a windows box solely for doing apples to apples comparisons of KSP installs.  Same mods, same hardware, etc.  Just windows vs linux, but these days, unless you buy the hardware at the same time and do some homework it is very likely the hardware won't really be identical for an off the shelf machine with apparently the same labeling.  Dual boot would be the way to do it

Edited by darthgently
Link to post
Share on other sites
On 1/11/2021 at 2:44 PM, darthgently said:

Absolutely possible.  I've found that the largest hurdle to solving install issues for KSP is that every one else's install is so completely different.  Even among linux users there are several different ways Mono can be configured and how the graphics card is integrated in can be very different also; NVidia alone as at least 3 fairly different ways to "get it working" permuting across proprietary or open source drivers, etc.  Thow in the permutations of mod combinations/versions, KSP versions, linux distros/kernels, and occasionally mangled GameData data files, sporadic module manager glitches,  and the Kraken, and it becomes very unlikely any other player can relate much to what is going on in one's own install.  As much as I love Environmental Visual Enhancements, I have to say that many of the slowness issues go away when I'm not running it.  It is a shame though because my gut tells me there is plenty of horsepower here to handle it in theory given my graphics card performance, clock speed, etc

 

I am very tempted to build a windows box solely for doing apples to apples comparisons of KSP installs.  Same mods, same hardware, etc.  Just windows vs linux, but these days, unless you buy the hardware at the same time and do some homework it is very likely the hardware won't really be identical for an off the shelf machine with apparently the same labeling.  Dual boot would be the way to do it

You could also look into IOMMU Passthrough, there's a bit of overhead but it's around 5%.

So if it was genuinely a Linux specific bug, the performance would be much, much greater than any deficit caused by the passthrough setup.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...