File d’attente de basculement matériel

Cet article décrit la fonctionnalité de file d’attente inversée matérielle prise en charge à partir de Windows 11 (WDDM 3.0). La fonctionnalité de file d’attente de basculement matériel permet d’envoyer plusieurs images futures à la file d’attente du contrôleur d’affichage. Le processeur 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é énergétique 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 suspens qui doivent être présentées sur le VSync suivant. Le pilote 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 jeu à fréquence d’images élevée où plusieurs images sont rendues 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 de faible consommation pendant le traitement des trames en file d’attente, 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 d’envoyer 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 du matériel de base présente une solution qui permet au processeur d’entrer dans un état d’alimentation faible et de décharger le traitement des images en file d’attente vers le GPU.

Dans les scénarios de jeu antérieurs à WDDM 3.0, une fois que le GPU a terminé le rendu de la scène sur la mémoire tampon arrière de la chaîne d’échange, il y a un aller-retour vers le processeur afin de soumettre la demande de présentation du contenu du cadre à l’écran. Pour les charges de travail GPU lourdes qui se terminent à proximité du VSync, cet aller-retour peut retarder les images et manquer le temps cible prévu, ce qui entraîne des problèmes d’image observables. La section File d’attente de basculement matérielle avancée introduit un mécanisme pour éviter cet aller-retour du processeur et présenter des images terminées à l’écran avec une latence très faible. La file d’attente de basculement matérielle avancée nécessite à la fois la fonctionnalité de base de la file d’attente de basculement matériel et la fonctionnalité de planification de matériel GPU étape 2 pour être présente.

File d’attente de basculement matériel de base

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

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

Les DDIs de file d’attente de basculement matériels 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, ce qui améliore l’efficacité énergétique des scénarios de lecture vidéo sur du matériel compatible.

Le diagramme suivant illustre l’architecture proposée.

Avec l’approche de la file d’attente de basculement du matériel, les composants de l’application et du processeur Dxgkrnl sont entièrement inactifs pendant deux intervalles VSync entre les temps v2 et v4, ce qui permet au processeur d’entrer dans un état de faible consommation. Le processeur n’est averti que lorsque l’image N+2 pour laquelle l’application a demandé une attente est terminée.

File d’attente de basculement matérielle avancée

Dans les scénarios de jeu avant WDDM 3.0, une fois que le GPU a terminé de restituer la scène à la mémoire tampon arrière de la chaîne d’échange, il y a un aller-retour vers le processeur afin de soumettre la demande de présentation du contenu du cadre à l’écran. Le diagramme suivant illustre ce scénario.

Le coût de cet aller-retour peut entraîner l’absence de 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 des conditions d’attente qui permettent à l’affichage d’envoyer la demande de basculement une fois que le GPU est terminé, rendant le cadre sans aller-retour du processeur. Étant donné que la file d’attente de basculement matérielle peut envoyer l’image N juste terminée à l’affichage sans aller-retour processeur, elle peut éviter les images manquées, comme illustré dans le diagramme suivant.

Le reste de cet article traite de la fonctionnalité de base de la file d’attente de basculement du matériel.

Prise en charge de DDI

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

Vérification de la disponibilité des fonctionnalités

La file d’attente de basculement matériel nécessite l’activation/la désactivation de la négociation du système d’exploitation. Un KMD qui prend en charge la file d’attente de basculement matériel doit d’abord appeler DXGKCB_QUERYFEATURESUPPORT pendant l’heure de démarrage 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 basculement matériel.

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

Un KMD peut utiliser l’exemple de code suivant lors des étapes d’affichage de la file d’attente de basculement du matériel et 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 l’affichage du pilote, même s’il est possible d’activer la file d’attente de basculement du matériel sans activer la planification du matériel GPU, cette combinaison n’est pas officiellement prise en charge. Windows exige actuellement que la planification du matériel GPU soit activée pour que la file d’attente de basculement matérielle de base soit activée sur les pilotes officiellement publiés.

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

MaxHwQueuedFlips a été ajouté à DXGK_DRIVERCAPS pour indiquer la prise en charge de la file d’attente de basculement du 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 la 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 futures images qui peuvent être mises en file d’attente pour être affichées pour un VidPnSource donné sur le GPU. Le système d’exploitation respectera les restrictions fournies par le pilote sur le type de retournements 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 et ne doit pas être utilisé par les pilotes.

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

