-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add tags for each alpaka accelerator #1781
Conversation
example how to get the real acc type out of the tag used in a trait template<typename T_Acc>
struct GetDefaultStrategy<T_Acc, std::enable_if_t<alpaka::concepts::ImplementsConcept<alpaka::ConceptAccHip, T_Acc>::value>>
{
// this will provide alpaka::AccGpuUniformCudaHipRt<alpaka::ApiHipRt, DimType, IdxType>
using realAccType = typename concepts::ImplementationBase<alpaka::ConceptAccHip, T_Acc>;
}; |
- Provide a file `alpaka/acc/Tags.hpp` with tags for each alpaka accelerator. - Add a concept to unique identify each accelerator with a acc concept tag.
034655a
to
3ef31a1
Compare
@psychocoderHPC does it mean that all possible accelerator tags will always be defined, even if the corresponding accelerators and backends are not available ? |
I am not sure the accelerator tags should be provided via the concepts mechanism, since they are not concepts in the C++ sense. E.g. the CUDA and OMP2 accelerator concepts impose the same syntactic requirements. In other words, we cannot turn these into C++20 concepts at some point. Since tags and accelerators are bijective, I also miss type functions to map between them: using Tag = alpaka::TagFor<Acc>;
using Acc = alpaka::AccFor<Tag, Dim, Idx>; Checking whether a type Or multiple: |
This is my understanding. |
In my draft, the tags will always be available and this tag can be used to check what type a "anonymous" accelerator is. |
Yes a separate trait is possible too. At the end I like to converge to the suggestion #944 that we can use the tags to write simple interfaces to allocate devices too (note: I am aware that my simple example in the issue is mixing devices and accelerators) constexpr size_t dim = 1;
auto numDevices = simple:acc::count(simple::acc::GpuCuda); This draft is a discussion base and I am open to move into all direction to find a useful and practical solution to avoid |
After a offline discussion, I recognized it is not useful because it only works, if the the function contains generic code and nothing acc specific, like CUDA built in functions in a kernel specialized for the CUDA acc. |
I already implemented the |
I implemented a prototype of acc tags in vinkuja: alpaka-group/vikunja@565823f I used vikunja, because I have a use case for the acc tags and also for memory visibility tags (see this issue: #1362). I want to use both to improve the API of vikunja. Now, my plan is to integrate the prototype for acc tags (and memory visibility later) in alpaka to make it available for all alpaka users. |
tags are implemented in PR #1804 |
We discussed today again in the alpaka meeting that it would be nice to have accelerator tags #1246 so that there is no need to use
#ifdef
to write traits for accelerators.I had some free minutes and therefore drafted this PR.
alpaka/acc/Tags.hpp
with tags for each alpaka accelerator.tag.
PIConGPU example to show the possible effect of the tag.
Code snipped without tags.
will be changed to without
#ifdef
CC-ing: @SimeonEhrig