Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

feat(cuda-core): borrow external streams as CudaStream

Open
  • Is something wrong?
#1,439 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
20/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
rust
Domain
api, backend

Research direction

The proposed behavior is described for CudaStream::borrow_raw, with a test named cuda-core/tests/borrow_raw.rs and a required CHANGELOG entry. Start by reading AGENTS.md's “Transplanting a cutile-rs pull request” section: this issue tracks an existing pull request from the archived repository, and the work is already implemented there. The issue asks for that pull request to be recreated against this repository; check the transplant instructions and verify the tests and checks listed in the original description.

Written by the indexing model from the issue text.

Description

cutile-rs post-migration-pr

Tracks pull request NVlabs/cutile-rs#315 (https://github.com/NVlabs/cutile-rs/pull/315) by @lucifer1004, opened 2026-09-25: feat(cuda-core): borrow external streams as CudaStream. The branch was rebased onto cutile-rs main on 2026-10-07 and merges cleanly.

@lucifer1004: that repository has moved here and is being archived, so the pull request is closed there, not rejected. If you want to continue the work, please recreate it against NVIDIA/cuda-rust. AGENTS.md in NVIDIA/cuda-rust has a "Transplanting a cutile-rs pull request" section that lets an agent do the replay (it fetches pull/315/head from NVlabs/cutile-rs, keeps your authorship and sign-off, and maps the moved paths).

Original description:

Why

runtime::Stream::borrow_raw wraps a stream owned by another library. The SIMT layer's CudaStream, however, can only be created by cuda-core, and dropping it destroys the handle. Code that launches through the SIMT layer therefore cannot enqueue work on a caller's stream. This includes the typed launchers cuda-oxide generates, which take &CudaStream. Examples of such caller streams are a framework's current stream and the tvm-ffi environment stream, the stream a tvm-ffi exported kernel entry must launch on.

What

CudaStream::borrow_raw(cu_stream, ctx) wraps such a stream without taking ownership, mirroring Stream::borrow_raw. A new owned flag records ownership. Dropping a borrowed stream neither destroys the handle nor changes the context's stream count. Streams created by cuda-core are unchanged. There is a CHANGELOG entry.

Tests

cuda-core/tests/borrow_raw.rs: repeatedly borrowing and dropping a stream leaves the source stream usable. cargo fmt, cargo clippy -p cuda-core --all-targets -D warnings and cargo test -p cuda-core pass on an RTX PRO 6000 (sm_120).

Also checked: the same commit cherry-picked onto v0.3.1, which cuda-oxide main depends on, lets cuda-oxide's generated module.<kernel>(&stream, config, ...) launch on a borrowed tvm-ffi environment stream. With it, a tvm-ffi entry for a cuda-oxide kernel needs no hand-marshalled cuLaunchKernel.

🤖 Generated with Claude Code

Dominant language
Rust
Stars
3.8k
Forks
325
Avg merge
6d 8h
Merged PRs (30d)
66

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from NVIDIA/cuda-rust

All issues in NVIDIA/cuda-rust

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.