Chemin de présentation DXGI

DXGI fournit des applications avec une méthodologie de présentation qui « fonctionne simplement ». Par exemple, les applications ne sont pas tenues d’effectuer des opérations spéciales pour passer du mode fenêtré au mode plein écran. Cette méthodologie de présentation est possible car DXGI et le pilote d'affichage en mode utilisateur fonctionnent ensemble pour préserver la présentation à travers des combinaisons de l'anticrénelage à échantillonnage multiple (MSAA), la rotation de l'écran, les différences de taille et de format entre les tampons arrière et avant, ainsi que les modes plein écran et fenêtré. Un autre avantage de DXGI est qu’il permet à un adaptateur d’affichage d’avoir une capacité limitée à analyser MSAA et à faire pivoter les surfaces, car DXGI fournit un DDI « sans état ». Dans une DDI sans état, le pilote de l'adaptateur n'a pas besoin d'enregistrer les données entre les appels DDI.

La tâche de base de la présentation consiste à déplacer des données d’une mémoire tampon de retour rendue vers la surface primaire pour l’affichage. Cette tâche est effectuée dans les différentes situations décrites dans les sections suivantes.

Mode fenêtré avec DWM activé

Dans le mode fenêtré lorsque le Gestionnaire de fenêtres du bureau (DWM) est activé, DXGI communique avec DWM et crée une vue d'une ressource partagée qui sert de cible de rendu pour le producteur DXGI et de texture pour DWM. Cette ressource partagée existe en plus des mémoires tampons back-end créées par l’application. DXGI appelle la fonction BltDXGI du pilote pour déplacer les données de l’une des mémoires tampons arrière vers la surface partagée. Cette opération peut nécessiter un étirement, une conversion des couleurs et une résolution MSAA. Toutefois, cette opération ne nécessite jamais de sous-rectangles source et de destination. En fait, ces sous-rectangles ne peuvent pas être exprimés dans l’appel à BltDXGI. Ce transfert de bloc de bits (bitblt) a toujours l’indicateur Present défini dans le membre Indicateurs de la structure DXGI_DDI_ARG_BLT vers laquelle le paramètre pBltData pointe. La définition de l’indicateur Present indique que le pilote doit effectuer l’opération de manière atomique. Le pilote effectue l’opération BitBlt atomiquement pour réduire la possibilité de déchirure pendant que le DWM lit la ressource partagée pour la composition.

Mode fenêtré avec DWM désactivé

Dans le mode fenêtré avec le cas DWM-off, DXGI appelle la fonction PresentDXGI du pilote avec l’indicateur Blt défini dans le membre Flags de la structure DXGI_DDI_ARG_PRESENT vers laquelle pointe le paramètre pPresentData. Dans cet appel PresentDXGI, DXGI peut spécifier l’une des mémoires tampons back créées par l’application dans les membres hSurfaceToPresent et SrcSubResourceIndex de DXGI_DDI_ARG_PRESENT. Il n’existe aucune surface partagée supplémentaire.

Mode plein écran

Le cas plein écran est plus compliqué que le mode fenêtré avec DWM activé ou désactivé.

Lorsque DXGI effectue la transition vers le mode plein écran, il tente d'exploiter une opération de bascule afin de réduire la bande passante et d'obtenir une synchronisation verticale. Les conditions suivantes peuvent empêcher l’utilisation d’une opération de retournement :

• L’application n’a pas réaffecté ses tampons de fond de manière à ce qu’ils correspondent à la surface primaire.

• Le pilote a spécifié qu’il n’analysera pas le tampon arrière (par exemple, car le tampon arrière est tourné ou est en MSAA).

• L’application a spécifié qu'il est impossible d'accepter que l'environnement d'exécution Direct3D écarte le contenu de la mémoire tampon d'arrière-plan et a demandé seulement un seul tampon (au total) dans la chaîne. (Dans ce cas, DXGI alloue une surface arrière et une surface principale ; toutefois, DXGI utilise la fonction PresentDXGI du pilote avec le jeu d’indicateurs Blt .)

