GPU acceleration?

[SirLynix]

Hi,

I'm wondering if Jolt would benefit from using the graphics card via a GPU solver, like PhysX, Newton and Bullet have.

Jolt is really good at using multiple CPU core (and CPU have more core now than in the past) but I'm wondering if you think Jolt could benefit from this, if this is somehow planned and how it would be implemented? Which API would Jolt use (CUDA, OpenCL, Vulkan)? Would this be up to the user to figure out (a bit like Bullet)?

I'm asking because I'm thinking about making a physics intensive (but not graphics intensive) app which could benefit from it, even though I'm still way out of having performance issues with Jolt.

[jrouwe]

GPU physics is definitively on my wish list but not something that is going to happen in the near future. I was thinking about providing an abstract GPU interface with DirectX and Vulkan (and perhaps Metal) implementations. The first focus will probably be to get ray casting against the physics system on GPU (since we do a lot of ray casts) and then I'll see what other parts of the engine could benefit.

[mihe]

I'm not sure how relevant this is, given that it was written four years ago now, but the author of BEPUphysics wrote a blog post about their reasoning for not making it GPU-accelerated. You might find it interesting: https://www.bepuentertainment.com/blog/2019/1/16/-but-gpus-arent-always-the-right-choice

[jrouwe]

Interesting read! It still sounds relevant, I'm worrying about the same things (but you don't really know until you try :)).

[jankrassnigg]

As a user of a physics library, I am quite strongly against running it on the GPU. For one, I want to use it on different platforms that may not support it, so the code would always need to be able to compile both for CPU and GPU, which is tricky in general.

Second, GPUs make it very hard for users to take control. Collision filtering is the obvious aspect. In games you often need to filter certain objects under very specific conditions. Jolt currently gives me a lot of control through callbacks and custom filtering code, which is great.

I've used PhysX back when they were trying to go all in on GPU acceleration, and as a consequence they had very simple, hardcoded filtering methods and they tried to expose "filter shaders" as code that you could compile both for the CPU and the GPU, but it had very limited functionality. It was quite a pain to control and as far as I've seen, they backed more and more away from this idea in recent years.

Havok also dabbled with GPU physics every once in a while, but AFAIK came to the conclusion that it is just not worth it, considering the inflexibility that comes with it, and the amount of rigid bodies games actually use for interaction.

So instead they turned this into a completely separate thing. If you use "particle physics" (IIRC that's what they called it), you get a fairly limited rigid body simulation that can run on the GPU (I think) and is targeted towards simulating thousands of bodies. This is mostly meant for visual effects. I think this is the right choice, because that is really the main use case for large amounts of bodies and you can get away with very restricted functionality in that case.

[Please-just-dont]

Me too, against. Mainly because it gets really really complicated with tons of difference interfaces. Do you use Cuda, OpenCL, DirectX, compute, Vulkan, WebGPU? And then you need figure what features are available for which platforms, it's really complicated stuff.

[jrouwe]

If I add GPU support, it will be an optional feature. I'm well aware that callbacks are not practical on the GPU, so the existing CPU-only implementation will not go away.

So instead they turned this into a completely separate thing. If you use "particle physics" (IIRC that's what they called it), you get a fairly limited rigid body simulation that can run on the GPU (I think) and is targeted towards simulating thousands of bodies. This is mostly meant for visual effects. I think this is the right choice, because that is really the main use case for large amounts of bodies and you can get away with very restricted functionality in that case.

This is exactly what I'm thinking about as well:

• Thousands of very simple bodies for VFX (probably convex hull, box, sphere only).
• Fast ray casts (if the ray casts don't need complex filtering logic and maybe only against static geometry).
• Soft body simulation.

All of them would have CPU fallbacks.

[RoboMage]

I personally think this would be a cool idea. I feel like Astro Bot might be doing something akin to this