Partager via

File d'attente matérielle des basculements

  • Article

Cet article décrit la fonctionnalité de file d'attente matérielle des basculements qui est 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. Le processeur et certaines parties du GPU peuvent passer à des états de faible consommation d'énergie tandis que le contrôleur d'affichage traite plusieurs images en file d'attente, ce qui permet des économies d'énergie dans les scénarios de lecture vidéo sur du matériel compatible.

Modèle de file d'attente des basculements avant WDDM 3.0

De nombreux contrôleurs d'affichage modernes prennent en charge la possibilité de mettre en file d'attente plusieurs images à afficher dans une séquence. À compter de WDDM 2.1, le système d'exploitation prend en charge plusieurs requêtes d'écrasement de basculement en suspens destinées à être présentées à la prochaine synchronisation verticale. Le pilote de miniport d'affichage (KMD) indique cette prise en charge à travers la valeur MaxQueuedMultiPlaneOverlayFlipVSync dans DXGK_DRIVERCAPS. Cette capacité est utile pour réduire la latence dans les scénarios de jeux à fréquence d'images élevée, où plusieurs images sont rendues de façon séquentielle avec un intervalle 0, dans le but de n'afficher que l'image la plus récente.

Dans les scénarios de lecture vidéo, les contenus de plusieurs futures images à afficher de façon séquentielle sont connus à l'avance et peuvent être mis en file d'attente vers le GPU. Cette mise en file d'attente anticipée permet au processeur d'entrer dans un état de faible consommation d'énergie tandis que les images mises en file d'attente sont traitées, ce qui permet d'importantes économies d'énergie. 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 matérielle de base des basculements présente une solution qui permet au processeur d'entrer en état de faible consommation d'énergie et de délester 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 dans la mémoire tampon d'arrière-plan de la chaîne d'échange, il se produit un aller-retour avec le processeur pour envoyer la requête de présentation des contenus de 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 tour d’aller-retour processeur et présenter des images terminées à l’écran avec une faible latence. La file d'attente matérielle avancée des basculements nécessite la présence des fonctionnalités de file d'attente matérielle de base des basculements et de l'étape 2 de planification matérielle du GPU.

File d'attente matérielle de base des basculements

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

Diagramme illustrant le cas de trois images, chacune restant à l'écran pendant un intervalle VSync.

Les parties pleines du diagramme montrent les moments où les threads de traitement et d'application de file d'attente des basculements du logiciel Dxgkrnl doivent sortir de veille et effectuer le travail du processeur. À chaque VSync, le contrôleur d'affichage doit émettre une notification du processeur au système d'exploitation lorsque le basculement est terminé, et ce dernier doit envoyer la requête de basculement suivante. L'application doit également sortir de veille à chaque VSync et interroger les statistiques présentes pour savoir quand la dernière image du lot de trois s'affiche.

Les DDI de file d'attente matérielle des basculements capables d'envoyer plusieurs futures images à 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 montre l'architecture proposée.

Diagramme illustrant le mécanisme de file d'attente matérielle de base des basculements.

Avec l'approche de file d'attente matérielle des basculements, les composants de l'application et du processeur Dxgkrnl sont totalement inactifs pendant deux intervalles VSync entre les temps v2 et v4, ce qui permet au processeur d'entrer dans un état de faible consommation d'énergie. Le processeur est informé uniquement lorsque l'image N+2 pour laquelle l'application a demandé une attente est terminée.

File d'attente matérielle avancée des basculements

Dans les scénarios de jeu antérieurs à WDDM 3.0, une fois que le GPU a terminé le rendu de la scène dans la mémoire tampon d'arrière-plan de la chaîne d'échange, il se produit un aller-retour avec le processeur pour envoyer la requête de présentation des contenus de l'image à l'écran. Le diagramme qui suit illustre ce scénario.

Diagramme illustrant le besoin d'un aller-retour avec le processeur pour afficher les images.

Le coût de cet aller-retour peut amener les images à manquer leur cible si le rendu se termine trop près de la synchronisation verticale, comme le montre le diagramme suivant.

Diagramme illustrant comment une image manque sa cible en raison du besoin d'un aller-retour avec le processeur.

Certains contrôleurs d'affichage prennent en charge en mode natif des conditions d'attente qui permettent à l'affichage d'envoyer la requête de basculement une fois que le GPU a terminé le rendu de l'image, sans besoin d'aller-retour avec le processeur. Étant donné que la file d’attente de retour matériel peut envoyer le cadre N terminé à l’affichage sans aller-retour du processeur, il peut éviter les images manquées, comme illustré dans le diagramme suivant.

Diagramme pour l'affichage complet des images sans besoin d'aller-retour avec le processeur.

Le reste de cet article traite de la fonctionnalité de file d'attente matérielle de base des basculements.

