An array of texture references?

I am ‘extremely’ new to CUDA. Would it be possible for you to share your bi- (tri-) linear interpolation code for CUDA… or direct me to some web/ book/ resources for interpolation.

The programming guide has been somewhat unclear in terms of floating point interpolations.

Thanks,

kpg

As I mentioned, I use the texture unit to get bilinear interpolation - just use cudaFilterModeLinear on a 2D float texture. I haven’t written explicit bi- or trilinear interpolation code in CUDA.

Wikipedia has a decent (but short) description on it:

[url=“Bilinear interpolation - Wikipedia”]http://en.wikipedia.org/wiki/Bilinear_interpolation[/url]

I know this topic is a little old, but I definitely wouldn’t mind having a go with this too…

I do not mind that.

But I hope that the texture or the cuda array is writable.

Writable textures? I don’t think you’ll see that any time soon, textures are optimised for reading and should be. If you need to write, you can just as well use normal linear memory, as the cache will only get in the way.

  1. You can “write” to a cudaArray texture by writing to a global memory pointer, then doing a fast device memcpy to update the cudaArray. The time for the copy is tiny, but for large textures the memory cost of the double buffer might be annoying.

  2. If you are using 1d textures bound to linear memory, you can write back to that same memory without any overhead or penalty.

I think that’s fine as long as you don’t read location you’re also writing in the same kernel invocation, otherwise the cache might go funny on you.

Please consider the following loop

while(true)

{

1) start kernel1 which reads a 2D or 3D texture

2) start kernel2 which updates the 2D or 3D texture, or the cuda array

}

Of course, no problem with texture cache. And the kernel1 is benifit from the bilnear or trilinear interpolation of 2D or 3D texture.

If the cuda array is writable as global pointer, no extra buffer is need for 2).

This is necessary for some iterative algorithm.

Any good idea for it?

Two choices:

  1. Don’t use textures. You’ll lost the texture cache benefit, but if your access pattern is predictable you can generally come up with an algorithm that coalesces reads

  2. Use textures to read the data from, write to a global memory array. After your kernel, use a (fast!) device to device call to copy the memory to the texture.

It depends on the specific case which one is best.

Can I belatedly join this thread to says that 3D textures is a feature I would really like to see added to cuda, and if it comes without emulation, so be it.

Alec

Whoops - Duplicate. Sorry