File d'attente matérielle des basculements

Cet article décrit la fonctionnalité de mise en file d’attente de basculage matériel prise en charge à partir de Windows 11 (WDDM 3.0). Une file d’attente de basculement matériel permet à plusieurs images futures d’être soumises à la file d’attente du contrôleur d’affichage. L’UC et les parties du GPU peuvent passer à des états d’alimentation inférieurs pendant que le contrôleur d’affichage traite plusieurs images en file d’attente, ce qui améliore l’efficacité de l’alimentation des scénarios de lecture vidéo sur du matériel compatible.

Modèle de file d’attente inversée Pré-WDDM 3.0

De nombreux contrôleurs d’affichage modernes prennent en charge la possibilité de mettre en file d’attente plusieurs images qui doivent être affichées dans une séquence. À compter de WDDM 2.1, le système d’exploitation prend en charge plusieurs demandes de remplacement de basculement en attente qui doivent être présentées sur la synchronisation virtuelle suivante. Le pilote de miniport d’affichage (KMD) indique cette prise en charge par le biais de la valeur MaxQueuedMultiPlaneOverlayFlipVSync dans DXGK_DRIVERCAPS. Cette fonctionnalité est utile pour réduire la latence dans les scénarios de jeux à fréquence d’images élevée où plusieurs images sont affichées séquentiellement avec l’intervalle 0, avec l’intention d’afficher uniquement l’image la plus récente.

Dans les scénarios de lecture vidéo, le contenu de plusieurs images futures à afficher séquentiellement est connu à l’avance et peut être mis en file d’attente vers le GPU. Cette mise en file d’attente avancée permet au processeur d’entrer dans un état d’alimentation faible pendant que les trames mises en file d’attente sont traitées, ce qui entraîne des économies d’énergie substantielles. Toutefois, avant WDDM 3.0, il n’existait aucun mécanisme permettant au système d’exploitation de soumettre plusieurs images qui doivent rester à l’écran pendant au moins un intervalle VSync sans intervention supplémentaire du processeur. La section file d’attente de basculement matériel de base introduit une solution qui permet au processeur d’entrer dans un état de faible consommation et de décharger le traitement des trames en file d'attente sur le GPU.

Dans les scénarios de jeu avant WDDM 3.0, une fois que le GPU a terminé le rendu de la scène sur le tampon arrière de la swap chain, il existe un aller-retour vers le processeur afin de soumettre la demande pour afficher l'image à l'écran. Pour les charges de travail GPU lourdes qui se terminent à proximité de VSync, cette boucle peut entraîner un retard des images et manquer le temps cible prévu, ce qui entraîne des problèmes d’images observables. La section Advanced hardware flip queue introduit un mécanisme pour éviter ce cycle aller-retour du processeur et présenter des images terminées à l’écran avec une faible latence. La file d'attente flip avancée nécessite la présence de la file d'attente flip matérielle de base et de la fonctionnalité de programmation matérielle GPU de niveau 2.

File d’attente de retournement de matériel de base

Le diagramme suivant illustre le cas de présenter trois images, chacune restant sur l’écran pour un intervalle VSync.

Le modèle de remplissage dans le diagramme montre les moments où le traitement de file d’attente des logiciels Dxgkrnl et les threads d’application doivent se réveiller et effectuer un travail de processeur. Sur chaque VSync, le contrôleur d’affichage doit émettre une notification processeur au système d’exploitation pour le retournement terminé, et le système d’exploitation doit envoyer la demande de retournement suivante. L'application doit également se réveiller sur chaque VSync et obtenir des statistiques de présentation pour finalement savoir quand la dernière image dans une série de trois images est affichée.

Les DDIS de file d’attente de basculement matériel qui peuvent envoyer plusieurs images futures à la file d’attente du contrôleur d’affichage sont disponibles à partir de WDDM 3.0. Comme indiqué précédemment, ce mécanisme permet au processeur et aux parties du GPU de passer à des états d’alimentation inférieurs pendant que le contrôleur d’affichage traite plusieurs images en file d’attente. Cette transition améliore l’efficacité de la puissance des scénarios de lecture vidéo sur du matériel compatible.

Le diagramme suivant illustre l’architecture proposée.