Prise en charge de DDI

Les DDI suivants ont été ajoutés pour prendre en charge la fonctionnalité de file d'attente matérielle des basculements.

Vérification de la disponibilité de la fonctionnalité

La file d'attente matérielle des basculements requiert l'activation/désactivation de la négociation du système d'exploitation. Un KMD qui prend en charge la file d'attente matérielle des basculements doit d'abord appeler DXGKCB_QUERYFEATURESUPPORT au moment du 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 matérielle des basculements.

La file d'attente matérielle des basculements ne peut être utilisée que si le rappel s'est produit correctement et si Enable est défini sur TRUE.

Un KMD peut utiliser l'exemple de code suivant pendant les étapes de mise en place et d'expérimentation de la file d'attente matérielle des basculements.


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 place du pilote, même s'il est possible d'activer la file d'attente matérielle des basculements sans activer la planification matérielle du GPU, cette combinaison n'est pas officiellement prise en charge. À l'heure actuelle, Windows exige que la planification matérielle du GPU soit activée afin que la file d'attente matérielle de base des basculements puisse être activée sur les pilotes officiellement publiés.

Indication des capacité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 matérielle des basculements. 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, le KMD indique que le matériel d'affichage prend en charge jusqu'à MaxHwQueuedFlips 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 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 ; les pilotes ne doivent pas l’utiliser.

Format du temps cible de basculement et de l'horodatage cible

Lorsque le système d'exploitation envoie une requête de basculement à la file d'attente matérielle des basculements, il envoie également le temps cible de basculement. Le retournement peut être rendu visible par 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 transmettre le temps cible et interpréter le temps réel de basculement.

Soumission de basculements mis en file d'attente

La structure DXGKARG_SETVIDPNSOURCEADDRESSWITHMULTIPLANEOVERLAY3, qui est transmise à la fonction de rappel DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 du KMD, a été modifiée comme suit pour permettre la soumission de basculements mis en file d'attente :

  • Les trois membres suivants ont été ajoutés à la structure DXGK_SETVIDPNSOURCEADDRESS_OUTPUT_FLAGS de OutputFlags. Pour en savoir plus sur ces membres, veuillez consulter Cas de nouvelles tentatives et d'échecs DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3.

    • HwFlipQueueDrainNeeded
    • HwFlipQueueDrainAllPlanes
    • HwFlipQueueDrainAllSources

  • Un membre TargetFlipTime a été ajouté. TargetFlipTime décrit le temps cible de basculement dans les 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 déchirement. En présence de basculements en suspens précédemment mis en file d'attente, le système d'exploitation garantit que pour chaque plan MPO référencé par la requête de basculement, TargetFlipTime est supérieur ou égal à l'un des temps cibles de basculement en suspens pour ce plan. En d'autres termes, il peut y avoir une séquence de basculements avec des horodatages identiques ou croissants, mais il ne peut pas y avoir de séquence qui remonte dans le temps.

Cas de nouvelles tentatives et d'échecs DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3

Échec de la mise en file d'attente de la requête au matériel en raison de basculements en suspens

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 de tels cas, le KMD doit retourner STATUS_RETRY depuis DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 et définir HwFlipQueueDrainNeededed égal sur 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 le KMD doit retourner STATUS_RETRY.

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

En outre, le KMD peut indiquer au système d'exploitation si la nouvelle soumission 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 d’flips en attente sur ce VidPnSourceId, cette condition est 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 basculements d'une simple adresse pouvant être mis en file d'attente vers un plan MPO. Le mécanisme STATUS_RETRY doit être utilisé pour les requêtes de basculement plus complexes, qui ne peuvent pas être totalement mises en file d'attente, comme les modifications de configuration de plan.

Échec de paramètre non valide

Dans le modèle de file d'attente matérielle des basculements, le traitement, par le système d'exploitation, des requêtes de basculement ayant échoué, a été modifié pour permettre une meilleure capacité de débogage. Lorsque le KMD ne parvient pas à traiter une requête de basculement, 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 vérification des bogues : ce comportement est souvent activé sur les builds de développement/préversion pour améliorer la débogueur à mesure que la condition d’échec se produit.
  • Transfert mémoire du noyau actif suivi d'un TDR : comportement de l'utilisateur final dans les systèmes de vente au détail.

Spécification du comportement d'interruption VSync

Pour réaliser des économies d’alimentation dans les scénarios de basculement mis en file d’attente, le système d’exploitation suspend souvent les interruptions VSync régulières pour maintenir l’UC dans un état de faible puissance. 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’elles soient en attente ou non. À l'inverse, sur un système totalement inactif, les interruptions VSync sont suspendues jusqu'à l'apparition d'une nouvelle activité de présentation ou d'écouteurs VSync.

