Editing Direct3D (section)

==Multithreading==
WDDM driver model in Windows Vista and higher supports arbitrarily large number of execution contexts (or threads) in hardware or in software. Windows XP only supported multitasked access to Direct3D, where separate applications could execute in different windows and be hardware accelerated, and the OS had limited control about what the GPU could do and the driver could switch execution threads arbitrarily.

The ability to execute the runtime in a multi-threaded mode has been introduced with Direct3D 11 runtime. Each execution context is presented with a resource view of the GPU. Execution contexts are protected from each other, however a rogue or badly written app can take control of the execution in the user-mode driver and could potentially access data from another process within GPU memory by sending modified commands. Though protected from access by another app, a well-written app still needs to protect itself against failures and device loss caused by other applications.

The OS manages the threads all by itself, allowing the hardware to switch from one thread to the other when appropriate, and also handles memory management and paging (to system memory and to disk) via integrated OS-kernel memory management.

Finer-grained context switching, i.e. being able to switch two execution threads at the shader-instruction level instead of the single-command level or even batch of commands, was introduced in WDDM/DXGI 1.2 which shipped with Windows 8.<ref name=wddm_w8/> This overcomes a potential scheduling problem when application would have very long execution of a single command/batch of commands and will have to be terminated by the OS watchdog timer.<ref>{{cite web | url=http://www.microsoft.com/whdc/device/display/wddm_timeout.mspx | title=Timeout detection and recovery (TDR) - Windows drivers | website=[[Microsoft]] }}</ref>

WDDM 2.0 and DirectX 12 have been reengineered to allow fully multithreaded draw calls. This was achieved by making all resources immutable (i.e. read-only), serializing the rendering states and using draw call bundles. This avoids complex resource management in the kernel-mode driver, making possible multiple reentrant calls to the user-mode driver via concurrent executions contexts supplied by separate rendering threads in the same application.