l_khr_extended_async_copies cannot deal with arbitary strides.

Both async_work_group_copy_2D2D and async_work_group_copy_3D3D measure both num_elements_per_line and [src/dst]_total_line_length in terms of element.

This means the data length and the strides when measured in bytes must be a multiple of the num_bytes_per_element.

For the data length this natural and it is difficult to see how it could not be true. But for stride it can easily be true.

Take for example an element size of 3, that needs to be aligned on 8 byte boundaries. If the data length is 3 (9 bytes) then a stride of 16 (16 - 9 = 7) cannot be expressed in elements. One would need to make the stride 24 (24 - 9 = 15) = 5 elements.

So it can be expressed - wastefully - but often the input data is already on a stride.

The net effect if the people just convert everything into bytes, think in bytes (even for the power of 2 cases).

Stride would much more naturally be expressed in bytes - it is simple the distance between row starts.

Everything relating to line length must apply to plane area as well.

Start with the definitions of async_work_group_copy_2D2D and async_work_group_copy_3D3D in the l_khr_extended_async_copies documentation. Compare the element-based line and plane measurements with the issue’s byte-stride example; done means the specification supports arbitrary byte strides and applies the same interpretation to plane area.

Written by the indexing model from the issue text.