Pour traiter tous ces cas, la structure de rappel et la structure de rappel de pilote suivantes ont été introduites :

Le 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 lorsque le basculement 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 du PresentId cible d'interruption. Il est demandé au KMD de stocker le PresentId cible d'interruption le plus récent afin que celui-ci puisse être respecté lorsque VSync est de nouveau activé.

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

  • Lorsque le PresentId cible est défini sur UINT64_MAX, aucune interruption VSync n'est requise jusqu'à ce que le PresentId cible soit à nouveau modifié. Les interruptions VSync sont désactivées, mais il est demandé au KMD d'implémenter le comportement DXGK_VSYNC_DISABLE_KEEP_PHASE pour réactiver les interruptions.

  • Lorsque le PresentId cible est défini sur 0, des interruptions sont nécessaires pour chaque VSync.

  • Pour toute autre valeur de PresentId, les interruptions sont déclenchées si le 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 VSync en 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 complète de VSync sur ce 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 de synchronisation VSync activée (DXGK_VSYNC_DISABLE_KEEP_PHASE). Après une certain temps (généralement équivalent à deux périodes VSync), le système d'exploitation effectue un suivi via 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 d’économiser la puissance maximale et de maintenir la parité des performances avec les systèmes de file d’attente de retournement non partitionware.

Annulation de basculements mis en file d'attente

Dans les cas tels que les transitions d'état plein écran ou les sorties d'application, il peut être nécessaire d'annuler de futurs basculements mis en file d'attente. Pour traiter ces cas, le rappel de pilote et les structures connexes suivants ont été introduits :

Le KMD fournit un pointeur vers sa fonction DxgkDdiCancelFlips dans DRIVER_INITIALIZATION_DATA.

Le système d'exploitation spécifie la plage des basculements mis en file d'attente à annuler lorsqu'il appelle DxgkDdiCancelFlips, et le KMD renvoie au système d'exploitation la plage de basculements qu'il a été capable d'annuler de manière synchrone.

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

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

Le système d'exploitation décide ensuite d'annuler les basculements N+2, N+3 et N+4, c'est pourquoi il appelle DxgkDdiCancelFlips avec PresentIdCancelRequested défini sur N+2.

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

  • Retourner N+2 est déjà envoyé au matériel d’affichage et ne peut pas être annulé au moment de l’appel.
  • Les retournements N+3 et N+4 peuvent être supprimés de manière synchrone de la file d’attente de retournement 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 des basculements indique les horodatages pour N, N+1, N+2 comme à l'habitude.

La plage de basculements annulés de manière synchrone doit être continue ; quand elle n'est pas nulle, elle est supposée inclure le dernier PresentId envoyé au KMD. Autrement dit, il ne peut y avoir aucune séparation entre deux plages de basculements annulés synchrones.

Annulation de basculements verrouillés sur plusieurs plans

Un basculement verrouillé est envoyé via l'appel DxgkDdiSetVidPnSourceAddress avec plusieurs plans et PresentIds. Le contrat entre le système d'exploitation et le KMD se poursuit :

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

Dans le modèle de file d'attente matérielle des basculements, ces basculements verrouillés sont annulés en transmettant plusieurs plans et PresentIds dans l'appel à DxgkDdiCancelFlips. L'ensemble des plans transmis dans ces cas doit correspondre à une requête de basculements verrouillés en suspens, et la décision du KMD concernant tous les PresentIds verrouillé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 l'interruption DxgkDdiSetVidPnSourceAddress et VSync.

Obtention de statistiques présentes pour les basculements mis en file d'attente

Étant donné que l'approche de file d'attente matérielle des basculements consiste à éviter de sortir de veille le processeur sur chaque VSync, il doit y avoir un mécanisme capable de conserver les temps d'affichage des images pour les derniers basculements 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 retournée fournie par le système d’exploitation pour chaque retournement terminé ou annulé 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 des basculements lorsque cette dernière n'a pas de requête en suspens. Dans ce cas, il fournit un nouveau pointeur de journal avant l’appel DxgkDdiSetVidPnSourceAddress suivant. Le journal de file d'attente des basculements est circulaire. Une fois l’entrée [NumberOfEntries-1] écrite, l’entrée de journal suivante est [0].

Lorsqu'un lot de basculements mis en file d'attente est terminé, le KMD doit garantir que le journal de file d'attente des basculements terminés est mis à jour au plus tôt des deux instants suivants :

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

DDI du journal de file d'attente des basculements

Les rappels associés au journal de file d'attente des basculements suivants ont été ajoutés, avec les structures associées :