Avec l’approche de file d’attente de basculement matériel, les composants de l’application et du processeur Dxgkrnl sont entièrement inactifs pour deux intervalles VSync entre les temps v2 et v4, ce qui permet au processeur d’entrer dans un état d’alimentation faible. L’UC est avertie uniquement lorsque la trame N+2 pour laquelle l’application a demandé un temps d'attente est terminée.

File d’attente avancée de retournement de matériel

Dans les scénarios de jeu avant WDDM 3.0, une fois que le GPU a terminé le rendu de la scène dans la mémoire tampon arrière de la chaîne d'échange, il y a un aller-retour vers le CPU afin de soumettre la demande pour afficher le contenu de la trame à l'écran. Le diagramme suivant montre ce scénario.

Le coût de cet aller-retour peut entraîner des images à manquer leur cible si le rendu est terminé trop près du VSync, comme illustré dans le diagramme suivant.

Certains contrôleurs d’affichage prennent en charge en mode natif les conditions d’attente qui permettent à l’affichage d’envoyer la demande de retournement une fois que le GPU a terminé le rendu de l’image sans aller-retour de l’UC. Étant donné que la file d’attente de basculement matériel peut soumettre la trame N achevée à l’affichage sans retour au processeur, elle pourrait éviter des trames manquées, comme illustré dans le diagramme suivant.

Le reste de cet article décrit la fonctionnalité de file d’attente de mise à jour matérielle de base.

Prise en charge du DDI

Les DDIS suivants ont été ajoutés pour prendre en charge la fonctionnalité de file d’attente de basculement matériel.

Vérification de la disponibilité des fonctionnalités

La file d’attente de retournement de matériel nécessite l’activation/désactivation du système d’exploitation. Un KMD qui prend en charge la file d’attente de retournement de matériel doit d’abord appeler DXGKCB_QUERYFEATURESUPPORT pendant l’heure de début de l’appareil avec un FeatureId de DXGK_FEATURE_HWFLIPQUEUE pour déterminer si le système d’exploitation autorise l’activation de la file d’attente de retournement de matériel.

La file d’attente de retournement matérielle ne peut être utilisée que si le rappel réussit et que l’option Activer a la valeur TRUE.

Un KMD peut utiliser le code d'exemple suivant pendant les étapes de configuration de la file d'attente de retournement matériel et lors des phases expérimentales.

DXGKARGCB_QUERYFEATURESUPPORT HwFlipQueueEnabledArgs = {};
HwFlipQueueEnabledArgs.DeviceHandle = DeviceHandle;
HwFlipQueueEnabledArgs.FeatureId = DXGK_FEATURE_HWFLIPQUEUE;
HwFlipQueueEnabledArgs.DriverSupportState = DXGK_FEATURE_SUPPORT_EXPERIMENTAL;

if (!NT_SUCCESS(pDxgkInterface->DxgkCbQueryFeatureSupport(&HwFlipQueueEnabledArgs)) ||
    !HwFlipQueueEnabledArgs.Enabled)
{
    // Disable hardware flip queue because the OS didn't allow it.           
}
else
{
    // Enable hardware flip queue because the OS allowed it.
}

Lors de la mise en service du pilote, même s'il est possible d'activer la file d'attente de retournement matériel sans activer la planification matérielle GPU, cette combinaison n'est pas officiellement prise en charge. Windows exige actuellement que la planification matérielle du GPU soit activée afin que la file d’attente de basculement matériel de base soit activée sur les pilotes publiés officiellement.

Indication des fonctionnalités de mise en file d’attente matérielle

MaxHwQueuedFlips a été ajouté à DXGK_DRIVERCAPS pour indiquer la prise en charge de la file d’attente de retournement matériel. Si le système d’exploitation a autorisé la prise en charge de la file d’attente de basculement matériel comme décrit précédemment, un KMD qui prend en charge une file d’attente de basculement matériel doit définir MaxHwQueuedFlips sur une valeur supérieure à 1. Lorsque MaxHwQueuedFlips est supérieur à 1, KMD indique que le matériel d’affichage prend en charge jusqu’à MaxHwQueuedFlips de futures images qui peuvent être mises en file d’attente pour un VidPnSource donné sur le GPU. Le système d’exploitation respecte les restrictions fournies par le pilote sur le type de flips pouvant être mis en file d’attente à l’avance.

