Multiple streams with each with a different texture
Dear All I have a kernel that uses a texture. But I want to run that kernel in multiple streams. I suppose that I have to have one different texture (and bind in the CPU) for each stream. But in the kernel the name of the texture is hard coded. Have I to repeat the kernel and run one for each stream (with each texture hard coded?)? May I declare an array of textures and use that way in each stream? Someone help on this? Thanks Luis Gonçalves texture<uchar, cudaTextureType2D, cudaReadModeElementType> tex1(false, cudaFilterModePoint, cudaAddressModeClamp);
Dear All

I have a kernel that uses a texture. But I want to run that kernel in multiple streams. I suppose that I have to have one different texture (and bind in the CPU) for each stream. But in the kernel the name of the texture is hard coded. Have I to repeat the kernel and run one for each stream (with each texture hard coded?)? May I declare an array of textures and use that way in each stream?

Someone help on this?

Thanks

Luis Gonçalves
texture<uchar, cudaTextureType2D, cudaReadModeElementType> tex1(false, cudaFilterModePoint, cudaAddressModeClamp);

#1
Posted 02/14/2018 04:43 PM   
You don't bind a texture to either a kernel or a stream. For texture references you bind it to a texture reference. For texture objects you bind it to a texture object. If you want the underlying texture to be separate (i.e. contain different data) for each kernel invocation, then you will need to either bind/unbind appropriately (may not be possible in a concurrency scenario), or use multiple texture references or multiple texture objects. If you are going to use multiple texture objects, you could certainly use an array to hold them. There are samples demonstrating array of texture object usage, if you look for them.
You don't bind a texture to either a kernel or a stream. For texture references you bind it to a texture reference. For texture objects you bind it to a texture object.

If you want the underlying texture to be separate (i.e. contain different data) for each kernel invocation, then you will need to either bind/unbind appropriately (may not be possible in a concurrency scenario), or use multiple texture references or multiple texture objects. If you are going to use multiple texture objects, you could certainly use an array to hold them. There are samples demonstrating array of texture object usage, if you look for them.

#2
Posted 02/14/2018 04:54 PM   
Seems from https://devblogs.nvidia.com/cuda-pro-tip-kepler-texture-objects-improve-performance-and-flexibility/ that with texture references and N kernels for N streams (one texture for each stream hard coded) is faster than using textures objects Some feedback on this, please?
Seems from


https://devblogs.nvidia.com/cuda-pro-tip-kepler-texture-objects-improve-performance-and-flexibility/


that with texture references and N kernels for N streams (one texture for each stream hard coded)

is faster than using textures objects

Some feedback on this, please?

#3
Posted 02/14/2018 05:16 PM   
Not sure how you reached that conclusion from that article. The final graph shows that using bindless textures (i.e. texture objects) is always delivering more GFLOPS for a particular application than using texture references - the red line is at or above the black line in all cases that I see there.
Not sure how you reached that conclusion from that article. The final graph shows that using bindless textures (i.e. texture objects) is always delivering more GFLOPS for a particular application than using texture references - the red line is at or above the black line in all cases that I see there.

#4
Posted 02/14/2018 05:51 PM   
@luisgo: If you are doing anything nontrivial in your kernels, the overhead of texture binding likely will be neglible. I would not mess around with texture reference anymore now that texture objects are around for quite some time.
@luisgo: If you are doing anything nontrivial in your kernels, the overhead of texture binding likely will be neglible. I would not mess around with texture reference anymore now that texture objects are around for quite some time.

#5
Posted 02/16/2018 09:02 AM   
Scroll To Top

Add Reply