libclsph / libclsph

OpenCL based GPU accelerated SPH fluid simulation library

libclsph

An OpenCL based GPU accelerated SPH fluid simulation library

Can I see it in action?

Demo #1
Demo #2

Why?

Libclsph was created to explore the possibilty of using the power of OpenCL to speed up the simulation of SPH fluid mechanics.

Smoothed particle hydrodynamics is a fluid simulation technique that can be used to produce realistic simulations for animation,CGI or videogames.

How ?

Libclsph uses C++11 and OpenCL to run simulations. Results are exported using industry standards and can then be used in programs like houdini. Simulation properties can be easily modified by the user.

Getting started

Be sure to visit the wiki for more information and detailed instructions on how to get started.

Libraries used

• picojson is used to load simulation properties from files.
• cereal is used for all serialization needs.
• partio is used to import/export particle data.
• tinyobjloader is used to load geometry in obj format.

libclsph's Issues

Reduce branching in all Kernels

Introduce an adaptable grid

The grid fitted to the particles must be adaptable, otherwise we would need to allocate an impossibly large amount of memory when dealing with a high amount of low mass particles.

Partition work groups in a more efficient way.

Local memory is declared as a kernel argument like so :
kernel void myKernel(const int length, const int height, local float* LP,local float* LT,...)

Then async_work_group_copy is used to copy the particles frome global memory to local memory.

__kernel void test( __local float* local_data,__global float *global_data,int group_size) {

.
.
.

  event_t e = async_work_group_copy(LF, global_data+group_id*group_size, group_size, 0);
  wait_group_events(1, &e);

  //Now calls are made using local memory only
}

Use less threads

Maybe use one thread per grid cell instead of one thread per particle.

Improve build system

Ideally, the build system would include the following:

1. configure script
2. separate Makefile for example
3. conditional compilation of certain features (goes along point 1.)

Use symlinks instead of copying directories in /bin.

Use an adaptive time step

The largest time-step possible should be used to increase the speed of the simulation.

This means the time step should have a reasonably high starting value, for example 0.1.

Then during each frame we check if the CFL was broken.

If it was then we need to simulate the frame again with a smaller time step.

Make better use of local memory

Use of atomics in grid.h stops us from using CodeXL for debugging.

Offending line is line 94.

See http://devgurus.amd.com/thread/167769 for details.

Accelerate collision detection

The code should not go over every face on the geometry.

It should use bounding boxes to find the closest face first so as not waste too much time.

Integrate Partio

Write files in bgeo format to save time.

Example program that uses partio : https://gist.github.com/OlivierLi/9043673

How to compile a program and link with partio :

g++ test.cpp libpartio.a -lz

Separate kernels in different files.

This enables easier debugging in codeXL. Files names must end in .cl.

Thread file IO operations

The result of the simulation should be written to file while the GPU simulates the next frame.

This could improve run times.

Since we only need to support c++11, std::thread can be used.

Create a validation script

Write a script to verify bit parity between two commits.

Add OpenGL Output

Hi, I am playing with your lib on OSX, and I am curious if it will be possible to add a basic 3D rendering.

I am translating the library into Javascript using WebCL, and a 3D output in WebGL will be really nice.

What do you think ? Seems possible to add it ?

Investigate structure packing to save a few bytes

Use pahole.

Stress test

A stress test should be performed to determine what is the absolute maximum of particles that can be used in a simulation.

Simulation Parameters structure might be becoming too large

Encountered a bug where merely adding a member to the simulation parameters struct broke only parts of the simulation (collisions in this case). I suspect the struct might be becoming too large to be passed at that point in the sim and therefore suggest moving all parameters that aren't needed on the GPU directly to the sph_simulation class.

More diagnostics would be required to try and pinpoint the exact cause of this issue.

More input validation

The user should be notified it he starts a simulation using suboptimal parameters.

Optimal settings are detailed here : https://github.com/libclsph/libclsph/wiki/Getting-the-best-performance.

File numbering

When the program starts from the serialized last_frame of a previous simulation it shouldn't overwrite the existing frames.

It should should continue the file series.