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