Driver residency in WDDM 2.0

This section provides details about the driver residency changes for Windows Display Driver Model (WDDM) 2.0. The functionality described is available starting with Windows 10.

In this section

Topic	Description
Residency overview	With the introduction of the new residency model, residency is being moved to an explicit list on the device instead of the per-command buffer list. The video memory manager will ensure that all allocations on a particular device residency requirement list are resident before any contexts belonging to that device are scheduled for execution.
Allocation usage tracking	With the allocation list going away, the video memory manager no longer has visibility into the allocations being referenced in a particular command buffer. As a result of this, the video memory manager is no longer in a position to track allocation usage and to handle related synchronization. This responsibility will now fall to the user mode driver. In particular, the user mode driver will have to handle the synchronization with respect to direct CPU access to allocation as well as renaming.
Offer and reclaim changes	For WDDM v2, requirements around Offer and Reclaim are being relaxed. User mode drivers are no longer required to use offer and reclaim on internal allocations. Idle/suspended applications will get rid of driver internal resources by using the TrimAPI that was introduced in Microsoft DirectX 11.1.
Access to non-resident allocation	Graphics processing unit (GPU) access to allocations which are not resident is illegal and will result in a device removed for the application that generated the error. There are two distinct models of handling such invalid access dependent on whether the faulting engine supports GPU virtual addressing or not: For engines that don't support GPU virtual addressing and use the allocation and patch location list to patch memory references, an invalid access occurs when the user mode driver submits an allocation list which references an allocation which is not resident on the device (i.e. the user mode driver hasn't called MakeResidentCb on that allocation). When this occurs, the graphics kernel puts the faulty context/device in error. For engines that do support GPU virtual addressing but access a GPU virtual address that is invalid, either because there is no allocation behind the virtual address or there is a valid allocation but it hasn't been made resident, the GPU is expected to raise an unrecoverable page fault in the form of an interrupt. When the page fault interrupt occurs, the kernel mode driver needs to forward the error to the graphics kernel through a new page fault notification. Upon receiving this notification, the graphics kernel initiates an engine reset on the faulting engine and puts the faulty context/device in error. If the engine reset is unsuccessful, the graphics kernel promotes the error to a full adapter wide timeout detection and recovery (TDR).
Process residency budgets	In WDDM v2, processes will be assigned budgets for how much memory they can keep resident. This budget can change over time, but generally will only be imposed when the system is under memory pressure. Prior to Microsoft Direct3D 12, the budget is handled by the user mode driver in the form of Trim notifications and MakeResident failures with STATUS_NO_MEMORY. TrimToBudget notification, Evict, and failed MakeResident calls all return the latest budget in the form of an integer NumBytesToTrim value that indicates how much needs to be trimmed in order to fit in the new budget.