x, y, z removed from C++ AMP

In the Visual Studio Developer Preview release of C++ AMP several core classes (e.g., extent, array, array_view) exposed members named x, y and z and get_x() , get_y() and get_z() . All such fields/properties/member functions have been removed in the Beta release, leaving as the only option to achieve the same results usage of the subscript operator.

Details and rationale

In C++ AMP, when talking about an index space identified by an N dimensional extent (i.e., extent<N>), the dimensions are ordered from 0 to N-1, where dimension 0 is the most significant dimension and dimension N-1 is the least significant.

The question of significance arises in the context of locality. Referencing an array with two indices which differ only by one unit in the least significant dimension results in adjacent memory references. Similarly, two threads whose ID’s only differ by one unit in the least significant dimension will typically execute close-by to each other.

Any C++ AMP function which takes dimensional data as a list of arguments, accepts them to be specified from most significant to less significant. For example, consider this specialized constructor of extent<3>:

extent(int _I0, int _I1, int _I2) restrict(cpu,amp);

To access _I0, you would write myExtent[0] . In the Developer Preview release, we provided the shortcuts z, y and x to mean: dimension 0, dimension 1 and dimension 2, respectively. In the case of 2 dimensions, y meant dimension 0 and x meant dimension 1. And finally for the case of a single dimension, x meant dimension 0. So for example, for an extent<3> instance, instead of writing myExtent[0] , you could have also written myExtent.z.

We have received ample feedback that the x, y, z syntax is counter-productive, and therefore decided to drop it. There were three specific objections:

1. The syntax appeared too domain specific (graphics and physics) to be included in the core classes, e.g. it didn’t make sense for financial workloads.
2. For graphics, the order of specification of dimensions (z,y,x) was opposite of what users of shader languages such as HLSL and OpenGL are used to.
3. Some found counterintuitive the fact that the order z,y,x was contrary to the alphabetical order.

How to update your code

If you have been following our C++ AMP samples, and following our lead, you will have noticed that none of them used x, y, z so perhaps none of your code needs updating.

For the rest of the code out there, in the table below I’ve captured in detail how this change affects Developer Preview based code, vs. Beta code.

Class	Developer Preview Syntax	Beta Syntax
index<1>	myIndex.x	myIndex[0]
index<2>	myIndex.ymyIndex.x	myIndex[0]myIndex[1]
index<N> for N >= 3	myIndex.z myIndex.ymyIndex.x	myIndex[0]myIndex[1]myIndex[2]
extent<N> for N >= 1	Same as class index
grid<N>	Class grid<N> has been removed. Use extent<N> instead
array<1>	myArray.x	myArray.extent[0]
array<2>	myArray.ymyArray.x	myArray.extent[0]myArray.extent[1]
array<3>	myArray.zmyArray.ymyArray.x	myArray.extent[0]myArray.extent[1]myArray.extent[2]
array_view<N> for N >= 1	Same as class array
tiled_index<D0>	tiled_index<D0>::tile_x	tiled_indx<D0>::tile_dim0
tiled_index<D0,D1>	tiled_index<D0,D1>::tile_ytiled_index<D0,D1>::tile_x	tiled_indx<D0,D1>::tile_dim0tiled_indx<D0,D1>::tile_dim1
tiled_index<D0,D1,D2>	tiled_index<D0,D1,D2>::tile_z tiled_index<D0,D1,D2>::tile_ytiled_index<D0,D1,D2>::tile_x	tiled_indx<D0,D1,D2>::tile_dim0tiled_indx<D0,D1,D2>::tile_dim1tiled_indx<D0,D1,D2>::tile_dim2

 

We hope you’ll agree that this change is for the better and the modifications necessary to your code are straight forward.

Short vector types

In the Beta release we are adding short-vector-types which do have the x, y, z notation familiar to HLSL and OpenGL programmers. These classes are available in the concurrency::graphics namespace and therefore are targeted at graphics programmer and adhere to the conventions used in that domain.