-
Notifications
You must be signed in to change notification settings - Fork 17
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
Topic/cuda aware communications #671
base: master
Are you sure you want to change the base?
Conversation
968bf7e
to
6f2e034
Compare
b3dfcdc
to
0838a95
Compare
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
efa8386
to
ab1a74a
Compare
Now passing 1-gpu/node, 8 ranks PTG POTRF |
This comment was marked as resolved.
This comment was marked as resolved.
cd7c475
to
3bab2d5
Compare
Signed-off-by: George Bosilca <[email protected]>
This allows to check if the data can be send and received directly to and from GPU buffers. Signed-off-by: George Bosilca <[email protected]>
This is a multi-part patch that allows the CPU to prepare a data copy mapped onto a device. 1. The first question is how is such a device selected ? The allocation of such a copy happen way before the scheduler is invoked for a task, in fact before the task is even ready. Thus, we need to decide on the location of this copy only based on some static information, such as the task affinity. Therefore, this approach only works for owner-compute type of tasks, where the task will be executed on the device that owns the data used for the task affinity. 2. Pass the correct data copy across the entire system, instead of falling back to data copy of the device 0 (CPU memory) Add a configure option to enable GPU-aware communications. Signed-off-by: George Bosilca <[email protected]>
Name the data_t allocated for temporaries allowing developers to track them through the execution. Add the keys to all outputs (tasks and copies). Signed-off-by: George Bosilca <[email protected]>
Signed-off-by: George Bosilca <[email protected]>
copy if we are passed-in a GPU copy, and we need to retain/release the copies that we are swapping
eb5c782
to
3e0cb38
Compare
…ut-only flows, for which checking if they are control flows segfaults
I think we need to create a CI test that targets gpu_nvidia and issues the job to that runner, correct? |
Failure in
Potential fix is to allocate a dev0copy like is done for the network received tiles, not sure why it doesn't already. |
Add support for sending and receiving the data directly from and to devices. There are few caveats (noted on the commit log).
The allocation of such a copy happen way before the scheduler is invoked
for a task, in fact before the task is even ready. Thus, we need to
decide on the location of this copy only based on some static
information, such as the task affinity. Therefore, this approach only
works for owner-compute type of tasks, where the task will be executed
on the device that owns the data used for the task affinity.
falling back to data copy of the device 0 (CPU memory)
TODOs
scheduling.c:157: int __parsec_execute(parsec_execution_stream_t *, parsec_task_t *): Assertion NULL != copy->original && NULL != copy->original->device_copies[0]'
device_gpu.c:2470: int parsec_device_kernel_epilog(parsec_device_gpu_module_t *, parsec_gpu_task_t *): Assertion PARSEC_DATA_STATUS_UNDER _TRANSFER == cpu_copy->data_transfer_status' failed.