When https://gerrit.gromacs.org/7837 is getting merged, Gromacs OpenCL builds start always linking to the bundled clFFT.
We should be able and prefer to link to the system clFFT by default though.
That might also later raise questions like what is the minimum version of clFFT required.
- detect external clFFT (CMake script available here: https://github.com/clMathLibraries/clFFT/blob/master/src/FindclFFT.cmake, as well as in Gromacs master: src/external/clFFT/src/FindclFFT.cmake)
- implement minimum version req'd
- implement clFFT version reporting in the
Added the bundled clFFT into OpenCL builds
Used an object library, since we have no need of a real library, to
have or to install, whether shared or static. Checked for the
availability of dynamic loading, and made it available portably to
Clfft initialization class is added and used in mdrunner to
initialize/tear down clFFT library resources in a thread-safe
manner, and only on ranks that require such setup. Noted TODOs
for future work.
Noted a useful style for explicit listing of source files.
Prefer linking to system clFFT rather than bundled one
Wrote a new find_package module that works in more modern
ways. Updated install guide.
Currently there is no support for checking the clFFT version, which is
unlikely to matter until they make the 2.14 release.
Test both internal and external clFFT build in Jenkins
Chose to test external linking of clFFT in pre-submit because that
compiles several minutes faster. Chose to test internal linking in
post-submit because rapid throughput is less important there.
The clfft label is used to understand that external linking of clFFT
is required for this configuration, much like the fftw, fftpack and
mkl labels, however there is no need to explicitly tie the clfft label
to the gpu or opencl ones.
Improve portability of PME on GPU code
Improve nvcc error reporting
When nvcc fails, tell the user about both standard error and standard
output. The former code was broken if _cuda_test_err would be
undefined, and reported by a user (see the link at Redmine #2500).
Disabled internal clFFT when using MSVC with OpenCL
We require clFFT for OpenCL support, and MSVC 2017. But clFFT only
supports MSVC 2010, and a user has reported that that clFFT does not
compile. As we have not provided for clFFT support to be disabled at
configure time (nor taught mdrun that it might not be able to run PME
on an OpenCL GPU in this case), it is simplest to withdraw support for
this corner case until clFFT support for modern MSVC is available.
#6 Updated by Szilárd Páll over 2 years ago
- Target version changed from future to 2019
- Difficulty simple added
- Difficulty deleted (
Given that no opt-out bundling may be a showstopper for distros, I'll target this for 2019.
We should also evaluate what are the needs on the Intel side when the PME port lands and gets tested.
#11 Updated by Aleksei Iupinov over 2 years ago
Once linking to system clFFT as a default is implemented, provide system clFFT in presubmit and none in post-submit? No explicit changes in releng required then, even (explicitness might be better, of course). It's the libclfft-dev package with dependencies in Ubuntu 16.04, likely non-default one.
#12 Updated by Aleksei Iupinov over 2 years ago
clFFT not packaged for Ubuntu 14, only 16+...
#18 Updated by Mark Abraham over 2 years ago
This call must succeed: https://github.com/clMathLibraries/clFFT/blob/master/src/library/lifetime.cpp#L51 and its implementation requires that dlopen() can be called.
#22 Updated by Szilárd Páll about 2 years ago
- Status changed from Blocked, need info to Resolved
Szilárd Páll wrote:
implement clFFT version reporting in the -version header
AFAICT, the above is not implemented yet. Could move it to a separate task as we likely want a more unified GPU FFT version reporting.
Created a more general issue related to FFT library version reporting. AFAICT we can close this.
#24 Updated by Mark Abraham almost 2 years ago
- Subject changed from detect and allow linking external clFFT to detect and allow linking external clFFT, or no clFFT
- Status changed from Closed to Accepted
- Assignee set to Mark Abraham
- Target version changed from 2019 to 2019.1
If our internal clfft doesn't build on a platform, and there's none found on the system, then that blocks the OpenCL build. Users should be able to get OpenCL support for NB even if there is no way to build clfft.
This does stop a Windows build supporting OpenCL, but the principle is more important than the fact of such a Windows version not working.
#25 Updated by Mark Abraham almost 2 years ago
Report from Mirco Wahab at https://mailman-1.sys.kth.se/pipermail/gromacs.org_gmx-users/2019-January/123689.html