texture memory destroyed after first step

Accelerated Computing CUDA CUDA Programming and Performance
#1

Hi all,

I allocate cudaArray, bind texture.
The first time step is ok, I read the right texture values in the kernel.
But after the first time step, all the texture values become NaN.

Do you have an idea what can destroy my memory?

I don’t do any cudaMalloc/cudaMemcpy/cudaUnbindTexture/cudaFreeArray/cudaFree after the first time step.

Thanks!

– pium

#2

After not using the texture in the kernel, it is still bugging due to a “cudaThreadSynchronize error”

I tried to add CUDA_SAFE_CALL( cudaThreadSynchronize() ); before calling the kernel function but it does not change anything.

What else can I try to synchronise which threads?

thanks.

– pium

#3

After not using the texture in the kernel, it is still bugging due to a “cudaThreadSynchronize error”

I tried to add CUDA_SAFE_CALL( cudaThreadSynchronize() ); before calling the kernel function but it does not change anything.

What else can I try to synchronise which threads?

thanks.

– pium

#4

It’s hard to tell without seeing your code…

#5

It’s hard to tell without seeing your code…

#6

unfortunately the code is very big.

I found that changing the grid size can make it working.

What is strange it’s if I call my kernel in a very small test application, it works well for any grid size. But in my big application, only selected grid size works.

Any suggestion where it can come from?

– pium

#7

unfortunately the code is very big.

I found that changing the grid size can make it working.

What is strange it’s if I call my kernel in a very small test application, it works well for any grid size. But in my big application, only selected grid size works.

Any suggestion where it can come from?

– pium

#8

My hunch is that your kernel is having out of bound access (bad pointers) which somehow overwrite the texture memory area… (the texture memory still resides in global memory only except that CUDA does not expose the memory area… so, if ur pointer is bad – you can actually corrupt your texture…)

#9

My hunch is that your kernel is having out of bound access (bad pointers) which somehow overwrite the texture memory area… (the texture memory still resides in global memory only except that CUDA does not expose the memory area… so, if ur pointer is bad – you can actually corrupt your texture…)

#10

Sarnath, I think about it, but now I am testing with a kernel that does nothing, just taking the first value of a texture, and cuPrintf it.
So if my memory is corrupted, it is not by my kernel!

#11

Sarnath, I think about it, but now I am testing with a kernel that does nothing, just taking the first value of a texture, and cuPrintf it.
So if my memory is corrupted, it is not by my kernel!

#12

There are finite limits on the maximum memory size and dimensions of textures that CUDA supports. Are you sure your “big” case isn’t exceeding the texture size limits? They are described in appendix G of the CUDA 3.0 programming guide.

#13

There are finite limits on the maximum memory size and dimensions of textures that CUDA supports. Are you sure your “big” case isn’t exceeding the texture size limits? They are described in appendix G of the CUDA 3.0 programming guide.

#14

The app is bigger, but the textures are the same, and I’d like the grid to be smaller that the dimension that works.

#15

The app is bigger, but the textures are the same, and I’d like the grid to be smaller that the dimension that works.