[OSQP] Update to 1.0 and include CUDA and MKL builders#11313
Conversation
|
|
Yea, the CUDA 12.9 update apparently exceeded the GitHub artifact size limit for the static libraries, so they weren't built. A while ago CMake wouldn't detect CUDA properly without the static CUDA runtime library, so that is why I have it here. I need to revisit that to see if maybe they relaxed CMake to work without it, or if there is another way to work around it. |
|
Hey, I managed to make cmake work with the dynamic CUDA sdk, if you want to have a look: b15a803. |
f2d088d to
61454b6
Compare
|
Any comments @giordano? I could just merge this, but thought a second set of eyes would be good 😁. |
|
Looks overall good to me. About the CUDA builds, do we still need to build for CUDA 11 nowadays? Also, if you felt brave you could also try building for aarch64, but that'd likely complicate the recipe a bit, but it's up to you. |
|
Just a curiosity: did the size of the static CUDA artifacts eventually get reduced to <2Gb? |
Yes, we introduced a new compression strategy for the artifacts that made the compressed size <2GB again, so we have static SDKs for 12.9 now. |
Is it possible for us to see how many people might be still downloading CUDA 11 artifacts? If we see a general decline in it, then I guess we could do something globally in Ygg to push up the version. As it is, we only build 11.4-11.8 (not the older ones) I have never quite understood how we do platform versioning for CUDA. I was under the impression CUDA had "Minor version compatibility" (https://docs.nvidia.com/deploy/cuda-compatibility/minor-version-compatibility.html), so I thought we could just compile with one version and use it on others in the same major version, but we build for every minor here. @maleadt does this compatibility only apply to the driver/runtime and not the libraries like cuBLAS, cuSPARSE, etc? Basically could we have a single CUDA 11 build if we wanted? |
It should work like that: Lines 51 to 53 in ac4c358 However, it's sometimes advantageous to build against newer versions of CUDA, because the code is then allowed to e.g. use newer APIs. So it can make sense to build for every minor version, but it depends on the software. |
61454b6 to
fde06cc
Compare
Include CUDA patch to include setting C++ standard and building with CUDA 13+
c68a7d5 to
e689a34
Compare
|
|
||
| Returns a list of the GPU architectures supported by the given CUDA version. | ||
| """ | ||
| function cuda_gpu_archs(cuda_ver) |
There was a problem hiding this comment.
I added this function to help CMake get an architecture list to build for the various CUDA versions (just building with all gives errors sometimes, and I don't actually want everything). Do you see any issues with this listing, or are there any that I am missing?
(I know I don't have the Jetson ones in here).
Update to latest upstream OSQP release - OSQP 1.0. This release includes first-class support for MKL and CUDA libraries, so introduce those as separate JLLs to separate out the library dependencies. (OSQP supports this by making new shared libraries for every backend that all expose the same API layer).