Partager via

Comparaison de l’accélération matérielle Direct2D et GDI

  • Article

Direct2D et GDI sont des API de rendu 2D en mode immédiat et offrent tous deux un certain degré d’accélération matérielle. Cette rubrique explore les différences entre Direct2D et GDI, notamment les différences passées et présentes dans les fonctionnalités d’accélération matérielle des deux API.

Cette rubrique comporte les parties suivantes :

Différences entre Direct2D et GDI

GDI restitue les géométries opaques et alias telles que les polygones, les ellipses et les lignes. Il restitue le texte avec alias et ClearType, et il peut prendre en charge la fusion de transparence via l’API AlphaBlend. Toutefois, sa gestion de la transparence est incohérente et la plupart des API GDI ignorent simplement le canal alpha. Peu d’API GDI garantissent ce que le canal alpha contiendra après une opération. Plus important encore, le rendu de GDI ne correspond pas facilement aux opérations 3D, et un GPU moderne s’affiche le plus efficacement sur la partie 3D de son moteur de rendu. Par exemple, les lignes avec alias de Direct2D sont conçues pour être implémentées simplement sous la forme de deux triangles rendus sur le GPU, tandis que GDI utilise l’algorithme de dessin de traits de Bresenham.

Direct2D restitue les primitives opaques, transparentes, avec alias et anti-alias. Les interfaces utilisateur modernes utilisent souvent la transparence et l’animation. Direct2D facilite la création d’une interface utilisateur moderne, car il dispose de garanties strictes quant à la façon dont il accepte et affiche le contenu transparent, et toutes ses primitives sont rendues à l’aide de l’accélération matérielle. Direct2D n’est pas un sur-ensemble pur de GDI : les primitives qui auraient été déraisonnablement lentes lorsqu’elles étaient implémentées sur un GPU ne sont pas présentes dans Direct2D. Étant donné que Direct2D est conçu en mettant l’accent sur l’accélération 3D, il est également facile à utiliser avec Direct3D.

Depuis Windows NT 4, GDI s’exécute en mode noyau. L’application appelle GDI qui appelle ensuite son équivalent en mode noyau qui passe les primitives à son propre modèle de pilote. Ce pilote envoie ensuite les résultats au pilote d’affichage en mode noyau global.

À compter de Windows 2000, GDI et les pilotes GDI se sont exécutés dans un espace indépendant dans le noyau appelé « espace de session ». Un espace d’adressage de session est créé pour chaque session d’ouverture de session, et chaque instance de GDI s’exécute indépendamment dans cet espace d’adressage en mode noyau distinct. Direct2D, toutefois, s’exécute en mode utilisateur et transmet les commandes de dessin via le pilote Direct3D en mode utilisateur au pilote en mode noyau.

figure 1 - direct2d par rapport à gdi

Accélération matérielle GDI et Direct2D

La différence la plus importante entre l’accélération matérielle Direct2D et GDI est la technologie sous-jacente qui les pilote. Direct2D est superposé à Direct3D supérieur et GDI a son propre modèle de pilote, l’interface de pilote GDI (DDI), qui correspond aux primitives GDI. Le modèle de pilote Direct3D correspond à ce que le matériel de rendu 3D d’un GPU affiche. Lorsque le DDI GDI a été défini pour la première fois, la plupart du matériel d’accélération d’affichage ciblait les primitives GDI. Au fil du temps, l’accent a été mis de plus en plus sur l’accélération des jeux 3D et moins sur l’accélération des applications. Par conséquent, l’API BitBlt a été accélérée sur le matériel et la plupart des autres opérations GDI ne l’ont pas été.

Cela définit l’étape d’une séquence de modifications de la façon dont GDI s’affiche à l’affichage. L’illustration suivante montre comment le rendu d’affichage GDI a changé de Windows XP à Windows 7.

figure 2 - évolution du rendu d’affichage gdi

Un certain nombre de facteurs supplémentaires ont également provoqué des modifications du modèle de pilote GDI , comme expliqué ci-dessous.

Complexité et taille croissantes des pilotes d’affichage

Les pilotes 3D sont devenus plus complexes au fil du temps. Le code plus complexe a tendance à présenter plus de défauts, ce qui permet au pilote d’exister en mode utilisateur, où un bogue de pilote ne peut pas provoquer de redémarrage du système. Comme le montre la figure ci-dessus, le pilote d’affichage est divisé en un composant complexe en mode utilisateur et en un composant en mode noyau plus simple.

Difficulté à synchroniser les espaces d’adressage de session et de noyau global

Dans Windows XP, un pilote d’affichage existe dans deux espaces d’adressage différents : l’espace de session et l’espace du noyau. Certaines parties du pilote doivent répondre aux événements tels que les événements de gestion de l’alimentation. Cela doit être synchronisé avec l’état du pilote dans l’espace d’adressage de session. Il s’agit d’une tâche difficile qui peut entraîner des défauts lorsque les pilotes d’affichage tentent de gérer ces espaces d’adressage distincts.

Gestion des fenêtres composites

