我們有一個多GPU架構（在Windows上），其中可以指定'作業'（這也指定他們應該在哪個GPU上完成），然後在特定的GPU上執行。 目前，我們的方法是在框架的啓動我們爲每個GPU創建一個「工作線程」，然後等待作業被處理。具體而言，我們使用「GPUWorker」類從https://devtalk.nvidia.com/search/more/sitecommentsearch/GPUworker/好的策略多GPU處理與CPU線程，cuda上下文創建開銷
它可以很好地，到目前爲止，但有一些嚴重的性能相關的缺點：
在我們frameowrk，特定的GPU被鎖定的全部時間即使GPU只在50％的工作時間內實際使用，也是「工作」的一部分。注意作業具有非常粗糙的粗糙度，例如'做光流計算'，其可以採取例如50 - 100毫秒。
人們不能具體的「異步」的工作（例如一個aysnchronous主機設備拷貝），它不鎖GPU
所以我現在想對這個問題「好」的策略。 我的想法如下：對於'已啓動'的每個新作業，我創建一個新的'臨時'CPU線程。 CPU線程然後設置將在其上完成工作的GPU的設備編號（通過'cudaSetDevice'）。我想在這個時候（對我來說很簡單，就是創建一個Cuda環境，在發佈正確的設備之後，作業的'doWork'功能由CPU線程執行，取決於作業是同步的還是異步的，一個「加入」完成（等待CPU線程完成）或不
我現在有幾個問題：
那是一個「好」的策略，或者是否有人知道的更好當然這應該是一個線程安全的策略
在我提出的策略中，典型的是什麼新CPU線程創建的開銷（以毫秒爲單位）以及Cuda上下文的（隱藏）創建）？此外，如果例如Cuda上下文的創建是有意義的，有沒有辦法（例如使用cuda設備api和某種'上下文遷移'）來減少這種開銷？