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


  • 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?

  • 2
    $\begingroup$ This isn't really the type of question anyone else can answer. It's going to depend entirely on how your fluid sim and rendering are written and the hardware it's running on. Maybe you should put together a prototype and profile it. That could give you data to push you in one direction or the other. $\endgroup$ Oct 2, 2016 at 14:52
  • 1
    $\begingroup$ I would suggest to provide more information to make this question specific. For example, how do you simulate your fluid? Do you use a particle based method such as SPH? Do you use a grid base method(the benchmark you mentioned is a grid based method)? How is your fluid coupled with other objects? All of these will impact the stability, convergence rate, and performance. $\endgroup$ Oct 2, 2016 at 15:57
  • $\begingroup$ Well you did answer my question. The fact that you can't give me a (specific) answer tells me that there, in fact, are scenarios where GPU powered sim is viable and/or desirable. Look at the bold text. $\endgroup$ Oct 2, 2016 at 18:10
  • 3
    $\begingroup$ What's the use of rendering the graphics at 60FPS if fluid simulation runs at 10 steps per second, Even if the simulation is slower, 60fps gives a better interactivity (think of rotating the scene). You could also for example interpolate between simulation steps. $\endgroup$ Oct 3, 2016 at 2:47
  • $\begingroup$ What @JulienGuertault said. There's a difference between a physically correct simulation, and something that's good for gameplay. Also, this isn't really a graphics question. Have you tried gamedev.stackexchange? $\endgroup$
    – 3Dave
    Oct 5, 2016 at 22:38

1 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.


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.


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.


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.


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.

  • 1
    $\begingroup$ Thanks, this will help me to work out how and what to implement and will give me some foundation to work from. Also, the last paragraph is a good advice! $\endgroup$ Oct 4, 2016 at 18:31
  • $\begingroup$ @DavidLively I just rephrased that paragraph. > The SIMT and SIMD models have nothing to do with bandwidth / "transfer latency.". I actually intended to describe how SIMT hides the memory access latency, not the transfer overhead. I think this is a major difference between SIMT and SIMD. I hope it is more clear now. Thank you for pointing out these issues. $\endgroup$ Oct 6, 2016 at 0:04
  • $\begingroup$ @TheyBusyTypist Much better. Thanks for updating. :) $\endgroup$
    – 3Dave
    Oct 6, 2016 at 14:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.