-
Notifications
You must be signed in to change notification settings - Fork 146
Forward-merge release/25.12 into main #1582
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
base: main
Are you sure you want to change the base?
Conversation
Looks like a find-and-replace error during one of the libcuvs_c changes. Authors: - Vyas Ramasubramani (https://github.com/vyasr) - Robert Maynard (https://github.com/robertmaynard) Approvers: - Robert Maynard (https://github.com/robertmaynard) - Corey J. Nolet (https://github.com/cjnolet) URL: #1563
|
FAILURE - Unable to forward-merge due to an error, manual merge is necessary. Do not use the IMPORTANT: When merging this PR, do not use the auto-merger (i.e. the |
## Description RAPIDS has deployed an autoscaling cloud build cluster that can be used to accelerate building large RAPIDS projects. This PR updates the conda and wheel builds to use the build cluster. This contributes to rapidsai/build-planning#228. --------- Co-authored-by: Nate Rock <rockhowse@gmail.com>
While profiling cuvs-java, we found that allocating a `PinnedMemoryBuffer` for each host->device or device->host memory copy was unnecessary and wasteful. This PR moves the allocation of a `PinnedMemoryBuffer` to `CuVSResourcesImpl`, so that the buffer can be cached and reused. Since `CuVSResources` are already meant to be per-thread, this is safe, as the `PinnedMemoryBuffer` will never be used concurrently. In order to do it cleanly, we introduced two named `ScopedAccess` classes and a helper method that will always find its way to the internal `MemorySegment` used by native functions to access the buffer, without the need to expose it via the public interface. Authors: - Lorenzo Dematté (https://github.com/ldematte) - Ben Frederickson (https://github.com/benfred) - MithunR (https://github.com/mythrocks) Approvers: - MithunR (https://github.com/mythrocks) URL: #1441
As discussed during a sync, we want to relax version matching/checking between cuvs-java and the cuVS C library. The rationale is that the C API should be pretty stable, and the cuvs-java bindings to the C API should not be affected by the cuVS version, provided that the API does not change. For these reasons, we do still want to check that - the C library version is at least as recent as the Java module - the C library is not "too far" in the future; we do not want unlimited forward compatibility, we want to be able to change the C API at some point (after e.g. a deprecation cycle). This PR introduces these checks, allowing cuvs-java to start and bind with C libraries up to 3 more cuVS releases in the future. Authors: - Lorenzo Dematté (https://github.com/ldematte) - MithunR (https://github.com/mythrocks) Approvers: - Chris Hegarty (https://github.com/ChrisHegarty) - MithunR (https://github.com/mythrocks) URL: #1544
… conda packages (#1494) The PR adds a new target `cuvs-cpp-headers` that is part of the main `cuvs-exports` set. It also separates out `cuvs_static` as its own optional component. Two new conda packages are added to reflect the aforementioned changes, namely `libcuvs-headers` and `libcuvs-static`. Authors: - Divye Gala (https://github.com/divyegala) - Robert Maynard (https://github.com/robertmaynard) Approvers: - Bradley Dice (https://github.com/bdice) - Robert Maynard (https://github.com/robertmaynard) - Gil Forsyth (https://github.com/gforsyth) URL: #1494
Exposes `cuvsRMMPoolMemoryResourceEnable`/`cuvsRMMMemoryResourceReset` via the Java API, with tests and benchmarks Authors: - Lorenzo Dematté (https://github.com/ldematte) - MithunR (https://github.com/mythrocks) Approvers: - MithunR (https://github.com/mythrocks) URL: #1453
Forward-merge triggered by push to release/25.12 that creates a PR to keep main up-to-date. If this PR is unable to be immediately merged due to conflicts, it will remain open for the team to manually merge. See forward-merger docs for more info.