Unfortunately there’s no way to do this currently - you can’t index into an array of texture references. The same restriction exists when using the graphics API.
Why not use cuTexRefCreate ? Then you should be able to get pointers to texture references which you can keep in an array. You can then bind cudaArrays to them as needed.
I haven’t tried this myself, but it seems like it would work. I do something similar in brook all the time.
But, the binding will still need to be done on the host using cuTexRefSetArray(). You can’t do it in the kernel.
Also, note that you can’t mix runtime API calls with driver API calls, in general.
You can also define arrays of texture references using the runtime API through its low-level component (based on struct textureReference). You’d use cudaBindTextureToArray() to bind a CUDA array to a texture reference (see Section B.3.1.4 of the new version of the programming guide (http://developer.download.nvidia.com/compu…Guide_0.8.1.pdf)).
Do you have to have different textures? Why can’t you pack the different textures into one really big texture and then do some additional indexing to figure out where in the big texture you actually want to look?
I would like to do this, but there’s one problem. How would the resulting array of textureReferences be used to to texture fetches? The texfetch() overloads all take a texture as the first argument. Grepping the headers shows there isn’t any texture fetch call that takes a textureReference.
Well, there’s more than one problem, but that’s the first I see. The second problem I see is I can’t pass the array of textureReferences to a kernel because the array variable is a pointer to the array in host memory.
If I keep praying, maybe 3D textures or DX10 texture arrays will make it into CUDA 1.0.