feat[cuda]: export arrays to ArrowDeviceArray #6253

a10y · 2026-02-02T20:04:11Z

This PR adds scaffolding for the first part of implementing export of Vortex Arrays directly to Arrow C Data Device Interface arrays, and implements the actual export for StructArray and PrimitiveArray

Setup

Arrow defines a standard for exchanging data in-process to native code using the C Data Interface, which converts an Arrow array into a struct of pointers.

There is an (experimental, but mostly stable) extension called the C Data Device Interface which includes extra information such as the GPU device type and device ID.

cudf knows how to import data exported this way using the from_arrow_device_column method for column_views.

We replicate the ArrowArray and ArrowDeviceArray structs from the spec.

These are very similar to the existing FFI_ArrowArray and FFI_ArrowSchema structs from the arrow-data crate, except that those use arrow Bytes and real pointers and we need to use CUDA device pointers and BufferHandles.

Testing

Rather than polluting the repo/CI with fetching and building cudf, I made a new repo https://github.com/vortex-data/cudf-test-harness/

This will load a cdylib, call its export_array() function, imports it into cudf and calls some simple functions, then frees it by calling the embedded release function pointer. This step is hooked up to CI now and only adds ~1m to the CUDA tests jobs.

vortex-cuda/cudf-test/src/lib.rs

codspeed-hq · 2026-02-03T17:16:21Z

Merging this PR will not alter performance

✅ 1138 untouched benchmarks
⏩ 1265 skipped benchmarks¹

_{Comparing aduffy/c-device-iface (a06184d) with develop (6b69f19)}

1265 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

Signed-off-by: Andrew Duffy <andrew@a10y.dev>

0ax1

Couple of questions / remarks

0ax1 · 2026-02-04T10:09:33Z

.github/workflows/ci.yml

+      - name: Download and run cudf-test-harness
+        run: |
+          curl -fsSL https://github.com/vortex-data/cudf-test-harness/releases/latest/download/cudf-test-harness-x86_64.tar.gz | tar -xz
+          cd cudf-test-harness-x86_64


nit: I basically try to never cd in shell scripts, considering the current pwd as state. obs not super important, naturally keep as is if you like.

0ax1 · 2026-02-04T10:10:43Z

.github/workflows/ci.yml

+        run: |
+          curl -fsSL https://github.com/vortex-data/cudf-test-harness/releases/latest/download/cudf-test-harness-x86_64.tar.gz | tar -xz
+          cd cudf-test-harness-x86_64
+          ./cudf-test-harness check $GITHUB_WORKSPACE/target/x86_64-unknown-linux-gnu/debug/libvortex_cudf_test.so


Should we leave a comment here to briefly hint at what is happening here with the test harness and why it lives in a separate repo?

0ax1 · 2026-02-04T10:15:46Z

vortex-cuda/cudf-test/src/lib.rs

+});
+
+/// External array
+#[unsafe(no_mangle)]


nit: Could throw in more docs here. What does external mean here exactly, and is export_array part of the arrow device ABI etc?

this is all just test code. I can comment to make that clearer

0ax1 · 2026-02-04T10:17:20Z

vortex-cuda/src/arrow/canonical.rs

