Skip to content
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

Allow two or more predecessor values to be passed to cuda_scheduler bulk customization #1167

Open
msimberg opened this issue Jun 12, 2024 · 0 comments
Labels
category: CUDA category: senders/receivers P2300 effort: 2 A few hours of work. effort: 3 A few days of work. good first issue priority: low Nice to have, but nobody is going to be sad if this is never done. type: feature type: refactoring

Comments

@msimberg
Copy link
Contributor

msimberg commented Jun 12, 2024

Currently only a single or zero values are allowed to be passed from the predecessor sender (

// TODO: This should pass through the additional arguments.
// Currently only works with zero or one arguments with a plain call
// operator like here.
void operator()(whip::stream_t stream) const { launch_bulk_function(f, shape, stream); }
). I think this could easily be generalized by collecting arguments into a tuple, and then using the unpack sender adaptor to split values again after the bulk operation.

Note, this is a good first issue if one is already familiar with CUDA. The changes required for this should be small, but may require a bit of background knowledge of CUDA and std::execution.

@msimberg msimberg added effort: 2 A few hours of work. effort: 3 A few days of work. priority: low Nice to have, but nobody is going to be sad if this is never done. type: feature type: refactoring category: CUDA category: senders/receivers P2300 good first issue labels Jun 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category: CUDA category: senders/receivers P2300 effort: 2 A few hours of work. effort: 3 A few days of work. good first issue priority: low Nice to have, but nobody is going to be sad if this is never done. type: feature type: refactoring
Projects
Status: Backlog
Development

No branches or pull requests

1 participant