Partager via

Chemin de présentation DXGI

  • Article

DXGI fournit aux applications 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 entre plusieurs exemples d’alias (MSAA), surveiller la rotation, les différences de taille et de format de mémoire tampon 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 les surfaces pivotées, car DXGI fournit un DDI « sans état ». Dans un DDI sans état, le pilote de l’adaptateur n’est pas nécessaire pour enregistrer des données entre les appels DDI.

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

Mode fenêtré avec DWM activé

En mode fenêtré avec le Gestionnaire Windows de bureau (DWM) sur la casse, DXGI communique avec DWM et ouvre une vue d’une ressource partagée qui est une cible de rendu pour le producteur DXGI et une texture pour DWM. Cette ressource partagée existe en plus des mémoires tampons d’arrière-mémoire que l’application crée. 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 l’étirement, la conversion de couleur et la 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 Présent défini dans le membre Flags de la structure DXGI_DDI_ARG_BLT vers laquelle pointe le paramètre pBltData . La définition de l’indicateur Présent indique que le pilote doit effectuer l’opération de manière atomique. Le pilote effectue l’opération bitblt de manière atomique pour réduire le risque de déchirement pendant que le DWM lit la ressource partagée pour la composition.

Mode fenêtré avec DWM désactivé

En mode fenêtré avec 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 n’importe quelle mémoire tampon arrière créée 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

La casse en plein écran est plus compliquée 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 basculement afin de réduire la bande passante et d’obtenir la synchronisation verticale. Les conditions suivantes peuvent empêcher l’utilisation d’une opération de retournement :

  • L’application n’a pas réallouer ses mémoires tampons arrière de manière à ce qu’elles correspondent à la surface primaire.

  • Le pilote a spécifié qu’il n’analysera pas la mémoire tampon principale (par exemple, parce que la mémoire tampon arrière est pivotée ou est MSAA).

  • L’application a spécifié qu’elle ne peut pas accepter l’abandon du runtime Direct3D du contenu de la mémoire tampon principale et n’a demandé qu’une seule mémoire tampon (total) dans la chaîne. (Dans ce cas, DXGI alloue une surface arrière et une surface primaire ; toutefois, DXGI utilise la fonction PresentDXGI du pilote avec l’indicateur Blt défini.)

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 l’indicateur Blt défini n’est pas non plus approprié (car la mémoire tampon arrière ne correspond pas exactement à la mémoire tampon avant), DXGI alloue la surface proxy. Cette surface de proxy correspond à la mémoire tampon frontale. Par conséquent, un basculement entre la surface du proxy et la mémoire tampon frontale devient possible. Si la surface de proxy existe, DXGI utilise la fonction BltDXGI du pilote avec l’indicateur Présent effacé (0) pour copier les mémoires tampons d’arrière-plan de l’application sur la surface 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 Flags de la structure DXGI_DDI_ARG_PRESENT pour déplacer les bits de surface proxy vers l’analyse.

Pour informer le pilote d’affichage en mode utilisateur que le pilote peut refuser l’analyse, le pilote reçoit des appels de création de ressources pour les 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 Transmission d’informations DXGI au moment de la création de la ressource.

DXGI définit l’indicateur DXGI_DDI_PRIMARY_OPTIONAL pour créer toutes les surfaces de mémoire tampon arrière (c’est-à-dire les surfaces facultatives) et ne définit pas l’indicateur pour une mémoire tampon frontale ou une surface proxy (autrement dit, une 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 Transmission 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 pas d’autre effet que d’amener DXGI à appeler la fonction PresentDXGI du pilote avec l’indicateur Blt défini au lieu de l’indicateur Flip .

Si DXGI_DDI_PRIMARY_OPTIONAL n’est pas défini pour une mémoire tampon frontale ou une surface de proxy, le pilote peut toujours refuser l’analyse en échouant l’appel de création de ressources avec le code d’erreur DXGI_DDI_ERR_UNSUPPORTED et la définition de 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 une mémoire insuffisante.

DXGI exploite cette méthodologie de refus lorsqu’il tente de créer une chaîne de présentation en plein écran pour une mémoire tampon MSAA ou arrière pivotée. Si le pilote n’analyse pas l’un de ces types ou les deux, le pilote refuse. 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 recule 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 disposer d’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 se désactive, DXGI crée une surface de proxy et appelle BltDXGI pour déplacer les données des mémoires tampons arrière 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 avant, 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 arrière soient étiquetées pour l’analyse sur un moniteur particulier lors de la création de ces mémoires tampons. Les mémoires tampons arrière fenêtrés ne peuvent pas encore être affectées définitivement à un moniteur particulier, car le moniteur est choisi dynamiquement lors de l’entrée en plein écran. Par conséquent, DXGI ne doit pas envoyer ces mémoires tampons de retour au pilote pour l’analyse (par le biais d’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 ou PresentDXGI du pilote (avec Blt défini) pour effectuer un bitblt sur une surface qui a été créée précédemment pour une opération de retournement. Cette situation ne devrait pas être un problème, mais 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 ré-exécution 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 non ê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 subit un retour en mode bitblt, car les mémoires tampons arrière de l’application ont été étiquetées pour un autre moniteur.

Enfin, vous devez être conscient de la situation qui se produit en ce qui concerne les mémoires tampons d’arrière MSAA si le pilote ne refuse 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 frontale MSAA par le biais d’opérations de retournement, et effectue une opération de résolution par ce qui équivaut au convertisseur numérique-vers-analogique (DAC). Dans ce cas, l’application peut redimensionner dynamiquement ses mémoires tampons arrière en mode plein écran, ce qui force DXGI à passer à l’appel de 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 avant correspondent toujours, DXGI spécifie que le pilote effectue un bitblt extensible sans résolution, éventuellement de conversion de couleur. Le pilote doit ensuite répliquer, sans résoudre, plusieurs échantillons dans la mémoire tampon avant, ce qui est nécessaire si un pilote choisit d’analyser MSAA.