[SYCL] Use Eigen classes within SYCL kernels

[nR3D]

So far SYCL vector types (sycl::vec) have been used as a replacement for Eigen matrices and arrays, since the latter are directly supported for SYCL kernel execution. This led to the introduction of a parallel set of data types (e.g. DeviceVecd instead of Vecd) that could be used within SYCL kernels. However, Eigen provides many algebraic methods that SYCL vectors lack, additionally the support for two different vector types would mean a less maintainable codebase. Ideally, using Eigen for both CPU and GPU execution is the option to pursue (as long as the performance gap w.r.t. SYCL vectors is not excessive). The following changes enable an initial support for Eigen data types within SYCL kernels, however many aspect are still to be considered, so I will keep this pull request as a draft for the moment being:

• [X] test_2d_dambreak is working as expected (with ca. 4% slowdown compared to SYCL vectors)
• [x] test_3d_dambreak is compiling correctly and it executes for the first second of simulation time, however it then segfaults by accessing a wrong GPU address. The simulation results are correct up until that point, and the same simulation runs fine with SYCL vectors.
  • Solved by increasing the allocation size of NeighborhoodDevice
• [X] When trying to compile using the cmake option "Debug" the compiler fails to generate PTX files (in the case of nvidia ahead-of-time compilation), which makes it more difficult to debug the 3d case, however "Release" compilation works fine. This could be the result of some code that Eigen uses internally which is considered undefined behavior to compile for device execution, and/or it's not supported by the compiler.
  • Solved by defining SYCL_DEVICE_ONLY or by switching to the git version of Eigen and using EIGEN_USE_SYCL
• [X] Eigen uses internally generic pointers for some functions (like min/max) which are not supported by SYCL (https://support.codeplay.com/t/eigen-support-only-tensor-module-or-arrays-and-matrices-as-well/561/5) so those methods have to be replaced by another implementation. However, re-implementing Eigen methods is against the objective of this PR. Ultimately, a work-around to make all Eigen methods work is needed.
  • Solved by defining SYCL_DEVICE_ONLY or by switching to the git version of Eigen and using EIGEN_USE_SYCL

https://gitlab.com/libeigen/eigen/-/issues/2763 This is a recently-opened discussion with additional resources and insights on SYCL support by Eigen.

[Xiangyu-Hu]

@nR3D we can check the macro in eigen for using https://gitlab.com/libeigen/eigen/-/blob/master/Eigen/Core#L111

[Xiangyu-Hu]

@nR3D another place for sycl is https://eigen.tuxfamily.org/dox-devel/Macros_8h_source.html and https://gitlab.com/libeigen/eigen/-/blob/master/Eigen/src/Core/util/Macros.h#L851

[nR3D]

I have solved the issue in the 3d case, it turned out to be a problem with the allocation size of the neighborhood list, which was too small. As discussed in previous PRs, the solution would be to define a method that determines the maximum number of particles contained withing the kernel's smoothing radius, or by removing the usage of a neighborhood list all together.

At this point all the issues with Eigen seem to have been solved, so I will remove the draft status from the PR.

[Xiangyu-Hu]

@nR3D Great to hear it.