Oferta y reclamación de cambios
En el caso de Windows Display Driver Model (WDDM) v2, se relajan los requisitos relacionados con la oferta y la reclamación . Los controladores en modo de usuario ya no son necesarios para usar la oferta y reclamar en las asignaciones internas. Las aplicaciones inactivas o suspendidas se deshacerán de los recursos internos del controlador mediante la API trimque se introdujo en Microsoft DirectX 11.1.
La oferta y la reclamación seguirán siendo compatibles en el nivel de API y se requiere el controlador en modo de usuario para reenviar solicitudes de aplicación para ofrecer o reclamar recursos al kernel. En WDDM v2, la asignación de ofertas ya no se admite a través de la lista de asignación y, como resultado, el controlador del modo de usuario debe cambiar la forma en que implementa la oferta y la reclamación.
Los recursos que ofrece una aplicación deben ofrecerse inmediatamente mediante el controlador de modo de usuario, llamando a OfferCb, si los recursos no tienen ninguna referencia en los búferes de acceso directo a memoria (DMA) que se están compilando actualmente en todos los contextos. Si los recursos tienen referencias pendientes en el búfer DMA que se está compilando, el controlador en modo de usuario debe aplazar la llamada a OfferCb hasta después de que se haya enviado el búfer DMA dependiente a través de RenderCb. El kernel de gráficos se encargará de aplazar la operación, de forma no bloqueada, hasta que sea seguro ofrecer el recurso y, como tal, el controlador en modo de usuario no tiene que preocuparse por tener que aplazar la llamada a OfferCb hasta que la operación dependiente se complete en la unidad de procesamiento de gráficos (GPU).
La reclamación de llamadas se pagina automáticamente en una asignación si está en la lista de requisitos de residencia (es decir, el usuario o el controlador ha solicitado que la asignación resida a través de una llamada MakeResidentCb ). En el caso de ReclaimAllocations2Cb, esta operación es asincrónica y se devuelve una barrera de paginación y se debe controlar de la misma manera que las vallas devueltas desde MakeResidentCb. Se garantiza que la asignación es residente y utilizable en la GPU cuando se señala la valla.
Inmediatamente después de volver de ReclaimAllocationsCb/ReclaimAllocations2Cb, se garantiza que el almacén de respaldo de la asignación es válido y la asignación se puede colocar bajo el acceso de CPU a través de Lock2Cb. El controlador no necesita esperar en la barrera de paginación para hacerlo.