Drop CUDA 10.x & c++14 & CMake < 3.18 support

[ptheywood]

As CUDA 11.x has been available for for 15 months now, it is avialable in most places we need it to be (although there are still a few HPC systems which we use where it is not quite available).

Although I have generally wanted to keep CUDA 10.x support in the past for compatability, I'm becoming more and more keen on dropping 10.x support for several reasons.

• C++ 17 only
  • For use of actual <filesystem>
  • constexpr enhancements, including if constexpr
    • should allow us to replace some macros with namespaced constexpr's without any runtime cost.
  • simplifed nested namespaces, i.e. namespace flamegpu::util { doesn't require two expressions.
  • <any>, removing the need for flamegpu::util::Any
  • static_assert changes that might remove the need for flamegpu::util::detail::StaticAssert
  • Probably others, see https://en.cppreference.com/w/cpp/17
  • Remove some complicated CMake logic choosing which c++ version to specify (which is duplicated across 2 repos)
• We can drop a bunch of CUDA 10.x workarounds / warnings in our CMake
• Reduces the build matrix required by CI (or atleast shifts it).

If we can, the time to do this is before we have a full non-prerelease release.

Outstanding HPC sites i'm aware of that we have access to and FLAME GPU 2.x is already / expected to be used on:

• [x] TUoS Bessemer
  • Driver for 11.0 deployed, but nvcc module was never made available.
  • ShARC recently updated to 11.3 + relevant cudnn. Will chase this for Bessemer too.
• [x] N8CIR Bede
  • Available in RHEL8 test partitiions. Should be deployed in general within a few months.
• [x] Prometheus (plgrid)
  • Unsure on what CUDA version is available, although likely 10+ for volta GPUs.

Once these systems no longer prevent us from dropping support entirely, we can:

• [x] Use C++17 all the time
• [x] Minimum supported CMake will become 3.18 (required for setting the cuda standard to 17)
  • [x] Drop workarounds for CMake < 3.18
  • [x] Use FindCUDAToolkit to replace custom NVTX and NVRTC find modules (+ probably some other things).
  • [x] dynamic link aginast cudart rather than static by default (set(CMAKE_CUDA_RUNTIME_LIBRARY shared) for CUDA language, else CUDA::cudart[_static] link target with findCUDAToolkit)
• ~Fully drop the findNVTX module, it is no longer required, and with CUDA >= 10.0 already we expect NVTX3 to be available if any NVTX is.~
  • Can't rely on CUDA::nvToolsExt, which finds NVTX1 not 3: https://gitlab.kitware.com/cmake/cmake/-/issues/21377
• [x] switch to the full <filesystem> rather than experimental.
• ~switch to std::Any (is this going to techincally be an api break?)~
  • Deferred as #857
• ~<charconv> and std::from_chars which is potentially more performant than atoi etc.~ std::from_chars doesn't have floating point support in all host compiler versions we would have to support at this time (GCC >= 11 required, clang doesn't support it, MSVC was the earliest).
• ~string_view can be used in constexpr, probably preferable to string literals in some cases (version info?)~
  • Not going to explicitly switch to this as of yet.
• ~make use of structured bindings, i.e. for const auto &[key, val] map iteration~
  • Can be adopted as and when useful post #850
• [x] Update vis logic to match?
  • https://github.com/FLAMEGPU/FLAMEGPU2-visualiser/pull/89
• [x] Consider CUDA 11.0 support in a final FLAME GPU 1 release to allow users to port more easily / compare directly? This is an unintended consequence of dropping the current CUDA version overlap.
  • This would be useful, but will not be implemented as a full release. an open PR on FLAMEGPU/FLAMEGPU adds support for linux, so this can be used if required for comparison. Non-cmake windows support makes this more effort than it is worth at this time.
• [x] Drop Workarounds for older MSVC versions whic do not support C++17? I.e. Less than 19.10 is VS2015 which should no longer be usable? I believe 2017 is unlikely to be usable either

For now, we can add deprecation warnings at cmake configure time, stating C++17/CUDA 11/CMake 3.18 will be required.

• [x] Add deprecation warnings (#619)

[Robadob]

Prometheus (plgrid)

11.0 appears available, when i do module avail

[ptheywood]

We will drop CUDA 10.x support when possible, but initial pre-releases will stil support it (but deprecated). CMake warning?

[ptheywood]

One downside to this change will be that there is no supported CUDA version for FLAME GPU 1.x and FLAME GPU 2.x.

It's possible to install multiple version side by side, but it might annoy some users / hinder people trying to port between them, especially on windows.

If we want to address this at all, a final FLAME GPU 1.5.x/1.6 release which adds CUDA 11.x support and directs users to FLAME GPU 2.x for future versions might not be a terrible idea? Fixing FLAME GPU 1 for CUDA 11.x on linux is easy. Windows probably just needs a different set of vcxproj files depending on which CUDA version you wish to use (for separate include directories). I.e don't provide our own version of cub/thrust with CUDA 11 as a new enough version ships with CUDA 11.