How to deal with index dimensions in alpaka?

[makortel]

In #141 it was noticed that 1D and 2D (and 3D) indices imply duplication of accelerator, device, and platform types. It would be good to think if that could be simplified somehow.

[makortel]

@fwyzard commented in #141 (comment)

This is a long standing issue with Alpaka: the number of dimensions ends up giving different accelerators, which (IIRC) in turn require having different devices, etc.

I tried discussing this with the Alpaka team but without much luck :-(

We could just give up on it for the time being, and just use 3-dimensional indices all the time ?
At least under the hood (like CUDA and oneAPI do in practice) and assume that people will use the right number of indices when writing/calling kernels ?

[makortel]

We could just give up on it for the time being, and just use 3-dimensional indices all the time ?

I think this could be a worthwhile attempt, perhaps even before moving beyond alpakatest.

[ghugo83]

We could just give up on it for the time being, and just use 3-dimensional indices all the time ?
At least under the hood (like CUDA and oneAPI do in practice) and assume that people will use the right number of indices when writing/calling kernels ?

Ok have tried this out.
Can have one type of platform only, with Dim3, indeed.

Here for example, only the type of platform with Dim2 was used anyway:
https://github.com/cms-patatrack/pixeltrack-standalone/blob/master/src/alpakatest/plugin-Test1/alpaka/alpakaAlgo1.cc#L247
And then kernels with 1D or 2D workdivs are called:

• 1D: https://github.com/cms-patatrack/pixeltrack-standalone/blob/master/src/alpakatest/plugin-Test1/alpaka/alpakaAlgo1.cc#L336
• 2D: https://github.com/cms-patatrack/pixeltrack-standalone/blob/master/src/alpakatest/plugin-Test1/alpaka/alpakaAlgo1.cc#L247

An issue is that when the work division is 1D, it can only be associated with Acc1 (not Acc3).
So it seems that the Acc types need to be duplicated anyway?

This works: ghugo83@eff39ec
But it only removes the duplication of device and platform types, not of accelerator types.

[makortel]

Thinking a bit further after staring #160 for a while made me realize that a Queue constructor requiring a DevAcc, a DevAcc depending on Acc, and Acc depending on Dim makes it hard to support passing a single Queue from one module to another in an Event product if we try to support many Dim types (unless it would be ok to construct a Queue with one device, and then queue operations that use otherwise the same device except for the dimensions).

[makortel]

(unless it would be ok to construct a Queue with one device, and then queue operations that use otherwise the same device except for the dimensions)

Actually alpakatest/plugin-Test1/alpaka/alpakaAlgo1.cc does exactly that constructs the queue with device with "2 dimensions" and enqueues kernels with both Acc2 and Acc1. So maybe that works in practice.

[ghugo83]

Actually alpakatest/plugin-Test1/alpaka/alpakaAlgo1.cc does exactly that constructs the queue with device with "2 dimensions" and enqueues kernels with both Acc2 and Acc1. So maybe that works in practice.

Yes exactly, actually we could maybe just have a Dim3 device and then enqueue kernels with the desired dimension. It definitely worked in alpakaAlgo1 for one type of device and queue (only the Workdiv (makes sense) and Acc (~ makes sense) would keep on being 1D versus 2D versus 3D dependent on a call case basis).