Make ArrayPartitions of GPU arrays work in DifferentialEquations solvers - #416
Merged
Merged
Conversation
…nd avoids recomputing global indices for each setindex!
Member
This should be fine here.
yes
Possibly some others should get looked at for GPU compatibility. |
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.
Checklist
contributor guidelines, in particular the SciML Style Guide and
COLPRAC.
Additional context
The only function that was preventing ArrayPartitions of GPU arrays to work in DifferentialEquations solvers was
recursivefill!, which was deferring toBase.fill!with scalar indexing. This PR makes fixes two things:recursivefill!callsfill!on each array within theArrayPartitions.xtuple - which now defer to the right GPU kernels.setindex!- which was unnecessary work.Example Code (similar to what was added to the tests):
Possible Issues
unrolled_foreach(f, x::Tuple)implementation for type stability when callingfill!on each subarray in theArrayPartition.xtuple. This now uses a closure forfwhich updates each subarray inline; it is type-stable when checking with Cthulhu, and it does not update any variable outside the closure; I see the SciML guidelines do not recommend closures - should I rewrite that as a struct and all that?recursivefill!forArrayPartitions; all tests seem to work, but I don't have the "bigger picture" of how this is used across the ecosystem - is this okay / non-ambiguous? Should the otherrecursivefill!implementations inutils.jlbe changed?