Data type for coordinates, xyzq data, LJ parameters data to use for GPU buffers - Redmine #3312
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, 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.
Pros:
- Native types - no need for casting.
Cons:
- 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.
- SYCL?
Problems:
- 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.
Cons:
- 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).
Examples:
(from redmine: issue id 3312, created on 2020-01-22 by artemzhmurov)
- Relations:
- relates #2936 (closed)
- child #3372 (closed)
- parent #3311 (closed)
- Changesets:
- Revision c5c220a0 by Artem Zhmurov on 2020-02-06T07:49:39Z:
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.
Refs #3312 and #2936
Change-Id: Iaea914a474195f214ca860f7345f6878b9a04813