Add gpu policies that do not check loop bounds #1778
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
Use a macro to generate the various aliases
This iteration mapping assumes that the number of iterations is the same as the size of the range and does no checking. This is useful when mapping gpu blocks as we often launch the exact number we need and don't need to check if we are in range. This can give ~5% speedup vs direct in this case.
There were a number missing for cuda/hip
This adds testing for unchecked policies with cuda and hip in kernel and launch.
|
I think this is an important PR to get in, I've talked to a few users who could benefit from this capability. |
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.
GPU Policies that don't check loop bounds
This is useful when using the block indices as the bounds are used when launching the kernel and do not need to be checked in the kernel.
This helps performance up to about 5% in some simple kernels and gets us to performance parity with the base variants in some RAJAPerf Kernels.
Regarding naming, I'm not sure that "unchecked" is the best. In some sense this is a "direct" policy, maybe something like "direct_unchecked" would be easier to understand?
These policies may not be safe to use with kernel, see #1733.
Design review (for API changes or additions---delete if unneeded)
On (date), we reviewed this PR. We discussed the design ideas:
This PR implements 1. and 3. It leaves out 2. for the following reasons