Exception handling cuda异常后的内存数据状态

Exception handling cuda异常后的内存数据状态,exception-handling,cuda,cuda-gdb,Exception Handling,Cuda,Cuda Gdb,CUDA文档不清楚CUDA应用程序引发异常后内存数据如何变化 例如,内核启动(动态)遇到异常(例如扭曲超出范围地址),当前内核启动将停止。在这一点之后,设备上的数据(例如设备变量)是否仍然保留,或者它们是否与异常一起被删除 具体的例子如下: CPU启动内核 内核将_设备_变量a的值更新为5,然后崩溃 CPU memcpy变量a的值从设备到主机,在这种情况下CPU得到的值是多少,5或其他 有人能说明这背后的基本原理吗?如果CUDA错误破坏CUDA上下文,则该行为未定义 这种类型的错误很明显,因为它

CUDA文档不清楚CUDA应用程序引发异常后内存数据如何变化

例如,内核启动(动态)遇到异常(例如扭曲超出范围地址),当前内核启动将停止。在这一点之后,设备上的数据(例如设备变量)是否仍然保留,或者它们是否与异常一起被删除

具体的例子如下:

  • CPU启动内核
  • 内核将_设备_变量a的值更新为5,然后崩溃
  • CPU memcpy变量a的值从设备到主机,在这种情况下CPU得到的值是多少,5或其他

  • 有人能说明这背后的基本原理吗?

    如果CUDA错误破坏CUDA上下文,则该行为未定义

    这种类型的错误很明显,因为它是“粘性的”,这意味着一旦发生,每个CUDAAPI调用都将返回该错误,直到上下文被破坏

    非粘性错误在cuda API调用返回后自动清除(除了
    cudaPeekAtLastError
    )。任何“崩溃内核”类型的错误(无效访问、未指定的启动失败等)都将是一个粘性错误。在您的示例中,步骤3将(始终)在调用
    cudaMemcpy
    将变量从设备传输到主机的结果上返回一个API错误,因此
    cudaMemcpy
    操作的结果是未定义和不可靠的,就好像
    cudaMemcpy
    操作也以某种未指定的方式失败一样

    由于损坏的CUDA上下文的行为未定义,因此没有任何分配内容的定义,也没有此类错误后机器的一般状态的定义

    非粘性错误的一个例子可能是试图
    cudamaloc
    获取比设备内存中可用数据更多的数据。这样的操作将返回内存不足错误,但该错误将在返回后被清除,后续(有效)cuda API调用可以成功完成,而不会返回错误。非粘性错误不会损坏CUDA上下文,CUDA上下文的行为与从未请求过无效操作的情况完全相同

    粘性错误和非粘性错误之间的这种区别在许多有文档记录的错误代码中都有,例如:

    非粘性、非cuda上下文损坏:

    cudaErrorMemoryAllocation=2 API调用失败,因为它无法分配足够的内存来执行请求的操作

    粘性,cuda上下文损坏:

    cudaErrorMisalignedAddress=74 设备在未对齐的内存地址上遇到加载或存储指令。无法使用上下文,因此必须将其销毁(并创建一个新的上下文)。此上下文中的所有现有设备内存分配无效,如果程序要继续使用CUDA,则必须重新配置


    请注意,
    cudadeviceset()
    本身不足以将GPU恢复到正常的功能行为。为了实现这一点,“拥有”过程也必须终止。看

    您能告诉我哪个cuda api调用清除这些非粘性错误的例子吗?
    cudaGetLastError()
    报告上一个错误,如果是非粘性错误,则清除它
    cudaPeekAtLastError()
    将报告错误(粘性或非粘性),但不会清除错误。如果没有错误,或者之前唯一的错误是非粘性的,并且之前已清除,则这些调用都可以报告
    cudaSuccess
    。好的,谢谢!因此,我要明确一点:如果我调用
    cudaGetLastError()
    两次,而第二次调用没有返回
    cudaSuccess
    ,那么我知道发生了一个粘性错误。是的,假设对
    cudaGetLastError()
    的两次调用之间没有中间活动,您能否详细说明一下
    cudaDeviceReset()的方法
    不足以在地址不对齐错误后恢复GPU?