Lorsque l’une des conditions précédentes s’est produite, empêchant ainsi une opération de retournement et un appel à la fonction PresentDXGI du pilote avec le jeu d’indicateurs Blt n’est pas approprié (car la mémoire tampon arrière ne correspond pas exactement à la mémoire tampon frontale), DXGI alloue la surface du proxy. Cette surface proxy correspond à la mémoire tampon frontale. Par conséquent, un retournement entre la surface du proxy et la mémoire tampon frontale devient possible. Si la surface du proxy existe, DXGI utilise la fonction BltDXGI du pilote avec l’indicateur Present effacé (0) pour copier les mémoires tampons back de l’application dans la surface du proxy. Dans cet appel BltDXGI , DXGI peut demander la conversion, l’étirement et la résolution. DXGI appelle ensuite la fonction PresentDXGI du pilote avec l’indicateur Flip défini dans le membre Indicateurs de la structure DXGI_DDI_ARG_PRESENT pour déplacer les bits de surface proxy vers l’analyse.

Pour avertir le pilote d’affichage en mode utilisateur que le pilote peut désactiver l’analyse, le pilote reçoit des appels de création de ressources pour des classes facultatives et non facultatives de surfaces d’analyse. Les surfaces d’analyse facultatives sont désignées par l’indicateur DXGI_DDI_PRIMARY_OPTIONAL. Les surfaces d’analyse non facultatives n’ont pas l’indicateur DXGI_DDI_PRIMARY_OPTIONAL défini. Pour plus d’informations sur ces types d’appels de création de ressources, consultez Passage d’informations DXGI au moment de la création des ressources.

DXGI définit l’indicateur DXGI_DDI_PRIMARY_OPTIONAL pour créer toutes les surfaces de mémoire tampon arrière (c’est-à-dire, surfaces facultatives) et ne définit pas l’indicateur pour toute mémoire tampon frontale ou surface proxy (autrement dit, surface non facultative).

Si DXGI_DDI_PRIMARY_OPTIONAL est défini pour une mémoire tampon arrière, le pilote peut définir l’indicateur DXGI_DDI_PRIMARY_DRIVER_FLAG_NO_SCANOUT. Pour plus d’informations sur la définition de cet indicateur, consultez Passage d’informations DXGI au moment de la création de la ressource. Si le pilote définit DXGI_DDI_PRIMARY_DRIVER_FLAG_NO_SCANOUT pour une mémoire tampon facultative, cela n’a aucun effet autre que d'entraîner l'appel de la fonction PresentDXGI du pilote avec l’indicateur Blt défini, au lieu de l’indicateur Flip défini.

Si DXGI_DDI_PRIMARY_OPTIONAL n'est pas activé pour un tampon avant ou la surface de proxy, le pilote peut toujours refuser le scan-out en échouant l'appel à la création de la ressource avec le code d'erreur DXGI_DDI_ERR_UNSUPPORTED et en définissant DXGI_DDI_PRIMARY_DRIVER_FLAG_NO_SCANOUT.

Note L’échec de l’appel de création sans définir DXGI_DDI_PRIMARY_DRIVER_FLAG_NO_SCANOUT est réservé aux cas d’échec réels, comme la mémoire insuffisante.

DXGI exploite cette méthodologie d’annulation lorsqu’elle tente de créer une chaîne de présentation en plein écran pour une mémoire tampon MSAA ou pivotée. Si le pilote n’analyse aucun ou les deux types de ces types, le pilote se désengagera. DXGI tente ensuite de créer une surface non pivotée, une surface non MSAA ou les deux jusqu’à ce que le pilote accepte la création de la ressource. Par conséquent, DXGI se replie progressivement jusqu’à ce que la surface non facultative corresponde exactement au format de la mémoire tampon frontale, au nombre d’échantillons, à la rotation et à la taille.

