global memory and texture memory conversion

Assume there are three kernel functios executing in serial, K1, K2 and K3.
If d_A is declared as a linear region in global memory before lauching K1, and K1 writes to K2. Can d_A be binded to texture and accessed in texture mode in K2(read only), and unbinded before K3 launched, then writable in K3?
If not, can any memcpy series functions realize the above functionality?

I’m kind of confused of such conversion in between linear memory and texture, what’s allowed and what’s not, via using those memcpy functions.


You can bind, then write in K1 read in K2 and write again in K3 all without unbinding. I do this all the time. There are no memcpys required.

But how to write to texture from device?

Well, since you specifically mention binding a location in device memory to a texture, you just write to the device memory. Specifically, this applies to textures bound with cudaBindTexture and read with tex1Dfetch.

If you are using 2D texture on the other hand, you will need to allocate a mirror cudaArray and write to device memory than copy to the array with cudaMemcpyToArray.


I’m still confused how to use ‘mirror cudaArray’… is it real physical memory, or virtual ? And how it also has all the advantage of texture memory while still writable?

Please read the manual. But I will try one last time to explain the same thing again.

There are TWO ways to use textures.

  1. Bind with cudaBindTextureToArray and read with tex2D
    “Array” memory must be allocated. It sits in device memory, but is not writeable except by cudaMemcpyToArray.
    Your options for populating a 2D texture are to 1) Copy data from the host to device. Or 2) Have a second area of device memory allocated with cudaMalloc and copy from it.
    In the 2nd case, you can write to that device memory in a kernel and then update the texture by using cudaMemcpyToArray.

  2. OR, you can bind a 1D texture directly to a device memory pointer with cudaBindTexture. These are read with tex1Dfetch. You can write to the same device pointer the texture is bound to, just be aware that there can be race conditions so threads should not read values that other threads may be writing in the same kernel. If K1 writes to the device memory, then K2 can read the texture without any problems.