Roaring Bitmap Filter in CAGRA by divyegala · Pull Request #2446 · NVIDIA/cuvs

divyegala · 2026-08-15T00:11:35Z

This PR uses cuco's Roaring Bitmap filter implementation to work with CAGRA search. Currently, it only supports single allowlist construction.

Benchmarks on GIST 1M, measuring single-batch search latency + filter construction time:

Allowed	Cardinality	Bitset total (ms)	CSR UDF total (ms)	Roaring total (ms)
0.1%	1,000	5.106	5.275	6.042
1%	10,000	1.209	1.553	1.545
10%	100,000	0.814	4.015	1.297
50%	500,000	1.199	17.801	2.146
90%	900,000	1.512	32.017	2.384
100%	1,000,000	1.530	35.768	2.552

Filter sizes:

Allowed	Cardinality	Bitset	CSR UDF	Roaring
0.1%	1,000	122.07 KiB	3.92 KiB	2.22 KiB
1%	10,000	122.07 KiB	39.08 KiB	19.80 KiB
10%	100,000	122.07 KiB	390.64 KiB	123.58 KiB
50%	500,000	122.07 KiB	1,953.14 KiB	128.27 KiB
90%	900,000	122.07 KiB	3,515.64 KiB	128.27 KiB
100%	1,000,000	122.07 KiB	3,906.27 KiB	128.27 KiB

copy-pr-bot · 2026-08-15T00:11:39Z

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

…filter

copy-pr-bot · 2026-09-02T19:49:35Z

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

divyegala · 2026-09-03T20:59:12Z

/ok to test 1529d8f

dantegd

Should we explicitly limit Roaring filters to direct cagra::search for now? I don’t think the query mapping works cleanly with dynamic batching because CAGRA may receive either max_batch_size or the actual batch size. Tiered search also passes the same filter to CAGRA and brute-force partitions with different row domains, and brute force doesn’t support Roaring. Since cagra::merge already rejects this filter type, would it make sense to reject or document these paths too, unless they’re intended to be supported? What do you think?

dantegd · 2026-09-10T16:21:22Z

+    tenant_views.push_back(allowlist.view());
+  }
+  cuvs::neighbors::filtering::roaring_filter roaring_filter(res, tenant_views);
+  auto roaring_result = search(roaring_filter, 2.0f / 3.0f);


Could we clarify the stream semantics here? Construction may return while serialization and the device-reference copy are still queued. Using the result on the same stream is safe, but another stream needs an explicit dependency, like the event handoff in the test. The current comment explains how long the input must remain valid, but not when the returned view is safe to use.

We commit to stream ordered synchronization guarantees on raft::resources. Is that not already true here? If the host returns execution, it is safe to use.

dantegd · 2026-09-10T16:34:04Z