HwQueuedFlipCaps a également été ajouté à DXGK_DRIVERCAPS. Ce membre est actuellement réservé à l’utilisation du système ; les pilotes ne doivent pas l’utiliser.

Inverser l'heure cible et le format de l'horodatage cible

Lorsque le système d’exploitation envoie une demande de retournement à la file d’attente de retournement du matériel, il envoie également l’heure de retournement cible. Le retournement peut être rendu visible pour l’utilisateur une fois que l'heure de retournement cible est atteinte.

Le système d’exploitation utilise les unités de compteur d’horloge du processeur, obtenues à partir de KeQueryPerformanceCounter, pour fournir le temps de trame cible et interpréter le temps de trame réel.

Envoi de transactions en file d'attente

La structure DXGKARG_SETVIDPNSOURCEADDRESSWITHMULTIPLANEOVERLAY3, qui est passée à la fonction de rappel DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 de KMD, a été modifiée de la manière suivante pour permettre l'envoi de flips en file d'attente :

• Les trois membres suivants ont été ajoutés à la structure OutputFlags de DXGK_SETVIDPNSOURCEADDRESS_OUTPUT_FLAGS. Pour plus d’informations sur ces membres, consultez cas de réessai et d’échec de DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 pour plus de détails.

  • HwFlipQueueDrainNeeded
  • HwFlipQueueDrainAllPlanes
  • HwFlipQueueDrainAllSources

• Un membre TargetFlipTime a été ajouté. TargetFlipTime décrit le temps de basculement cible en unités QPC. Lorsque l’horloge atteint cette valeur, l'image peut être envoyée à l’affichage tout en respectant les indicateurs VSync et de tearing. En présence de retournements en attente précédemment mis en file d’attente, le système d’exploitation garantit que pour chaque plan MPO référencé par la demande de retournement, TargetFlipTime est supérieur ou égal à l’une des heures cibles de retournement en attente pour ce plan. En d’autres termes, il peut y avoir une séquence de retournements avec des horodatages identiques ou croissants, mais il ne peut pas y avoir de séquence qui revienne dans le temps.

Cas de tentative de réessai et d'échec pour DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3

Échec de la file d’attente de la demande sur le matériel en raison de retournements en attente

Il existe plusieurs cas spéciaux qui peuvent empêcher KMD de mettre en file d’attente une demande de retournement pendant que d’autres demandes de retournement sont en attente. Dans ce cas, KMD doit retourner STATUS_RETRY de DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 et définir HwFlipQueueDrainNeeded égal à 1. Le système d’exploitation tente de soumettre à nouveau la demande de retournement après que toutes les retournements en attente sur les plans affectés par le retournement sont terminés et une fois que l’heure cible est atteinte.

Dans certains cas, le matériel d’affichage peut nécessiter l’achèvement des retournements en attente sur tous les plans, pas seulement ceux référencés par la demande de retournement entrante. Dans ce cas, les indicateurs HwFlipQueueDrainNeeded et HwFlipQueueDrainAllPlanes doivent être définis sur 1, et KMD doit retourner STATUS_RETRY.

De même, le matériel d’affichage peut nécessiter l’achèvement des flips en attente sur toutes les sources VidPn afin de réallouer des ressources internes, auquel cas les indicateurs HwFlipQueueDrainAllSources et HwFlipQueueDrainNeeded doivent être définis, et KMD doit retourner STATUS_RETRY.

En outre, KMD peut indiquer au système d’exploitation si la réamission doit être effectuée au niveau de l’irQL de l’appareil (PrePresentNeeded défini sur 0), ou si le système d’exploitation doit effectuer cet appel à PASSIVE_LEVEL (PrePresentNeeded défini sur 1). Si KMD retourne toujours STATUS_RETRY même s’il n’y a plus de retours en attente sur ce VidPnSourceId, cette condition est traitée comme une défaillance de paramètre non valide.

