Vue d’ensemble de DXGI

Microsoft DirectX Graphics Infrastructure (DXGI) reconnaît que certaines parties des graphiques évoluent plus lentement que d’autres. L’objectif principal de DXGI est de gérer les tâches de bas niveau qui peuvent être indépendantes du runtime graphique DirectX. DXGI fournit une infrastructure commune pour les composants graphiques futurs ; le premier composant qui tire parti de DXGI est Microsoft Direct3D 10.

Dans les versions précédentes de Direct3D, des tâches de bas niveau telles que l’énumération des périphériques matériels, la présentation d’images rendues à une sortie, le contrôle gamma et la gestion d’une transition en plein écran étaient incluses dans le runtime Direct3D. Ces tâches sont désormais implémentées dans DXGI.

L’objectif de DXGI est de communiquer avec le pilote de mode noyau et le matériel système, comme illustré dans le diagramme suivant.

Une application peut accéder directement à DXGI ou appeler les API Direct3D dans D3D11_1.h, D3D11.h, D3D10_1.h ou D3D10.h, qui gère les communications avec DXGI pour vous. Vous pouvez utiliser DXGI directement si votre application doit énumérer des appareils ou contrôler la façon dont les données sont présentées à une sortie.

Cette rubrique contient les sections suivantes.

• Énumération des adaptateurs
  • Nouvelles informations sur l’énumération des cartes pour Windows 8
• Présentation
  • Créer une chaîne d’échange
  • Soins et alimentation de la chaîne d’échange
  • Gestion du redimensionnement des fenêtres
  • Choix de la sortie et de la taille DXGI
  • Débogage en mode Full-Screen
  • Destruction d’une chaîne d’échange
  • Utilisation d’un moniteur pivoté
  • Changement de mode
  • Conseil sur les performances en plein écran
  • Considérations relatives aux multithreads
• Réponses DXGI de DLLMain
• Modifications de DXGI 1.1
• Modifications de DXGI 1.2
• Rubriques connexes

Pour voir les formats pris en charge par le matériel Direct3D 11 :

• Prise en charge du format DXGI pour le matériel de niveau de fonctionnalité Direct3D 12.1
• Prise en charge du format DXGI pour le matériel de niveau de fonctionnalité Direct3D 12.0
• Prise en charge du format DXGI pour le matériel de niveau de fonctionnalité Direct3D 11.1
• Prise en charge du format DXGI pour le matériel de niveau de fonctionnalité Direct3D 11.0
• Prise en charge matérielle des formats Direct3D 10Level9
• Prise en charge matérielle des formats Direct3D 10.1
• Prise en charge matérielle des formats Direct3D 10

Énumération des adaptateurs

Un adaptateur est une abstraction du matériel et des fonctionnalités logicielles de votre ordinateur. Il existe généralement de nombreux adaptateurs sur votre ordinateur. Certains appareils sont implémentés dans le matériel (comme votre carte vidéo) et d’autres sont implémentés dans des logiciels (comme le rastériseur de référence Direct3D). Les adaptateurs implémentent les fonctionnalités utilisées par une application graphique. Le diagramme suivant montre un système avec un seul ordinateur, deux cartes (cartes vidéo) et trois moniteurs de sortie.

Lors de l’énumération de ces éléments matériels, DXGI crée une interface IDXGIOutput1 pour chaque sortie (ou moniteur) et une interface IDXGIAdapter2 pour chaque carte vidéo (même s’il s’agit d’une vidéo carte intégrée à une carte mère). L’énumération est effectuée à l’aide d’un appel d’interface IDXGIFactory, IDXGIFactory::EnumAdapters, pour retourner un ensemble d’interfaces IDXGIAdapter qui représentent le matériel vidéo.

DXGI 1.1 a ajouté l’interface IDXGIFactory1 . IDXGIFactory1::EnumAdapters1 retourne un ensemble d’interfaces IDXGIAdapter1 qui représente le matériel vidéo.

Si vous souhaitez sélectionner des fonctionnalités matérielles vidéo spécifiques lorsque vous utilisez des API Direct3D, nous vous recommandons d’appeler de manière itérative la fonction D3D11CreateDevice ou D3D11CreateDeviceAndSwapChain avec chaque handle d’adaptateur et le niveau de fonctionnalité matérielle possible. Cette fonction réussit si le niveau de fonctionnalité est pris en charge par l’adaptateur spécifié.

Nouvelles informations sur l’énumération des cartes pour Windows 8

