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 220.127.116.11. 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.
thanks for the information and we have not noticed this yet. Will check and get back to you. Please be patient till then
Meanwhile if you get any other information please share here.
Thanks for your patience . For better understanding of the current scenerio , could you please give to us with more details like OS type , amd driver version , Graphics card type . Kindly send us the sample code also .
Thanks in advance ,