Il est important que la valeur de MaxHwQueuedFlips reflète toujours le nombre maximal de modifications simples, uniquement liées à l’adresse, pouvant être mises en file d’attente dans un plan MPO. Le mécanisme de STATUS_RETRY doit être utilisé pour les demandes de retournement plus complexes qui ne peuvent pas être profondément mises en file d’attente, telles que les modifications de configuration du plan.

Échec de paramètre non valide

Dans le modèle de file d’attente de retournement matériel, la gestion des demandes de retournement échouées par le système d’exploitation a été retravaillée pour permettre une meilleure débogabilité. Lorsque KMD ne parvient pas à traiter une requête flip, elle doit renvoyer STATUS_INVALID_PARAMETER depuis DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3. Selon les paramètres du système d’exploitation, le système d’exploitation effectue l’une des actions suivantes :

• Arrêt du débogueur du noyau et vérification des erreurs : ce comportement est souvent activé sur les builds de développement/préversion pour améliorer le débogage au moment où la condition d’échec se produit.
• Vidage de noyau Live suivi d’un TDR : comportement du client final.

Spécification du comportement d’interruption VSync

Pour réaliser des économies d'énergie dans les scénarios de file d'attente de basculement, le système d'exploitation suspend souvent les interruptions de VSync régulières pour maintenir le processeur (UC) dans un état de faible consommation. Toutefois, certains retournements sont marqués comme nécessitant une interruption pour que l’application observe le lot de présentations terminées et met en file d’attente un travail supplémentaire. Il existe également des cas où les applications demandent de se réveiller sur chaque interruption VSync, qu'il y ait des demandes de flip en attente ou non. À l’inverse, sur un système complètement inactif, les interruptions VSync sont suspendues jusqu’à ce que les nouvelles activités de présentation ou les écouteurs VSync apparaissent.

Pour gérer tous ces cas, le rappel de pilote et la structure de rappel suivants ont été introduits :

• DXGKDDI_SETINTERRUPTTARGETPRESENTID
• DXGKARG_SETINTERRUPTTARGETPRESENTID

KMD fournit un pointeur vers sa fonction DxgkDdiSetInterruptTargetPresentId dans DRIVER_INITIALIZATION_DATA

Le système d’exploitation appelle DxgkDdiSetInterruptTargetPresentId pour spécifier le PresentId cible qui doit entraîner une interruption VSync déclenchée lorsque le retournement correspondant est terminé. Cette fonction est appelée au niveau de l’interruption de l’appareil (DIRQL) pour se synchroniser avec DxgkDdiSetVidPnSourceAddress et l’interruption VSync.

Interaction avec DxgkDdiControlInterrupt

Lorsque les interruptions VSync sont entièrement désactivées via DxgkDdiControlInterrupt/DxgkDdiControlInterrupt2/DxgkDdiControlInterrupt3, elles restent désactivées indépendamment de la valeur PresentId cible d’interruption. KMD doit stocker l'ID actuel de la cible d'interruption afin de pouvoir l'utiliser une fois que VSync est à nouveau activé.

Lorsque les interruptions VSync sont activées via DxgkDdiControlInterruptXxx, l’ID présent de la cible d’interruption (pSetInterruptTargetPresentId) fournit un contrôle plus précis comme suit :

• Lorsque l’ID actuel cible est défini sur UINT64_MAX, aucune interruption VSync n’est requise jusqu’à ce que l’ID actuel cible soit modifié à nouveau. Les interruptions VSync sont désactivées, mais KMD doit implémenter le comportement DXGK_VSYNC_DISABLE_KEEP_PHASE afin de réactiver les interruptions.

• Lorsque l'ID de cible actuel est défini sur 0, des interruptions sont nécessaires pour chaque VSync.

• Pour toute autre valeur d’ID présente, les interruptions sont déclenchées si le PresentId actuellement scanné >>= InterruptTargetPresentId.

Lorsque plusieurs plans MPO sont disponibles, l’interruption VSync doit être déclenchée si l’un des plans l’exige.

Désactivation en 2 étapes du VSync avec DxgkDdiSetInterruptTargetPresentId

