After a quick skim of the Runtime API’s Graph Management functions, I’m not seeing any information on the lifetimes of cudaGraph_t and cudaGraphExec_t objects.
I’m going to assume that the API supports destroying cudaGraph_t and cudaGraphExec_t objects as soon as they’re no longer needed.
Specifically:
cudaGraphCreate(&cg) // create the graph
// add nodes... // build the graph
cudaGraphInstantiate(&cge,cg) // build the executable
cudaGraphDestroy(cg) // we're done with the graph so destroy it
cudaGraphLaunch(cge,stream) // launch the executable
cudaGraphExecDestroy(cge) // we're done with the executable so destroy it
My question is, in some way, a repetition of @allanmac . I want to be sure that I can issue
cudaGraphLaunch(clonedGraphExec, streamForGraph);
and then immediately
cudaGraphExecDestroy(graphExec);
even though the actual execution on the streamForGraph could be delayed. In my actual code I use driver API and I wait on some value (acts like a semaphore) in order to release the next batch of CUDA commands on some stream. It is important to be sure that in this way, the resources related to graphExec handle will be properly deallocated/released yet, at the time the GPU get to the actual execution of the graph, the handle is still valid, despite cudaGraphExecDestroy(graphExec); has already been called at that stage.
It is possible to have a sequence such as you are showing. However the details (surrounding code, exact structure/contents of the graph) matter. I suggest reading this section of the programming guide.