Thank you! Your suggestion led me in the right direction.
As a side note, it boggles me why any data structure (e.g. texture reference) is restricted to file scope.
I don’t see why a texture reference cannot be passed as a function argument. Bad language design, imho.
Maybe because a texture reference isn’t a data structure. The way it has been exposed in CUDA makes it look/behave somewhat like one, but it isn’t. It is much closer to another type of kernel than a data structure.
Thanks for your help. Moving the texture declaration to file scope certainly helped, but now I have a new problem.
How do I make the texture visible across files? For instance one file has host code which initializes and binds the texture.
The device code is on a separated file. How to get around this??
The way that the SimpleTexture example in the SDK does it (I think) is by using an include statement to include the .cu file with the device code.
When I try that, I get a whole bunch of compiler errors that functions in the device code file have already been defined! The include statement leads to double-compiling in my case.
Personally i used a cudaShared.cu with all my texture declarations, structure definitions, const int’s and so on so forth.
All you have to do is #include it from every file.
You also have to NOT include the file during the compilation.
In visual studio: right click the file and set “exclude from build” to yes.
Thanks. This gets rid of compiler errors, but now I get runtime texture memory access errors.
How does this work for you, and not for me?? I include my “cudaShared.cu” in both files, and excluded it from build.
In emudebug mode the filter mode of my texture is seen to be cudaFilterModePoint inside the device code kernel, whereas I specifically set it to cudaFilterModeLinear in the other file. This is a clear indication that the texture is not bound as far is the device code file is concerned.
Thanks for the suggestion Ailleur. It does not work for me however. the texture becomes bound bound incorrectly, and the texture access fails.
The correct solution (at least for me) is the one posted by avidday here.
I have a multi-threaded app that calls a kernel in each thread that processes different image data however the same kernel is used. I bind a texture to a cudaArray so that I can call tex2D(). Right now each thread binds a different pointer to a cudaArray to the same texture<float,2> reference. Don’t I need a texture reference for each thread so as to not have a conflict? The declaration of a texture at file scope is hindering me from havind a texture for each thread. Otherwise I can declare 4 different textures but I would need to duplicate my kernel code so that one uses tex1 and the other uses tex2 and so on. I don’t know how the texture references are implemented to know whether or not a conflict is happening.