Si l’appel du système d’exploitation à DxgkDdiSetInterruptTargetPresentId définit un InterruptTargetPresentId sur un plan qui entraînerait la désactivation complète de VSync sur cette VidPnSource (autrement dit, ce plan était le dernier plan qui a maintenu VSync activé, et maintenant ce plan désactive également VSync), KMD doit également désactiver les interruptions VSync, mais conserver la phase VSync dans le matériel activé (DXGK_VSYNC_DISABLE_KEEP_PHASE). Après une certaine période (généralement équivalente à deux périodes VSync), le système d’exploitation suit un appel à DxgkDdiControlInterruptXxx avec DXGK_VSYNC_DISABLE_NO_PHASE. Cet appel garantit que KMD a la possibilité de désactiver la phase VSync et les horloges VSync afin de maximiser l'économie d'énergie et de maintenir la parité de performance avec les systèmes sans file d’attente matérielle.

Annulation de retournement mise en file d’attente

Dans des cas tels que les transitions d'état en plein écran ou les sorties d'application, les inversions en file d'attente futures pourraient devoir être annulées. Pour gérer ces cas, la fonction de rappel du pilote et les structures connexes suivantes ont été introduites :

• DXGKDDI_CANCELFLIPS
• DXGKARG_CANCELFLIPS
• DXGK_CANCELFLIPS_PLANE

KMD fournit un pointeur vers sa fonction DxgkDdiCancelFlips dans DRIVER_INITIALIZATION_DATA.

Le système d’exploitation spécifie la plage de retournements mis en file d’attente pour annuler lorsqu’il appelle DxgkDdiCancelFlips, et kmD renvoie au système d’exploitation la plage de retournements qu’il a pu annuler de manière synchrone.

L'exemple suivant illustre les mécanismes et le cas synchrone de l'annulation d'inversion sur un seul plan. (Le système d’exploitation ne prend pas en charge l’annulation asynchrone dans Windows 11, version 22H2.) Imaginez que les flips suivants sont mis en file d’attente vers la file d’attente matérielle :

• PresentId N
• time t0 PresentId N+1
• heure t1 PresentId N+2
• time t2 PresentId N+3
• time t3 PresentId N+4
• temps t4

Le système d’exploitation décide ensuite d’annuler les retournements N+2, N+3 et N+4. Il appelle donc DxgkDdiCancelFlips avec PresentIdCancelRequested défini surN+2.

Lorsque KMD inspecte l’état de file d’attente de retournement du matériel, il détermine que :

• L'image N+2 est déjà envoyée au matériel d'affichage et ne peut pas être annulée au moment de l'exécution de l'appel.
• Les flips N+3 et N+4 peuvent être supprimés de façon synchrone de la file d’attente de flips matérielle sans effets secondaires.

Par conséquent, KMD définit PresentIdCancelled sur N+3 et termine N+2 comme d’habitude.

Le système d’exploitation marque N+3 et N+4 comme annulé, et il traite N, N+1, N+2 comme étant en cours de vol. Lorsque les interruptions VSync suivantes sont déclenchées, le journal de file d’attente inverse indique les horodatages pour N, N+1, N+2 comme d’habitude.

La plage de retournements annulés de manière synchrone doit être continue et, quand elle n’est pas égale à zéro, est supposée inclure le dernier ID présent envoyé à KMD. En d'autres termes, il ne peut y avoir aucune lacune dans les deux plages synchrones de retournement annulé.

Annulation des retournements interblocés sur plusieurs plans

Un retournement verrouillé est envoyé en appelant DxgkDdiSetVidPnSourceAddress avec plusieurs plans et PresentIds. Le contrat entre le système d’exploitation et kmD suit :

• L’ensemble des plans doit être rendu visible sur le même VSync.
• Le matériel d’affichage n’est pas autorisé à afficher uniquement un sous-ensemble de ces plans sur un VSync, et le reste sur le VSync suivant.

Dans le modèle de file d’attente de retournement matériel, ces retournements verrouillés sont annulés en passant plusieurs plans et PresentIds dans l’appel à DxgkDdiCancelFlips. L’ensemble des plans passés dans ces cas doit correspondre à une demande de basculement en attente, et la décision du KMD concernant tous les PresentIds interbloqués doit être la même :

• Ne pas annuler, ou
• Annuler de façon synchrone

