New patch coming, plus Unity 5 work to begin

[sal_vager]

The move up a version of PhysX does indeed allow multithreaded physics.

Do you have a source for this marach ?

[Wjolcz]

Hope it has some small goodies like the previus one had (small rocket fins).

[basic.syntax]

[marach]

Do you have a source for this marach ?

right here. Scroll down to performance (near the bottom). Also personal experience ofc...

Of the examples out there the video below is the same code in U4 and U5 apparently the models are 11 capsule colliders and 4 sphere colliders each so... ~40x15=600 colliders on screen...

::edit to add::

The unchanged code btw is the reason the guys seem to slide around oddly in U5 some code does need to be fixed manually after the automatic pass U5 does.

Edited May 13, 2015 by marach

[sal_vager]

Performance

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.

Performance ninjas interested in more data should visit Pierre Terdiman’s blog. He’s the core developer behind the PhysX SDK.

Neat.

[Sky_walker]

So, if I understand correctly, Unity 5 will allow folks with multi-core CPUs to use all of the in KSP, right? As it stands with Unity 4, I believe only one core can be used due to how it's put together or whatnot.

If this is the case, then I'm very much looking forward to when it's been implemented

Here is something to read for you:

Is it just me, or is Unity 5 going to be AMAZING for KSP?

How exactly would a Unity 5 update affect KSP?

Unity 5 [is now available]

[NoMrBond]

Of the examples out there the video below is the same code in U4 and U5 apparently the models are 11 capsule colliders and 4 sphere colliders each so... ~40x15=600 colliders on screen....

We need to keep in mind that as impressive as the Gangbeasts demo is, it isn't really representative for KSP because even with PhysX 3.3 while each collection (joined bodies) can have its own thread, a single collection still can't have multiple threads so 4 bodies of 150 parts each will perform a lot better than a single body with 600 parts.

That's not to say the PhysX 2.8.4 to 3.3 upgrade that's occurring from Unity 4 to 5 won't offer benefits from the threading (a ship next to a station, or a rover next to a base could each have independent threads for example) and from moving from x87 only to also supporting SIMD acceleration (plus the new MTJS in Unity 5 itself). The drop mesh and hinge bridge examples from Pierre Terdiman's blog seem the closest in terms for representing what KSP will be doing with the physics system.

[Eric S]

So, if I understand correctly, Unity 5 will allow folks with multi-core CPUs to use all of the in KSP, right? As it stands with Unity 4, I believe only one core can be used due to how it's put together or whatnot.

If this is the case, then I'm very much looking forward to when it's been implemented

Sort of. I'm a programmer, but I've never touched PhysX or Unity aside from reading up on this topic, but here's my general impression.

Unity 5 includes an updated version of PhysX that can split physics simulation between multiple threads and therefore CPU cores. However, they're still not splitting a single grouping up between multiple threads, so unless I'm missing something, we'll still see a one-thread-per-craft limit. So no, octo-core CPUs will not be getting a 700% performance increase on a single craft. It should also be noted that PhysX doesn't scale linearly according to the number of CPU cores you throw at it. One of the developers posted some benchmarks showing that three threads were running about twice as fast as a single thread.

On the other hand, PhysX 3.3 includes a lot of optimizations over PhysX 2.8.(something). In micro-benchmarks involving the kind of connected rigid body simulation that KSP uses, 3.3 is performing about 50% better than 2.8.x Understand that micro-benchmark scores seldom translate directly to real world improvement, but that indicates that even without threaded physics emulation we might see an improvement, though one capped at 50% and even that is optimistic.

From what I understand, assigning separate threads to separate craft should be easy enough that it will probably make it into 1.1. Docking two similar craft together should have performance not too far below having a single one of those craft within the physics window until they actually dock, though docking a simple craft to a complex craft won't show as much of an improvement. So optimal performance improvement will probably occur when you have one craft of similar complexity per CPU core.

On the subject of how much work has been done on Unity 5 already, it sounded like they had a test build of KSP running with Unity 5 though with no comments on if everything was working, let alone debugged. Since the PhysX 3.X API is not backwards compatible with the PhysX 2.X API, it could well be that it came up but most physics was broken.

As a side note, while the devs of some Unity 5 based games have reported quick and smooth porting over to Unity 5, the dev(s) of Beseige, the closest game to KSP in regards to engine physics usage that has commented on how much work the switch to Unity 5 took that I have seen said that after two weeks they still didn't have anything that they could show to users, and the last update that happened a few weeks after that statement was made didn't list an upgrade to U5 in the release notes. I suspect this is because of the PhysX incompatibility.

[bonyetty]

I really wish Devs (in general, not only Squad) wouldn't use twitter for thiese kind of communication - the short format leads to more question than anything.

I'm reading the tweet as

"Tomorrow, hotfix is release, and we start working on Unity 5"

but it can be read as

"Tomorrow, we start working on a hotfix, and we also start working on Unity 5"

And, that changes a lot, since, I'm currently waiting a bit before playing the game...

I read it as the former. And like you have waited to play today.