Ogólnie w z multi threadingiem w sterownikach chodzi o to żeby wykonywać różne taski na różnych wątkach procesora, na przykład ja jednym wątku przygotowujesz kolejkę rozkazów dla gpu do kopiowania danych a drugim wątku budujesz rozkazy już dla samego renderingu - tak to mniej więcej zrozumiałem jak czytałem dokumentacje do dx11 MT. Choć jak się dłużej nad tym zastanowiłem to chyba to jest raczej typowy use case dla MT + async
Być może bardziej taki przypadek jest dobry dla Dx 11 MT: na jednym wątku budujesz rozkazu dla pierwszej klatki, dla kolejnej klatki na kolejnym wątku i na przemian wysyłasz rozkazy dla GPU.
Problem z tym ze GPU NV i tak w chwili obecnej nie są w stanie działać w sposób asynchroniczny, dlatego jak chcesz raz coś wyrenderować a raz np coś skopiować to musisz wyczyścić cały kontekst co zajmuje dużo czasu. Jedyną optymalizacją ze strony NV w tej chwili jest priorytet zadań ustalany przez sterownik dlatego do każdej gry wychodzą sterowniki które odpowiednio ustawiają priorytety.
Ogólnie asynchroniczne shadery zbliżają GPU nieco do zasady działania CPU gdzie możliwa jest szybka zmiana konteksty i przełączenie się między zadaniami. Dzięki połączeniu multi threadingu po stronie API i CPU i asynchronicznych shaderów po stronie GPU możliwa się staje o wiele większa utylizacja obu zasobów.
Przy czym jakaś tam możliwość multi threadingu w dx 11 już istnieje.
EDIT: AMD natomiast nie wspiera dx 11 command list które pozwalają na wielowątkowe budowanie rozkazów, dlatego sterownik AMD ma duży nacisk na cpu. Oczywiście w DX 12 i Vulkanie sytuacja się zmieni.