Define getindex_field and setindex_field
#2050
Merged
Conversation
This file contains 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
charleskawczynski
requested review from
dennisYatunin,
Sbozzolo and
sriharshakandala
Sbozzolo
approved these changes
Oct 18, 2024
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.
As I was trying to refactor our cuda dss code to use less DataLayouts internals, I realized that DataLayouts currently doesn't have an interface to achieve the same level of parallelism that our dss implementation achieves. So, this PR adds an interface to support this. This PR defines
getindex_fieldandsetindex_field!. These new functions take a universal index and, unlikegetindex(::AbstractData, ::CartesianIndex), uses the field index. This will allow us to write data-agnostic kernels that leverage the universal indexing scheme, while still allowing us to use cuda threads for each field variable.This will allow us to refactor our dss kernels, so that we can close #2048, while not losing our current level of parallelism.