Texture References and Asynchronous Kernel Calls


Let’s say I have a CUDA module declaring a texture reference and a kernel using this reference. I initialize the texture reference (using cuTexRefSetAddress, cuTexRefSetArray or similar) and launch the kernel. Am I now allowed to modify this texture reference (while the first kernel may still be executing, or maybe even still is waiting to launch), launch the same kernel again (possibly in another stream), and rely on that the first kernel launch is going to use the texture reference as it was first initialized? I guess it would require that the state of the texture reference is somehow queued up with the rest of the kernel launch parameters at the time you launch a kernel?

This seems to work as expected, but maybe I just happen to be lucky… Can anyone verify that it’s OK to modify a texture reference used by a kernel just after the kernel has been launched (or, rather queued up to be launched).


I seem to be “lucky” aswell, at least if you interpretate the manual.
I have 4 streams with async cudarray/memcopies and re-bind my only texture reference before I launch (queue up) the corresponding kernel to each stream.
It does seems to be a kernel-specific texture state in each stream, which contradicts to the text about textures in the manual which states that previous
texture bindings becomes unbinded…(implies only one global texture state)