我还没有进入 GPGPU 编程，所以我不知道 CUDA (OPENCL) 的确切细节，但假设 GPU 处于最佳（冷却良好，...）环境 - 纯 CUDA (OPENCL ) 代码永久损坏 GPU？ GPGPU 编程系统是否足够强大，可以从代码中的所有错误中恢复？
我见过this question，但因为 eaponte 有一个特定的问题，需要解决这个问题，所以它被发布了。我以一般的方式要求更多。
非常感谢您的意见。
【问题讨论】：
在过去几年在许多用户共享的开发和生产环境中使用 Nvidia Tesla 卡之后，由于“编程错误”，我没有看到任何“物理损坏”的卡。因此，凭经验回答第一个问题：我猜（也是 GTX）是否能够最大程度地运行危机。在不着火的情况下，它也应该能够在高负载下生存您的 OpenCL/CUDA 内核。是的，供应商通常会注意热量水平并减少时钟等，正如您从 CPU 中所知道的那样。不过，系统制造商需要获得认证，以确保他们能够处理产生的热量，尤其是在多 GPU 系统中。
当然，过去曾有过一些代码损坏了各种硬件，这当然也可能发生在 GPU 上 - 但我从未读过关于特定的代码驱动案例，尽管它会是一个有趣的研究问题。
通常情况下，GPU 可能会像任何硅片一样受到损坏，只需使用它们即可。这种情况时有发生，例如，由于晶体管老化或冷却不良导致过热。我们还更换了使用了几年后突然出现故障的 GPU，就像更换 CPU 一样。
由于最初的问题相当宽泛，所以再补充一个：今天的 CPU/GPU/APU/... 包含如此多的晶体管，生产过程非常复杂，以至于通常情况下并非芯片的所有组件都真正可用（参见：具有 7/8 个活动通道的 PS3/Cell 处理器；企业与游戏产品等）。实际上，去年我们遇到了这样的情况，即驱动程序更新将一些以前“工作”的 GPU 渲染成现在产生许多双 ECC 错误的 GPU。通过其他驱动程序更新再次修复了该问题，并且仅影响特定一代早期生产周期的卡。我们推测的一个想法是，中断驱动程序没有正确屏蔽 RAM 的“不可用”部分，这种行为对最终客户是透明的。
GPGPU 编程系统是否足够强大，可以从所有环境中恢复？ 代码错误？
我当然可以用“否”来回答这个问题。在开发过程中，我们经常会遇到内核中频繁且“残酷”的段错误会导致驱动程序崩溃的情况。完全重启主机系统通常是我们在这种情况下恢复以使特定 GPU 再次可用的唯一方法。
【讨论】：