Uploaded August 2022 | Updated September 2026, 1 week ago
There is no time for caution when Cooper lands Ranger 1 on Miller's planet in Interstellar.
FluidX3D source code: github.com/ProjectPhysX/FluidX3D
This is the largest CFD simulation ever done on a single GPU node, with 10 billion LBM grid points on 4x AMD Instinct MI250 (8x MI200 GCD with 64GB VRAM each).
Simulating 36k time steps took 123 minutes at 2152×4784×968 grid resolution, plus 203 minutes for rendering 5x 20s 1080p video. Shown is the Q-criterion isosurfaces with marching-cubes. Reynolds number is 1 Million with Smagorinsky-Lilly subgrid model.
How is it possible to squeeze 10 billion grid points in only 512GB?
I'm using two techniques here, which together form the holy grail of lattice Boltzmann, cutting memory demand down to only 55 Bytes/node for D3Q19 LBM, or 1/3 of conventional codes:
1. In-place streaming with Esoteric-Pull. This almost cuts memory demand in half and slightly increases performance due to implicit bounce-back boundaries.
Paper: doi.org/10.3390/computation10060092
2. Decoupled arithmetic precision (FP32) and memory precision (FP16): all arithmetic is done in FP32, but LBM density distribution functions in memory are compressed to FP16. This almost cuts memory demand in half and almost doubles performance, without impacting overall accuracy for most setups.
Paper: researchgate.net/publication/362275548_Accuracy_and_performance_of_the_lattice_Boltzmann_method_with_64-bit_32-bit_and_customized_16-bit_number_formats
Graphics are done directly in FluidX3D with OpenCL, with the raw simulation data already residing in ultra-fast video memory. No volumetric data (1 frame of the velocity field is 14GB!) ever has to be copied to the CPU or hard drive, but only rendered 1080p frames (8MB) instead. Once on the CPU side, a copy of the frame is made in memory and a thread is detached to handle the slow .png compression, all while the simulation is already continuing. At any time, about 16 frames are compressed in parallel on 16 CPU cores, while the simulation is running on GPU.
Paper: researchgate.net/publication/360501260_Combined_scientific_CFD_simulation_and_interactive_raytracing_with_OpenCL
Timestamps:
0:00 side view
0:20 follow view
0:40 wing view
1:00 window view
1:20 front view
#CFD #GPU #FluidX3D #OpenCL
There is no time for caution when Cooper lands Ranger 1 on Miller's planet in Interstellar.
FluidX3D source code: github.com/ProjectPhysX/FluidX3D
This is the largest CFD simulation ever done on a single GPU node, with 10 billion LBM grid points on 4x AMD Instinct MI250 (8x MI200 GCD with 64GB VRAM each).
Simulating 36k time steps took 123 minutes at 2152×4784×968 grid resolution, plus 203 minutes for rendering 5x 20s 1080p video. Shown is the Q-criterion isosurfaces with marching-cubes. Reynolds number is 1 Million with Smagorinsky-Lilly subgrid model.
How is it possible to squeeze 10 billion grid points in only 512GB?
I'm using two techniques here, which together form the holy grail of lattice Boltzmann, cutting memory demand down to only 55 Bytes/node for D3Q19 LBM, or 1/3 of conventional codes:
1. In-place streaming with Esoteric-Pull. This almost cuts memory demand in half and slightly increases performance due to implicit bounce-back boundaries.
Paper: doi.org/10.3390/computation10060092
2. Decoupled arithmetic precision (FP32) and memory precision (FP16): all arithmetic is done in FP32, but LBM density distribution functions in memory are compressed to FP16. This almost cuts memory demand in half and almost doubles performance, without impacting overall accuracy for most setups.
Paper: researchgate.net/publication/362275548_Accuracy_and_performance_of_the_lattice_Boltzmann_method_with_64-bit_32-bit_and_customized_16-bit_number_formats
Graphics are done directly in FluidX3D with OpenCL, with the raw simulation data already residing in ultra-fast video memory. No volumetric data (1 frame of the velocity field is 14GB!) ever has to be copied to the CPU or hard drive, but only rendered 1080p frames (8MB) instead. Once on the CPU side, a copy of the frame is made in memory and a thread is detached to handle the slow .png compression, all while the simulation is already continuing. At any time, about 16 frames are compressed in parallel on 16 CPU cores, while the simulation is running on GPU.
Paper: researchgate.net/publication/360501260_Combined_scientific_CFD_simulation_and_interactive_raytracing_with_OpenCL
Timestamps:
0:00 side view
0:20 follow view
0:40 wing view
1:00 window view
1:20 front view
#CFD #GPU #FluidX3D #OpenCL
![FluidX3D [FLUID SIMULATION] Some Real Time Demonstrations](https://i.ytimg.com/vi/kpCAaydlzi4/mqdefault.jpg "FluidX3D [FLUID SIMULATION] Some Real Time Demonstrations
FluidX3D is a real time 3D fluid simulation based on the lattice Boltzmann method. It is written in OpenCL (GPU code) and optimized to the physical limit (video memory bandwith, ~500GB/s).
FluidX3D has been completely overhauled, all velocity sets (D2Q9, D3Q13, D3Q15, D3Q19, D3Q27) as well as all collision operators (single relaxation time (SRT), two relaxation time (TRT), multi relaxation time (MRT)) have been added and can be freely combined. In my implementation, neither TRT or MRT have any measurable performance impact since the bottleneck is still the memory bandwidth, capped by the hardware to about 420GB/s on the Titan Xp. The swap algorithm is OS-Pull (fastest algorithm, but not as memory efficient) and the data layout is the faster struct-of arrays (SoA). Ive reached the optimization limit with 2.6 Giga lattice updates per second (GLUPs) for D3Q19 on the Titan Xp.
Ive translated my graphics library Line3D into OpenCL with the Bresenham algorithm for drawing lines on a bitmap. It can handle up to 2 billion lines per second, which is way faster than all other graphics libraries for primitive shapes out there.
For more information about FluidX3D and my other projects, visit
http://www.projectphysx.de
Music: CMA - Youre Not Alone")
![DroneEngine [QUADCOPTER SIMULATION] June Update: control modes](https://i.ytimg.com/vi/kps6_SK4Dw4/mqdefault.jpg "DroneEngine [QUADCOPTER SIMULATION] June Update: control modes
Es geht voran mit der DroneEngine. Ich habe drei unterschiedliche Steueralgorithmen implementiert, die zukünftig die Grundlage für das simulierte Sensor-Feedback bilden werden. Weitere Updates werden folgen.
Song: Ellie Goulding - Lights [LuQuS Remix]")
![PhysX3D [GRAVITY SIMULATION] Planetary Movement through Space](https://i.ytimg.com/vi/llhXEzWEWxI/mqdefault.jpg "PhysX3D [GRAVITY SIMULATION] Planetary Movement through Space
This is how the planets and moons move relative to the solar system barycenter. In a similar way the whole solar system moves around the center of the milky way.
More information at: http://www.projectphysx.de
Music: Chris Zabriskie - Cylinder Three")
![FluidX3D [FLUID SIMULATION] 65536 Particles in Real Time](https://i.ytimg.com/vi/nMyFEnO3j_w/mqdefault.jpg "FluidX3D [FLUID SIMULATION] 65536 Particles in Real Time
FluidX3D is a GPU-accelerated real time 3D fluid simulation based on the lattice Boltzmann method.
Ive added some upgrades, namely the one-step-pull algorithm (OS-Pull) for a combined streaming-and-collide step which cuts VRAM access in half.
Particles are also calculated on the GPU. They dont impact performance much (less than 1%), since 65536 is a small number compared to 256x128x128 LBM nodes. Furthermore, if only the particle positions have to be sent over PCI-e to the CPU for graphics instead of the entire velocity field, it doubles the calculation steps per second, because then the GPU does not have to wait idle until the slow data transfer is done.
For more information about FluidX3D and my other projects, visit
http://www.projectphysx.de
Music: CMA - Youre Not Alone")
