Fluid sim: CPU vs. GPU

Question

I have very recently started looking into real-time fluid simulation. Idea is to make a game that would use 3D fluid simulation as a core gameplay mechanic.

Looking around the web, I found this article that compares the performance of fluid simulations on CPU and GPU. While the article itself is a bit dated, I assume that while CPUs and GPUs today are faster, the performance ration between the two has stayed similar enough to keep the article relevant. Actually, comparing their hardware (Core 2 Quad Q6600 and GeForce 8800 GT) to today's hardware (eg. i5 6600K and GTX 1070), CPU has 230% performance gain, while GPU has staggering 1670% performance gain. This would make the article more relevant today than it was before (more than six times).

Now, using the biggest grid they tested with (GS, 128^3, page 7, table 2), GPU simulation was over 3000 times faster than the CPU simulation. Even if utilizing 4 cores (they were using only a single thread), it's still over 700-fold performance gain (back in the day, today that would go up to 5000-fold). Given the results for smaller grids, that difference would only increase with bigger grids than 128^3.

The question is, along with all the normal rendering the GPU is tasked with doing, is it viable to burden it with the task of computing the simulation too, in any case at all?

What's the use of rendering the graphics at 60FPS if fluid simulation runs at 10 steps per second, effectively making the game look like it's running at 10FPS? Wouldn't it be better if I rendered graphics at 30FPS, but could do the simulation at 30 steps per second as well?

Basically, the question is, what would take longer:

• For the GPU to render a frame AND compute the simulation step

OR

• For the CPU to compute rest of the game logic AND compute the simulation step.

I know that this heavily depends on the GPU involved and the remainder of the GPU and CPU load, but look at the whole thing this way:

Even if I used just 1% of the power of GPU, the speed would still be 7(50!) times greater than using the CPU.

I'm a big novice in when it comes to computer graphics, so I may have gotten it all wrong. Does anything I wrote make any sense, or is it just gibberish?

Answer 1

Let's go through the paper you mentioned and try to list the factors which will affect your decision on whether to use GPU or CPU for simulation. I will also add some comments about my opinion for each factor.

Computation bound

A GPU program runs in a SIMT(Single instruction, multiple threads) model. In this model, if some threads stall due to memory access or divergence, thread scheduler will schedule another set of threads to run to hide the memory latency.

As we can see it requires adequate computation load to make this mechanism work. If one implementation is memory bound, we hardly benefit from the SIMT programming model.

Fortunately, fluid simulation is a computation bound task for most of the cases.

Locality

In the paper you mentioned we can observe perfect locality:
for each grid point we only have to examine its neighbors.

The actual memory access pattern depends on the finite difference scheme you use. But for all grid based simulation methods(Eulerian or Lattice-Boltzmann method), I think the locality always presents.

Divergence

A warp (a group of 32 threads) in a GPU program can be executed in parallel if they follow the same code path. Otherwise the program diverges and the execution of each branch will be serialized. Divergence will hurt the performance.

In particle based simulations (such as SPH method) we usually have to query the nearest N particles. A tree-like data structure will be used.

In GPU a tree data structure may introduce divergence because particles may fall into different branches.

The paper you mentioned uses grid based methods, where all threads execute along the same code path (Jacobi or Gauss-Seidel iteration), so divergence is not a problem here.

Interactivity

In the paper it uses static boundary conditions.
For this case you just need to upload the boundary conditions to GPU memory only once.

If you have dynamic boundary conditions, for example, which are specified by the user at each frame, the overhead of memory transfer between GPU and CPU should be taken into consideration.

Spatial complexity

Uniform grid based simulations cannot handle very large computation volume, because the spatial complexity is cubic.

There are adaptive grid methods, which use relatively higher resolution for the computation region we are most interested in. But that would also bring in divergence.

Numerical issues

For fluid simulation you cannot decide the number of steps solely based on the performance/frame rate.

In grid based methods, the Courant–Friedrichs–Lewy (CFL) condition puts a constraint on how large simulation step you can have. Given a fixed time step, too large or too small steps would cause instability and blow up the simulation.

In particle based methods and some stable grid based methods (such as the semi-Lagrangian method used in the paper), we can use relatively larger simulation steps.

But we still cannot increase the step size with no bound because of the accuracy. For example in grid based methods a large step size would introduce too much numerical viscosity.

Summary

As a summary, if your simulation has strong convergence and locality, prefer a GPU implementation; otherwise, prefer a CPU one.

In practice, I will always implement a CPU version because it is easier to debug and it will be useful as a baseline. Then I will profile it to locate the bottleneck and decide whether to have a GPU version.