Power9

You can't effectively use a GPU and not be parallel - so yes, the GPU portion of PhysX runs in parallel. The complication is that you need to be parallel in a specific way. Although every CPU-bound task in modern games can be parallelized, they can't all be parallelized effectively in the way required by GPUs. Some tasks still require CPU-style code execution. For tasks that run nicely on GPUs the performance benefit of using a GPU is significant, but quite as drastic as it seems. An RTX 2080 Ti gives you a max theoretical performance of ~14 teraflops @ 250W. An AMD Epyc 7742 gets you ~3 teraflops @ 225W. That's a factor of five. GPUs are really good at vector operations, when a bunch of tasks are doing exactly the same thing on adjacent data. They're bad at indirection, for example in object oriented programming, or anything that involves non-adjacent data. They're also bad at small tasks - if you don't have a 100,000 items to process, it's not worth bothering the GPU with it. The algorithms I describe above would probably work fine on a GPU depending on a bunch of details, but your ships in KSP probably don't have enough parts to be worth bothering the GPU with - with a parallel algorithm a decent CPU will be faster on even thousands of discrete parts. With a CPU-parallel physics engine, KSP2 could definitely get us 4x the performance on 8 core CPUs over KSP1, or 20x the performance for people gaming on top of the line server CPUs. With a GPU physics engine, they might be able to get us 50x the simulation performance of KSP 1 for users who have a high end dedicated physics GPU.

I have no idea whether KSP2 will support multiple threads for physics or not, but I *do* know a bit about multithreading. Physics simulations are one of the most well studied areas for parallel programming, and you can *absolutely* do rigid body simulations in parallel. Here's a paper that discusses some of the issues and solutions for multi-threaded game physics as researched by a CS grad student back in 2014: http://scholarworks.sjsu.edu/cgi/viewcontent.cgi?article=1341&context=etd_projects The basic idea for KSP-style rigid body physics is pretty simple: You divide the parts into groups by location, and have a separate thread calculate physics for each group. To handle cross group interactions, you either do the operation in two passes (no conflict motions and conflict detection, followed by conflict resolution) or you allow threads to duplicate a small amount of work recalculating physics for parts belonging to other threads. Either of these strategies scale better than most parallel algorithms for game engines. Maybe they're 20% more expensive than an optimized single threaded solution, but that still would make them more than 3x as fast running physics on 4 cores. In general, there is *no* CPU bound task in a video game that can't be parallelized. The reason we don't see a lot of parallel optimization yet is commercial: it hasn't been a good deal to spend extra developer time to add functionality which excludes users still on dual core boxes.