LLNL / zfp

Compressed numerical arrays that support high-speed random access
http://zfp.llnl.gov
BSD 3-Clause "New" or "Revised" License
768 stars 155 forks source link

update cuda cmake code #232

Open robertu94 opened 3 months ago

robertu94 commented 3 months ago

Hi @lindstro, some students I am working with encountered problems building the CUDA version of ZFP using a new version of CMake (v3.27 and newer). This is because the FindCUDA cmake package was disabled in favor of FindCUDAToolkit and CUDA language support in this version and will be removed in a future version after being deprecated in 3.10. The replacement features were introduced in cmake 3.17, but I find they are stable after 3.20 (the new cmake minimum required version that I introduced here).

As I have documented here: https://robertu94.github.io/guides/dependencies.html#tooling-versions, cmake 3.20 is available on all major Linux distros for their normal support cycles except Ubuntu 20.04, and CMake 3.20 is available on this platforms via pip install cmake or other package management systems including spack. Supporting cmake 3.17 also includes CentOS-7 until it is deprecated in July, but will not support Ubuntu 20.04 which only provides cmake 3.16.

Regardless if you adopt this patch or not the spack package for ZFP needs to be updated as it does not build the cuda variant after cmake 3.27 to something of the effect of depends("cmake@:3.26", when="@:1.0.0+cuda")

cc: @jtian0

lindstro commented 3 months ago

@robertu94 I appreciate the contribution and would like to merge your PR, though we first need to find a workaround for the AppVeyor tests, which use CMAKE 3.16. I've been wanting to transition off AppVeyor and move to GitHub Actions. I can't remember what the issues were when we last looked into this, and I'm afraid I don't have time to tackle that at the moment.

Another minor challenge is that we've been doing a lot of CUDA (and HIP) work on the staging branch (which has not been pushed to in a while). This branch consolidates work from multiple branches, including new variable-rate (de)compression work and HIP support. Once complete, we will merge all this new work into develop.

I would prefer to incorporate these changes there first and work out any potential kinks before merging into develop. Currently our only GPU tests are being run at LLNL through GitLab CI, and so we'll also need to see if there are any issues there before I'm ready to merge into develop.

If you don't mind, can you please retarget your PR to the staging branch? I expect it will be another couple of months or so before we will complete work on staging and will be ready to merge into develop.