Skip to content

Releases: ProjectPhysX/FluidX3D

FluidX3D v2.0 (multi-GPU upgrade)

09 Jan 18:30
Compare
Choose a tag to compare

Big multi-GPU Update:

  • Multi-GPU simulations are now possible on a single node (PC/laptop/server), allowing to pool VRAM from multiple GPUs.
    • Easy setup with minimal changes to the user: instead of LBM lbm(Nx, Ny, Nz, nu, ...);, use LBM lbm(Nx, Ny, Nz, Dx, Dy, Dz, nu, ...);, with Dx/Dy/Dz indicating how many domains (GPUs) in each spatial direction to use. By default, all identical GPUs will be automatically assigned their domains, however the GPUs can also be manually set with a list of their indices: ./make.sh 2 6 3 4 or /bin/FluidX3D 2 6 3 4.
    • All extensions are supported and validated to produce binary identical results compared to single-GPU simulations.
    • Multi-GPU also works with non-identical GPUs, regardless of vendor. Yes, you can run FluidX3D on unholy combinations of Nvidia/AMD/Intel GPUs/CPUs at the same time. I only recommend similar memory capacity and bandwidth, as the weakest GPU will bottleneck performance.
    • No SLI/Crossfire/NVLink/InfinityFabric is required. All communication runs over PCIe and is compatible with all hardware.
    • No MPI installation is required.
    • Total grid resolution must be equally divisible into domains, such that all domains are the same size.
    • The resolution of each domain is restricted to 4.29 billion grid points (2³², 225GB VRAM), but domain number and thus total grid resolution is unrestricted.
    • Under the hood: Complete re-write of C++ backend, to account for the domain decomposition architecture. The code is already fully optimized and shortened for maximum maintainability/upgradeability.
  • Grid resolution can now be arbitrary and is not anymore restricted to the condition (Nx*Ny*Nz)%WORKGROUP_SIZE==0.

Known issues:

  • Raytracing graphics are disabled for multi-GPU. The simulated light rays would have to travel through the entire simulation box, crossing domain boundaries. This is not easily possible, because each GPU only keeps its own domain in VRAM.

FluidX3D v1.4 (Linux graphics)

02 Mar 07:18
Compare
Choose a tag to compare
  • Big update for Linux users: Added interactive graphics mode on Linux with X11. No external dependencies, compiles out-of-the-box with the "compile on Linux with X11" command in make.sh.
  • Re-wrote C++ graphics library to minimize API dependencies
  • Colors are now signed int consistently.
  • Fixed streamline visualization in 2D.

FluidX3D v1.3 (minor bug fixes)

10 Nov 16:20
Compare
Choose a tag to compare
  • added OpenCL driver bug workaround for old AMD GPUs (binary number literals for flag bitmasks don't work, so change to hexadecimal literals)
  • FORCE_FIELD and VOLUME_FORCE can now be used independently
  • added unit conversion functions for torque

FluidX3D v1.2 (force/torque compuatation)

24 Oct 15:54
Compare
Choose a tag to compare
  • added functions to compute force/torque on objects
  • added function to translate Mesh
  • added Stokes drag validation setup
  • added more benchmarks in Readme

FluidX3D v1.1 (GPU voxelization)

29 Sep 12:46
Compare
Choose a tag to compare
  • added new GPU voxelization
  • fixed broken triangle rendering with some Intel iGPUs (driver bug workaround in marching_cubes)
  • added tool to print current camera position (key G)
  • refactoring

FluidX3D v1.0 (public release)

19 Sep 16:37
Compare
Choose a tag to compare

Initial public release of FluidX3D.