DxgkDdiCancelFlips est appelé au niveau d’interruption de l’appareil (DIRQL) pour se synchroniser avec DxgkDdiSetVidPnSourceAddress et l'interruption VSync.

Obtention de statistiques actuelles pour les inversions en file d'attente

Étant donné que l’approche de file d’attente de retournement matérielle consiste à éviter de réveiller le processeur sur chaque VSync, il doit y avoir un mécanisme permettant de conserver les temps d’affichage des images pour les derniers retournements mis en file d’attente.

Les pilotes graphiques qui prennent en charge la file d’attente de retournement matériel doivent écrire des informations dans la mémoire tampon du journal de la file d’attente de retournement fournie par le système d’exploitation pour chaque opération de retournement terminée ou annulée pour un plan MPO donné pour chaque VidPnSource actif.

Le système d’exploitation garantit de fournir le pointeur de journal de file d’attente inversé (dans un appel à DxgkDdiSetFlipQueueLogBuffer) avant le premier appel DxgkDdiSetVidPnSourceAddress pour un plan MPO donné pour chaque VidPnSource actif. Le système d’exploitation est autorisé à détruire la mémoire tampon du journal de la file d’attente inversée lorsque la file d’attente inversée n’a pas de demandes en attente. Dans ce cas, il fournit un nouveau pointeur de log avant l'appel DxgkDdiSetVidPnSourceAddress suivant. Le journal de file d’attente de retournement est circulaire. Une fois l’entrée [NumberOfEntries-1] écrite, l’entrée de journal suivante est [0].

Une fois qu’un lot de retournements en file d’attente est terminé, KMD doit garantir que le journal de file d'attente des retournements pour les retournements terminés est mis à jour au plus tôt à l'un de ces deux moments donnés :

• Gestionnaire d’interruptions VSync pour un retournement qui exigeait qu’une interruption soit déclenchée.
• En réponse à une requête DxgkDdiUpdateFlipQueueLog explicite du système d’exploitation.

Inverser les entrées DDIs du journal de file d'attente

Les rappels associés aux journaux de file d’attente inversés suivants et les structures associées ont été ajoutés :

• DXGKDDI_SETFLIPQUEUELOGBUFFER

• DXGKARG_SETFLIPQUEUELOGBUFFER

• DXGK_FLIPQUEUE_LOG_ENTRY

• DXGKDDI_UPDATEFLIPQUEUELOG

• DXGKARG_UPDATEFLIPQUEUELOG

KMD fournit un pointeur vers ses fonctions dans DRIVER_INITIALIZATION_DATA.

Mises à jour de la structure d’interruption VSync

Les modifications suivantes ont été apportées à la structure DXGKARGCB_NOTIFY_INTERRUPT_DATA pour implémenter des interruptions VSync pour le modèle de file d’attente de retournement matériel :

• La valeur d’énumération DXGK_INTERRUPT_CRTC_VSYNC_WITH_MULTIPLANE_OVERLAY3 a été ajoutée en tant que InterruptType.
• La structure CrtcVSyncWithMultiPlaneOverlay3 a été ajoutée à l’union. La sémantique de CrtcVSyncWithMultiPlaneOverlay3 est similaire à la structure CrtcVSyncWithMultiPlaneOverlay2 existante, sauf qu’au lieu d’un seul dernier PresentId terminé pour chaque plan, CrtcVSyncWithMultiPlaneOverlay3.pMultiPlaneOverlayVSyncInfo pointe vers la plage de PresentIds précédemment non signalés à partir du journal de la file d’attente inversée.
• La structure DXGK_MULTIPLANE_OVERLAY_VSYNC_INFO3 a été ajoutée pour le membre pMultiPlaneOverlayVSyncInfo de CrtcVSyncWithMultiPlaneOverlay3.

À l’aide de l’exemple de diagramme de file d’attente de mise à jour matérielle de base :

Diagramme illustrant le mécanisme de base de la file d'attente matérielle de basculement.

Supposons que FirstFreeFlipQueueLogEntryIndex a été défini sur 40 lors de la soumission du flip N, puis les présentations N, N+1, N+2 ont été terminées.

