Add generic device policies #2036
Conversation
|
|
||
| // kernel (For) index mapping | ||
| template<int nx_threads> | ||
| using device_global_size_x_direct = RAJA::cuda_global_size_x_direct<nx_threads>; |
There was a problem hiding this comment.
There are more policies than these. Check out the cuda or hip policy file where there are policies for the cartesian product of things like this.
- (|flatten) x (global|block|thread) x (|size) x (x|y|z|xy|xz|yx|yz|zx|zy|xyz|xzy|yxz|yzx|zxy|zyx) x (direct_unchecked|direct|loop) x (|unchecked)
- (global|block|thread) x (x|y|z|xy|xz|yx|yz|zx|zy|xyz|xzy|yxz|yzx|zxy|zyx) x (syncable_loop)
There was a problem hiding this comment.
Where should we draw the line in terms of providing device generics? I think it would be a little burdensome in terms of boilerplate to have using device_policy = .... for all possible cartesian products of policies.
We could probably automatically emit device generics with a .hpp.in + CMake file configure type interface, which would just cover all the cases in <backend>/policy.hpp, and error out if there isn't a backend specific implementation available. This is probably a bit cleaner and maintainable than manually generating a long list of aliases.
There was a problem hiding this comment.
Also--not sure if we can generate SYCL analogues to all of these cartesian product policies. However we could just leave the policies undefined in the case of SYCL
There was a problem hiding this comment.
I think this pointing out that that SYCL is the forgotten backend, various policies such as unchecked, don't have a SYCL analogue. Is this the right place to introduce them or should we just have them throw an error?
There was a problem hiding this comment.
The robot pointed out we are missing the following:
Missing SYCL policy families
- sycl_exec_async
- sycl_launch_explicit_t
- sycl_exec_grid*
- sycl_exec_occ_*
- sycl_exec_base*
- sycl_exec_with_reduce*
- sycl_work*
- sycl_reduce_tuning
- sycl_multi_reduce_*
- sycl_warp_reduce
- sycl_warp_direct
- sycl_warp_loop
- sycl_warp_masked_direct
- sycl_warp_masked_loop
- all sycl_*_direct_unchecked variants
- all sycl_flatten_* variants
- all sycl_*_nested_* aliases
- the 2D/3D permutation families for sycl_thread_*, sycl_block_*, and sycl_global_*
- the *_size_* variants for thread/block/global families
There was a problem hiding this comment.
I don't think this PR is the right place to add more sycl policies.
There was a problem hiding this comment.
This is why I suggested creating generic versions of all the policies that the current device backend supports. That way we don't have to worry about reconciling the differences yet. Then users can remove ifdefs for the cases that are portable across their use cases at least.
| using device_global_thread_z = RAJA::cuda_global_thread_z; | ||
|
|
||
| // kernel (loop) index mapping | ||
| using device_thread_x_direct = RAJA::cuda_thread_x_direct; |
There was a problem hiding this comment.
Would it make sense to rewrite some examples like launch_flatten using the generic names? It could simplify the examples
|
|
||
| // kernel (For) index mapping | ||
| template<int nx_threads> | ||
| using device_global_size_x_direct = RAJA::cuda_global_size_x_direct<nx_threads>; |
There was a problem hiding this comment.
Where should we draw the line in terms of providing device generics? I think it would be a little burdensome in terms of boilerplate to have using device_policy = .... for all possible cartesian products of policies.
We could probably automatically emit device generics with a .hpp.in + CMake file configure type interface, which would just cover all the cases in <backend>/policy.hpp, and error out if there isn't a backend specific implementation available. This is probably a bit cleaner and maintainable than manually generating a long list of aliases.
|
@artv3 @MrBurmark I pushed a commit containing an automatic CMake based file generation for |
artv3
force-pushed
the
artv3/generic-device-policies
branch
from
1994916 to
d40be98
Compare
|
@llnl/raja-core , I pushed up additional support along with a table listing what we support and don't within device_* -- thank you all for the reviews |
|
@rhornung67 I pushed up a change to the read the docs to adjust for browser width. If you have a chance can you let me know if this works? |
That's great! I like it. 🥇 |
4 participants
Summary
AI generated, but I have reviewed the code and it looks reasonable.
Link to new policy documentation: https://raja.readthedocs.io/en/artv3-generic-device-policies/sphinx/user_guide/feature/policies.html