Si le pilote refuse toute surface non facultative, DXGI doit toujours avoir un moyen de déplacer des bits de la mémoire tampon arrière vers la surface primaire. Par conséquent, si le pilote refuse l’analyse pour MSAA et la rotation, le pilote opte pour la résolution, la rotation ou les deux lorsque DXGI appelle la fonction BltDXGI du pilote. Lorsque le pilote désactive, DXGI crée une surface proxy et appelle BltDXGI pour déplacer les données des mémoires tampons de retour vers cette surface proxy. Le pilote ne doit pas avoir de raison de refuser cette surface de proxy, car le proxy correspond exactement à la mémoire tampon frontale.

Les situations inhabituelles suivantes se produisent lorsque l’application ne recrée pas ses surfaces après une transition vers ou hors mode plein écran :

• Si l’application ne recrée pas ses surfaces lorsqu’elle passe en mode plein écran, DXGI détermine que les mémoires tampons arrière ne correspondent pas à la mémoire tampon frontale, même si elles correspondent vraiment au format, à la taille, à la rotation et au nombre d’échantillons. La raison de cette détermination est que le système d’exploitation exige que les mémoires tampons de retour soient marquées pour l’analyse sur un moniteur particulier lorsque ces mémoires tampons sont créées. Les mémoires tampons arrière en mode fenêtré ne peuvent pas encore être affectées définitivement à un moniteur particulier, car le moniteur est choisi dynamiquement lorsque le mode plein écran est activé. Par conséquent, DXGI ne doit pas envoyer ces mémoires tampons de retour au pilote pour l’analyse (via une opération de retournement). Les applications de ce type forcent généralement DXGI à créer la surface proxy.

• Si l'application ne recrée pas ses mémoires tampons arrière lorsqu'elle revient en mode fenêtré, DXGI peut appeler le BltDXGI du pilote ou PresentDXGI (avec Blt défini) pour effectuer un bitblt sur une surface créée précédemment pour une opération de basculement. Cette situation ne devrait pas être un problème, mais elle est mentionnée ici pour l’exhaustivité. Notez que DXGI détruit toujours la surface du proxy lorsque l’application passe en mode fenêtré.

Notez également que les applications peuvent redimensionner dynamiquement leurs mémoires tampons arrière pendant que les applications sont en mode plein écran. Cette action entraîne la nouvelle occurrence de la logique décrite dans les situations précédentes. Par conséquent, la surface de proxy peut être créée et détruite, et la désactivation peut ou ne pas être nécessaire au fil du temps, même si l’application reste en mode plein écran. L’application peut également transférer sa sortie vers un autre moniteur dynamiquement sans quitter le mode plein écran. Par conséquent, l’application entraîne un retour en mode bitblt, car les mémoires tampons back de l’application ont été marquées pour un autre moniteur.

Enfin, vous devez être conscient de la situation qui se produit en ce qui concerne les mémoires tampons de retour MSAA si le pilote ne désactive pas l’analyse MSAA. Dans ce cas, le pilote opte pour l’analyse de MSAA. Par conséquent, DXGI échange la mémoire tampon arrière MSAA et la mémoire tampon avant MSAA via des opérations de retournement et effectue une opération de résolution par ce qui équivaut au convertisseur numérique à analogique (DAC). Dans ce cas, l’application peut redimensionner dynamiquement ses mémoires tampons arrière en mode plein écran, amenant DXGI à faire appel à la fonction BltDXGI du pilote. Étant donné que les caractéristiques MSAA de la mémoire tampon arrière et de la mémoire tampon frontale correspondent toujours, DXGI spécifie que le pilote effectue un étirement bitblt sans résolution, éventuellement avec conversion de couleur. Le pilote doit ensuite répliquer, sans résoudre, plusieurs échantillonnages vers la mémoire tampon frontale, ce qui est nécessaire si un pilote choisit d’analyser MSAA.