À compter de Windows 8, un adaptateur appelé « Microsoft Basic Render Driver » est toujours présent. Cet adaptateur a un VendorId de 0x1414 et un DeviceID de 0x8c. Cette carte a également la valeur DXGI_ADAPTER_FLAG_SOFTWARE définie dans le membre Flags de sa structure DXGI_ADAPTER_DESC2 . Cet adaptateur est un périphérique de rendu uniquement qui n’a pas de sorties d’affichage. DXGI ne retourne jamais DXGI_ERROR_DEVICE_REMOVED pour cet adaptateur.

Si le pilote d’affichage d’un ordinateur ne fonctionne pas ou est désactivé, l’adaptateur principal (NULL) de l’ordinateur peut également être appelé « Microsoft Basic Render Driver ». Mais cet adaptateur a des sorties et n’a pas la valeur DXGI_ADAPTER_FLAG_SOFTWARE définie. Le système d’exploitation et les applications utilisent cette carte par défaut. Si un pilote d’affichage est installé ou activé, les applications peuvent recevoir des DXGI_ERROR_DEVICE_REMOVED pour cette carte, puis doivent réinscrire les cartes.

Lorsque l’adaptateur d’affichage principal d’un ordinateur est l'« adaptateur d’affichage Microsoft Basic » (adaptateur WARP ), cet ordinateur dispose également d’un deuxième adaptateur. Ce deuxième adaptateur est le périphérique de rendu uniquement qui n’a pas de sorties d’affichage et pour lequel DXGI ne retourne jamais DXGI_ERROR_DEVICE_REMOVED.

Si vous souhaitez utiliser WARP pour le rendu, le calcul ou d’autres tâches de longue durée, nous vous recommandons d’utiliser l’appareil de rendu uniquement. Vous pouvez obtenir un pointeur vers l’appareil de rendu uniquement en appelant la méthode IDXGIFactory1::EnumAdapters1 . Vous créez également le périphérique de rendu uniquement lorsque vous spécifiez D3D_DRIVER_TYPE_WARP dans le paramètre DriverType de D3D11CreateDevice , car le périphérique WARP utilise également l’adaptateur WARP de rendu uniquement.

Présentation

Le travail de votre application consiste à restituer des images et à demander à DXGI de présenter ces images à la sortie. Si l’application dispose de deux mémoires tampons disponibles, elle peut afficher une mémoire tampon tout en présentant une autre. L’application peut nécessiter plus de deux mémoires tampons en fonction du temps nécessaire au rendu d’une image ou de la fréquence d’images souhaitée pour la présentation. L’ensemble de mémoires tampons créées est appelé chaîne d’échange, comme illustré ici.

• Créer une chaîne d’échange
• Soins et alimentation de la chaîne d’échange
• Gestion du redimensionnement des fenêtres
• Choix de la sortie et de la taille DXGI
• Débogage en mode Full-Screen
• Destruction d’une chaîne d’échange
• Utilisation d’un moniteur pivoté
• Changement de mode
• Conseil sur les performances en plein écran
• Considérations relatives aux multithreads

Une chaîne d’échange a une mémoire tampon avant et une ou plusieurs mémoires tampons arrière. Chaque application crée sa propre chaîne d’échange. Pour optimiser la vitesse de présentation des données à une sortie, une chaîne d’échange est presque toujours créée dans la mémoire d’un sous-système d’affichage, comme illustré dans l’illustration suivante.

Le sous-système d’affichage (qui est souvent une vidéo carte mais qui peut être implémenté sur une carte mère) contient un GPU, un convertisseur numérique-analogique (DAC) et de la mémoire. La chaîne d’échange est allouée dans cette mémoire pour rendre la présentation très rapide. Le sous-système d’affichage présente les données dans la mémoire tampon avant à la sortie.

Une chaîne d’échange est configurée pour dessiner en mode plein écran ou fenêtré, ce qui élimine la nécessité de savoir si une sortie est fenêtré ou en plein écran. Une chaîne d’échange en mode plein écran peut optimiser les performances en changeant la résolution d’affichage.

Créer une chaîne d’échange

Les mémoires tampons d’une chaîne d’échange sont créées à une taille particulière et dans un format particulier. L’application spécifie ces valeurs (ou vous pouvez hériter de la taille de la fenêtre cible) au démarrage, puis peut éventuellement les modifier à mesure que la taille de la fenêtre change en réponse aux événements d’entrée utilisateur ou de programme.

