-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Introduce reused_buffer_index_per_stream in allocation planner which will be reset after computing the reuse buffer for each stream #19515
Conversation
…ntime into leca/experiment
Thanks for this ! Do you know if it works when reverting this change? https://github.com/microsoft/onnxruntime/pull/19481/files If it does, we don't need to disable the streams on the DML EP anymore and can revert it. |
Yes it works. I've tested it in v1.17 without your PR. I will revert your PR once this PR is in |
/azp run Python format |
No pipelines are associated with this pull request. |
…will be reset after computing the reuse buffer for each stream (#19515) ### Description <!-- Describe your changes. --> Introduce reused_buffer_index_per_stream in allocation planner which will be reset after computing the reuse buffer for each stream. So if a NodeArg is an input of several Ops across different streams and reuses other NodeArg, the reused NodeArg won't be involved when computing the second stream's reuse plan. ### Motivation and Context <!-- - Why is this change required? What problem does it solve? - If it fixes an open issue, please link to the issue here. --> This is to fix #19480, which is a crash for the scenario mentioned above. --------- Co-authored-by: Lei Cao <[email protected]>
Description
Introduce reused_buffer_index_per_stream in allocation planner which will be reset after computing the reuse buffer for each stream. So if a NodeArg is an input of several Ops across different streams and reuses other NodeArg, the reused NodeArg won't be involved when computing the second stream's reuse plan.
Motivation and Context
This is to fix #19480, which is a crash for the scenario mentioned above.