Feature #3311: GPU infrastructure development
Data type for coordinates, xyzq data, LJ parameters data to use for GPU buffers
To use opaque DeviceBuffer type in CPU parts of the code, one needs a proper data-type for, e.g. coordinates. Current solutions include passing a void* and using DeviceBuffer<float>, both of which are faulty. Proposed solutions are:
Solution 1. Declare native GPU types for the CPU code-path.
Both CUDA and OpenCL have native vector types, which can be declared for CPU code path.
- Native types - no need for casting.
- Polluted data-type space.
- Introducing new data type will require defining it across the platforms.
- Potentially, more difficult integration of OpenCL and CUDA code-paths.
- OpenCL float3 format has float4 layout.
Solution 2. Define new or use existing CPU types.Pros:
- No need to define new data types for most used objects, e.g. can use RVec for coordinates.
- Casting can be done in the GPU kernel: the rest of the code can potentially be platform-agnostic.
- Data will have to be casted to native types, probably inside computational kernel. Safety checks for the casts will be required.
- Some new data types will be needed (e.g. for C6-C12 LJ parameters).
Use RVec instead of float for x, v and f device buffers
Using RVec instead of float for coordinates data-types allows to
remove multiplications by DIM when the adresses, offsets and sizes
are computed. Since the native device types are not used in CPU
part of the code, the type casting remains.
#4 Updated by Mark Abraham 2 months ago
Solution 1 also makes any code that uses the compatibility types (even just by name) dependent on the value of
GMX_GPU. Currently that would make for a nasty dependency on config.h. That nastiness can be tackled, but solution 2 naturally solves it by having types that make sense in the domain of use (e.g. also xyzq for nbnxm module, fdv0 for tables)