On 9/16/22 06:38, Andrius Merkys wrote:
I have never worked with packaging CUDA software. Since it cannot be built on buildd, I suppose all uploads will have to source+binary. It is interesting how this works with sponsoring, in particular who (you or sponsor) will have to build the binaries for upload.
Pbuilder has no problem (with non-free enabled, with no GPU) building the binary packages for amd64, and that's the only architecture I know of where the non-CUDA-enabled version works, much less the CUDA-enabled one. I *can* certainly build the binaries, but I don't know whether that's appropriate, as the sponsor would not be able to ensure that they were safe. So I'd assume the sponsor would need to build.
I know there is some active effort on arm64 support now upstream (https://github.com/lorenzo-rovigatti/oxDNA/issues/31), but that is for the CPU-only version, and still isn't fully working, so this would presumably only be amd64 for now.
By the way, what would be the binary compatibility of the CUDA package? I.e., what is the range of CUDA versions that could use the binary package without rebuilding it from source?
That's a good question; CUDA compatibility seems to be rather complex, and I'm not that familiar with it.
From an architecture side, the upstream build system has an option, CUDA_COMMON_ARCH, to compile for nvcc-version-supported common architectures, and my package turns this on. This should result in support for 5.0, 5.2, 6.0, 6.1, 7.0, and 7.5 in the same binary package. I expect 7.5 being the latest architecture is outdated upstream code in select_compute_arch.cmake, and is not intentional, so that could be changed. I'm also not sure about what this would mean for running on a newer (>=8) or other (eg, 7.2) architecture (not at all without rebuilding? or just slower?). I don't have shiny new GPUs to test it with, but I suppose I could try installing the binary packages on an AWS instance with a new GPU and seeing what happens.
Best, Constantine