Then after I bind it to the appropriate memory, I use it inside a kernel to access the texture:
float4 value = tex1Dfetch(texRef, x);
Even a brief examination shows that something bizarre is going on here. texRef is declared without any modifiers; that is, it exists in host memory. Yet there I am referring to it inside a kernel! That can’t possibly work, and yet it does. It seems that texRef is two different symbols at once, one in host memory and one in device memory, and nvcc is doing something behind the scenes to make it look like a single variable. What is really going on here?
The reason I need to understand is that I’m writing multithreaded code. Two different threads might be executing the same kernel at the same time, but with different textures. It seems that when one thread calls cudaBindTexture() to bind a texture to the reference, that will mess up the other thread. What is the correct way of handling this?
Yes, it is confusing. Behind the scenes, the texture reference is really just an index into some settings stored on the GPU per texture. nvcc does the magic to make host code change those settings when you bind, change options, etc…
Actually, you don’t have to worry at all in multithreaded code. Think of the texture reference (along with constant memory and device memory) as having automatic thread local storage. What is really going on under the hood is that the texture references are stored per CUDA context and each of your host threads has a different context.