Partager via

Mises à jour pour les versions 1.5, 1.6 et ultérieures d'IddCx

  • Article

Les mises à jour suivantes dans IddCx versions 1.5 et 1.6 s’appliquent à la fois aux pilotes d’affichage indirects (IDD) de console et à distance.

Version mise à jour de IddCxGetVersion

La version IddCx retournée par IddCxGetVersion a été mise à jour vers 0x1500 pour la version 1.5 et 0x1600 pour la version 1.6. Consultez Versions IddCx pour une liste complète des informations sur les versions liées à IddCx.

Informations WPP dans les symboles IddCx publics

À compter d’IddCx version 1.5, les fichiers de symboles IddCx publics contiennent toutes les informations du processeur de trace logicielle Windows (WPP). Cette modification signifie que la commande du débogueur !wmitrace.logdump décode et affiche le message WPP dans le débogueur du noyau.

Possibilité d’accéder aux mémoires tampons allouées dans la mémoire système

Dans certains scénarios, les mémoires tampons de la chaîne d’échange résident dans la mémoire système ; par exemple, lorsque WARP (Windows Advanced Rasterization Platform, le convertisseur logiciel fourni par le système) est l’adaptateur de rendu utilisé. IddCx 1.5 ajoute les rappels de système d’exploitation suivants qui permettent au pilote d’accéder aux mémoires tampons dans la mémoire système, ce qui évite une copie de sous-ressource :

  • IddCxSwapChainInSystemMemory permet à un IDD de vérifier si les mémoires tampons d’une chaîne d’échange résident dans la mémoire système. Le résultat de ce rappel reste constant tout au long de la durée de vie de la chaîne d’échange. Le pilote doit vérifier la valeur de ce rappel dans son rappel EvtIddCxMonitorAssignSwapChain et configurer l’état pour libérer et acquérir des mémoires tampons.

  • IddCxSwapChainReleaseAndAcquireSystemBuffer permet à un IDD de libérer et d’acquérir une mémoire tampon, ainsi que d’obtenir des informations pour accéder à la mémoire tampon (par exemple, un pointeur de mémoire système, un pitch/stride de la mémoire tampon, ainsi que le format et les dimensions de surface). La mémoire tampon retournée est valable jusqu’au prochain appel réussi à cette fonction.

    Au moment de l’affectation d’une nouvelle chaîne d’échange, le pilote doit décider quelle variante d'IddCxSwapChainReleaseAndAcquireBuffer/IddCxSwapChainReleaseAndAcquireSystemBuffer il va appeler pour la chaîne d’échange particulière et doit continuer à utiliser cette variante pour le reste de la durée de vie de cette chaîne d’échange. Pour décider, le pilote doit prendre en compte ses exigences spécifiques et le résultat de l’appel à IddCxSwapChainInSystemMemory. Un pilote provoque un bogue du système d’exploitation pour vérifier le processus UMDF s’il :

    • Appelle l’autre variante d’IddCxSwapChainReleaseAndAcquireSystemBuffer/IddCxSwapChainReleaseAndAcquireBuffer.
    • Appelle IddCxSwapChainReleaseAndAcquireSystemBuffer lorsque IddCxSwapChainInSystemMemory retourne une erreur.

Les pilotes sont recommandés, mais pas nécessaires pour utiliser ces fonctions de rappel. Le comportement avant IddCx 1.5 reste pris en charge.

Possibilité d’accéder aux mémoires tampons en mémoire physiquement contiguë

Remarque

IddCxSwapChainGetPhysicallyContiguousAddress n’est pris en charge sur aucun système Windows 10 et sera probablement déconseillé à l’avenir.

À compter d’IddCx 1.6, l’indicateur IDDCX_ADAPTER_FLAGS_PREFER_PHYSICALLY_CONTIGUOUS et la fonction de rappel d'OS IddCxSwapChainGetPhysicalContiguousAddress ont été ajoutés afin que les mémoires tampons soient accessibles en mémoire contiguë physiquement.

Les pilotes d’affichage peuvent demander que les surfaces principales soient allouées dans la mémoire système physiquement contiguë en définissant l’indicateur IDDCX_ADAPTER_FLAGS_PREFER_PHYSICALLY_CONTIGUOUS dans IDDCX_ADAPTER_CAPS. Cette fonctionnalité permet à un pilote d’analyser directement une surface sans copie intermédiaire.

Il n'est pas garanti que la demande du pilote pendant l’initialisation réussisse. Si la requête ne réussit pas, l’appel à IddCxAdapterInitAsync n'échoue pas. Au lieu de cela, une fois que le pilote effectue un appel IddCxSwapChainReleaseAndAcquireBuffer (ou IddCxSwapChainReleaseAndAcquireSystemBuffer), il doit appeler IddCxSwapChainGetPhysicalContiguousAddress pour récupérer l’adresse physique de la surface. IddCxSwapChainGetPhysicalContiguousAddress attend d’abord les commandes de rendu en attente, puis vide et invalide les caches processeur associés à la plage d’adresses où la surface est stockée. Toutefois, si la demande initiale d’allocation des surfaces dans la mémoire physiquement contiguë a échoué, IddCxSwapChainGetPhysicalContiguousAddress retourne E_NOINTERFACE.