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.

Sign up for GitHub

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

Jump to bottom

Unify async and non-async operations using optional_ref<const stream_t> optional arguments #689

Open
eyalroz opened this issue Oct 20, 2024 · 0 comments
Open

Unify async and non-async operations using optional_ref<const stream_t> optional arguments #689

eyalroz opened this issue Oct 20, 2024 · 0 comments
Assignees
@eyalroz
Labels
task

Comments

@eyalroz
Copy link
Owner

eyalroz commented Oct 20, 2024

In the comments re issue #641 , I sketch out an approach to unifying the copy functions involving optional_ref<const stream_t> for the same wrapper API call usable both for async and non-async variants of CUDA's own APIs. This is also applicable to other operations in the cuda::memory::async namespace: set(), zero(), allocate(), free(). If we adopt that approach for copying, let's also have it for these operations.
@eyalroz eyalroz added the task label Oct 20, 2024
@eyalroz eyalroz self-assigned this Oct 20, 2024
@eyalroz eyalroz mentioned this issue Oct 20, 2024
Open
eyalroz added a commit that referenced this issue Oct 21, 2024
@eyalroz
Regards #689: Moved allocate() out of the async sub-namespace
74cbfe1
eyalroz added a commit that referenced this issue Oct 21, 2024
@eyalroz
Fixes #689: All remaining async subnamespace operations - `typed_se…
c079d9b 
…t()`, `set()` and zero()` - now out of the namespace, and unified with their non-async variants
eyalroz added a commit that referenced this issue Oct 26, 2024
@eyalroz
Regards #689: Moved allocate() out of the async sub-namespace
250be5c
eyalroz added a commit that referenced this issue Oct 26, 2024
@eyalroz
Fixes #689: All remaining async subnamespace operations - `typed_se…
e499aec 
…t()`, `set()` and zero()` - now out of the namespace, and unified with their non-async variants
eyalroz added a commit that referenced this issue Oct 26, 2024
@eyalroz
Regards #689: Moved allocate() out of the async sub-namespace
9afdf8f
eyalroz added a commit that referenced this issue Oct 26, 2024
@eyalroz
Fixes #689: All remaining async subnamespace operations - `typed_se…
407c89a 
…t()`, `set()` and zero()` - now out of the namespace, and unified with their non-async variants
eyalroz added a commit that referenced this issue Oct 28, 2024
@eyalroz
Regards #689: Moved allocate() out of the async sub-namespace
58cc11d
eyalroz added a commit that referenced this issue Oct 28, 2024
@eyalroz
Fixes #689: All remaining async subnamespace operations - `typed_se…
d350e1e 
…t()`, `set()` and zero()` - now out of the namespace, and unified with their non-async variants
eyalroz added a commit that referenced this issue Nov 15, 2024
@eyalroz
Regards #689: Moved allocate() out of the async sub-namespace
3f930b0
eyalroz added a commit that referenced this issue Nov 15, 2024
@eyalroz
Fixes #689: All remaining async subnamespace operations - `typed_se…
dd6c5df 
…t()`, `set()` and zero()` - now out of the namespace, and unified with their non-async variants
eyalroz added a commit that referenced this issue Nov 16, 2024
@eyalroz
Regards #689: Moved allocate() out of the async sub-namespace
4f93c92
eyalroz added a commit that referenced this issue Nov 16, 2024
@eyalroz
Fixes #689: All remaining async subnamespace operations - `typed_se…
be24ced 
…t()`, `set()` and zero()` - now out of the namespace, and unified with their non-async variants
eyalroz added a commit that referenced this issue Nov 16, 2024
@eyalroz
Regards #689: Moved allocate() out of the async sub-namespace
6f1887f
eyalroz added a commit that referenced this issue Nov 16, 2024
@eyalroz
Fixes #689: All remaining async subnamespace operations - `typed_se…
3d88bdd 
…t()`, `set()` and zero()` - now out of the namespace, and unified with their non-async variants
eyalroz added a commit that referenced this issue Nov 16, 2024
@eyalroz
Regards #689: Moved allocate() out of the async sub-namespace
272a6c2
eyalroz added a commit that referenced this issue Nov 16, 2024
@eyalroz
Fixes #689: All remaining async subnamespace operations - `typed_se…
ee4e618 
…t()`, `set()` and zero()` - now out of the namespace, and unified with their non-async variants
eyalroz added a commit that referenced this issue Nov 16, 2024
@eyalroz
Regards #689, Fixes #688: Unification of asynchronous & synchronous c…
efaf7f6 
…opy functions:

* All copy functions now take an optional stream via an `optional_ref` parameter;
* No longer using the `cuda::memory::async` subnamespace for any copy functions; they are all directly in `cuda::memory`
* Fixes #688: Now supporting async copy using copy parameters structures
* Explicitly including `memory.hpp` in `multi_wrapper_impls/memory.hpp`
eyalroz added a commit that referenced this issue Nov 16, 2024
@eyalroz
Fixes #689: Completed removal of cuda::memory::async:
e9c1643 
* Operations affected include: `allocate()`, `free()`, typed_set()`, `set()`, zero()`
* Combined (kinda-)synchronous and asynchronous operations using an `optional_ref<stream_t>` extra parameter, defauling to `{}`/`nullopt` for the synchronous version
* Already done with `copy()` in an earlier commit
* `prefetch()` and `prefetch_to_host()` also affected, but no additional parameter is necesary
* Operations affected include: `allocate()`, `free()`, typed_set()`, `set()`, zero()`
* Comment tweaks
* Removed some redundant code
eyalroz added a commit that referenced this issue Nov 16, 2024
@eyalroz
Regards #689, Fixes #688: Unification of asynchronous & synchronous c…
ffbae89 
…opy functions:

* All copy functions now take an optional stream via an `optional_ref` parameter;
* No longer using the `cuda::memory::async` subnamespace for any copy functions; they are all directly in `cuda::memory`
* Fixes #688: Now supporting async copy using copy parameters structures
* Explicitly including `memory.hpp` in `multi_wrapper_impls/memory.hpp`
eyalroz added a commit that referenced this issue Nov 16, 2024
@eyalroz
Fixes #689: Completed removal of cuda::memory::async:
b9cef21 
* Operations affected include: `allocate()`, `free()`, typed_set()`, `set()`, zero()`
* Combined (kinda-)synchronous and asynchronous operations using an `optional_ref<stream_t>` extra parameter, defauling to `{}`/`nullopt` for the synchronous version
* Already done with `copy()` in an earlier commit
* `prefetch()` and `prefetch_to_host()` also affected, but no additional parameter is necesary
* Operations affected include: `allocate()`, `free()`, typed_set()`, `set()`, zero()`
* Comment tweaks
* Removed some redundant code
eyalroz added a commit that referenced this issue Nov 17, 2024
@eyalroz
Regards #689, Fixes #688: Unification of asynchronous & synchronous c…
e8d27d6 
…opy functions:

* All copy functions now take an optional stream via an `optional_ref` parameter;
* No longer using the `cuda::memory::async` subnamespace for any copy functions; they are all directly in `cuda::memory`
* Fixes #688: Now supporting async copy using copy parameters structures
* Explicitly including `memory.hpp` in `multi_wrapper_impls/memory.hpp`
eyalroz added a commit that referenced this issue Nov 17, 2024
@eyalroz
Fixes #689: Completed removal of cuda::memory::async:
67cfe79 
* Operations affected include: `allocate()`, `free()`, typed_set()`, `set()`, zero()`
* Combined (kinda-)synchronous and asynchronous operations using an `optional_ref<stream_t>` extra parameter, defauling to `{}`/`nullopt` for the synchronous version
* Already done with `copy()` in an earlier commit
* `prefetch()` and `prefetch_to_host()` also affected, but no additional parameter is necesary
* Operations affected include: `allocate()`, `free()`, typed_set()`, `set()`, zero()`
* Comment tweaks
* Removed some redundant code
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@eyalroz eyalroz

Labels
task
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@eyalroz