Après avoir créé la chaîne d’échange, vous souhaiterez généralement y afficher des images. Voici un fragment de code qui configure un contexte Direct3D à afficher dans une chaîne d’échange. Ce code extrait une mémoire tampon de la chaîne d’échange, crée une vue render-target-view à partir de cette mémoire tampon, puis la définit sur l’appareil :

ID3D11Resource * pBB;
ThrowFailure( pSwapChain->GetBuffer(0, __uuidof(pBB),    
  reinterpret_cast<void**>(&pBB)), "Couldn't get back buffer");
ID3D11RenderTargetView * pView;
ThrowFailure( pD3D11Device->CreateRenderTargetView(pBB, NULL, &pView), 
  "Couldn't create view" );
pD3D11DeviceContext->OMSetRenderTargets(1, &pView, 0);
        

Une fois que votre application a rendu un frame dans une mémoire tampon de chaîne d’échange, appelez IDXGISwapChain1::P resent1. L’application peut ensuite afficher l’image suivante.

Soins et alimentation de la chaîne d’échange

Après avoir rendu votre image, appelez IDXGISwapChain1::P resent1 et affichez l’image suivante. C’est l’étendue de votre responsabilité.

Si vous avez précédemment appelé IDXGIFactory::MakeWindowAssociation, l’utilisateur peut appuyer sur la combinaison de touches Alt-Enter et DXGI fera passer votre application du mode fenêtré au mode plein écran. IDXGIFactory::MakeWindowAssociation est recommandé, car un mécanisme de contrôle standard pour l’utilisateur est fortement souhaité.

Bien que vous n’ayez pas à écrire plus de code que ce qui a été décrit, quelques étapes simples peuvent rendre votre application plus réactive. La considération la plus importante est le redimensionnement des mémoires tampons de la chaîne d’échange en réponse au redimensionnement de la fenêtre de sortie. Naturellement, la meilleure route de l’application consiste à répondre à WM_SIZE et à appeler IDXGISwapChain::ResizeBuffers, en passant la taille contenue dans les paramètres du message. Ce comportement fait évidemment que votre application répond bien à l’utilisateur lorsqu’il fait glisser les bordures de la fenêtre, mais c’est aussi exactement ce qui permet une transition en plein écran fluide. Votre fenêtre reçoit un message WM_SIZE chaque fois qu’une telle transition se produit, et l’appel de IDXGISwapChain::ResizeBuffers est la possibilité pour la chaîne d’échange de réallouer le stockage des mémoires tampons pour une présentation optimale. C’est pourquoi l’application doit libérer toutes les références qu’elle a sur les mémoires tampons existantes avant d’appeler IDXGISwapChain::ResizeBuffers.

L’échec de l’appel d’IDXGISwapChain::ResizeBuffers en réponse au passage en mode plein écran (le plus naturellement, en réponse à WM_SIZE) peut empêcher l’optimisation du basculement, où DXGI peut simplement permuter la mémoire tampon affichée, au lieu de copier la valeur des données d’un plein écran.

IDXGISwapChain1::P resent1 vous informe si votre fenêtre de sortie est entièrement masquée via DXGI_STATUS_OCCLUDED. Dans ce cas, nous vous recommandons de passer en mode de secours (en appelant IDXGISwapChain1::P resent1 avec DXGI_PRESENT_TEST), car les ressources utilisées pour restituer le frame sont gaspiller. L’utilisation de DXGI_PRESENT_TEST empêche toute présentation de données tout en effectuant l’occlusion case activée. Une fois qu’IDXGISwapChain1::P resent1 retourne S_OK, vous devez quitter le mode veille ; n’utilisez pas le code de retour pour basculer en mode de secours, car cela peut laisser la chaîne d’échange dans l’impossibilité de renoncer au mode plein écran.

Le runtime Direct3D 11.1, disponible à partir de Windows 8, fournit une chaîne d’échange de modèle inversé (autrement dit, une chaîne d’échange dont la valeur DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL est définie dans le membre SwapEffect de DXGI_SWAP_CHAIN_DESC ou DXGI_SWAP_CHAIN_DESC1). Lorsque vous présentez des trames à une sortie avec une chaîne d’échange de modèle inversé, DXGI dissocie la mémoire tampon d’arrière-plan de tous les emplacements d’état de pipeline, comme une cible de rendu de fusion de sortie, qui écrit dans la mémoire tampon 0. Par conséquent, nous vous recommandons d’appeler ID3D11DeviceContext::OMSetRenderTargets immédiatement avant le rendu dans la mémoire tampon d’arrière-mémoire. Par exemple, n’appelez pas OMSetRenderTargets , puis effectuez un travail de nuanceur de calcul qui ne finit pas par être rendu sur la ressource. Pour plus d’informations sur les chaînes de permutation de modèle inversé et leurs avantages, consultez DXGI Flip Model.

