作为一个大型项目的一部分，我遇到了一个奇怪的一致错误，我无法理解，但它是一个典型的“黑匣子”错误;与cuda-gdb python -m pycuda.debug prog.py -args一起运行时，它运行正常，但速度很慢。如果我丢下pycuda.debug，它会中断。始终如一，在多内核执行中完全相同。
解释;我有（目前有三个）内核，用于不同的网格和块排列，以解决更大优化问题的“切片”。这些严格来说应该工作，或者不工作，因为函数本身只被告知“这里有更多的数据”，除了数据的内容之外，不知道任何诸如迭代编号是否输入数据被分区或者不是，直到这一点，他们表现得很完美。
基本上，如果没有pycuda.debug将调试符号暴露给GDB，我无法看到发生了什么，但我也看不到WITH pycuda.debug的问题。
pycuda实际上做了什么，所以我知道在我的内核代码中要查找什么？
答案 0 :(得分：1)
几乎没有。它主要在pycuda.driver模块中设置编译器标志，以便使用必要的调试符号编译CUDA代码，并按照CUDA-gdb的方式进行组装。剩下的就是一个很小的包装器，很好地封装了pycuda库，所以一切都能正常工作。整个过程大约有20行python，如果需要，可以在源代码发布中看到代码。
这里的关键是调试器中运行的代码会将寄存器和共享内存中的所有内容溢出到本地内存，以便驱动程序可以读取本地程序状态。因此，如果您有为调试器构建时运行的代码，并且在正常构建时失败，则通常意味着共享内存缓冲区溢出或指针错误导致GPU等效于段错误。