4 ms·

The author is also working on a really impressive voxel physics engine: https://youtu.be/3259aycYcek https://youtu.be/3259aycYcek

by hopfog 2y ago

pornel 2y ago
I'm surprised the simulation is run on the CPU! This problem has solutions that fit the GPU well, even for grid<>particle conversions.
- deleted 2y ago
  [deleted]
- troglobite 2y ago
  this kind of sims are better suited for CPU ;-), gpu are good to work on meshes, not really on pure particles. At GPU are super good for grid based hydro.
  - lukan 2y ago
    "gpu are good to work on meshes, not really on pure particles" Why? Having thousands of particles, all in need of doing the same operations on them in parallel screams GPU to me. It is just way harder to program a GPU, vs a CPU.
    - thegeomaster 2y ago
      Collision detection is usually a tree search, and this is a very branching workload. Meaning that by the time you reach the lowest nodes of the tree, your lanes will have diverged significantly and your parallelism will be reduced quite a bit. It would still be faster than CPU, but not enough to justify the added complexity. And the fact remains that you usually want the GPU free for your nice graphics. This is why in most AAA games, physics is CPU-only.
      - kotsoft 2y ago
        Yeah, pretty much this, I've experimented with putting on the GPU a bit but I would say particle based is 3x faster than a multithreaded & SIMD CPU implementation. Not 100x like you will see in Nvidia marketing materials, and on mobile, which this demo does run on, GPU often becomes weaker than CPU. Wasm SIMD only has 4 wide but the standard is 8 or 16 wide on most CPUs today. But yeah, once you need to do graphics on top, that 3x pretty much goes away and is just additional frametime. I think they should work together. On my desktop stuff, I also have things like adaptive resolution and sparse grids to more fully take advantage of things that the CPU can do that are harder on GPU. The Wasm demo is still in its early stages. The particles are just simple points. I could definitely use the GPU a bit more to do lighting and shading a smooth liquid surface.
        thegeomaster 2y ago
        Agree with most of the comment, just to point out (I could be misremembering) 4-wide SIMD ops that are close together often get pipelined "perfectly" onto the same vector unit that would be doing 8- or 16-wide SIMD, so the difference is often not as much as one would expect. (Still a speedup, though!)
      - lukan 2y ago
        "Collision detection is usually a tree search" Yes, because of the very limited numbers of CPU cores. With a GPU you can just assign one core to one particle. Here is a simple approach to do it with WebGPU: https://surma.dev/things/webgpu/ https://surma.dev/things/webgpu/ It uses the very simple approach, of testing every particle with EVERY other particle. Still very performant (the simulation, the choosen rendering with canvas is very slow) I currently try to do something like this, but optimised. With the naive approache here and Pixi instead of canvas, I get to 20000 particles 120 fps on an old laptop. I am curious how far I get with an optimized version. But yes, the danger is in calculating and rendering blocking each other. So I have to use the CPU in a smart way, to limit the data being pushed to the GPU. And while I prepare the data on the CPU, the GPU can do the graphic rendering. Like I said, it is way harder to do right this way. When the simulation behaves weird, debugging is pain.
    - troglobite 2y ago
      The issue is not really parallelism of computation. The issue is locality. Usually a hydro solver need to solve 2 very different problem short and long range interaction. therefore you "split" the problem into a particle-mesh (long range) and a particle to particle (short range). In this case there is no long range interaction (aka gravity, electrodynamics), therefore you would go for a pure p2p implementation. Then in a p2p, if you have very strong coupling between particles that will insure the fact that neighbors stay neighbors (that will be the case with solids, or with very high viscosity). But in most case you will need are rebalancing of the tree (and therefor the memory layout) every time steps. This rebalancing can in fact dominate the execution time as usually the computation on a given particle represent just a few (order 100) flop. Then this rebalancing is usually faster to be done on CPU than on GPU. Then evidently, you can do this rebalancing "well" on gpu, but the effort to have a proper implementation will be huge ;-).