Gestion du redimensionnement des fenêtres

Vous pouvez utiliser la méthode IDXGISwapChain::ResizeBuffers pour gérer le redimensionnement des fenêtres. Avant d’appeler ResizeBuffers, vous devez libérer toutes les références en suspens aux mémoires tampons de la chaîne d’échange. L’objet qui contient généralement une référence à la mémoire tampon d’une chaîne d’échange est un render-target-view.

L’exemple de code suivant montre comment appeler ResizeBuffers à partir du gestionnaire WindowProc pour WM_SIZE messages :

    case WM_SIZE:
        if (g_pSwapChain)
        {
            g_pd3dDeviceContext->OMSetRenderTargets(0, 0, 0);

            // Release all outstanding references to the swap chain's buffers.
            g_pRenderTargetView->Release();

            HRESULT hr;
            // Preserve the existing buffer count and format.
            // Automatically choose the width and height to match the client rect for HWNDs.
            hr = g_pSwapChain->ResizeBuffers(0, 0, 0, DXGI_FORMAT_UNKNOWN, 0);
                                            
            // Perform error handling here!

            // Get buffer and create a render-target-view.
            ID3D11Texture2D* pBuffer;
            hr = g_pSwapChain->GetBuffer(0, __uuidof( ID3D11Texture2D),
                                         (void**) &pBuffer );
            // Perform error handling here!

            hr = g_pd3dDevice->CreateRenderTargetView(pBuffer, NULL,
                                                     &g_pRenderTargetView);
            // Perform error handling here!
            pBuffer->Release();

            g_pd3dDeviceContext->OMSetRenderTargets(1, &g_pRenderTargetView, NULL );

            // Set up the viewport.
            D3D11_VIEWPORT vp;
            vp.Width = width;
            vp.Height = height;
            vp.MinDepth = 0.0f;
            vp.MaxDepth = 1.0f;
            vp.TopLeftX = 0;
            vp.TopLeftY = 0;
            g_pd3dDeviceContext->RSSetViewports( 1, &vp );
        }
        return 1;

Choix de la sortie et de la taille DXGI

Par défaut, DXGI choisit la sortie qui contient la majeure partie de la zone cliente de la fenêtre. Il s’agit de la seule option disponible pour DXGI lorsqu’il passe lui-même en plein écran en réponse à l’entrée de remplacement. Si l’application choisit de passer en mode plein écran par elle-même, elle peut appeler IDXGISwapChain::SetFullscreenState et passer un IDXGIOutput1 explicite (ou NULL, si l’application est heureuse de laisser DXGI décider).

Pour redimensionner la sortie en mode plein écran ou fenêtré, nous vous recommandons d’appeler IDXGISwapChain::ResizeTarget, car cette méthode redimensionne également la fenêtre cible. Étant donné que la fenêtre cible est redimensionnée, le système d’exploitation envoie WM_SIZE, et votre code appelle naturellement IDXGISwapChain::ResizeBuffers en réponse. Il s’agit donc d’un gaspillage d’efforts pour redimensionner vos mémoires tampons, puis redimensionner la cible par la suite.

Débogage en mode plein écran

Une chaîne d’échange DXGI abandonne le mode plein écran uniquement lorsque cela est absolument nécessaire. Cela signifie que vous pouvez déboguer une application plein écran à l’aide de plusieurs moniteurs, tant que la fenêtre de débogage ne chevauche pas la fenêtre cible de la chaîne d’échange. Vous pouvez également empêcher tout changement de mode en ne définissant pas l’indicateur DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH .

Si le basculement de mode est autorisé, une chaîne d’échange abandonne le mode plein écran chaque fois que sa fenêtre de sortie est obclée par une autre fenêtre. L’occlusion case activée est effectuée pendant IDXGISwapChain1::P resent1, ou par un thread distinct dont l’objectif est de watch pour voir si l’application ne répond plus (et n’appelle plus IDXGISwapChain1::P resent1). Pour désactiver la capacité du thread distinct à provoquer un commutateur, définissez la clé de Registre suivante sur une valeur autre que zéro.

