Skip to content

[OSQP] Update to 1.0 and include CUDA and MKL builders#11313

Open
imciner2 wants to merge 3 commits into
JuliaPackaging:masterfrom
osqp:osqp/develop-1.0
Open

[OSQP] Update to 1.0 and include CUDA and MKL builders#11313
imciner2 wants to merge 3 commits into
JuliaPackaging:masterfrom
osqp:osqp/develop-1.0

Conversation

@imciner2

Copy link
Copy Markdown
Member

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).

@fingolfin

Copy link
Copy Markdown
Member
ERROR: LoadError: Unsatisfiable requirements detected for package CUDA_SDK_static_jll [8d8e3561]:
--
  | CUDA_SDK_static_jll [8d8e3561] log:
  | ├─possible versions are: 10.2.89-12.8.1 or uninstalled
  | └─restricted to versions 12.9.0 by an explicit requirement — no versions left

@imciner2

Copy link
Copy Markdown
Member Author

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.

@Technici4n

Copy link
Copy Markdown
Contributor

Hey, I managed to make cmake work with the dynamic CUDA sdk, if you want to have a look: b15a803.

@imciner2

Copy link
Copy Markdown
Member Author

Any comments @giordano? I could just merge this, but thought a second set of eyes would be good 😁.

@giordano

Copy link
Copy Markdown
Member

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.

@Technici4n

Copy link
Copy Markdown
Contributor

Just a curiosity: did the size of the static CUDA artifacts eventually get reduced to <2Gb?

@imciner2

Copy link
Copy Markdown
Member Author

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.

@imciner2

Copy link
Copy Markdown
Member Author

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.

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?

@maleadt

maleadt commented Dec 4, 2025

Copy link
Copy Markdown
Member

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:

# enhanced compatibility, semver-style
artifact.major == host.major &&
Base.thisminor(artifact) <= Base.thisminor(host)

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.

Include CUDA patch to include setting C++ standard and building with
CUDA 13+
Comment thread platforms/cuda.jl

Returns a list of the GPU architectures supported by the given CUDA version.
"""
function cuda_gpu_archs(cuda_ver)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@maleadt

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants