-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SDP option to use blas-sys and lapack-sys #61
Comments
I am happy to try to support this but I am not clear exactly how it should work. My understanding of the I think specifying something like
would only really be promising that the C-style interface is there - it doesn't promise anything about linkage and doesn't go looking for any system-supplied library to load. The other statuc options, e.g. "sdp-accelerate", just enable one of the BLAS sources for linking. This is done by enabling additional compile-time options. A possible model might be to handle access to some system installation in the way we do it in Python. In that case we do not link to BLAS at all, but rather query back to Python and request function pointers for whichever BLAS functions Python is already using. See here. I don't have a strong feeling about the best way of doing this for Drake. My suspicion is that if it were easy to dynamically link to some "system BLAS" as a standard features in the rust blas crate then this would already exist. It may be very difficult to write a really general dynamically linked option that will always work. I would therefore suggest that if Drake already knows about some system BLAS and can provide pointers to individual functions, then we write something like the Python loader mechanism for you. That might also avoid issues with loading two different blas libraries at the same time. |
Thanks for the feedback! Let me explore a bit more on my end to see what might suit us best. |
I found https://github.com/rust-ndarray/ndarray#how-to-enable-blas-integration which seems to indicate that openblas-src can be configured to use the system dynamic library. I see if I can wrangle it (or something like it) to get it working. |
Okay, I found a pretty good solution. The Drake PR is RobotLocomotion/drake#20475. At the lowest layer, Rust is/was already calling into the normal BLAS (and LAPACK) ABI (e.g., The only change I needed to make to [clarabel] Opt-out of Rust linking for BLAS/LAPACK
The blas_src and lapack_src crates are the Rust ecosystem's solution
for inversion of control when linking the BLAS and LAPACK libraries.
Library code refers to those crates and then the top-level Cargo file
of the ultimate application binary turns on a feature flag of those
crates that adds the right lines to the linker (and can also rebuild
BLAS and LAPACK from source, if necessary).
However, since Drake's ultimate "application" is to ship our own
shared library, we must not allow Rust to govern which libraries to
link. Thus, we need to delete the lines that perform the linking.
--- src/algebra/dense/blas.rs
+++ src/algebra/dense/blas.rs
@@ -8,8 +8,6 @@ cfg_if::cfg_if! {
}
else {
- // standard imports via blas-lapack-rs crates
- extern crate blas_src;
- extern crate lapack_src;
+ // Use whatever shared libraries Drake provided.
use lapack::*;
use blas::*;
} That patch is pretty small so I don't mind at all to carry it locally within Drake indefinitely. If you wanted to, though, I could imagine an upstream feature flag in From my perspective though, BTW There was also one tiny cleanup to |
I should also mention for the record that turning on Clarabel's |
Here's a feature request ...
Is your feature request related to a problem? Please describe.
In RobotLocomotion/drake#19449, I'm working to add Clarabel integration into Drake. Most users of Drake use our pre-compiled binary releases instead of building from source.
As such, it is not practical for us to force a choice of BLAS/LAPACK at compile time. Instead, we dynamically link to the
libblas.so
andliblapack.so
(libblas.dylib
andliblapack.dylib
) from the user's operating system, so that their choice of the best BLAS for their own computer applications is respected. It allows us to ship one binary release of Drake that can perform well on many different computers.At the moment, it does not appear that
Clarabel.rs
orClarabel.cpp
offer a feature to use the system BLAS, which prevents us from extending our BLAS convention to Clarabel as well.Describe the solution you'd like
See https://github.com/blas-lapack-rs/blas-lapack-rs.github.io/wiki for background.
The
Cargo.toml
as of 0.6.0 currently offers these features:I'd like to request a feature option to use the system blas, something like:
I believe it also might require changes to
src/algebra/dense/blas.rs
etc to spell things a little differently.Describe alternatives you've considered
I've been trying to prepare my own patches to accomplish this, but doing it with downstream patching it fairly awkward, and my unfamiliarity with Rust is slowing me down a bit. Since I would plan to upstream the patches anyway, I thought I'd ask here to see if we could find a way to ship 0.7.0 with
blas-sys
out of the box. Y'all might be able to do this more quickly than myself.The text was updated successfully, but these errors were encountered: