5 Second Hell Did Not Happened ?!

Hi everyone,

I modified the template code in CUDA SDK, just like this, added a big loop,

testKernel( float* g_idata, float* g_odata) 

{

  // shared memory

  // the size is determined by the host application

  extern  __shared__  float sdata[];

 // access thread id

  const unsigned int tid = threadIdx.x;

  // access number of threads in this block

  const unsigned int num_threads = blockDim.x;

 // read in input data from global memory

  // use the bank checker macro to check for bank conflicts during host

  // emulation

  SDATA(tid) = g_idata[tid];

  __syncthreads();

 // perform some computations

  SDATA(tid) = (float) num_threads * SDATA( tid);

  __syncthreads();

  

  //BIG LOOP

  for( int j=0;j<16;j++ )

	for( int i=0;i<10000000;i++ )

  // write data to global memory

  __syncthreads();

  g_odata[tid] = SDATA(tid);

}

So the kernel will execute more than 10sec on my only ONE Winfast 8800GT, CUDA 1.1, 169.09 version driver, when it was running, sometimes I could not click the “Start Button” or anything others about GUI operation, even move the command line window. When it had done, the Windows message quere will be processed. >.<

I do not know why, or something I tested is wrong ? <img src=‘http://hqnveipbwb20/public/style_emoticons/<#EMO_DIR#>/crying.gif’ class=‘bbc_emoticon’ alt=’:’(’ />

Here is the old post,

http://forums.nvidia.com/index.php?showtop…98&#entry176998

I have a kernel that I need to execute many times. The first time it says it takes 16 seconds to run and then everytime after that it takes only 600us. I think that the 600us runs are not working properly as my data is not right.

Try running this kernel in a loop and see if you get this.

You should always check for errors after every kernel call in debug builds via cudaThreadSynchronize() and then cudaGetLastError() to debug these situations. After a timeout error occurs, all future kernel calls will result in an immediate (probably your 600us) return with “Error in previous launch”.

To answer the OP: When a kernel is executing, the display is frozen because the GPU is putting 100% of its resources toward the kernel. So you are seeing expected behavior.