Proposer et récupérer des modifications
Pour windows Display Driver Model (WDDM) v2, les exigences relatives à l’offre et à la récupération sont assouplies. Les pilotes en mode utilisateur ne sont plus tenus d’utiliser l’offre et de récupérer sur les allocations internes. Les applications inactives/suspendues se débarrasseront des ressources internes du pilote à l’aide de l’API Trimintroduite dans Microsoft DirectX 11.1.
L’offre et la récupération continueront d’être prises en charge au niveau de l’API et le pilote de mode utilisateur est requis pour transférer les demandes d’application pour offrir ou récupérer des ressources au noyau. Sous WDDM v2, l’allocation de l’offre n’est plus prise en charge par le biais de la liste d’allocation. Par conséquent, le pilote en mode utilisateur doit modifier la façon dont il implémente l’offre et la récupération.
Les ressources proposées par une application doivent être proposées immédiatement par le pilote en mode utilisateur, en appelant OfferCb, si les ressources n’ont aucune référence dans les mémoires tampons d’accès direct à la mémoire (DMA) en cours de génération dans tous les contextes. Si les ressources ont des références en attente dans la mémoire tampon DMA en cours de génération, le pilote en mode utilisateur doit différer l’appel à OfferCb jusqu’à ce que la mémoire tampon DMA dépendante ait été envoyée via RenderCb. Le noyau graphique s’occupe de différer l’opération, de manière non bloquante, jusqu’à ce qu’il soit sûr d’offrir la ressource et, par conséquent, le pilote en mode utilisateur n’a pas à se soucier de devoir différer l’appel à OfferCb jusqu’à ce que l’opération dépendante se termine sur l’unité de traitement graphique (GPU).
La récupération d’appel est automatiquement mise en page dans une allocation si elle figure dans la liste des conditions de résidence (c’est-à-dire que l’utilisateur ou le pilote a demandé que l’allocation soit résidente via un appel MakeResidentCb ). Pour ReclaimAllocations2Cb, cette opération est asynchrone et une clôture de pagination est retournée et doit être gérée de la même façon que les clôtures retournées par MakeResidentCb. L’allocation est garantie d’être résidente et utilisable sur le GPU lorsque la clôture est signalée.
Immédiatement après le retour de ReclaimAllocationsCb/ReclaimAllocations2Cb, le magasin de stockage de l’allocation est garanti comme valide et l’allocation peut être placée sous l’accès processeur via Lock2Cb. Le pilote n’a pas besoin d’attendre sur la clôture de pagination pour le faire.