我想我應該比絕大多數人了解nVidia的GPU怎麼做scheduling，但我的認知和你並不同。我不認為scheduling的討論和遊戲相關。首先，Windows並非real-time OS，它的thread time-slice大約是25ms。另一方面，以60 fps的畫面輸出來說，每張frame的間隔大約是16ms。以現代遊戲等級的GPU來說，每個command buffer的執行時間都是us等級的（對1GHz的GPU而言，1us=1000 clock cycles），即便加上DPC，也幾乎不會超過100 us。換言之，就算遊戲根據場景臨時插入的GPU task大概都可以在下個frame present之前render完成。
Async compute對於之前nVidia GPU造成的真正問題點在於，nVidia的GPU設計並無法快速地在graphics和compute操作模式之間切換，更不用說能同時執行graphics和compute指令。如果遊戲大量地將原本以graphics command執行的工作改用compute command完成，可想見必然會影響效能。針對這樣的操作模式，從GM20X已經開始提出改善此種操作效能的方法，但是實測下來的結果仍然造成開啟async compute導致效能下降，因此後來的驅動程式便關閉GM20X對async compute的支援。而Pascal又有其他改良的設計，如同之前一些測試顯示，開啟async compute確實可以提昇效能。
總結下來，傳統上對於nVidia的GPU而言，直接利用graphics command執行比將大量工作利用DX12的async compute queue運算來得有效率。