-
Notifications
You must be signed in to change notification settings - Fork 43
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
Support Simple protocol plans using scratch buffer #371
base: main
Are you sure you want to change the base?
Conversation
yzygitzh
commented
Oct 22, 2024
•
edited
Loading
edited
- Separate the options whether to use packet and whether to use double buffer.
- Reduce primitive implementation fixes in executor.
- Add validation for number of operations, channels and channels per operation.
src/executor/executor.cc
Outdated
plan.impl_->lightLoadExecutionPlan(inputMessageSize, outputMessageSize, contsSrcOffset, constDstOffset, rank, | ||
sendBufferSize, recvBufferSize, flag); | ||
this->setupDeviceExecutionPlan(this->contexts[key], rank, plan); | ||
this->contexts[key].deviceExecutionPlansBuffer = | ||
allocExtSharedCuda<char>(this->contexts[key].deviceExecutionPlans.size() * sizeof(DeviceExecutionPlan)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If find the key, seems it will overwrite the previous plan. It may cause problem when using cuda graph. Only last plan will be copied to GPU memory. Maybe we need to distinguish the plan with inputMessageSize, outputMessageSize, flag
. And let kernel load the plan with correct device_ptr.
@Binyang2014 Any updates in this PR? |
I think there not blocker for this PR. Just need to resolve the conflict. Let me check with Ziyue |