Le Gestionnaire de fenêtres de bureau (DWM), le gestionnaire de fenêtres de composition introduit dans Windows 7, affiche toutes les fenêtres sur des surfaces hors écran, puis les compose pour les afficher à l’écran. Cela nécessite que GDI puisse effectuer un rendu sur une surface qui sera ensuite rendue par Direct3D pour l’afficher. Cela a posé un problème dans le modèle de pilote XP, car GDI et Direct3D étaient des piles de pilotes parallèles.

Par conséquent, dans Windows Vista, le pilote d’affichage DDI GDI a été implémenté en tant que pilote d’affichage canonique (CDD) fourni par Microsoft, qui a rendu le contenu GDI dans une bitmap de mémoire système à composer à l’écran.

Rendu GDI dans Windows 7

Le modèle de pilote utilisé dans Windows Vista exigeait que chaque fenêtre GDI soit soutenue par une surface de mémoire vidéo et une surface de mémoire système. Cela a entraîné l’utilisation de la mémoire système pour chaque fenêtre GDI.

Pour cette raison, GDI a été à nouveau modifié dans Windows 7. Au lieu d’effectuer un rendu sur une surface de mémoire système, GDI a été modifié pour être rendu en un segment de mémoire à ouverture. La mémoire d’ouverture peut être mise à jour à partir de la surface de mémoire vidéo contenant le contenu de la fenêtre. GDI peut retourner dans la mémoire d’ouverture, et le résultat peut ensuite être renvoyé à la surface de la fenêtre. Étant donné que le segment de mémoire d’ouverture est adressable par le GPU, le GPU peut accélérer ces mises à jour de la surface de mémoire vidéo. Par exemple, le rendu de texte, BitBlts, AlphaBlend, TransparentBlt et StretchBlt sont tous accélérés dans ces cas.

Contraste entre l’accélération Direct2D et GDI dans Windows 7

Direct2D et GDI sont des API de rendu 2D en mode immédiat et sont accélérées sur le matériel. Toutefois, il existe un certain nombre de différences qui subsistent dans les deux API.

Emplacement des ressources

GDI conserve ses ressources, en particulier les bitmaps, dans la mémoire système par défaut. Direct2D conserve ses ressources en mémoire vidéo sur l’adaptateur d’affichage. Lorsque GDI doit mettre à jour la mémoire vidéo, cela doit être effectué via le bus, sauf si la ressource se trouve déjà dans le segment de mémoire d’ouverture ou si l’opération peut être exprimée directement. En revanche, Direct2D peut simplement traduire ses primitives en primitives Direct3D, car les ressources sont déjà en mémoire vidéo.

Méthode de rendu

Pour maintenir la compatibilité, GDI effectue une grande partie de son rendu sur la mémoire d’ouverture à l’aide du processeur. En revanche, Direct2D traduit ses appels d’API en primitives Direct3D et en opérations de dessin. Le résultat est ensuite rendu sur le GPU. Une partie du rendu de GDI est effectuée sur le GPU lorsque la mémoire d’ouverture est copiée sur la surface de mémoire vidéo représentant la fenêtre GDI.

Extensibilité

Les appels de rendu de Direct2D sont tous des flux de commandes indépendants vers le GPU. Chaque fabrique Direct2D représente un appareil Direct3D différent. GDI utilise un flux de commandes pour toutes les applications sur le système. La méthode de GDI peut entraîner une accumulation de gpu et de contexte de rendu du processeur.

Emplacement

Direct2D fonctionne entièrement en mode utilisateur, y compris l’heure d’exécution de Direct3D et le pilote Direct3D en mode utilisateur. Cela permet d’éviter les plantages système causés par des défauts de code dans le noyau. GDI, cependant, dispose de la plupart de ses fonctionnalités dans l’espace de session en mode noyau, avec sa surface d’API en mode utilisateur.

Disponibilité de l’accélération matérielle

GDI est une accélération matérielle sur Windows XP et une accélération sur Windows 7 lorsque le Gestionnaire de fenêtres de bureau est en cours d’exécution et qu’un pilote WDDM 1.1 est en cours d’utilisation. Direct2D est une accélération matérielle sur presque tous les pilotes WDDM et que DWM soit en cours d’utilisation ou non. Sur Vista, GDI s’affiche toujours sur le processeur.

Modèle de présentation

Lorsque Windows a été conçu pour la première fois, la mémoire était insuffisante pour permettre à chaque fenêtre d’être stockée dans sa propre bitmap. Par conséquent, GDI est toujours rendu logiquement directement à l’écran, avec différentes régions de découpage appliquées pour garantir qu’une application ne s’affiche pas en dehors de sa fenêtre. Dans le modèle Direct2D , une application s’affiche dans un back-buffer et le résultat s’affiche lorsque l’application a terminé le dessin. Cela permet à Direct2D de gérer des scénarios d’animation beaucoup plus fluide que GDI.

Conclusion

Le code GDI existant continuera de fonctionner correctement sous Windows 7. Toutefois, lors de l’écriture de nouveau code de rendu graphique, Direct2D doit être pris en compte, car il tire mieux parti des GPU modernes.