问题描述：
cuda程序调试时出现Cuda grid launch failed,如下图
[attach]2963[/attach]
经调试发现是kernel内程序引起的Cuda grid launch failed错误，但不知怎么解释该错误，有些帖子说是数组越界。
正常。
目前已知kernel里对global memory/shared memory访问的越界行为，根据运行环境和时机的不同，
出现
ULP(Unspecified Launch Failure),
cudaErrorUnknown,
access violation(仅当nsight存在才有可能出现这个）。
这三种。
至于如何解决，要看你那里出现问题了。
一般情况下nsight会告诉你是哪个.cu的哪行出现access violation, 以及出现时候的线程编号等信息。
没有立刻就能解决的通用方案。但是楼主可以根据提示进行自我检查。
此问题已经解决，但我目前是将需要进行并行计算的数据全部传递到全局显存，且没有做优化，以此实现并行计算，可效率却没有得到预计的提升幅度，如500×500条光线的并行计算时间为62s，对应算法CPU计算时间为82s，提升幅度相当有限。
恭喜楼主，同时建议楼主发表心得，回馈论坛。
关于您的第二个问题，“没有做优化，以此实现并行计算，效率没有得到预计的提升幅度”。
诚如您所言，没有优化是一个方面，的确可能因此导致效率低下。
此外，除了“优化”外，GPU编码代码还需要一定的基本准则，这些准则不是优化。但如果不遵循，可能会极大的影响效率。
（1）是否在warp内有分支(请参考profiler的divergent branch数据)
（2）是否访问global memory是合并的。（请参考profiler的关于显存访问合并的相关信息）。
这二点是非常重要的基本准则，
违背(1)会极大的降低运算效率。而，
违背(2)则会极大的影响访存效率。
还请楼主仔细斟酌完此2点后，再考虑“优化”。
此外，其他的一些开发过程中的编译参数等，也许影响速度。（甚至简单的debug->release的编译结果你就会感觉到不同的运行速度）。
请楼主考虑如上要求和建议。
版主，您好！造成此帖的问题应该就是访问越界，目前由于在赶毕业论文的程序，可能近期不能写心得，等这段时间忙完后，我会写个从接触CUDA到使用CUDA整个过程的感受。
此外，除了“优化”外，GPU编码代码还需要一定的基本准则，这些准则不是优化。但如果不遵循，可能会极大的影响效率。
（1）是否在warp内有分支(请参考profiler的divergent branch数据)
（2）是否访问global memory是合并的。（请参考profiler的关于显存访问合并的相关信息）。
说明：
（1）由于每条光线的起点相同、方向不同，所以光线遍历二叉树的路线也不相同，wrap内应该是存在分支的，但存在光线数组中临近光线方向不会相差太大的特性，因此wrap内分支的问题有所降低。
（2）这个问题我需要看完楼主推荐的资料才能回答。
（3）有关光线跟踪CUDA计算的文献采用了将数据传递至texture memory来加速，目前不清楚该方案可以带来多大的性能提升，请版主明示。
感谢您的回复。
对于您的最后一个问题，您使用texture后有多大的性能提升。我谨慎的表示，这个问题不一定。
使用texture是否有性能提升，以及能提升多少，要看你的具体访问模型。不能直接给出直接数据。在2.x上我一般不推荐使用texture, 除非性能的确提升了。在1.x和3.x上推荐您使用，除非性能的确下降了。
恩，我在创建一个计算结果正确的CUDA工程session时，本来创建时间和执行时间相当，但一直处于创建等待过程中，此外我创建了一个新的工程测试了可以正常创建其session
请问问题可能会出在哪？