HKCU\Software\Microsoft\DXGI\DisableFullscreenWatchdog

Destruction d’une chaîne d’échange

Vous ne pouvez pas libérer une chaîne d’échange en mode plein écran, car cela peut créer une contention de thread (ce qui entraînera le déclenchement d’une exception non continuable par DXGI). Avant de libérer une chaîne d’échange, passez d’abord en mode fenêtré (à l’aide de IDXGISwapChain::SetFullscreenState( FALSE, NULL )), puis appelez IUnknown::Release.

Utilisation d’un moniteur pivoté

Une application n’a pas besoin de se soucier de l’orientation du moniteur, DXGI fait pivoter une mémoire tampon de chaîne d’échange pendant la présentation, si nécessaire. Bien sûr, cette rotation supplémentaire peut avoir un impact sur les performances. Pour de meilleures performances, prenez soin de la rotation dans votre application en procédant comme suit :

• Utilisez le DXGI_SWAP_CHAIN_FLAG_NONPREROTATED. Cela avertit DXGI que l’application va produire une image pivotée (par exemple, en modifiant sa matrice de projection). Notez que cet indicateur n’est valide qu’en mode plein écran.
• Allouez chaque mémoire tampon de chaîne d’échange dans sa taille pivotée. Utilisez IDXGIOutput::GetDesc pour obtenir ces valeurs, si nécessaire.

En effectuant la rotation dans votre application, DXGI effectue simplement une copie au lieu d’une copie et une rotation.

Le runtime Direct3D 11.1, disponible à partir de Windows 8, fournit une chaîne d’échange de modèle inversé (autrement dit, une chaîne d’échange dont la valeur DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL est définie dans le membre SwapEffect de DXGI_SWAP_CHAIN_DESC1). Pour optimiser les optimisations de présentation disponibles avec une chaîne de permutation de modèle inversé, nous vous recommandons de faire en sorte que vos applications orientent le contenu pour qu’il corresponde à la sortie particulière sur laquelle réside le contenu lorsque ce contenu occupe entièrement la sortie. Pour plus d’informations sur les chaînes de permutation de modèle inversé et leurs avantages, consultez DXGI Flip Model.

Changement de mode

La chaîne d’échange DXGI peut modifier le mode d’affichage d’une sortie lors d’une transition plein écran. Pour activer la modification automatique du mode d’affichage, vous devez spécifier DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH dans la description de la chaîne d’échange. Si le mode d’affichage change automatiquement, DXGI choisit le mode le plus modeste (la taille et la résolution ne changent pas, mais la profondeur de couleur peut). Le redimensionnement des mémoires tampons de chaîne d’échange n’entraîne pas de changement de mode. La chaîne d’échange promet implicitement que si vous choisissez une mémoire tampon d’arrière-mémoire qui correspond exactement à un mode d’affichage pris en charge par la sortie cible, elle basculera vers ce mode d’affichage lors de l’entrée en mode plein écran sur cette sortie. Par conséquent, vous choisissez un mode d’affichage en choisissant la taille et le format de votre mémoire tampon d’arrière-mémoire.

Conseil sur les performances en plein écran

Lorsque vous appelez IDXGISwapChain1::P resent1 sur une application plein écran, la chaîne d’échange retourne (par opposition à des fentes) le contenu de la mémoire tampon d’arrière-plan vers la mémoire tampon avant. Cela nécessite que la chaîne d’échange ait été créée à l’aide d’un mode d’affichage énuméré (spécifié dans DXGI_SWAP_CHAIN_DESC1). Si vous ne parvenez pas à énumérer les modes d’affichage ou si vous spécifiez incorrectement le mode d’affichage dans la description, la chaîne d’échange peut effectuer un transfert de bloc de bits (bitblt) à la place. Le bitblt provoque une copie d’étirement supplémentaire ainsi qu’une utilisation accrue de la mémoire vidéo, et est difficile à détecter. Pour éviter ce problème, énumérez les modes d’affichage et initialisez correctement la description de la chaîne d’échange avant de créer la chaîne d’échange. Cela garantit des performances maximales lors du basculement en mode plein écran et évite la surcharge de mémoire supplémentaire.

Considérations relatives au multithread

Lorsque vous utilisez DXGI dans une application avec plusieurs threads, vous devez veiller à éviter de créer un interblocage, où deux threads différents s’attendent l’un sur l’autre pour se terminer. Il existe deux situations dans lesquelles cela peut se produire.

