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.

[egeso14]

Hey @jrouwe , me and @KlachDavid are students at Northwestern University. Currently, we're taking a class in GPU parallel programming using CUDA and we wanted to tackle parallelizing a physics engine for our final project. Jolt is one of the best documented and performant open source Physics Engines out there, which is why we chose it as the subject of our project.

We wanted to ask if you have any advice on where to start. What are some calculations that could really benefit from being parallelized via the GPU? We saw the performance analysis for different thread counts, are there specific parts of the codebase that wouldn't get such diminishing returns from being parallelized?

[jrouwe]

Is the intention to modify Jolt and replace part of it with your CUDA implementation or do you want to use Jolt as a reference on how to do things and want to write a simulation from scratch?

[egeso14]

We intend to modify jolt.

[jrouwe]

I think it's going to be quite hard to modify the existing simulation, but if I had to pick something then the soft body simulation would probably be easiest and you might get some gains there. Another thing you could try is BroadPhase::FindCollidingPairs but my guess is that you won't gain much because of the CPU<->GPU roundtrip and because the CPU cannot start until the GPU finishes (right now the broad phase and narrow phase run in parallel). As stated above, a GPU version of something most likely is not going to replace an existing part of Jolt but rather add a new API to do 'lots of X' (where X is a feature that is also supported through the existing API).

B.t.w. I'm currently looking at DX12, Vulkan and Metal and how to provide a common interface for compute jobs. I don't intend to support CUDA as it is a vendor specific implementation.

[egeso14]

Hey @jrouwe

Sorry for taking a while to respond. Your comments were very helpful in steering us in the right direction.
We wanted to run some performance tests to investigate the areas you pointed out, but got some surprising results. In the sample soft body stress test, which we modified to include a much greater number of shapes, we noticed that our machines were struggling. When we ran the performance test, however, we noticed that the bottleneck was a call to SetColor within Triangle(), which are both part of the debugRenderer script.

We think this is because that script in particular does quite a few GPU calculations on the CPU per cycle. We will continue testing to find other potential bottlenecks, both with soft bodies and the broad phase collision detection as well as without the rendered, but we were curious to why you chose to run the color and normal calculations mentioned earlier on the CPU? Does this relate to the dynamic vertex constraints of soft bodies?

[jrouwe]

I'm going to create a new discussion to stop pinging all other people on this thread:

#1471

[TheFloatingBrain]

I had a suggestion, it seems like one of the issues with GPU acceleration is triggering events and launching queries and such and getting that data back and forth. I wanted to propose that perhaps batch jobs might be possible. That a buffer on the GPU could have entries made on it under certain conditions (events, like collisions). This buffer could then be digested CPU side or operated on by compute shaders (avoid copy operation). The same thing could be done with queries, all this could be fused with collision/physics operations.

Additionally uniforms of other buffers could contain date to test conditions and perform operations ("if the id is the id of the player [do x/put y in the buffer]", "if the id is the id of this kind of entity do [do z/put w in the buffer]").

[eazuooz]

Reason against running a physics engine on the GPU:

Physics simulation and rendering compete for the same GPU resources, leading to performance bottlenecks. Since both are compute-intensive tasks, running them simultaneously can cause contention and reduce overall frame stability.

[Please-just-dont]

@eazuooz There's such a thing as async compute though, which is actually common as far as I know.

[SirLynix]

Async compute is just a secondary command feed that doesn't need to wait or interfere with other tasks (such as rendering), but it uses the same GPU resources (core, memory, ..) and can cause problems like op says.

GPU acceleration is a pretty nice feature to have if you can still wether to use it or not

[jrouwe]

I've opened up a PR that exposes a compute interface: #1847. CI is failing at the moment, so it needs a bit more work.