Linear Interpolation for floats

Hi

I’m using OpenCL with MacOS right now (but my target is Windows with Nvidia and ATI).
I would like to use the Texture-Cache and Hardware-Linear-Interpolation to gain Performance.
Sadly the Current OpenCL-Standard is telling me, that the result of a sampler on a floating-point image
with linear-interpolation is undefined in OpenCL 1.0. I tried it with my Mac and it really isn’t working.
Does anyone know if this works on Nvidia or ATI and if this becomes part of the Standard? As far as
I know Cuda is already capable of this…

Thanks in advance!

The spec is not saying that the result of a sampler on a floating-point image with linear interpolation is undefined. The spec is saying that the relative error of the computations that the HW uses to perform linear interpolation is undefined. For most cases, the relative error should not be a major problem. The issue, however, is that there is no clear way to define relative error that can be used to verify the accuracy of linear interpolation across all GPUs.

Can you clarify what you mean by it isn’t working? Can you provide a test example that shows the problem?

Here is the part of the standard I’m referring to:

2D and 3D images created with an image_channel_data_type value of CL_FLOAT or
CL_HALF_FLOAT can only be used with samplers that use a filter mode of
CL_FILTER_NEAREST. The values returned by read_imagef and read_imageh for 2D
and 3D images if image_channel_data_type value is CL_FLOAT or CL_HALF_FLOAT
and sampler with filter_mode = CL_FILTER_LINEAR are undefined.

To me that sounds like it doesn’t work.
I’m away from my Computer so I can’t post any Code right now, but I can do that later if necessary.

The text you are referring to is found in section 10, item 3. This is a restriction for GPUs implementing the OpenCL ES i.e. embedded profile not desktop GPUs. On desktop GPUs, 2D & 3D images with image_channel_data_type values of CL_FLOAT and CL_HALF_FLOAT are supported. In fact they are required - refer to tables 5.6 and 5.7 in the 1.0 specification.

Oh thanks, I didn’t realize this. I found this passage via textsearch and wasn’t looking for the heading!
But in my Testcode it really wasn’t working with linear and it worked fine with nearest neighbor. I will figure this out tomorrow…

So, I tried one last thing for today and ran my code with CL_FILTER_NEAREST (while using an int2 in imagef as coordinates and doing my own interpolation). Everything worked fine. After that I switched to CL_FILTER_LINEAR (and changed nothing else, so there was really no interpolation necessary) and it didn’t work anymore.
I have to switch to an easier example tomorrow so I can really see in detail what is going wrong.

One last question: I’m using a CL_RGBA-Texture right now, because my System is telling me, that I can’t use CL_R or CL_INTENSITY with CL_FLOAT (which would be the type of texture I really need). I’m simply putting my value for every pixel in all three color-channels and 1.0 in the alpha-Channel. Is the Interpolator doing something fancy that I’m not thinking about and this is the real origin of my Problems?

Thanks again for your time!

Is it possible for you to post a test example that shows this problem?

I have found my mistake(s).
After you told me it had to work I sat down and read through the standard carefully (with headings this time :wink: )!
The first thing I got wrong was CL_ADDRESS_REPEAT combined with CL_NORMALIZED_COORDS_FALSE which doesn’t work. I changed this to CL_ADDRESS_CLAMP_TO_EDGE. It got a little bit better, but the error still was really bad. So I stripped down my Code to the bare minimum to reproduce the problem and show it to you. After playing a little bit with this version I realized, that the second problem I had was the 0.5 offset in Pixel-Addressing in OpenCL. So after adding 0.5 to my coordinates everything worked fine.
What really annoys me in this context is that I should have known this from my experience with OpenGL. I even tried CL_ADDRESS_CLAMP_TO_EDGE earlier but there was still this huge error and I couldn’t imagine that this little offset would cause such an error…

Thank you very much again for helping me out on this one!