pytorch RuntimeError： Couldn't open shared file mapping

pytorch 报错

 

RuntimeError: 

Couldn't open shared file mapping: <0000027567981322>, error code: <1455>

 

pytorch Windows常见问题汇总

多进程处理错误 “驱动程序关闭”

 请更新您的图形驱动程序。如果这种情况持续存在，这可能是因为您的显卡太旧或计算压力对于您的显卡来说太重了。请根据这篇 文章 更新 TDR 设置

Working around TDR in Windows for a better GPU computing experience

在Windows上使用视频卡/ GPU进行计算有一个有趣的副作用。 对于中等要求的事情，它可以正常工作，但是，如果您执行的代码充分利用了显卡，则可能会使图形用户界面无响应，或者至少响应速度很慢。 实际上，这也可能在Linux中发生，但是Windows具有Windows显示器驱动程序模型（WDDM）内置的称为超时检测和恢复（TDR）的功能，该功能可监视此类情况并在发生这种情况时重置图形驱动程序 。 这样做的目的是防止系统在程序中出现故障（导致过度使用显卡）时挂起，这通常是一件好事，因为它可以帮助防止Windows冻结。 但是，当您有意要使用显卡进行耗时超过一两秒钟的繁重工作时，此功能可能会成为一个大问题。

一个快速的例子（我观察过TDR的实际例子）是运行nbody。 这是一个GPU加速的小型CUDA程序，具有基准模式，该模式仅运行一小会儿。 足够短的时间它不会触发TDR，而具有可视化模拟显示的备用模式也不能将GPU推得太硬而无法触发TDR。 如果您将基准测试模式与延长测试的其他参数一起使用（特别是增加基准测试模拟中的实体数量），则它将触发TDR，并导致CUDA代码错误和Windows桌面上的消息，提示驱动程序 已重置。

该基准测试确实不是非常重要的软件，但是在某些应用程序中，这类代码可能很重要-而且，可以编写许多其他GPU程序来利用NVIDIA显卡的全部功能……所以 这会使Windows成为无法接受此类工作的平台吗？

乍一看似乎如此，但事实证明，您可以更改TDR的行为来解决此问题！ 在这方面有两个主要选项：

1）调整TDR启动并杀死驱动之前的时间长度。 默认长度为2秒，但是如果您知道需要更多时间，则可以增加该时间。

2）完全关闭TDR。

这两者都可以通过注册表项访问，Microsoft在这里很方便地介绍了这一点。以下是与本讨论有关的重要部分的总结:

 

 我发现更改其中任何一个都可以使nbody的基准运行时间更长。 如果您知道您要运行的代码不应该花费超过一定时间的时间，那么第二种选择似乎更可取-但是如果您不知道它可能花费多长时间，并且不想 您的代码被打断，仅关闭TDR当然是可行的。

请记住，这些不仅会影响您运行的CUDA代码：它们还会使合法的图形软件出现故障，有可能导致系统挂起。

 

除了上面的注册表项，我还尝试了其他一些值得注意的事情：

1）我尝试在普通的GeForce卡（特别是980 Ti），Titan X和Quadro（M4000）上运行代码。 我想看看更专业级别的卡的性能是否会有所不同，但Titan X和Quadro都表现出相同的TDR行为。

2）我想知道是否只有在变得无响应的卡是驱动实际GUI /显示的主要卡时才可能发生。 因此，我将两张GeForce卡都放入了（980 Ti和Titan X）中，并且仅在第二张卡上进行了基准测试……但是它仍然使TDR失效。

3）最后，我尝试将Tesla K40卡作为辅助卡-这次与Quadro M4000一起使用。 在特斯拉上运行基准测试并没有使TDR失败！ 这样就提供了另一种解决TDR的方法，尽管对于许多开发人员而言，GeForce卡将是一种更实惠的选择。

 

win7下修改显卡TDR