add multi-GPU Jacobi iteration - #545
Draft
NIne-WIngEd wants to merge 1 commit into
Draft
Conversation
Author
|
Hi! I opened this as a draft so I can validate the implementation on the Iris AMD GPU CI before marking it ready for review. |
Collaborator
|
Thanks @NIne-WIngEd! CI is down at the moment but should be back up soon. Early next week if not sooner. Will approve the CI run then. Thanks! |
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
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.
Motivation
This PR adds the multi-GPU Jacobi example requested in #117.
The original reference runs the full grid on one GPU.
This version splits the interior rows across multiple GPUs.
Each GPU works on its own rows.
Iris is used to move the edge values between neighboring GPUs.
Closes #117
Technical Details
The grid is split by rows across all ranks.
Each rank keeps one halo row above its owned rows and one halo row below them.
Those halo rows hold the newest edge values from the neighboring ranks.
This lets the normal Jacobi four-neighbor update keep working at GPU boundaries.
The Jacobi update itself runs in a Triton kernel.
A second Triton kernel handles halo exchange.
It uses
DeviceContext.store()to write the first and last owned rows into the neighboring rank halo space.After each iteration the local residual is reduced across all ranks with Iris CCL
all_reduce.This gives every rank the same convergence value.
That also makes every rank stop on the same iteration.
The row split also supports uneven grid sizes.
Early ranks take one extra row when the interior rows do not divide evenly.
I also added
tests/examples/test_jacobi.py.The test runs the same distributed path on a small uneven grid.
It gathers the distributed result and compares it against a plain PyTorch Jacobi reference.
Test Plan
Local checks:
ruff formatruff checkgit diff --checkGPU validation still needs to run on ROCm hardware.
This PR is opened as a draft so the Iris AMD GPU CI can run the real distributed tests.
I plan to verify the example and test with 2 ranks first.
Then I will verify 4 ranks and 8 ranks.
Test Result
Local static checks pass.
The implementation and test both compile successfully.
Ruff passes.
The working tree is clean before the PR.
Real multi-GPU execution is pending Iris CI because my local machine does not have an AMD ROCm GPU.
Submission Checklist