Lorsque le système d’exploitation envoie une demande de basculement à la file d’attente de basculement matérielle, il envoie également le temps de basculement cible. Le basculement peut être rendu visible par l’utilisateur une fois que l’heure de basculement cible a été atteinte.

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

Envoi de retournements en file d’attente

La structure DXGKARG_SETVIDPNSOURCEADDRESSWITHMULTIPLANEOVERLAY3 , qui est passée à la fonction de rappel DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 de KMD, a été modifiée comme suit pour permettre l’envoi de retournements en file d’attente :

• Les trois membres suivants ont été ajoutés à la structure DXGK_SETVIDPNSOURCEADDRESS_OUTPUT_FLAGS de OutputFlags. Pour plus d’informations sur ces membres, consultez Cas de nouvelles tentatives et d’échecs DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 .

  • 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, le cadre peut être envoyé à l’affichage tout en respectant VSync et en déchirant les indicateurs. En présence de flips 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 basculement 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 une séquence qui remonte dans le temps.

Cas de nouvelle tentative et d’échec de DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3

Échec de la mise en 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 alors que d’autres demandes de retournement sont en attente. Dans ce cas, KMD doit retourner STATUS_RETRY à partir de DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 et définir HwFlipQueueDrainNeeded égal à 1. Le système d’exploitation tentera de soumettre à nouveau la demande de basculement une fois que tous les flips en attente sur les plans affectés par ce retournement sont terminés et une fois l’heure cible atteinte.

Dans certains cas, le matériel d’affichage peut nécessiter l’achèvement des flips en attente sur tous les plans, et pas seulement ceux référencés par la demande de retournement entrante. Dans ce cas, les indicateurs HwFlipQueueDrainNeeded etHwFlipQueueDrainAllPlanes 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 les ressources internes, auquel cas les indicateurs HwFlipQueueDrainAllSources et HwFlipQueueDrainNeededed doivent être définis, et KMD doit retourner STATUS_RETRY.

En outre, KMD peut indiquer au système d’exploitation si la nouvelle soumission doit être effectuée à 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 basculements en attente sur ce VidPnSourceId, cette condition sera traitée comme un échec de paramètre non valide.

Il est important que la valeur de MaxHwQueuedFlips reflète toujours le nombre maximal de retournements de modification d’adresse uniquement qui peuvent être mis en file d’attente vers un plan MPO. Le mécanisme STATUS_RETRY doit être utilisé pour les demandes de retournement plus complexes qui ne peuvent pas être mises en file d’attente, telles que les modifications de configuration de plan.

Échec de paramètre non valide

Dans le modèle de file d’attente de basculement matériel, la gestion par le système d’exploitation des demandes de basculement ayant échoué a été retravaillée pour permettre une meilleure débogueur. Lorsque KMD ne parvient pas à traiter une demande inversée, il doit retourner STATUS_INVALID_PARAMETER à partir de 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 case activée de bogues : ce comportement est souvent activé sur les builds de développement/préversion pour une meilleure capacité de débogage à mesure que la condition d’échec se produit.
• Live Kernel Dump suivi d’un TDR : comportement de l’utilisateur final de vente au détail.

Spécification du comportement d’interruption VSync

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

Pour gérer tous ces cas, la structure de rappel et de rappel de pilote suivante ont été introduites :

• 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 basculement correspondant est terminé. Il est appelé 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 quelle que soit la valeur PresentId cible d’interruption. KMD est nécessaire pour stocker le dernier ID présent de cible d’interruption afin qu’il puisse être respecté une fois que VSync est à nouveau activé.

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

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

• Lorsque l’ID présent cible est défini sur 0, des interruptions sont requises pour chaque VSync.

• Pour toute autre valeur d’ID présent, les interruptions sont déclenchées si l’id PresentId >actuellement analysé = InterruptTargetPresentId.

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

Désactivation de VSync à 2 étapes avec DxgkDdiSetInterruptTargetPresentId

Si l’appel du système d’exploitation à DxgkDdiSetInterruptTargetPresentId définit un InterruptTargetPresentId sur un plan qui entraînerait la désactivation de VSync entièrement sur ce VidPnSource (autrement dit, ce plan était le dernier plan qui avait maintenu VSync activé, et maintenant il désactive également VSync), KMD doit désactiver les interruptions VSync, mais conserver la phase VSync dans le matériel activée (DXGK_VSYNC_DISABLE_KEEP_PHASE). Après une certaine période (généralement équivalente à deux périodes VSync), le système d’exploitation effectue 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 pour économiser une puissance maximale et maintenir la parité des performances avec les systèmes de file d’attente inversée non matériels.

