When enabling CUDA (or HIP) as a language, CMake will either use a user provided value (via CMAKE_CUDA_ARCHITECTURES or env{CUDAARCHS}) or set CMAKE_CUDA_ARCHITECTURES to a defualt for the verison of CUDA used (50 for 12.x, 75 for 13.x).
At this point, we cannot tell if this value was set by the user or by CMake.
We currently provide a library-default of all-major, if this was not set by the user, via flamegpu_init_cuda_architectures which must be before CUDA is enabled, and then flamegpu_set_cuda_architectures is called either by the library target, or injected into the project command.
Although this is currently functional, adding in HIP support in #1379 significantly complicates this process, and if we were to add #260 and support find_package(flamegpu) would have some chicken-and-egg type issues related to languages and architecture flags.
If we remove our library-provided default and instead accept the CMake provided default, but strongly encourage users to build the correct architecture for their system we can:
- Not require users call
flamegpu_init_cuda_architectures in their code (but maintain it as a deprecated noop for atleast a release)
- Delete a lot of complex CMake, which is hard to achieve consistent behaviour with for CUDA and AMD
- Just use
all-major explicitily when required (and/or toolchain files)
- Avoid issues related to this when we add
find_package(flamegpu) support.
- Potentially move some of
flamegpu_set_cuda_architectures into a warning-generating function in case invalid values are set (although these errros may be caught by CUDA language support not being found in the first place)?
Approved by @mondus during FLAMEGPU team meeting
Todo:
When enabling CUDA (or HIP) as a language, CMake will either use a user provided value (via
CMAKE_CUDA_ARCHITECTURESorenv{CUDAARCHS}) or setCMAKE_CUDA_ARCHITECTURESto a defualt for the verison of CUDA used (50for 12.x,75for 13.x).At this point, we cannot tell if this value was set by the user or by CMake.
We currently provide a library-default of
all-major, if this was not set by the user, viaflamegpu_init_cuda_architectureswhich must be before CUDA is enabled, and thenflamegpu_set_cuda_architecturesis called either by the library target, or injected into theprojectcommand.Although this is currently functional, adding in HIP support in #1379 significantly complicates this process, and if we were to add #260 and support
find_package(flamegpu)would have some chicken-and-egg type issues related to languages and architecture flags.If we remove our library-provided default and instead accept the CMake provided default, but strongly encourage users to build the correct architecture for their system we can:
flamegpu_init_cuda_architecturesin their code (but maintain it as a deprecated noop for atleast a release)all-majorexplicitily when required (and/or toolchain files)find_package(flamegpu)support.flamegpu_set_cuda_architecturesinto a warning-generating function in case invalid values are set (although these errros may be caught by CUDA language support not being found in the first place)?Approved by @mondus during FLAMEGPU team meeting
Todo:
flamegpu_init_cuda_architecturesandflamegpu_set_cuda_architectureswithAUTHOR_WARNINGsstating that these methods are deprecated, no longer do anything and calls to them should be removedflamegpu_init_cuda_architecturesin examplesflamegpu_set_cuda_architecturesinto a warning-generating function in case invalid values are set, although these errors will probably be caught by atry-compilefailureCMAKE_CUDA_ARCHITECTURESis always used (this should be the case already)CMAKE_CUDA_ARCHITECTURES/CUDAARCHS/CMAKE_HIP_ARCHITECTURES