Introduce accelerator tags

[j-stephan]

In today's meeting @psychocoderHPC brought up the idea of having special Accelerator tags that are always visible - the backends that are actually activated do not matter. This enables the user to easier specialize traits for accelerators without having to guard them with #ifdef.

We would like to implement this for alpaka 0.7.0. Due to time constraints this has been marked as an optional feature.

[j-stephan]

I think this may also be related to #966.

[bernhardmgruber]

I would like to add my proposition during the last alpaka VC, that we should just declare all backend accelerator templates upfront. This way, users can specialize their traits based on the incomplete accelerator types and no extra tag types are needed. This has the drawback, that we cannot refer to members of incomplete accelerators. Still, I would like this solution to be explored.

Another solution would be a global enum of all accelerators. Each accelerator has a getter for his enumerator and traits on the user side are specialized on these enumerators.

[sbastrakov]

I think tag types are almost always same or better than enum for these purposes. Tags can be added from anywhere, including user code, while enum is one and centralized.

[psychocoderHPC]

Another solution would be a global enum of all accelerators. Each accelerator has a getter for his enumerator and traits on the user side are specialized on these enumerators.

What @sbastrakov said. Enums can not be extended from the user code.

I try to write a draft with my thoughts, soon.

[frobnitzem]

Is this related to the enumeration of accelerator types in:

alpaka/example/vectorAdd/src/vectorAdd.cpp

Line 85 in 8eea243

// - AccGpuCudaRt

As a new alpaka user, I'm held up by the difficulty of storing auto const devAcc = alpaka::getDevByIdx<Acc>(0u); in my own classes. All the alpaka documentation creates this this as "const auto". How do I name it's storage type (const alpaka::DevUniformCudaHipRt) when declaring classes meant to be specialized to one device? Maybe I should just template it.

[sbastrakov]

Yes, it's sometimes awkward due to alpaka operating with conditionally defined accelerator types, e.g. AccGpuCudaRt<...> being defined when cuda was configured to be used and found. These types (or types depending on them) are propagated basically everywhere as template parameters. Unconditionally defined tags would make it more simple and less ifdef-guardy.

In user code we normally make corresponding template parameters. Those could in principle mirror alpaka examples e.g. take Acc type and derive the rest from there. Of course it's also possible to start from another level, like Dev or Queue type.

If you just want to specialize kernel code, perhaps you mean for accelerator, not device in alpaka speech? There is a recent example added on it #1271. If you meant something else, please clarify

Edit: fixed typos, fat fingers