Annulation de retournement en file d’attente

Dans les cas tels que les transitions d’état en plein écran ou les sorties d’application, les futurs retournements en file d’attente peuvent devoir être annulés. Pour gérer ces cas, le rappel de pilote suivant et les structures associées ont été introduits :

• 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 en file d’attente à annuler lorsqu’il appelle DxgkDdiCancelFlips, et KMD signale au système d’exploitation la plage de flips qu’il a pu annuler de manière synchrone.

L’exemple suivant illustre la mécanique et le cas synchrone d’annulation de retournement 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 de basculement matériel :

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

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

Lorsque KMD inspecte l’état de la file d’attente de basculement matériel, il a déterminé que le basculement N+2 a déjà été envoyé au matériel d’affichage et ne peut pas être annulé au moment de l’appel, mais que N+3 et N+4 peuvent être supprimés de manière synchrone de la file d’attente de basculement matériel sans effets secondaires. 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 étant annulé, et il traite N, N+1, N+2 comme étant en version d’évaluation. Lorsque les interruptions VSync suivantes sont déclenchées, le journal de la file d’attente inversée 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, lorsqu’elle n’est pas égale à zéro, elle est supposée inclure le dernier ID présent soumis à KMD. En d’autres termes, il ne peut y avoir d’écarts à l’intérieur des deux plages de retournements annulés synchrones.

Annulation des retournements verrouillé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 est le suivant :

• L’ensemble de 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 basculement matériel, ces retournements verrouillés sont annulés en passant plusieurs plans et PresentIds dans l’appel à DxgkDdiCancelFlips. L’ensemble des plans transmis dans de tels cas doit correspondre à une demande de retournement verrouillée en attente, et la décision de KMD concernant tous les PresentIds verrouillés doit être la même :

• N’annulez pas, ou
• Annuler de manière synchrone

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

Obtention des statistiques présentes pour les flips en file d’attente

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

Les pilotes graphiques qui prennent en charge la file d’attente de basculement matériel sont nécessaires pour écrire des informations pour chaque basculement terminé ou annulé par un plan MPO donné pour chaque VidPnSource actif vers la mémoire tampon de journal de file d’attente de basculement fournie par le système d’exploitation.

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 journal avant le prochain appel DxgkDdiSetVidPnSourceAddress . Le journal de la file d’attente inversée est circulaire. Une fois l’entrée [NumberOfEntries-1] écrite, l’entrée de journal suivante est [0].

Une fois qu’un lot de flips en file d’attente est terminé, KMD doit garantir que le journal de la file d’attente inversée pour les flips terminés est mis à jour au plus tôt de ces deux points dans le temps :

• Gestionnaire d’interruptionS VSync pour un flip qui nécessitait la levée d’une interruption.
• En réponse à une requête DxgkDdiUpdateFlipQueueLog explicite du système d’exploitation.

Retourner les DDIs du journal de file d’attente

Le rappel suivant lié au journal de file d’attente inversée 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 afin d’implémenter des interruptions VSync pour le modèle de file d’attente de basculement matériel :

• La valeur d’énumération DXGK_INTERRUPT_CRTC_VSYNC_WITH_MULTIPLANE_OVERLAY3 a été ajoutée en tant que Type d’interruption.
• 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 PresentId terminé pour chaque plan, CrtcVSyncWithMultiPlaneOverlay3.pMultiPlaneOverlayVSyncInfo pointe vers la plage de PresentIds non signalés auparavant dans le 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.

Utilisation de l’exemple de file d’attente de basculement matériel de base :

Supposons que FirstFreeFlipQueueLogEntryIndex a été défini sur 40 au moment de l’envoi du flip N , puis que N, N+1, N+2 présentes ont été terminés.

Une fois qu’une configuration de plan unique a terminé trois PresentIds N, N+1 et N+2 à des moments respectifs v2, v3, v4, KMD aura écrit trois nouvelles entrées dans sa mémoire tampon de journal de file d’attente inversée avec les 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 suivantes de mémoire tampon de journal de file d’attente inversée comme suit :