Une fois qu’une configuration de plan unique a terminé les trois PresentIds N, N+1 et N+2 aux moments respectifs v2, v3, v4, KMD a écrit trois nouvelles entrées dans sa mémoire tampon de journal de file d'attente de basculement avec des index 40, 41 et 42. KMD signale une valeur FirstFreeFlipQueueLogEntryIndex de 43 dans la structure CrtcVSyncWithMultiPlaneOverlay3 . Le système d’exploitation observe que FirstFreeFlipQueueLogEntryIndex est passé de 40 à 43 et lit les entrées de journal 40, 41 et 42. KMD doit définir les valeurs de mémoire tampon du journal de la file d’attente inversée suivantes :

• VidPnTargetId : même signification que dans CrtcVSyncWithMultiPlaneOverlay2

• PhysicalAdapterMask : même signification que dans CrtcVSyncWithMultiPlaneOverlay2

• MultiPlaneOverlayVSyncInfoCount = 1

• pMultiPlaneOverlayVSyncInfo[0]. LayerIndex = 0

• pMultiPlaneOverlayVSyncInfo[0]. FirstFreeFlipQueueLogEntryIndex = 43

• LogBufferAddressForPlane0[40]. PresentId = N

• LogBufferAddressForPlane0[40]. PresentTimestamp = v2

• LogBufferAddressForPlane0[41]. PresentId = N+1

• LogBufferAddressForPlane0[41]. PresentTimestamp = v3

• LogBufferAddressForPlane0[42]. PresentId = N+2

• LogBufferAddressForPlane0[42]. PresentTimestamp = v4

Demande de mise à jour du journal de la file d’attente inversée explicite

Il existe des cas où le système d’exploitation doit obtenir des informations sur le dernier lot de retournements terminé sans avoir à attendre l’interruption VSync. Dans de tels cas, le système d’exploitation effectue un appel explicite à DxgkDdiUpdateFlipQueueLog pour demander à KMD de lire à partir de sa structure de données matérielles d’affichage propriétaire et d'écrire les informations de basculement dans le journal de la file d’attente de basculement. La sémantique du journal est la même que celle décrite précédemment ; La seule modification est que FirstFreeFlipQueueLogEntryIndex est retourné au système d’exploitation en dehors de l’interruption VSync.

DxgkDdiUpdateFlipQueueLog est appelé au niveau d’interruption de l’appareil (DIRQL), et il se trouve dans la même classe de synchronisation que DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 DDI.

Modifications du mode d’affichage et transitions d’alimentation en présence d’un retournement en file d’attente dans la file d’attente matérielle

Dxgkrnl garantit que les retournements déjà mis en file d’attente dans la file d’attente de retournement matériel sont terminés ou annulés avant de lancer une modification du mode ou de mettre hors tension le moniteur.

Mappage des requêtes Present aux horodatages de file d’attente de retournement matériel

Lorsque la file d'attente de basculement matériel est activée sur un adaptateur particulier, un horodatage accompagne tous les appels de basculement. En d’autres termes, KMD n’a pas besoin de gérer une combinaison d’anciennes et nouvelles sémantiques DxgkDdiSetVidPnSourceAddress .

Le système d’exploitation convertit automatiquement les demandes d’API Present basées sur des intervalles existants en appels de retournement basés sur l’horodatage en KMD. Les sections suivantes décrivent différents cas et comment ils sont associés à une combinaison d’indicateurs, de durée et d’horodatages reçus par KMD.

Les transformations tearing et nontearing de la sémantique

La sémantique des retournements de déchirure est conceptuellement la même lorsque la file d’attente de retournement matérielle est activée. Une fois TargetFlipTime atteint, KMD doit effectuer le retournement à l'affichage tout en respectant les indicateurs tels que FlipImmediate, FlipImmediateNoTearing et FlipOnNextVSync. En d’autres termes, KMD doit se comporter comme si l'OS lui avait soumis le flip exactement à TargetFlipTime avec les mêmes drapeaux et paramètres de retournement.

Par exemple, si FlipOnNextVSync est défini sur 1 et que TargetFlipTime se trouve au milieu du cadre, le retournement ne doit être affiché que sur le VSync suivant.

Prise en charge de FlipOverwrite et file d’attente de retournement de matériel

