我还没有进入GPGPU编程，因此我不知道CUDA（OPENCL）的具体细节，但假设GPU处于最佳（良好冷却......）环境中 - 可以使用纯CUDA（OPENCL）代码永久性损坏 GPU？ GPGPU编程系统是否足以恢复代码中的所有错误？
我见过this question，但是因为eaponte有一个特定的问题需要解决，所以这个问题已经发布了。我以一般的方式提出更多要求。
非常感谢您的投入。
答案 0 :(得分：1)
在过去几年中在许多用户共享的开发和生产环境中使用Nvidia Tesla卡之后，由于“编程错误”，我在此期间没有看到任何“物理损坏”的卡。所以以经验回答第一个问题：我想（如果（也是一个GTX）能够以最大值运行危机。在没有着火的情况下它也应该在高负载下存活在OpenCL / CUDA内核中。是的，供应商通常会照顾热量并减少时钟等，因为您从CPU中了解它。然而，系统制造商需要一个认证来确保它们能够处理产生的热量，尤其是在多GPU系统中。
但是当然有一些代码在过去一直在破坏所有类型的硬件，这当然也可能发生在GPU上 - 但我从来没有读到过特定的，代码驱动的情况，尽管它会是一个有趣的研究问题。
通常，只需使用它们就可以像任何一块硅一样损坏GPU。这种情况有时会发生，例如，由于晶体管老化或由于冷却不良而过热。我们在服务数年后也更换了突然发生故障的GPU，就像我们更换CPU一样。
由于最初的问题是相当广泛的另外一个补充：今天的CPU / GPU / APU / ......包含如此多的晶体管和生产过程非常复杂，通常情况下并非芯片的所有组件都实际可用（参见：PS3 / Cell Processor with 7/8 active lane; enterprise vs. gaming products，et al。）。我们实际上去年有一个案例，其中驱动程序更新将一些以前“工作”的GPU渲染到GPU中，现在产生了许多双ECC错误。这是通过其他驱动程序更新再次修复的，并且仅影响特定代的早期生产周期中的卡。我们推测的一个想法是，破解驱动程序没有正确掩盖RAM的“不可用”部分，这种行为对最终客户来说是透明的。
GPGPU编程系统是否足够强大，可以从所有系统中恢复 代码中的错误？
我当然可以回答这个问题。在开发过程中，我们经常遇到内核频繁且“残酷”的段错误会导致驱动程序崩溃的情况。完全重启主机系统通常是我们在这种情况下恢复以使特定GPU再次可用的唯一方法。