我已经用 nsight 3.0将 TDR修改为60，应该不存在内核函数执行时间的限制。具体问题是这样的
#define Mb01 2626
#define Mb02 1000
for(int i=0;i<Mb01;i++)
{
cout<<“判断 ib=”<<i<<“时固体壁面的可见性”<<endl;
grid1=i/thread1+1;
soild_jxs_panduan<<<grid1,thread1>>>(i);
cout<<"判断 ib="<<i<<"时固体壁面与虚拟壁面间的可见性"<<endl；
grid1=Mb02/thread1+1;
virtual_jxs_panduan<<<grid1,thread1>>>(i);
}
每次执行的时候，i=31时，程序就卡在那里了，等待约60秒显卡才启动
如果我将红色的那句改成for(int i=100;i<Mb01;i++) ，i=131时就又卡在那里了，也是等待约60秒显卡才启动
我在用小数据测试时这个程序是可以执行通过的，结果也比较准确。
改成大数据后出现这样的结果，我的理解是主机和设备不是同步执行的，内核的发射堆积31个后满了，就不能再执行下去了
我是初学CUDA，对其中细节不甚清楚，还请大神们不吝赐教
您好，我估计是您的kernel出的问题，但是您这里只有host代码，所以无法具体指出。
以及，连续发射kernel的话，灌几千个进队列都妥妥的，并无31个限制。
手机党先回复这些，请您检查您的kernel代码。
祝您好运！
但是为什么每次都是31次呢？会不会是内存超过了最大的限制。还有一个，在执行这个内核函数时virtual_jxs_panduan<<<grid1,thread1>>>(i);，计算量会很大，里面函数调用很多，就是说2626个线程会同时执行，会不会因为计算量太大而出问题
LZ您好：
1：如2#所说，灌几千个kernel进执行队列都无问题的，绝对不会因为31个卡住，请相信这一点。
2：“会不会是内存超过了最大的限制”，合理的访存是程序员需要自己保证的，无法理解您“超过最大限制”的含义。同时指出，如果您给kernel的访存指针是错误的，那么kernel不会执行的；如果在kernel里面写越界了，kernel有可能挂掉；如果在kernel里面死循环了，kernel可能会超时。
3：“还有一个，在执行这个内核函数时virtual_jxs_panduan<<<grid1,thread1>>>(i);，计算量会很大，里面函数调用很多”，一般来说这都不是问题。如果您的kernel的计算量随着输入参数i的增加而增加以及同时您的计算量真的大到了60秒都计算不完，那么的确可能超时的。但是kernel的计算量，您自己应该有个大概的评估和判断。同时，如果是这种情况，您还可以尝试继续增加TDR限制时间，看看会否在计算更多步的时候超时。
4：“就是说2626个线程会同时执行，会不会因为计算量太大而出问题”，CUDA架构支持的同时计算的线程数远多于2626，所以这个不是线程数量导致的。
同时，计算量的算法是单个线程的计算量*线程数。在计算量很大的时候，运行一个kernel的确有可能超时。但是，一个kernel连续跑60s还不结束，这也是比较少见的情况。
您的问题大致答复如上。
如同2#指出的那样，您的程序有可能是kernel的bug，但是您却拒绝给出确切信息，而是反复自己猜测，这无助于解决问题。
祝您好运~
这两个内核函数是这样的，个人检查了很多遍，找不到问题所在
我用nsight 3.0 调试时，也会出现黑屏现象，我个人分析原因可能有：
1.确实可能有bug
2.单卡单机调试会不会也会有影响，因为我的卡确实不高端 Geforce 310M
LZ您好，大致看过您5#给出的kernel的代码。
1：您给出的代码中，关于函数传入值ib1，操作似乎都很正常。
2：您在kernel中调用了数个device函数，其中一个是计算中心点坐标的函数，另一个是扫描网格做判断的函数。这两个函数没有具体实现。其中前一个估计是计算量很少的；后一个建议您检查下，如果那里有bug或者每次那里的计算量都会大为提升的话，随着ib1的数值的增加，可能真的产生了超时。
3：您还可以在其他较好显卡的机器上跑跑看，看看情况有什么不同，以避免是您笔记本的较弱的显卡造成的问题。
大致建议如此，供您参考。
祝您编码顺利~
谢谢您，我把TDR改为600，可以执行了，用Visual Profiler 分析，的确是超时了，我分析是这个内核函数有很多判断，分支很多，不适合用并行，这个问题解决了，心里舒坦多了，再次谢谢您
system
10