Capture work forked onto other streams during stream capture - #1529
Open
pvelesko wants to merge 3 commits into
Open
Capture work forked onto other streams during stream capture#1529pvelesko wants to merge 3 commits into
pvelesko wants to merge 3 commits into
Conversation
Capture on one stream, fork two more streams through hipEventRecord plus hipStreamWaitEvent, launch a kernel on each, join back, end capture, and expect nothing to have run, three nodes in the graph, all three writes after launch, and hipErrorStreamCaptureUnjoined for a fork that never joins. Today the forked kernels run eagerly and only the origin stream's kernel is recorded (github issue 1523).
A stream capture records into the origin stream only; an event recorded on the capturing stream and waited on from another stream was captured as an event record node plus an event wait node, and the work then launched on the other stream ran eagerly outside the graph. Follow the CUDA/HIP cross-stream capture semantics as implemented in ROCm clr (hip_event.cpp, hip_stream.cpp, hip_graph.cpp): hipEventRecord on a capturing stream adds no node and instead tags the event with the stream's current capture dependencies; hipStreamWaitEvent on such an event joins the waiting stream into the same capture (same graph, no dependencies yet) or, when the stream is already part of it, merges the event's nodes into its dependencies, so a fork joins back by recording an event on the fork and waiting on it from the origin; hipStreamEndCapture is refused with hipErrorStreamCaptureUnmatched on a forked stream, and with hipErrorStreamCaptureUnjoined when a leaf of the graph is not among the origin's dependencies (a fork that never joined). Ending the capture resets every forked stream and the events recorded during it; destroying a stream or an event mid capture detaches it. The per queue LastNode_ becomes the dependency set CaptureDeps_ because a join yields several dependencies. Waiting with hipEventWaitExternal, and waiting on an event not recorded in a capture, still record an event wait node as before.
Both pass now that stream capture follows event dependencies onto other streams (github issue 1523).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stream capture now follows event dependencies onto other streams, following the ROCm clr implementation in
hip_event.cpp,hip_stream.cppandhip_graph.cpp.hipEventRecordon a capturing stream tags the event with the stream's current capture dependencies instead of adding a node,hipStreamWaitEventon such an event joins the waiting stream into the same capture (or, for a stream already in it, merges the event's nodes into its dependencies, which is how a fork joins back), andhipStreamEndCapturereturnshipErrorStreamCaptureUnmatchedon a forked stream andhipErrorStreamCaptureUnjoinedwhen a fork was never joined. The reproducerTestFix1523CrossStreamCaptureforks two streams, launches one kernel on each of three streams, joins, replays the graph and checks the unjoined error; it failed withwork ran during capture, slots are 0 1 1before the fix. On OpenCL CPU the fix also makesUnit_hipStreamBeginCapture_nestedStreamCapture,Unit_hipStreamBeginCapture_streamReuseand 12 further catch graph tests pass with no new failures against the base branch. Stacked on #1522.Fixes #1523