Age | Commit message (Collapse) | Author |
|
|
|
Streaming is only implicit depending on the selected propagation pattern.
|
|
|
|
Sadly OpenCL kernels don't accept pointer-to-pointer arguments which
complicates the control structure implementation.
A workaround is to cast them into `uintptr_t` which is guaranteed to be large
enough to fit any pointer on the device. Special care has to be taken to always
perform the pointer shifts on actual floating point pointers and not on
type-less pointers.
|
|
|
|
This way the expanded call to pow2 is resolved into a common subexpression.
|
|
Currently only for the SSS streaming pattern.
CudaCodePrinter in `utility/printer.py` is required to add a 'f' suffix
to all single precision floating point literals. If this is not done
(when targeting single precision) most calculations happen in double
precision which destroys performance. (In OpenCL this is not necessary
as we can simply set the `-cl-single-precision-constant` flag. Sadly
such a flag doesn't seem to exist for nvcc.)
|
|
|
|
An interesting extension of the AA pattern. The main advantage of this is
that updating pointers in a control structure is much more elegant than
duplicating all function implementations as is required by the normal AA
pattern. For more details see [1].
Only works for the SOA layout.
On a pure memory access level this pattern is equivalent to the AA pattern.
The difference is how the memory locations are calculated (by pointer swap
& shift or by different indexing functions for odd and even time steps).
[1]: "An auto-vectorization friendly parallel lattice Boltzmann streaming
scheme for direct addressing" by Mohrhard et al. (2019)
|
|
|
|
Doesn't change the outcome but is more in line how the rest of the
generated code looks like.
|
|
|
|
|
|
|
|
Works well but function naming is getting kind of clunky, e.g. "velocity_momenta_boundary_tick_cells"
This could be hidden to a degree by proving branching wrappers for
the odd and even time step implementations. However this would not
vectorize when targeting Intel via OpenCL.
|
|
|
|
|
|
Note that special care has to be taken to provide ghost cells around
active cells so the algorithm has somewhere to stream to and from.
This is also the case for the AB pattern but there they only have to
be equilibrilized once instead of after every other time step.
Even when such an equilibrilization is performed there is still a
potential bug as inbound populations at the outer boundary are never
streamed to (this is not a problem for AB using pull-only streaming).
A vectorizable solution may require direction-specific ghost cell
equilibrization.
|
|
|
|
This should allow for plugging in e.g. a AA pattern implementation
without without touching any file but `AA.$target.mako`.
OpenCL and C++ target templates now look basically the same and could
potentially be merged. However this would decrease flexibility should
more differences appear in the future. Maintaining separate template
files is an acceptable overhead to preserve flexibility.
|
|
|
|
|
|
|
|
This paves the way for dropping in other LBM collision models.
As a side benefit the default momenta calulcation is now fully inlined where possible.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SOA and AOS should not be target specific, neighbor offset calculation /
bijection between gid and cell coordinates should be customizable.
|
|
|
|
|
|
No guarantee for correctness - I mostly fiddled this together in order
to use common nixpkgs python package functions for including boltzgen
in other shell environments.
|
|
Requires different function naming as OpenCL 1.2 doesn't support overloads.
The OpenCL kernel code generated using this commit was successfully tested
on an actual GPU. Time to set up some automatic validation.
|
|
|
|
|
|
It is more flexible to place OpenCL thread ID dependent dispatching in a separate function.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Selection of the desired templates is possible via a new `functions` parameter.
|
|
Yields ~160 MLUPs on a Xeon E3-1241 for D2Q9 double precision lid driven cavity.
Obviously not anywhere near what is possible on GPUs but respectable for a CPU implementation.
Especially considering how simple it is.
|
|
|
|
|
|
|