Uploaded October 2022 | Updated September 2026, 2 weeks ago
FluidX3D source code: github.com/ProjectPhysX/FluidX3D
Timelapse: 1km/h wind blowing over a city for about an hour, simulated with FluidX3D on a 3 billion voxel grid. OpenCL compute (1448×2896×724 resolution grid, 34k time steps) plus rendering took ~104 minutes. Shown is the Q-criterion isosurfaces with marching-cubes. Reynolds number is 19 Million with Smagorinsky-Lilly subgrid model.
How is it possible to squeeze 3 billion grid points in only 160GB VRAM?
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 35GB!) ever has to be copied to the CPU or hard drive, but only rendered 4K frames (33MB) 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 bottom view
0:20 top view
0:40 side view
Thanks to the people at Jülich Supercomputing Centre for letting me test their hardware!
The 3D model of the city was provided by Thomas Tian: building-engineering.de
#CFD #GPU #FluidX3D #OpenCL
FluidX3D source code: github.com/ProjectPhysX/FluidX3D
Timelapse: 1km/h wind blowing over a city for about an hour, simulated with FluidX3D on a 3 billion voxel grid. OpenCL compute (1448×2896×724 resolution grid, 34k time steps) plus rendering took ~104 minutes. Shown is the Q-criterion isosurfaces with marching-cubes. Reynolds number is 19 Million with Smagorinsky-Lilly subgrid model.
How is it possible to squeeze 3 billion grid points in only 160GB VRAM?
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 35GB!) ever has to be copied to the CPU or hard drive, but only rendered 4K frames (33MB) 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 bottom view
0:20 top view
0:40 side view
Thanks to the people at Jülich Supercomputing Centre for letting me test their hardware!
The 3D model of the city was provided by Thomas Tian: building-engineering.de
#CFD #GPU #FluidX3D #OpenCL
![Line3D [GRAPHICS ENGINE] Dynamische Beleuchtung](https://i.ytimg.com/vi/_9i8RSxTkjA/mqdefault.jpg "Line3D [GRAPHICS ENGINE] Dynamische Beleuchtung
Ich hab noch ein bisschen an der Java-Grafikausgabe aus meinem Projekt PhysX3D weiter geschrieben. Aus einfachen Linien sind Polygone geworden, die dynamisch von einer (oder auch mehreren) frei beweglichen Lichtquellen beleuchtet werden. In diesem Beispiel berechnet die CPU auf einem Kern 25.600 Dreiecke pro Frame, und das etwa 30 Mal in der Sekunde.
Ich verwende dazu nur die elementarsten Java-Bibliotheken wie das JFrame, ein Fenster, in dem ich Linien, Text und Vielecke zeichnen kann.
Wie funktioniert die Berechnung?
Für jedes Dreieck wird der Normalenvektor berechnet. Das ist sozusagen eine Linie, die immer senkrecht auf der Fläche des Dreiecks steht. Dann wird der Normalenvektor skalar mit dem Vektor vom Mittelpunkt des Dreiecks zur Lichtquelle multipliziert. Einfach ausgedrückt vergleicht man dabei, ob der Normalenvektor zur Lichtquelle zeigt. Wenn er das tut, ist die Fläche heller, sonst dunkler. Mit dem Ergebnis der skalaren Multiplikation wird die Helligkeit des Dreiecks skaliert.
Die Lichtquelle muss nicht immer am selben Punkt sein, sie kann sich auch bewegen, wie hier im Video demonstriert.
Was ist der praktische Nutzen davon?
Das Prinzip der dynamischen Beleuchtung ist heutzutage in jedem Computerspiel und in jeder Rendering-Software zu finden, bloß werden dort die Dreiecke noch viel kleiner gemacht, damit zum Beispiel ein animiertes Gesicht nicht eckig aussieht.")
![FluidX3D [FLUID SIMULATION] - Real Time Free Surface LBM with Volume-of-Fluid](https://i.ytimg.com/vi/a1u2g9ahIDk/mqdefault.jpg "FluidX3D [FLUID SIMULATION] - Real Time Free Surface LBM with Volume-of-Fluid
FluidX3D is a real time 3D fluid simulation based on the lattice Boltzmann method. It is written in OpenCL C (GPU code) and optimized to the physical limit (video memory bandwith, ~520GB/s).
All demonstrations in the video are simulated and visualized in real time on a Nvidia Titan Xp. Graphics are done with the OpenCL C version of Line3D, the fastest graphics engine ever written for primitive shapes like lines, dots and circles. It can handle up to 2 billion lines per second.
The free surface is done with the volume-of-fluid (VoF) extension to LBM. It allows simulating free surfaces with a sharp interface layer. Having to avoid race conditions makes an efficient GPU implementation of VoF is quite challenging. Currently there is no surface tension yet; the curvature estimation algorithm is still under construction.
The volume force (gavity) is implemented with the Gou forcing scheme.
Hardware Setup:
CPU: Intel Core i7-8700K @ 4,5GHz all core
GPU: Nvidia Titan Xp
RAM: 2x8GB Corsair Vengeance LPX DDR4 3200MHz CL16
Mainboard: ASUS ROG STRIX Z370-I GAMING
SSD 1: Samsung 970 PRO 512GB
SSD 2: Samsung 860 EVO 1TB
CPU Cooler: Cooltek LP53
PSU: Corsair SF600
Housing: Fractal Design Node 202
Timestamps:
0:00 - Intro
0:02 - honey coiling
0:34 - large drop impact
0:45 - drop splashing in flowing water
0:55 - throwing drop sideways in resting water
1:00 - eternal periodic water tap
1:07 - dam break without obstacles
1:18 - asymmetric dam break with two connected chambers
1:29 - droplet impact
1:39 - eternal periodic fountain
1:50 - dam break with cuboid obstacle
2:06 - more honey coiling (just because it is so cool)
More information at http://www.projectphysx.de
Music: Notaker - Fatal System Error")
![FluidX3D [FLUID SIMULATION] - Smashing the Memory Wall with FP16 | 100 Subscriber Special](https://i.ytimg.com/vi/aWFi__zMUkk/mqdefault.jpg "FluidX3D [FLUID SIMULATION] - Smashing the Memory Wall with FP16 | 100 Subscriber Special
FluidX3D is a real time 3D fluid simulation based on the lattice Boltzmann method. It is written in OpenCL C (GPU code) and optimized to the physical limit (video memory bandwith, ~520GB/s).
All demonstrations in the video are simulated and visualized in real time on a Nvidia Titan Xp. Graphics are done with the OpenCL C version of Line3D, the fastest graphics engine ever written for primitive shapes like lines, dots and circles. It can handle up to 2 billion lines per second.
LBM performance is only limited by video memory bandwidth - the so-called memory wall. Storing the LBM distribution functions in memory as FP16 instead of FP32 cuts the memory bandwidth requirements in half, doubling the simulation speed at the cost of a bit of accuracy. My implementation has a hardware efficiency of up to 95%, meaning that 520 GB/s of the total 548 GB/s of video memory bandwidth are used. This results in a peak performance of 5.2 GLUPs (giga lattice updates per second, how many LBM lattice points are processed in 1 second) for the D3Q19 velocity set.
More information at http://www.projectphysx.de
Music: Notaker - Fatal System Error")