+
+    let null_count = match validity {
+        Validity::NonNullable | Validity::AllValid => 0,
+        Validity::AllInvalid => len,


Early return all invalid case?

E.g we're doing

if matches!(values.validity()?, Validity::AllInvalid) { return ConstantArray::new(Scalar::null(values.dtype().clone()), output_len) .to_canonical(); }

in the runend case.

This was actually an oversight and I think to start with, I actually think we should avoid handling any nulls whatsoever for now

0ax1 · 2026-02-04T10:36:06Z

vortex-cuda/src/arrow/canonical.rs

+    // We need the children to be held across await points.
+    let mut children = Vec::with_capacity(fields.len());
+
+    for field in fields.iter() {


How about sth along the lines of:

let futures = fields .iter() .map(|field| { let field = field.clone(); async move { let cuda_field = field.execute_cuda(ctx).await?; export_canonical(cuda_field, ctx).await } }) .collect::<Vec<_>>(); let results = join_all(futures).await;

If fields live on different streams, they run in parallel.

are fields going to live on different streams? if so, things might get a little weird with the SyncEvent stuff

Specifically: the contract for the returned ArrowDeviceArray is that its sync_event field, if not NULL, contains a pointer to a cudaStream_t which AFAIU can only be linked to one stream.

Similarly the CudaExecutionCtx is linked to only one global stream rn. So assuming that StructArray::execute_cuda(ctx) gets called, all of its fields should be getting executed with the same context, and thus the same stream.

0ax1 · 2026-02-04T10:40:25Z

vortex-cuda/src/arrow/canonical.rs

+    let buffer = if buffer.is_on_device() {
+        buffer
+    } else {
+        // TODO(aduffy): I don't think this type parameter does anything


I think we need T here to know what type is returned from cuda alloc.
let mut cuda_slice: CudaSlice<T> = self.device_alloc(host_slice.len())?;

Should we put a phantom data marker on BufferHandle instead?

0ax1 · 2026-02-04T10:41:08Z

vortex-cuda/src/arrow/canonical.rs

+            for child in children {
+                release_array(child);
+            }
+            drop(private_data);


Why the explicit drop at the end of the scope?

i guess not strictly necessary but i like being explicit here. the private_data owns all of the resources allocated on the rust/cudarc side so dropping it signals that the array is actually freed here

0ax1 · 2026-02-04T10:44:59Z

vortex-cuda/src/arrow/mod.rs

+}
+
+unsafe impl Send for ArrowDeviceArray {}
+unsafe impl Sync for ArrowDeviceArray {}


We can drop the Sync impl I think.

0ax1 · 2026-02-04T10:50:49Z

vortex-cuda/src/arrow/mod.rs

+
+use crate::CudaExecutionCtx;
+
+#[derive(Debug, Copy, Clone)]


Should we gen this with bindgen?

i'd prefer to leave bindgen out of this one, since ArrowArray and ArrowDeviceArray cannot be trivially bindgen'ed since they rely on some cudarc types.

I based these definitions off of the ones in https://github.com/apache/arrow-rs/blob/main/arrow-data/src/ffi.rs#L27, with the addition of device stuff

joseph-isaacs · 2026-02-04T16:02:53Z

vortex-cuda/cudf-test/src/lib.rs

put this inn vortex-test-e2e-cuda?

joseph-isaacs · 2026-02-04T16:07:48Z

vortex-cuda/src/arrow/canonical.rs

+pub(crate) struct CanonicalDeviceArrayExport;
+
+#[async_trait]
+impl ExportDeviceArray for CanonicalDeviceArrayExport {


would this logic every differ from export arrow with a different execute function?

joseph-isaacs · 2026-02-04T16:12:26Z

vortex-cuda/src/arrow/mod.rs

+/// event that the client must wait on.
+#[repr(C)]
+#[derive(Debug)]
+pub struct ArrowDeviceArray {


can we use a regular arrow array instead of this?

joseph-isaacs · 2026-02-04T16:17:30Z

Could we share logic between this exporter and the arrow export if we could pass around a different executor?

a10y force-pushed the aduffy/c-device-iface branch from 9d62079 to 18f8a3d Compare February 2, 2026 20:05

a10y commented Feb 2, 2026

View reviewed changes

vortex-cuda/cudf-test/src/lib.rs Outdated Show resolved Hide resolved

a10y force-pushed the aduffy/c-device-iface branch from 3a8ddb6 to a2d1c95 Compare February 3, 2026 17:19

a10y added the changelog/feature A new feature label Feb 3, 2026

a10y changed the title ~~WIP: initial work toward export to device interface~~ feat[cuda]: export arrays to ArrowDeviceArray Feb 3, 2026

a10y force-pushed the aduffy/c-device-iface branch 2 times, most recently from 497d765 to 79b7afc Compare February 3, 2026 17:59

a10y marked this pull request as ready for review February 3, 2026 18:19

a10y added 10 commits February 3, 2026 13:28

initial work toward export to device interface

e54c3cb

Signed-off-by: Andrew Duffy <andrew@a10y.dev>

starting on cudf integration tests

1135748

Signed-off-by: Andrew Duffy <andrew@a10y.dev>

add cudf test harness

032e334

Signed-off-by: Andrew Duffy <andrew@a10y.dev>

more test

182e35b

Signed-off-by: Andrew Duffy <andrew@a10y.dev>

fix tests

a31192f

Signed-off-by: Andrew Duffy <andrew@a10y.dev>

delete a bunch of code, add some more to the test

da8c680

Signed-off-by: Andrew Duffy <andrew@a10y.dev>

cleanup

fc53a44

Signed-off-by: Andrew Duffy <andrew@a10y.dev>

drop impl

2c94c69

Signed-off-by: Andrew Duffy <andrew@a10y.dev>

free the right way

0990251

Signed-off-by: Andrew Duffy <andrew@a10y.dev>

add CI step to validate cudf compatibility

1495dbc

Signed-off-by: Andrew Duffy <andrew@a10y.dev>

a10y force-pushed the aduffy/c-device-iface branch from 74549dc to 930f824 Compare February 3, 2026 18:28

lol

b489712

Signed-off-by: Andrew Duffy <andrew@a10y.dev>

a10y force-pushed the aduffy/c-device-iface branch from 930f824 to b489712 Compare February 3, 2026 18:29

a10y added 2 commits February 3, 2026 13:30

comment

e67b57a

Signed-off-by: Andrew Duffy <andrew@a10y.dev>

fix

b672525

Signed-off-by: Andrew Duffy <andrew@a10y.dev>

a10y requested review from 0ax1 and joseph-isaacs February 3, 2026 18:49

a10y and others added 2 commits February 3, 2026 16:06

sync event propagation

75cb1ee

Signed-off-by: Andrew Duffy <andrew@a10y.dev>

add struct array for C export (#6294)

a06184d

Signed-off-by: Andrew Duffy <andrew@a10y.dev>

0ax1 reviewed Feb 4, 2026

View reviewed changes

joseph-isaacs reviewed Feb 4, 2026

View reviewed changes

vortex-cuda/cudf-test/src/lib.rs

Copy link

Contributor

joseph-isaacs Feb 4, 2026

Choose a reason for hiding this comment

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

put this inn vortex-test-e2e-cuda?

joseph-isaacs reviewed Feb 4, 2026

View reviewed changes

feat[cuda]: export arrays to ArrowDeviceArray #6253

Are you sure you want to change the base?

feat[cuda]: export arrays to ArrowDeviceArray #6253

Conversation

a10y commented Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Setup

Testing

Uh oh!

Uh oh!

codspeed-hq bot commented Feb 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Merging this PR will not alter performance

Footnotes

Uh oh!

0ax1 left a comment

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!

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!

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!

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!

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!

Choose a reason for hiding this comment

Uh oh!

a10y Feb 4, 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!

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!

joseph-isaacs commented Feb 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

a10y commented Feb 2, 2026 •

edited

Loading

codspeed-hq bot commented Feb 3, 2026 •

edited

Loading

a10y Feb 4, 2026 •

edited

Loading