Partager via

Vue d’ensemble de DXGI

  • Article

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.

diagramme de la communication entre les applications, dxgi et les pilotes et le matériel

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.

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

É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.

diagramme d’un ordinateur avec deux cartes vidéo et trois moniteurs

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.

illustration d’une chaîne d’échange

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.

illustration d’un sous-système d’affichage

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

Différences entre Direct3D 9 et Direct3D 10 : Direct3D 10 est le premier composant graphique à utiliser DXGI. DXGI a des comportements de chaîne d’échange différents.
  • Dans DXGI, une chaîne d’échange est liée à une fenêtre lors de la création de la chaîne d’échange. Cette modification améliore les performances et économise de la mémoire. Les versions précédentes de Direct3D permettaient à la chaîne d’échange de modifier la fenêtre à laquelle la chaîne d’échange est liée.
  • Dans DXGI, une chaîne d’échange est liée à un appareil de rendu lors de la création. L’objet d’appareil retourné par direct3D create device functions implémente l’interface IUnknown . Vous pouvez appeler QueryInterface pour interroger l’interface IDXGIDevice2 correspondante de l’appareil. Une modification apportée au périphérique de rendu nécessite la recréation de la chaîne d’échange.

  • Dans DXGI, les effets d’échange disponibles sont DXGI_SWAP_EFFECT_DISCARD et DXGI_SWAP_EFFECT_SEQUENTIAL. À compter de Windows 8 l’effet d’échange DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL est également disponible. Le tableau suivant montre un mappage des définitions d’effet de permutation Direct3D 9 à DXGI.

    Effet d’échange D3D9 Effet d’échange DXGI
    D3DSWAPEFFECT_DISCARD DXGI_SWAP_EFFECT_DISCARD
    D3DSWAPEFFECT_COPY DXGI_SWAP_EFFECT_SEQUENTIAL avec 1 tampon
    D3DSWAPEFFECT_FLIP DXGI_SWAP_EFFECT_SEQUENTIAL avec 2 mémoires tampons ou plus
    D3DSWAPEFFECT_FLIPEX DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL avec 2 mémoires tampons ou plus

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.

Notes

Dans Direct3D 10 et Direct3D 11, vous n’avez pas besoin d’appeler IDXGISwapChain::GetBuffer pour récupérer la mémoire tampon 0 après avoir appelé IDXGISwapChain1::P resent1 , car pour des raisons pratiques, les identités des mémoires tampons d’arrière-mémoires changent. Cela ne se produit pas dans Direct3D 12, et votre application doit suivre manuellement les index de mémoire tampon.

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.

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.

Guide de programmation pour DXGI