• 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 file d’attente inversée explicite

Il existe des cas où le système d’exploitation doit obtenir des informations sur le dernier lot terminé de flips sans avoir à attendre l’interruption de VSync. Dans ce cas, le système d’exploitation effectue un appel explicite à DxgkDdiUpdateFlipQueueLog pour demander que KMD lise à partir de sa structure de données matérielles d’affichage propriétaire et qu’il écrive des informations de basculement passées dans le journal de la file d’attente inversée. La sémantique du journal est identique à 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.

Changements de mode d’affichage et transitions d’alimentation en présence d’un flip en file d’attente dans la file d’attente de basculement matériel

Dxgkrnl s’assure que les basculements déjà en file d’attente dans la file d’attente de basculement matériel sont terminés ou annulés avant de lancer un changement de mode ou de mettre hors tension le moniteur.

Mappage des demandes présentes aux horodatages de file d’attente de basculement matériels

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

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

Sémantique des retournements déchirants et non déchirants

La sémantique des retournements est conceptuellement la même lorsque la file d’attente de basculement matérielle est activée. Une fois le TargetFlipTime atteint, KMD doit envoyer le flip à afficher tout en respectant les indicateurs tels que FlipImmediate, FlipImmediateNoTearing et FlipOnNextVSync. En d’autres termes, KMD doit se comporter comme si le système d’exploitation lui avait envoyé le flip exactement à TargetFlipTime avec les mêmes indicateurs de basculement et paramètres.

Par exemple, si FlipOnNextVSync a la valeur 1 et que le TargetFlipTime se trouve au milieu du cadre, ce retournement ne doit être affiché que sur le VSync suivant.

Prise en charge de FlipOverwrite et file d’attente de basculement matérielle

La file d’attente de basculement matériel est un sur-ensemble strict de la fonctionnalité de remplacement de basculement 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 basculement matériel en définissant MaxHwQueuedFlips sur une valeur supérieure à 1.

Plusieurs retournements 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 d’affichage matériel doit sélectionner le flip expiré le plus récemment mis en file d’attente et le soumettre à l’affichage. Le reste des flips expirés doit être traité comme annulé, et les entrées de journal de file d’attente inversées correspondantes doivent contenir DXGK_HWFLIPQUEUE_TIMESTAMP_CANCELLED en tant que valeurs PresentTimestamp .

Interaction entre Duration et TargetFlipTime

Le paramètre Duration dans la structure DXGKARG_SETVIDPNSOURCEADDRESSWITHMULTIPLANEOVERLAY3 doit prendre effet lorsque le basculement spécifié dans cette structure s’affiche à 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 2022, afin de simplifier l’implémentation de pilotes pour le matériel qui ne prend pas en charge les modifications de durée personnalisées en file d’attente, le système d’exploitation envoie uniquement des demandes de basculement avec un nouveau paramètre Duration une fois que les demandes de basculement précédentes ont été effectuées.

Mappage des intervalles présents à TargetFlipTime

Intervalles de mappage lorsque le taux d’actualisation est fixe

Pour conserver la sémantique de l’intervalle présent existant, le système d’exploitation doit calculer le temps de basculement cible à l’aide de l’intervalle actuel et du taux d’actualisation. Toutefois, la définition de l’heure de basculement cible exactement sur l’heure VSync prévue à laquelle le basculement doit atteindre l’écran entraîne des problèmes fréquents en raison de la synchronisation VSync manquée au cas où le minutage VSync réel dérive un peu. Pour se prémunir contre les problèmes, 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 actuel au temps de basculement cible :

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

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

La fonctionnalité de fréquence d’actualisation virtuelle peut temporairement augmenter le taux d’actualisation d’affichage à un multiple entier du taux d’actualisation actuel (autrement dit, 24 Hz peut être augmenté à 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 autre que multiple

Lorsque le taux d’actualisation est remplacé par un autre que multiple d’un taux d’actualisation actuel (par exemple, de 24 Hz à 60 Hz), le système d’exploitation doit inspecter les retournements de file d’attente pour voir si son temps cible calculé est toujours valide compte tenu du nouveau taux d’actualisation. Si le temps de basculement cible doit être modifié, le système d’exploitation annule les basculements en file d’attente et les met en file d’attente avec les temps de basculement cible nouvellement calculés.