Also, do you have a performance comparison with other physics engines?
Also, do you have a performance comparison with other physics engines?
Regarding GPGPU, you're correct that bepuphysics v2 is strictly CPU-side, and also that I could likely make a GPGPU version faster. I wrote a blog post about why I chose to go with CPU-only: https://www.bepuentertainment.com/blog/2019/1/16/-but-gpus-a...
The short version is comparative advantage. I have other things to use the GPU on, and the GPU is even better at those things. And driver bugs.
Also, as I've mentioned elsewhere, while I have not done rigorous benchmarking, a casual evaluation showed that bepuphysics v2 on the CPU compares well with physX 4.1 running on a GPU of similar cost. Collision detection heavy scenes tend to favor GPU physX, while solver-heavy scenes tend to favor bepuphysics v2.
(Except for AMD's Threadripper CPUs unclear reasons. I suspect inter-CCX communication kills effective memory bandwidth in the solver. A 1700x is about as fast as a 2950x, and modern Intel cpus with full rate AVX2 can be much faster. Zen 2 should change things significantly.)
> if you want to run physics serverside, it’ll probably need to run on things that aren’t windows
On the other hand, you’re in control of hardware. For some kinds of projects, CUDA saves lots of time compared to DirectCompute or OpenCL: better libraries (these hand-optimized BLAS, FFT, etc.), better runtime i.e. simpler CPU-GPU interop, and better language, CUDA is relatively modern C++, with templates and constexpr. Unlike graphics, CUDA runs fine on Linux.
I’m not an expert in CUDA but I’ve completed a couple of projects where my clients needed to compute some GPGPU stuff on their servers, or on other people’s servers they’ve rented.
For my purposes, CUDA isn't really an option due to needing to run simulations on both servers and unknown clients (ideally with a single codebase), but for other services that never leave the datacenter I'd definitely consider it.