Le 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 en vue d'implémenter des interruptions VSync pour le modèle de file d'attente matérielle des basculements :

  • La valeur d'énumération DXGK_INTERRUPT_CRTC_VSYNC_WITH_MULTIPLANE_OVERLAY3 a été ajoutée comme 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 PresentId correspondant au dernier réalisé pour chaque plan, CrtcVSyncWithMultiPlaneOverlay3.pMultiPlaneOverlayVSyncInfo pointe vers la plage des PresentIds précédemment non signalés à partir du journal de file d'attente des basculements.
  • La structure DXGK_MULTIPLANE_OVERLAY_VSYNC_INFO3 a été ajoutée pour le membre pMultiPlaneOverlayVSyncInfo de CrtcVSyncWithMultiPlaneOverlay3.

Revenant au diagramme de l'exemple de file d'attente matérielle de base des basculements :

Diagramme illustrant le mécanisme de file d'attente matérielle de base des basculements.

Supposons que FirstFreeFlipQueueLogEntryIndex était défini sur 40 au moment où le basculement N a été envoyé, puis les présentations N, N+1, N+2 ont été réalisées.

Une fois qu’une configuration de plan unique a terminé trois PresentIds N, N+1 et N+2 respectivement v2, v3, v4, KMD a écrit trois nouvelles entrées dans sa mémoire tampon de journal de file d’attente inversée avec des index 40, 41 et 42. Le KMD signale une valeur FirstFreeFlipQueueLogEntryIndex égale à 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. Le KMD a besoin de définir les valeurs suivantes de la mémoire tampon du journal de file d'attente des basculements :

  • 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

Requête explicite de mise à jour du journal de file d'attente des basculements

Il arrive que le système d'exploitation ait besoin d'obtenir des informations sur le dernier lot de basculements réalisés sans avoir à attendre l'interruption VSync. Dans de tels cas, le système d'exploitation lance un appel explicite à DxgkDdiUpdateFlipQueueLog pour demander au KMD de lire dans sa structure de données du matériel d'affichage propriétaire et d'écrire les informations relatives aux basculements passés dans le journal de file d'attente de renversement. La sémantique du journal est la même que celle décrite précédemment ; la seule différence 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 se trouve dans la même classe de synchronisation que le DDI DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3.

Modifications du mode d'affichage et transitions d'alimentation en présence d'un basculement en suspens 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 de présentation aux horodatages de file d'attente matérielle des basculements

Lorsque la file d’attente de retournement matérielle est activée sur un adaptateur particulier, un horodatage accompagne tous les appels de retournement. 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 plusieurs cas et la façon dont ceux-ci sont mappés à une combinaison d'indicateurs, Duration, et les horodatages reçus par le KMD.

La sémantique de la déchirure et de la non-mise à jour de la sémantique

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

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 matérielle des basculements

La file d'attente matérielle des basculements est un super-ensemble strict de la fonctionnalité d'écrasement 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 choisit, dans la file d'attente matérielle des basculements, de donner à MaxHwQueuedFlips une valeur supérieure à 1.

Plusieurs basculements avec un TargetFlipTime expiré

Lorsque plusieurs basculements avec un TargetFlipTime expiré sont mis en attente pour un plan MPO donné, la file d'attente d'affichage matériel doit choisir le basculement expiré introduit le plus récemment dans la file d'attente et l'envoyer à l'affichage. Les autres basculements expirés doivent être traités comme annulés, et les entrées de journal de file d'attente des basculements correspondantes doivent contenir DXGK_HWFLIPQUEUE_TIMESTAMP_CANCELLED comme valeurs PresentTimestamp.

Interaction entre Duration et TargetFlipTime

Le paramètre Duration de 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 souhaité pour la fréquence d'actualisation de l'affichage au niveau de la sortie spécifiée par VidPnSourceId dans 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 de présentation à TargetFlipTime

Intervalles de mappage lorsque la fréquence d'actualisation est fixe

Pour conserver la sémantique existante de l'intervalle de présentation, le système d'exploitation doit calculer le temps cible de basculement à l'aide de l'intervalle de présentation et de la fréquence 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 erreurs sont dues à la synchronisation VSync manquée lorsque le minutage VSync réel dérive un peu. Pour prévenir les bugs visuels, le système d'exploitation soustrait la moitié de l'intervalle VSync du temps cible de basculement.

Voici une formule simplifiée pour mapper l'intervalle de présentation au temps cible de basculement :

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

Intervalles de mappage lorsque la fonctionnalité WDDM 2.9 de la fréquence d'actualisation virtuelle 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 de la fréquence d'actualisation actuelle :

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 remplacé par un non-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 leur heure cible calculée est toujours valide pour le nouveau taux d’actualisation. Si l’heure de retournement cible doit être modifiée, le système d’exploitation annule les retournements mis en file d’attente et les met en file d’attente avec les temps de retournement de cible nouvellement calculés.