Closed deukhyun-cha closed 2 months ago
I would appreciate some help on testing especially for dpcpp and metal backends if possible.
Attention: Patch coverage is 0%
with 8 lines
in your changes are missing coverage. Please review.
Project coverage is 74.94%. Comparing base (
39908af
) to head (c04baf6
).
I would appreciate some help on testing especially for dpcpp and metal backends if possible.
I was able to run the example added here for serial, cuda, dpcpp, and openmp backends.
I was going through this change and feeling the interface should be done through the device like other stream related functions. If so, should it also work with current stream on the device (instead of taking the stream as an argument)? I would appreciate advice.
I was going through this change and feeling the interface should be done through the device like other stream related functions. If so, should it also work with current stream on the device (instead of taking the stream as an argument)? I would appreciate advice.
Since it is complete, I would leave the existing implementation in the PR as is.
There is already a waitFor
function in device
that waits on a given streamTag
. Since streamTags
are associated with the stream
which was active when they were created, the existing implementation of device::waitFor
is problematic in the case where the active stream has been changed by the user. To avoid this ambiguity, device::waitFor
should be reimplemented later using the function added in this PR to synchronize the current stream
. A separate API for waiting on a specific streamTag
could be added to that class afterwards, if needed.
I was going through this change and feeling the interface should be done through the device like other stream related functions. If so, should it also work with current stream on the device (instead of taking the stream as an argument)? I would appreciate advice.
Since it is complete, I would leave the existing implementation in the PR as is.
There is already a
waitFor
function indevice
that waits on a givenstreamTag
. SincestreamTags
are associated with thestream
which was active when they were created, the existing implementation ofdevice::waitFor
is problematic in the case where the active stream has been changed by the user. To avoid this ambiguity,device::waitFor
should be reimplemented later using the function added in this PR to synchronize the currentstream
. A separate API for waiting on a specificstreamTag
could be added to that class afterwards, if needed.
Thanks @kris-rowe, appreciate your comment.
I was able to build this for Metal backend and run stream examples (after updating for some fixes) on a Mac. The branch is updated.
@kris-rowe just wanted to check if you have any general comments for me to consider on this PR before the detailed review?
This is to implement a feature described in Add support a stream to synchronize for a specific event #512.