A Microsoft a DirectX 11 API részeként mutatta be a Windows 7 operációs rendszertől elérhető deferred context funkciót. Az alapkoncepció az volt, hogy megoldják a rajzolási parancsok többszálú feldolgozását anélkül, hogy teljesen új API-t írjanak, és ezzel elveszítsék a régebbi API-k irányába a kompatibilitást.

A szabványos grafikus API-kat, így például a Direct3D-t is alapvetően egyszálú feldolgozásra tervezték, hiszen a rendszer alapjainak 90-es évek második felére tehető definiálásánál még nem is voltak tervben a többmagos processzorok. A hatékonyságra vonatkozó problémák azonban az elmúlt tíz évben egyre komolyabbá váltak, mivel az új processzorok egy szálra levetített teljesítménye generációnként jó, ha 5-10%-kal nőtt. Ezt a grafikus meghajtók megpróbálták kezelni különböző trükkök bevetésével, amelyek (ha lehetett) többszálú feldolgozással operáltak, de igazán lényeges előrelépést nem hoztak. Ezek behatárolták a fejlesztők mozgásterét is, így mára teljesen általánossá vált, hogy az adott program tartalmát készítő szakemberei is a grafikus API-ra, illetve a driverre optimalizálják az alkalmazott textúrákat.

A problémára egyébként már tíz éve felhívták a figyelmet a fejlesztők, így a Microsoft a DirectX 10 kiadása után el is kezdett dolgozni egy lehetséges megoldáson. Ez lett végül a DirectX 11-ben megjelent deferred context, ami az úgynevezett immediate context kiegészítésének tekinthető. Utóbbi arra szolgál, hogy amint kap az API egy parancsot, azt azonnal hajtassa végre a grafikus alrendszerrel. Ez évekig hatékony feldolgozási formának számított, de a mai hardverek mellett már nem az. A deferred context az immediate context modelljét úgy egészíti ki, hogy az API-hoz eljutó parancs nem kerül azonnal végrehajtásra. Ezek először egy parancslistában gyűlnek össze, majd az immediate context segítségével kiadhatók.

[+]

A párhuzamosítás lényegében az adott grafikus motorban történhet meg, de itt az implementációk különbözhetnek. A gyakorlati példákból kiindulva a Firaxis LORE motorja működik a leghatékonyabban. Ez a rendszer parancsfolyamokat hoz létre több processzorszálon, majd a leképzésért felelős rész ezeket juttatja el az API-nak, így betölthetők a parancslistába, majd végrehajthatók. Nagy átlagban ezzel 5-10%-os gyorsulásra tesz szert az előbbi motorra épülő játék.

Sajnos a többi játék deferred context implementációja nem ilyen jó, és ebből kitalálható, hogy miért nem támogatják igazán ezt a megoldást a fejlesztők. A deferred context csak rendkívül kiegyensúlyozottan működő rendszer mellett hatékony, ami ha nincs meg, akkor konkrétan lassulást okoz gyorsulás helyett.

A potenciális problémák között szerepel, hogy a deferred context nagyobb többletterhelést eredményez a grafikus driverben a parancsok felépítésénél, de ez legalább több szálon futhat. Utóbbi egyszerre jó és rossz, mivel a futtatott program mellett dolgozó úgynevezett rejtett szálak extra erőforrást vesznek el a processzortól, ami jelentősen lassíthatja a játék egyéb feladatainak elvégzését, mindemellett a parancslista csak egy processzorszálon kezelhető, így egy processzormagot ez a feladat jellemzően felemészt. Ez szimplán kétmagos processzoron nagyon kedvezőtlen hatást eredményez. Szintén megjegyzendő, hogy a deferred context egyirányú működést valósít meg, így a parancspufferek nem használhatók fel újra.

A fenti problémák már a DirectX 11 megjelenése előtt kiderültek, így a Microsoft a deferred context koncepcióját opcionálisan támogatható funkcióként jegyezte be a szabványba, hogy a gyártók szabadon dönthessenek a támogatás mellett, vagy éppen ellene, hiszen nem egyértelműen előnyös a rendszer használata. Ebből a szempontból az NVIDIA támogatja a rendszert, míg az Intel és az AMD inkább nem.