gpu-direct: make it optional and have fallback solution with device-host explicit transfers#389
Draft
svalat wants to merge 17 commits into
Draft
gpu-direct: make it optional and have fallback solution with device-host explicit transfers#389svalat wants to merge 17 commits into
svalat wants to merge 17 commits into
Conversation
…e IdefixCommArrayXD<> to handle the no gpu-direct transfers.
…ginal function names
…h idefix::MPI_ API.
…ers all time for validation purpose
…nd a solution for the NO GPU DIRECT case
… solve the Axis issue
svalat
marked this pull request as draft
July 10, 2026 15:21
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.
Handle when there is no-gpu-direct
The patch mostly wrap the MPI interface to make the transfers manually between the host & device when GPU direct is not available.
In order to avoid allocating an host buffer for every transfers, the
IdefixArrayXDclasses has been extended asIdefixCommArrayXDwhich contains the standard array on device, and optionally (if GPU direct is disabled and if running on GPU) a host buffer to make the communications.In order to apply in the code, all the MPI communication calls (
MPI_Send,MPI_Recv,MPI_Start....) need to be replaced by theidefix::MPI_*corresponding frunctions which expect anIdefixCommArrayas parameter.It means that we should not continue to use
.data()to feed the MPI calls (the compiler will complain for theidefix::MPI_*functions).When the wrapper is called it ensure to sync the communication buffer in & out during the communication process so it is transparent for the calling code.
One care
You should not use directly the
IdefixCommArrayXDin a GPU loop (get a compiler warning in case due to host array in use). This is way the patch uses the.deviceView()to get it casted in a friendly way for the GPU.Note: in case you still keep it that way, it should not be a problem appart the warning in the compilation output because the host array will not be used in the kernel because not accessible (private).
Note: this semantic is only used if we communicate with the buffer, all the rest of the code using standard
IdefixArrayis not concerned.Case of persitent comms
For the persistent comms and async comms, an new
idefix::MPI_Request_XDhas been defined to carry the information on how to sync the communication buffer with its device counter part when required. Again if you useidefix::MPI_*just follow the compiler which will force you to type correctly usingidefix::MPI_Request_XDinstead ofMPI_Request.Validation
To validate, you need to :
Note: Also make a second validation, by playing with the various internal modes of idefix about MPI (persistent, async, sync) => to be sure that all paths are still working (not yet validated).
Issue
I currently pass most of the MPI test except the AsixFluxTube which crash => investigation ongoing.
When having GPU direct
in this case, the
IdefixCommArrayGpuDirectimplementation is used, which is just an empty stub which just does nothing.Questions
MPI_waitallwith multiple comms, I start all the host-device transfers asynchronously and usingKokkos::fence(). I can also avoid it to get simpler code as we have max 2 comms at this location.MPI_*API the same inside theidefix::namespace, we can also name them allMPI_View_to clearly separate the concept. To be discussed what is best.Mpi::CheckConfig()so it uses the copies when not having GPU Direct, is it what we want ?TODO