Proposal: add .x(), .y(), ... accessors to alpaka::Vec

[fwyzard]

As we gain more experience rewriting CUDA code and porting it to Alpaka, one of the aspects that people are struggling a lot with is the use of OpenCL-like indices for accessing alpaka::Vec variables, when they are used for the work division, execution index, etc.

For 1 dimensional kernel things are easy

dim3 id = ...;
f(id.x);

maps to

Vec<DimInt<1u>, float> id = ...'
f(id[0]);

For a 2 dimensional kernel things are already complicated:

dim3 id = ...;
f(id.x, id.y);

maps to

Vec<DimInt<2u>, float> id = ...'
f(id[1], id[0]);

The problem is not so much that .x, .y map to [1], [0]...

The biggest problem is that .x maps to [N-1], .y maps to [N-2], etc.
This means that .x maps to [0] in a 1-dimensional kernel, but .x maps to [1] in a 2-Dimensional kernel, etc. - which is very confusing for users, when they mix 1D and 2D kernels.

Even though we briefly entertained the possibility, it's clear that we cannot change the ordering of the indices used in Alpaka, as it would break all existing code.

But we could add a more familiar syntax to Vec variables: .x(), .y(), .z() accessors.

Vec<DimInt<1u>, float> id = ...'
f(id.x());

Vec<DimInt<2u>, float> id = ...'
f(id.x(), id.y());

We should be able to use SFINAE or partial specialisation to make .x() available only when N > 0, .y() available only when N > 1, etc.

What do you think ?

[psychocoderHPC]

I agree that the indexing model alpaka is using is complicated for codes coming from CUDA. We have the same issue with PIConGPU which can be used for 2D and 3D.

[psychocoderHPC]

@fwyzard #2201 provides the named access to the vector data.

The biggest problem is that .x maps to [N-1], .y maps to [N-2], etc.

This is currently not solved. Maybe we should add a method s(idx),at(idx) which is reverting the index order and internally map the access of these method to the alpaka element order.