La file d’attente de retournement matérielle est un superensemble strict de la fonctionnalité de remplacement de retournement contrôlée par la valeur MaxQueuedMultiPlaneOverlayFlipVSync dans DXGK_DRIVERCAPS.

Par conséquent, le système d’exploitation ignore la valeur MaxQueuedMultiPlaneOverlayFlipVSync si le pilote opte pour la file d’attente de retournement matériel en définissant MaxHwQueuedFlips sur une valeur supérieure à 1.

Retourne plusieurs fois avec un TargetFlipTime expiré

Lorsqu'il y a plusieurs flips en file d'attente avec un TargetFlipTime expiré pour un plan MPO donné, la file d'attente de l'affichage matériel doit sélectionner le flip expiré le plus récemment mis en file d'attente et le soumettre à l'affichage. Les autres retournements expirés doivent être considérés comme annulés, et les entrées de journal de la file d'attente de retournement correspondantes doivent contenir DXGK_HWFLIPQUEUE_TIMESTAMP_CANCELLED comme valeurs de PresentTimestamp.

Interaction entre la durée et TargetFlipTime

Le paramètre Duration de la structure DXGKARG_SETVIDPNSOURCEADDRESSWITHMULTIPLANEOVERLAY3 doit prendre effet lorsque le flip spécifié dans cette structure est affiché à l’écran. Il spécifie le nouveau comportement de taux d’actualisation d’affichage souhaité pour la sortie spécifiée par VidPnSourceId sur tous les plans. Dans les versions WDDM 3.1 et Windows Server 2022, afin de simplifier l’implémentation du pilote pour le matériel qui ne prend pas en charge les modifications de durée personnalisée mises en file d’attente, le système d’exploitation envoie uniquement les demandes de retournement avec un nouveau paramètre Duration une fois les demandes de retournement précédentes terminées.

Mappage des intervalles présents à TargetFlipTime

Intervalles de mappage lorsque le taux d’actualisation est fixe

Pour conserver la sémantique d’intervalle actuel existante, le système d’exploitation doit calculer le temps de retournement cible à l’aide de l’intervalle actuel et du taux d’actualisation. Toutefois, la définition de l’heure de retournement cible exactement sur l’heure VSync prévue à laquelle le retournement doit atteindre l’écran entraîne des erreurs fréquentes. Ces problèmes sont dus à la synchronisation VSync manquée lorsque le chronométrage VSync réel dérive légèrement. Pour protéger contre les dysfonctionnements, le système d’exploitation soustrait la moitié de l’intervalle VSync du temps de basculement cible calculé.

Voici une formule simplifiée pour mapper l’intervalle présent au temps de retournement cible :

TargetFlipTime = PreviousFlipStartVSyncTime + (PreviousFlipPresentInterval * FixedRefreshRate) - (FixedRefreshRate / 2)

Intervalles de mappage lorsque la fonctionnalité de taux d’actualisation virtuel WDDM 2.9 est présente

La fonctionnalité de taux d’actualisation virtuelle peut temporairement augmenter le taux d’actualisation d’affichage à un multiple entier du taux d’actualisation actuel (autrement dit, 24 Hz peuvent être augmentés à 144 Hz ou 192 Hz). Pour les appareils capables de prendre en charge cette augmentation, la formule de la section précédente est modifiée pour utiliser le multiple le plus rapide du taux d’actualisation actuel :

TargetFlipTime = PreviousFlipStartVSyncTime + (PreviousFlipPresentInterval * FixedRefreshRate) - (FastestRefreshRate / 2)

Intervalles de mappage lorsque le taux d’actualisation est remplacé par un nonmultiple

Lorsque le taux d’actualisation est modifié pour un taux qui n’est pas un multiple du taux d’actualisation actuel (par exemple, de 24 Hz à 60 Hz), le système d’exploitation doit inspecter les flips de file d’attente pour voir si leur heure cible calculée est toujours valide pour le nouveau taux d’actualisation. Si l’heure de rafraîchissement cible doit être modifiée, le système d’exploitation annule les rafraîchissements en attente et les planifie à nouveau avec les heures de rafraîchissement cibles nouvellement calculées.