DISCUSSION: PhysX thread splitting

[pincushionman]

All right, so many of us have watched the 2015/3/24 Squadcast and seen what the current state of the game is re: multithreaded PhysX.

As is known, Unity 5's PhysX 3 implementation allows for multiple physics threads. The discussions happening on this board for the past several months have been about whether there was a possibility that single vessels could be spread across threads, and the general consensus was that no, they could not. The squadcast pretty much confirmed this; single vessels are indeed individual threads, and new threads are spawned when vessels undergo separation in the flight scene.

It also showed a major problem with this: complete game freeze while the (new) threads are prepared. On KasperVld's not-junk gaming laptop a 650-ish vessel was split into a rocket and launch tower, and took 45 seconds to prepare and spawn the new threads. Another significant freeze of 15 seconds was also encountered on booster separation. Further staging events (what I would call "reasonable" part counts) showed no noticeable freezes.

Now, the vessel being shown is pretty excessive, and Kasp is on a laptop. But his laptop is a powerful gaming laptop, and even small freezes during gameplay are quite immersion-breaking. Especially on less-powerful older systems that many of us may have. So - we who are not the developers, how do we think they should approach fixing this, and how can they?

I have three different thoughts on the matter, but I'm not really knowledgeable about multithreading, or about Unity/PhysX thread handling in particular. But here goes:

1. Code cleanup. Don't worry guys, it'll get better. Just wait. It could be simply that the current state is running in a non-optimized manner for pre-release, and small things will be done to speed up this simulation step. I don't have high hopes for this, at least for the 1.1 release; after all, they've been workng on the Unity 5 port for nearly a year, and I'd expect low-hanging fruit to be picked by now. But one can always hope.
2. Delay thread splitting. I'm sorry PhysX, I'm kinda busy right now. Vessels are running just fine on a single thread prior to a staging event, and from experience, we know that KSP vessels run just fine on a single thread after staging events, too. It may be possible to prevent PhysX from splitting the objects into separate threads immediately and wait until we have more time to let it happen. Figuring out when that good time is, however, is another problem. But once vessels are in space and no longer thrusting or under atmospheric forces things are much less time-sensitive and we can better afford to be inconvenienced by this.
3. Pre-stage threads for separated vessels. I can see the future. Trust me. The problem with trying to split a single vessel across threads is that information has to be shared in two directions between threads, which is slow and cumbersome. Also, if a vessel can break up in an arbitrary manner, there is no way to predict the best way to split the parts up. However, we have an ace up our sleeve here - the staging list is well-defined. We know which parts will go to which threads beforehand. It may be possible to prepare these threads while the stage prior is active, and only have to copy the state of the appropriate part nodes to them rather than having to stop and wait while the new threads are created from scratch. We don't need to worry about two-way communication for this; the child threads are strictly slaves to the previous stage thread. Ideally we only have to do this for the next staging event if these threads can be created in the background.

Now, as I stated before, I know very little about multithreading besides what's been discussed on this forum, and next to nothing about PhysX, so what I'm suggesting may be completely impossible. It's also possible that some of this is already happening and the process is just that slow. But I'd sure like to hear the thoughts of those of you more knowledgeable than me! Because while the vessels I saw in the Squadcast are excessively large and complex, the freezes are a little scary. And if there's anything that can be done to mitigate that, even if it's a little more processor intensive, it would make me very happy.

TL;DR: Staging can freeze the game. Can it be fixed? I'd rather have a slowdown than a freeze.

[luinux]

Even worse: what would happen to a 600-ish parts rocket during an "unexpected disassembly"? If it splits in, say, 20 big chunks, do that means launching 20 threads in less than an in-game second? Threads share memory, but it seems Unity is copying all of that everytime it spawns a thread, maybe there is some way to reduce the amount of memory a PhysX thread is using?

 

[Temeter]

Btw, the lag hickup probably was an issue with importing files from 1.0. Rich (on stream) explained that this was caused for him by using the stockfix symmetry mod when he build the craft in 105. So when he loaded it in 110, some radial parts were multiplied; where he had 6 clamps before, the game suddenly had to deal with 36 clamps, etc. Would also explain the explosions during launch.

I didn't see those lag issues on other crafts on KSPTV yet, although there wasn't too much superlarge decoupling. In any case, a 260 part proton-like could decouple without the slightest amount of lag.

So most likely everything is fine. Don't think we can really help the devs anyway, aside maybe from reporting bugs in the later prerelease, but nice idea in any way!

Edited March 26, 2016 by Temeter

[NoMrBond]

It's almost certainly a bug, PhysX3.3 should be more than an order of magnitude faster at physics setup than PhysX2.8 was.

I'm sure it'll get ironed out once people get back from Easter