Hello,
I've noticed a bug with the read_imagef function (and possibly other overloads) when operating on 2D image arrays when using floating-point coordinates. The third coordinate, which represents the index of the 2D image to sample, is being normalized to 0..1, such that a coordinate of 0 samples the first image, and a coordinate of 1 samples the last image. The behaviour I expected is for the last coordinate to be rounded to an integer, such that 0..0.5 corresponds to the first image, 0.5..1.5 corresponds to the second image, and so on. The Intel OpenCL runtime exhibits this behaviour, so at least one of the two runtimes is broken with respect to that function, and I believe the AMD runtime to be in error.
The relevant parts of the specification are 8.4 and 6.12.14.2. They still don't really say whether the third component is expected to be normalized when using floating-point coordinates, but I suspect it is not meant to, because otherwise there would be little difference between 2D image arrays and 3D images; furthermore, it makes little sense to address an image array using a normalized layer index, since that would suggest the number of images in the array is not important in the sense that they could be interpolated, which is clearly not the case as layers are to be independent of one another.
I didn't find a bug tracker so I'm posting this here, apologies if it is the wrong place.