+    auto& sample_filter =
+      dynamic_cast<const cuvs::neighbors::filtering::roaring_filter&>(sample_filter_ref);
+    RAFT_EXPECTS(sample_filter.valid(), "roaring_filter must be initialized before search.");
+    RAFT_EXPECTS(sample_filter.num_queries() == static_cast<std::size_t>(queries.extent(0)),


Do we expect Roaring filters to work through dynamic batching as well? Dynamic batching may call CAGRA with either max_batch_size or the actual batch size, so this equality can fail depending on the dispatch mode. If that path isn’t supported yet, should we document it or reject the filter earlier?

Let's reject it

dantegd · 2026-09-10T16:48:10Z

+{
+  auto minimum_cardinality = dataset_rows;
+  for (auto const& allowlist : allowlists) {
+    minimum_cardinality = std::min(minimum_cardinality, allowlist.cardinality());


Is using the minimum cardinality intentional here? One very small or empty allowlist makes the batch-wide filtering rate approach 0.999, which can substantially increase the MULTI_CTA work for every query in the batch. Would it be worth adding coverage for mixed-cardinality batches or documenting this tradeoff?

This is documented, I ran into this problem myself. The right way to do this for users it to set search_params::filtering_rate so that it is a CAGRA search specific hint, and users can tradeoff between latency and recall.

…ng-filter

cjnolet · 2026-09-16T14:31:14Z

+namespace core {
+
+/**
+ * @brief Non-owning device view of one immutable Roaring allowlist.


This is a core vocab type. Do we want to consider putting this in raft at some point?

I like the idea of putting it in RAFT as we are introducing several new filters as core vocabulary types that I consider are reusable.

cjnolet · 2026-09-16T14:33:28Z

+ * @see cuvs::core::roaring_allowlist
+ * @see https://github.com/RoaringBitmap/RoaringFormatSpec
+ */
+struct roaring_filter : public base_filter {


Any benefits to calling this a roaring_bitmap_filter just for clarity? I'm kind of neutral to both- just not sure if one always implies the other.

Good point, let's do roaring_bitmap_filter 👍

…ng-filter

divyegala · 2026-09-17T00:53:38Z

/ok to test 35f50f5

copy-pr-bot · 2026-09-17T00:53:41Z

/ok to test 35f50f5

@divyegala, there was an error processing your request: E2

See the following link for more information: https://docs.gha-runners.nvidia.com/cpr/e/2/

divyegala · 2026-09-17T00:55:35Z

/ok to test 3025b9a

dantegd

Some very minor things, otherwise it looks great!

dantegd · 2026-09-17T21:46:04Z

+  auto empty_allowlist = cuvs::core::roaring_allowlist::from_ids(
+    res, n_rows, raft::make_host_vector_view<const std::uint32_t, std::int64_t>(nullptr, 0));
+  roaring_bitmap_filter.set_allowlist(res, 1, empty_allowlist.view());
+  auto empty_result = search(roaring_bitmap_filter, 0.999f);


Could we let this search use the default filtering rate? The filter’s automatic estimate should already be 0.999f after installing the empty allowlist, so this would exercise the new params.filtering_rate < 0 CAGRA dispatch path without changing the test’s intended behavior. The owner test covers the estimator itself, but not this wiring. What do you think?

divyegala · 2026-09-17T23:28:57Z

/ok to test

copy-pr-bot · 2026-09-17T23:29:00Z

/ok to test

@divyegala, there was an error processing your request: E1

See the following link for more information: https://docs.gha-runners.nvidia.com/cpr/e/1/

divyegala · 2026-09-17T23:29:24Z

/ok to test 82d706c

dantegd · 2026-09-21T23:24:40Z

/merge

Initial impl

f640677

divyegala added 2 commits September 2, 2026 19:18

Merge branch 'main' of https://github.com/rapidsai/cuvs into roaring-…

3a1f3ca

…filter

single batch upstream cuco

35f50f5

divyegala marked this pull request as ready for review September 2, 2026 19:49

divyegala requested review from a team as code owners September 2, 2026 19:49

divyegala added feature request New feature or request non-breaking Introduces a non-breaking change labels Sep 2, 2026

divyegala added 4 commits September 2, 2026 20:29

just single batch for now

5668d01

reduce surface area

2637cf4

Merge branch 'main' into roaring-filter

db29ef9

Merge branch 'main' into roaring-filter

1529d8f

dantegd requested changes Sep 10, 2026

View reviewed changes

divyegala changed the base branch from main to release/26.10 September 10, 2026 17:50

divyegala and others added 4 commits September 10, 2026 19:12

address review

b7fcf78

Merge branch 'roaring-filter' of github.com:divyegala/cuvs into roari…

90ec178

…ng-filter

Merge remote-tracking branch 'origin/release/26.10' into roaring-filter

34904d7

Merge branch 'release/26.10' into roaring-filter

2c3fa9e

cjnolet reviewed Sep 16, 2026

View reviewed changes

Comment thread cpp/cmake/patches/cuco_override.json Outdated

cjnolet reviewed Sep 16, 2026

View reviewed changes

Comment thread cpp/include/cuvs/core/roaring_allowlist.hpp

cjnolet reviewed Sep 16, 2026

View reviewed changes

Comment thread cpp/include/cuvs/core/roaring_allowlist.hpp

cjnolet reviewed Sep 16, 2026

View reviewed changes

divyegala added 3 commits September 16, 2026 19:20

more reviews

6bbf402

Merge remote-tracking branch 'origin/release/26.10' into roaring-filter

cff0180

Merge branch 'roaring-filter' of github.com:divyegala/cuvs into roari…

9942dc3

…ng-filter

divyegala requested a review from a team as a code owner September 16, 2026 19:21

divyegala added 2 commits September 17, 2026 00:48

use rapids cmake

b560335

follow pattern

3025b9a

divyegala added 2 commits September 17, 2026 11:07

Merge branch 'release/26.10' into roaring-filter

bb6a6d0

Merge branch 'release/26.10' into roaring-filter

16ed867

dantegd requested changes Sep 17, 2026

View reviewed changes

divyegala added 3 commits September 17, 2026 23:27

review comments

6f2a0d3

Update rapids_config.cmake

e966a7d

Merge branch 'release/26.10' into roaring-filter

82d706c

dantegd approved these changes Sep 21, 2026

View reviewed changes

rapids-bot Bot merged commit 73fa5f7 into NVIDIA:release/26.10 Sep 21, 2026
285 of 290 checks passed

divyegala mentioned this pull request Sep 30, 2026

[FEA] Roaring Bitmap support #1972

Closed

Conversation

divyegala commented Aug 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

copy-pr-bot Bot commented Aug 15, 2026

Uh oh!

copy-pr-bot Bot commented Sep 2, 2026

Uh oh!

divyegala commented Sep 3, 2026

Uh oh!

dantegd left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

divyegala Sep 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

divyegala commented Sep 17, 2026

Uh oh!

copy-pr-bot Bot commented Sep 17, 2026

Uh oh!

divyegala commented Sep 17, 2026

Uh oh!

dantegd left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

divyegala commented Sep 17, 2026

Uh oh!

copy-pr-bot Bot commented Sep 17, 2026

Uh oh!

divyegala commented Sep 17, 2026

Uh oh!

dantegd commented Sep 21, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

divyegala commented Aug 15, 2026 •

edited

Loading

divyegala Sep 10, 2026 •

edited

Loading