• Le thread de rendu n’est pas le thread de pompe de messages.
• Le thread exécutant une API DXGI n’est pas le même thread que celui qui a créé la fenêtre.

Veillez à ce que le thread de pompe de messages n’attende jamais sur le thread de rendu lorsque vous utilisez des chaînes de permutation en plein écran. Par instance, l’appel de IDXGISwapChain1::P resent1 (à partir du thread de rendu) peut entraîner l’attente du thread de rendu sur le thread de pompe de message. Lorsqu’un changement de mode se produit, ce scénario est possible si Present1 appelle ::SetWindowPos() ou ::SetWindowStyle() et si l’une de ces méthodes appelle ::SendMessage(). Dans ce scénario, si le thread de pompe de messages a une section critique qui le protège ou si le thread de rendu est bloqué, les deux threads se bloquent.

Pour plus d’informations sur l’utilisation de DXGI avec plusieurs threads, consultez Multithreading et DXGI.

Réponses DXGI de DLLMain

Étant donné qu’une fonction DllMain ne peut pas garantir l’ordre dans lequel elle charge et décharge les DLL, nous vous recommandons de ne pas appeler les fonctions ou méthodes Direct3D ou DXGI, y compris les fonctions ou méthodes qui créent ou libèrent des objets. Si la fonction DllMain de votre application appelle un composant particulier, ce composant peut appeler une autre DLL qui n’est pas présente sur le système d’exploitation, ce qui provoque le blocage du système d’exploitation. Direct3D et DXGI peuvent charger un ensemble de DLL, généralement un ensemble de pilotes, qui diffère d’un ordinateur à l’autre. Par conséquent, même si votre application ne se bloque pas sur vos ordinateurs de développement et de test lorsque sa fonction DllMain appelle des fonctions ou des méthodes Direct3D ou DXGI, elle peut se bloquer lorsqu’elle s’exécute sur un autre ordinateur.

Pour vous empêcher de créer une application susceptible de provoquer le blocage du système d’exploitation, DXGI fournit les réponses suivantes dans les situations spécifiées :

• Si la fonction DllMain de votre application libère sa dernière référence à une fabrique DXGI, DXGI lève une exception.
• Si la fonction DllMain de votre application crée une fabrique DXGI, DXGI retourne un code d’erreur.

Modifications de DXGI 1.1

Nous avons ajouté les fonctionnalités suivantes dans DXGI 1.1.

• Prise en charge des Surfaces partagées synchronisées

  Les surfaces partagées synchronisées pour Direct3D 10.1 et Direct3D 11 permettent un partage efficace des surfaces de lecture et d’écriture entre plusieurs appareils Direct3D (le partage entre les appareils Direct3D 10 et Direct3D 11 est possible). Consultez IDXGIKeyedMutex::AcquireSync et IDXGIKeyedMutex::ReleaseSync.

• Prise en charge des couleurs élevées

  Prend en charge le format DXGI_FORMAT_R10G10B10_XR_BIAS_A2_UNORM.

• IDXGIDevice1::SetMaximumFrameLatency et IDXGIDevice1::GetMaximumFrameLatency

• IDXGIFactory1::EnumAdapters1 énumère les adaptateurs locaux sans moniteurs ou sorties attachés, ainsi que les adaptateurs avec des sorties attachées. Le premier adaptateur retourné est l’adaptateur local sur lequel le serveur principal du bureau est affiché.

• Prise en charge du format BGRA

  DXGI_FORMAT_B8G8R8A8_UNORM et DXGI_FORMAT_B8G8R8A8_UNORM_SRGB, consultez IDXGISurface1::GetDC et IDXGISurface1::ReleaseDC.

Modifications de DXGI 1.2

Nous avons ajouté les fonctionnalités suivantes dans DXGI 1.2.

• Chaîne d’échange stéréo
• Chaîne de permutation de modèle inversé
• Présentation optimisée (défilement, sale rectangles et rotation)
• Amélioration des ressources partagées et de la synchronisation
• Duplication du bureau
• Utilisation optimisée de la mémoire vidéo
• Prise en charge des formats de 16 bits par pixel (bpp) (DXGI_FORMAT_B5G6R5_UNORM, DXGI_FORMAT_B5G5R5A1_UNORM, DXGI_FORMAT_B4G4R4A4_UNORM)
• API de débogage

Pour plus d’informations sur DXGI 1.2, consultez Améliorations de DXGI 1.2.

Rubriques connexes

Guide de programmation pour DXGI