Texture as class member


I have an issue with the texture references because they can only be declared static at file scope according to the doc

So, is there any trick to have a texture as a class member ?

Thank you !


No idea ? :(

It is such a limitation, don’t you think ? Or am I totally wrong ?

Thank you.

Ok, it seems to be impossible…

In the driver API, there is “cuTexRefCreate”, but the function is “deprecated”

It seems there is no solution… and it’s quite sad, because it is a huge limitation !

A workaround would be to bind/unbind textures each time we use them…
… or to implement a TextureManager class, with a thousand texture<> declared at file scope, hoping the user will not try to allocate more than 1000 classes :/

Any suggestion ?

The binding/unbinding approach already appears sufficient to me. If for you it’s not the case, then just create a larger texture array and store your textures inside. As for the class member, you can store the integer index into the texture array in the class to indicate the starting position of your small texture.

Thank you for your answer.

About the bind/unbind thing, I wonder if it has an impact on caching performance ?

I mean :

while(...) {




while(...) {



Will the bind/unbind solution produce more cache misses ?

I’m not sure if the texture cache is preserved between calls even if you don’t rebind the texture. However, the size of the texture cache is between 6 and 8 kB per multiprocessor, so the cost of flushing it between kernels is negligible, unless your kernels are extremely short.

Used in conjunction with a pool to control resources, it’s possible to come up with a fancy solution using function pointers to bind/unbind/access the textures.

I’ve used this technique to create classes that look like:

Texture A_tex( a_data );
Texture B_tex( b_data );

Textures are bound/unbound on construction/destruction, can be used as kernel parameters, and even accessed with .

Unfortunately this is part of a closed source project, but it is doable with some voodoo :)

Thank you very much,

What freaks me is that in a multithreaded application, the solutions may become quite ugly to maintain…!

Even if it’s not my concern, I don’t get why CUDA is so restrictive when dealing with textures.
Dealing with textures in OpenGL/GLSL doesn’t make me crazy like that :D
I’m not qualified enough to pretend that texture management is badly designed in CUDA, but this what I think :(

Anyway, thanks for sharing your ideas, it’s really helpful!

Forget what I said about OpenGL, since we are constantly binding and unbinding textures, and dealing with a fixed number of texture units!

Then, I’ll go for bind()/unbind(). Thanks again!

PS: what happened to cuTexRefCreate ? :)