[question] Tips for setting up Cuda packages

[LouChiSoft]

What is your question?

Hi @jcar87, hopefully you don't mind the ping too much, @memsharded mentioned that you have been doing some Cuda build with Conan and I was hoping to get your input on setting up Cuda packages. The main one is around things like setting architecture flags. With our project being a single pipeline built up from multiple composable libraries things like architecture needs to be consistent across all the packages. Is there a method to propagate architecture flags down from the top so that everything is always aligned? Additionally, how did you manage things like CUDA_RESOLVE_DEVICE_SYMBOLS flags. From my local testing, I found that to use static libraries correctly everything needs to have CUDA_SEPARABLE_COMPILATION enabled but only the final executable needs to have CUDA_RESOLVE_DEVICE_SYMBOLS enabled.

Also any additional pitfalls that you may have ran into would also be helpful. Cheers

Have you read the CONTRIBUTING guide?

• [X] I've read the CONTRIBUTING guide

[jcar87]

Hi @LouChiSoft - thanks for raising this question! very relevant :D

Are you talking about the cuda architecture flags like --gpu-code=sm_50,compute_50?

As for CUDA_RESOLVE_DEVICE_SYMBOLS:

From my local testing, I found that to use static libraries correctly everything needs to have CUDA_SEPARABLE_COMPILATION enabled but only the final executable needs to have CUDA_RESOLVE_DEVICE_SYMBOLS enabled.

What you describe already sounds like CMake's default behaviour? https://cmake.org/cmake/help/latest/prop_tgt/CUDA_RESOLVE_DEVICE_SYMBOLS.html That is, if the setting is unset, static libraries will not have "resolve device symbols" enabled, but only executables (and shared libraries) will - is there a scenario where this is not happening as described?

[LouChiSoft]

Are you talking about the cuda architecture flags like --gpu-code=sm_50,compute_50?

Yes, those flags are the ones I meant. Due to the nature of some of our code being protected IP we can't really have any PTX code in the final binary, so in CMake I have been only setting -real architectures manually for each library we compile. Both tedious and error prone. But since Conan is still very new to me I am unsure how you would propagate that flag down into the dependencies. The behaviour we are ideally looking for is that we can compile the top most project with a set of -real architectures and conan would handle pulling the dependencies, building them with the same -real architectures and saving that binary locally. Then in the future when Nvidia brings out new GPUs and new architectures we can simply append the new architecture to that list and Conan would rebuild accordingly.

is there a scenario where this is not happening as described?

This might just be my inexperience with Cuda, I've spent a rather long time trying to get static libraries working and only recently figured that part out. But again since I am unfamiliar with Conan I wasn't sure if because it was Cuda if I needed to do something special

[valgur]

Just to second the notion, I'm very interested in seeing a config- or (even better) profile-level setting for CUDA_ARCHITECTURES as well, if possible. I've been adding it as an option to my recipes (e.g. https://github.com/valgur/cupoch/blob/master/conanfile.py#L43), but it's difficult to ensure it's being applied consistently, especially for external packages, such as ones from CCI.

[LouChiSoft]

Also another topic related to Cuda and specifically CMake versions. We can mandate that CMake is the build tool, but the version of CMake that gets used is harder to enforce. As a result we have to support basically from CMake 3.13 onwards and depending on which version of CMake you use depends on how you can set certain flags, like CUDA_ARCHITECTURES for example