The author is also working on a really impressive voxel physics engine: https://youtu.be/3259aycYcek https://youtu.be/3259aycYcek

by hopfog 2y ago

The author is also working on a really impressive voxel physics engine: https://youtu.be/3259aycYcek https://youtu.be/3259aycYcek

pornel 2y ago

I'm surprised the simulation is run on the CPU! This problem has solutions that fit the GPU well, even for grid<>particle conversions.

deleted 2y ago
[deleted]
troglobite 2y ago
this kind of sims are better suited for CPU ;-), gpu are good to work on meshes, not really on pure particles. At GPU are super good for grid based hydro.
- lukan 2y ago
  "gpu are good to work on meshes, not really on pure particles" Why? Having thousands of particles, all in need of doing the same operations on them in parallel screams GPU to me. It is just way harder to program a GPU, vs a CPU.
  - thegeomaster 2y ago
    Collision detection is usually a tree search, and this is a very branching workload. Meaning that by the time you reach the lowest nodes of the tree, your lanes will have diverged significantly and your parallelism will be reduced quite a bit. It would still be faster than CPU, but not enough to justify the added complexity. And the fact remains that you usually want the GPU free for your nice graphics. This is why in most AAA games, physics is CPU-only.
    - kotsoft 2y ago
      Yeah, pretty much this, I've experimented with putting on the GPU a bit but I would say particle based is 3x faster than a multithreaded & SIMD CPU implementation. Not 100x like you will see in Nvidia marketing materials, and on mobile, which this demo does run on, GPU often becomes weaker than CPU. Wasm SIMD only has 4 wide but the standard is 8 or 16 wide on most CPUs today. But yeah, once you need to do graphics on top, that 3x pretty much goes away and is just additional frametime. I think they should work together. On my desktop stuff, I also have things like adaptive resolution and sparse grids to more fully take advantage of things that the CPU can do that are harder on GPU. The Wasm demo is still in its early stages. The particles are just simple points. I could definitely use the GPU a bit more to do lighting and shading a smooth liquid surface.
      - thegeomaster 2y ago
        Agree with most of the comment, just to point out (I could be misremembering) 4-wide SIMD ops that are close together often get pipelined "perfectly" onto the same vector unit that would be doing 8- or 16-wide SIMD, so the difference is often not as much as one would expect. (Still a speedup, though!)
    - lukan 2y ago
      "Collision detection is usually a tree search" Yes, because of the very limited numbers of CPU cores. With a GPU you can just assign one core to one particle. Here is a simple approach to do it with WebGPU: https://surma.dev/things/webgpu/ https://surma.dev/things/webgpu/ It uses the very simple approach, of testing every particle with EVERY other particle. Still very performant (the simulation, the choosen rendering with canvas is very slow) I currently try to do something like this, but optimised. With the naive approache here and Pixi instead of canvas, I get to 20000 particles 120 fps on an old laptop. I am curious how far I get with an optimized version. But yes, the danger is in calculating and rendering blocking each other. So I have to use the CPU in a smart way, to limit the data being pushed to the GPU. And while I prepare the data on the CPU, the GPU can do the graphic rendering. Like I said, it is way harder to do right this way. When the simulation behaves weird, debugging is pain.
  - troglobite 2y ago
    The issue is not really parallelism of computation. The issue is locality. Usually a hydro solver need to solve 2 very different problem short and long range interaction. therefore you "split" the problem into a particle-mesh (long range) and a particle to particle (short range). In this case there is no long range interaction (aka gravity, electrodynamics), therefore you would go for a pure p2p implementation. Then in a p2p, if you have very strong coupling between particles that will insure the fact that neighbors stay neighbors (that will be the case with solids, or with very high viscosity). But in most case you will need are rebalancing of the tree (and therefor the memory layout) every time steps. This rebalancing can in fact dominate the execution time as usually the computation on a given particle represent just a few (order 100) flop. Then this rebalancing is usually faster to be done on CPU than on GPU. Then evidently, you can do this rebalancing "well" on gpu, but the effort to have a proper implementation will be huge ;-).