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

DPPLQueue_Memcpy should return an Event handle and not wait. #84

Closed
diptorupd opened this issue Oct 1, 2020 · 4 comments
Closed

DPPLQueue_Memcpy should return an Event handle and not wait. #84

diptorupd opened this issue Oct 1, 2020 · 4 comments
Assignees

Comments

@diptorupd
Copy link
Contributor

Currently DPPLQueueMemcpy waits on the event returned by sycl::queue.memcpy before returning. We should instead just return the event back to caller.

@diptorupd
Copy link
Contributor Author

diptorupd commented Jan 31, 2021

@adarshyoga I am assigning this ticket to you as it will be related to the asynchronous kernel execution improvements you are working on for Numba-dppy.

@diptorupd
Copy link
Contributor Author

@adarshyoga ping.

@diptorupd
Copy link
Contributor Author

diptorupd commented Jun 23, 2021

@oleksandr-pavlyk I have started making the changes needed to fix the issue. However, I wanted to clarify few things that will be impacted by making DPCTLQueue_Memcpy non-blocking.

  1. The SyclQueue.memcpy function only allows copying from one _Memory object to another. However, what is the expected behavior when the _Memory objects are not using the same queue as the SyclQueue instance on which memcpy is invoked?
  2. Similar to (1), but the _Memory objects are using two different queue.
  3. Why should the memcpy functions be restricted to just between two _Memory objects?
  4. The copy* functions in _Memory all use DPCTLQueue_Memcpy. Should we change these functions to non-blocking as well?
  5. Should we introduce the dependent events arguments to the functions at this point?

@diptorupd diptorupd assigned diptorupd and unassigned adarshyoga Jun 23, 2021
@diptorupd
Copy link
Contributor Author

fixed in #557

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants