Accélération 2D : la Voodoo 4 plus forte que les Radeon HD 5800 et GeForce GTX !

Introduction

Commençons par le commencement : si vous n’avez pas encore lu notre dossier intitulé La 2D sous Windows : surprise !, nous vous conseillons de le faire avant de continuer. Vous y apprendrez tout ce qu’il y a à savoir sur l’histoire de la 2D sous Windows et les problèmes que rencontrent les cartes graphiques haut de gamme actuelles pour la gérer.

Dans cette deuxième partie, nous nous focaliserons sur l’importance de la GDI, expliquerons plus en détails le rendu graphique en 2D et présenterons notre benchmark 2D. Pour bien faire comprendre les résultats de cet outil de test, nous devons cependant commencer par expliquer certains éléments théoriques fondamentaux.

Pourquoi testons-nous encore GDI à l’ère de Windows 7 et de Direct2D ?

En réaction à la première partie de cet article, un certain nombre d’entre vous ont répliqué que depuis le lancement de Windows Vista et des cartes graphiques comptables DirectX 10, le rendu 2D via GDI était devenu obsolète. Effectivement, Direct2D et WPF (Windows Presentation Foundation) ont été mis à la disposition des développeurs depuis un moment. Il reste néanmoins à ceux-ci beaucoup de bonnes raisons pour continuer à utiliser la GDI (Graphics Device Interface) ; c’est pourquoi nous allons analyser son comportement et ses performances, et ce, même si Windows 7 semble à première vue avoir changé la donne. Parmi les raisons qui poussent les développeurs à utiliser, aujourd’hui encore, la GDI, citons les suivantes :

• La GDI est compatible avec les vieilles cartes graphiques alors que Direct2D nécessite une carte compatible DirectX 10 ou supérieur.
• La GDI est prise en charge par toutes les versions de Windows, tandis que Direct2D n’est disponible que sous Windows Vista et Windows.
• Toutes les applications graphiques prévues pour fonctionner sous Windows XP (et a fortiori sous une version plus ancienne de Windows) utilisent la GDI.

Il faut ajouter à cela le fait que bon nombre de développeurs sont réticents à l’idée de devoir retravailler leur logiciel afin de tirer parti de nouvelles API. À l’heure actuelle, beaucoup d’entre eux continuent à utiliser les vieilles bibliothèques de programmation qu’ils connaissent et maîtrisent, et ce, même si des technologies plus récentes sont disponibles, simplement parce que passer d’une bibliothèque à l’autre nécessite la réécriture et le test de tout le code affecté. Sachant que les gains en performances apportés par une telle conversion sont bien souvent imperceptibles, on comprend que la raison qui pousse les développeurs à s’y opposer est bien souvent d’ordre économique : cela nécessite trop de temps et de travail pour un résultat insuffisant. Il suffit de jeter un coup d’œil à l’implémentation de Direct2D au sein de divers composants de Mozilla Firefox pour se faire une idée de la lenteur avec laquelle le secteur procède à cette évolution. Par ailleurs, n’oublions pas que pour une entreprise ou un développeur, passer entièrement à Direct2D équivaut à rendre son produit inutilisable pour l’ensemble des utilisateurs de Windows XP, ce qui représente un véritable suicide commercial. Bref, tous ces éléments s’agglutinent et il reste une observation, claire, implacable : la GDI a toutes les chances de continuer à rester incontournable tant que Windows XP ne cessera d’être employé par une part significative de la communauté des utilisateurs finaux.

Outre ces raisons historiques, il y a également une série de raisons techniques qui expliquent la persistance de la GDI. Premièrement, plusieurs des modules de code essentiels de la GDI (ceux qui sont le plus souvent inclus et appelés par les applications Windows) ne sont pas entièrement portables. Deuxièmement, si Direct2D est capable faire tout ce que fait Direct3D, il est gourmand en ressources et en puissance de traitement ; les développeurs qui ont choisi de ne pas opter pour Direct3D l’ont généralement fait après mûre réflexion. Troisièmement, la GDI fonctionne indépendamment des périphériques de sortie utilisés (écrans, imprimantes, etc.) : cela signifie que la même routine permet d’assurer à la fois le rendu sur écran et l’impression, ce qui a l’avantage de diviser par deux la taille du code nécessaire, et donc la maintenance et le risque d’erreur liés à celui-ci. La plupart des imprimantes bon marché actuelles sont des périphériques GDI et il y a peu de chances pour que cela change, même sous Windows 7, qui propose encore une multitude de pilotes pour imprimantes de ce type.

De la nécessité d’avoir une vision d’ensemble

Nous-mêmes considérons à la fois le passage à WPF et Direct2D comme un pas en avant irréversible et comme une « évolution forcée » dont le moteur est Microsoft, mais tous ceux que les nouvelles technologies ennuient doivent faire l’effort de repenser aux évolutions précédentes (que nous récapitulerons dans les pages qui suivent) : jusque dans Windows XP, on retrouve en effet une énorme quantité de technologie héritée et nous avons atteint le point où, pour continuer à avancer, la seule solution est de faire table rase du passé. Le problème, bien sûr, est qu’une telle approche prend l’utilisateur à rebrousse-poil. Windows XP lui-même n’était pas exempt d’incompatibilités avec le passé, comme l’avait à l’époque montré la phobie dont témoignaient les puces graphiques intégrées aux chipsets AMD 780G et 785G vis-à-vis de cet OS.

Dans cet article, nous allons refaire les tests de la première partie, mais cette fois à l’aide de notre logiciel de benchmark maison, que vous pouvez d’ailleurs télécharger et lancer sur votre PC. Comme nous allons le voir, même les cartes graphiques les plus onéreuses se cassent les dents sur certains de ces tests, pour la simple raison qu’elles sont affectées par des pilotes qui n’ont pas été optimisés pour ce que bon nombre de personnes considèrent comme une « technologie dépassée », alors qu’elle reste encore largement employée.

GDI et la 2D, de Windows XP à Windows 7

XP : la GDI sans concurrence

Jusqu’à Windows XP (inclus), la GDI a joué un rôle essentiel dans le rendu graphique en 2D, comme le montre la présence de procédures ultra-simplifiées : les mouvements de souris permettant de tracer une ligne, par exemple, sont transmis à win32k.sys, la bibliothèque centralisant l’ensemble des entrées graphiques. Peu importe, en réalité, que vous utilisiez la souris, le clavier ou un autre périphérique d’entrée, car toutes les données convergent vers la même routine et sont ensuite envoyées aux modules de rendu graphique en 2D. Les actions de l’utilisateur n’incluent que des informations graphiques en 2D, lesquelles sont immédiatement traduites en instructions de dessin GDI, qui sont elles-mêmes passées à l’interface GDI, comme l’illustrent les flèches roses du diagramme ci-dessous.

La simplicité de ces procédures explique également pourquoi il est si facile d’accélérer matériellement la 2D dès lors que la carte graphique soit capable de les traiter indépendamment. La flèche bleue montre le chemin (direct) qu’empruntent les informations pour retourner à l’application appelante, qui est alors prévenue quand le contenu d’une fenêtre a changé et doit donc être redessiné (par exemple lorsque plus aucune fenêtre ne la recouvre, ce qui signifie que son contenu est à nouveau visible).

Windows Vista : le CPU au lieu du GPU et le tampon au lieu du direct

Comme nous l’avons expliqué dans lapremière partie de cet article, le chemin qu’empruntent les données graphiques dans Windows Vista est complètement différent de celui prévu par Windows XP. Jusqu’à ce dernier, toutes les versions de Windows géraient la 2D via la GDI et win32k.sys.

Dans Windows Vista, ce rôle est repris par le DWM (Dynamic Windows Manager), qui gère les fenêtre uniquement via Direct3D. Chaque fenêtre est donc considérée comme une texture 3D et stockée dans le tampon des textures de la carte graphique. Il s’agit d’une évolution sensée et pratique pour les cartes graphiques modernes, mais cela signifie également que la GDI ne peut plus accéder aux données graphiques, que ce soit en lecture ou en écriture. Les communications semblent rompues.

C’est là qu’intervient la double mise en mémoire tampon du contenu des fenêtres, que nous avions abordée dans la première partie de cet article.

Que se passe-t-il exactement ? Pour comprendre, regardez les flèches rouges du diagramme ci-dessus. Au lieu d’un pilote graphique unifié (nommé « pilote d’affichage DDI » sous Windows XP), on fait maintenant appel au pilote CDD (Canonical Display Driver), qui est indépendant de la carte graphique. Alors que chaque fenêtre est stockée sous forme de texture dans la mémoire de la carte graphique, elle doit également être stockée dans un tampon équivalent au sein de la mémoire vive du système (et sa taille est égale à sa hauteur x sa largeur x 32 bits de couleurs, soit 4 octets).

La version la plus récente de chaque fenêtre est transformée en un bitmap stocké dans le tampon en mémoire système, puis convertie en texture 3D stockée dans la mémoire de la carte graphique. D’un bout à l’autre de la chaîne, le DWM gère toutes les fenêtres et déplace leur contenu à l’aide de Direct3D. Il traite également les données indiquant quelles portions des fenêtres sont visibles à l’écran, afin de faire en sorte que toute zone devenant dissimulée ou affichée soit redessinée (il s’agit de la flèche bleue dans le diagramme ci-dessus). Lorsque cela se produit, le DWM effectue le rendu de la fenêtre à l’aide de Direct3D et copie le contenu de la mémoire système dans la mémoire vidéo. Comme on le voit, les applications ne doivent plus redessiner les fenêtres (contrairement à ce qui se passait sous Windows XP).

En pratique, la méthode que nous venons de décrire désactive l’accélération matérielle de la 2D, ce qui engendre une réduction considérable des performances par rapport à Windows XP, réduction qui se manifeste très clairement par la tendance (bien documentée) de Vista à afficher des traînées en 2D et à consommer de grandes quantités de mémoire vive.

Windows 7 : l’accélération matérielle à doses homéopathiques

Comme nous le disions déjà dans lapremière partie de notre article, nous nous sommes rendus compte dès nos tous premiers tests que Windows 7 gérait au moins en partie l’accélération matérielle des commandes GDI… pour autant que la carte graphique dispose de pilotes WDDM 1.1. En l’absence de tels pilotes (ce qui par exemple le cas avec la plupart des chipsets graphiques Intel), Windows 7 se comporte à peu près comme Vista. Qu’est-ce que cela signifie en pratique ? C’est ce que va nous dire le diagramme suivant :

À première vue, cela ressemble à s’y méprendre au diagramme de Windows Vista. À une différence près : il n’est plus nécessaire de mettre deux fois en tampon le contenu de chaque fenêtre. Au lieu de la mémoire système, on parle maintenant « d’aperture memory », c’est-à-dire une région bien spécifique de la mémoire système à laquelle la carte graphique peut accéder directement. Si une zone d’une fenêtre est déplacée ou se fait recouvrir, son contenu est directement copié de cette région de la mémoire vers la mémoire de la carte graphique.

Malheureusement, contrairement à Windows XP, seules une série de commandes GDI sont prises en charge par le GPU sous Windows 7 : ClearType, ColorFill, BitBlt, AlphaBlend, TransparentBlt et StretchBlt, c’est-à-dire en langage courant, le rendu de texte, le remplissage de surfaces à l’aide de simples couleurs et la copie d’images et de surimpressions transparents. Par conséquent, le rendu d’images géométriques complexes n’est pas du tout accéléré mais les copies d’images et de remplissages d’images peuvent facilement être transférées de la mémoire système allouée à la carte graphique (la fameuse « aperture memory » de tout à l’heure) vers la mémoire vidéo.

Résumé

Windows XP accélérait matériellement l’ensemble des commandes GDI, Windows Vista aucune et Windows 7 certaines. Par rapport à Vista, Windows 7 dispose d’un modèle de pilotes WDDM qui réduit la consommation de mémoire en éliminant presque entièrement la double mise en tampon du contenu des fenêtres. Ceci dit, en réalité, même Vista bénéficie aujourd’hui de cette avancée : elle a en effet été intégrée à la platform update qui a été déployée via Windows Update à la fin de l’année 2009 (c’est-à-dire au moment où DirectX 11 a été lancé).

Rendu graphique 2D via GDI

Peu importe comment XP, Vista et Windows 7 interagissent avec la GDI : pour le développeur, le code reste identique. C’est l’implémentation de ce code, et particulièrement l’accélération par la carte graphique, qui diffère d’un Windows à l’autre, comme nous venons de le voir à la page précédente. Dans cette section, nous allons voir comment cela fonctionne en pratique.

Commandes de tracé de ligne

Quoi que l’on souhaite dire sur le rendu de la 2D via GDI, tout est basé sur une série bien définie d’instructions de dessin standardisées. Nous n’aborderons pas ces instructions en détail, mais il suffit de savoir qu’à chaque primitive graphique (lignes, courbes, polygones, rectangles et ellipses) correspond une commande spécifique pouvant être assortie de propriétés, comme le remplissage, l’épaisseur et la couleur de la ligne, etc. Plus loin dans cet article, nous décrirons ces commandes (ainsi que les paramètres qui leur sont associés) telles qu’elles sont envoyées à la GDI par les applications ; tout ce qui se produit après n’est de toute façon plus du ressort de ces dernières.

Dessin direct ou avec mise en tampon : une comparaison

D’une certaine manière, quand on veut déplacer du sable, peu importe que l’on fasse appel à un million de fourmis qui transportent chacune un grain du point A au point B ou que l’on utilise un éléphant qui déplace tout le sable dans un gros sac en une seule fois. Après tout, les deux méthodes atteignent le même objectif.

Il y a toutefois des différences évidentes entre les deux approches : celle de l’éléphant implique nettement moins de circulation entre les deux points et coordonner les actions d’un million de fourmis nécessite plus de temps et de ressources que charger un seul sac sur le dos du pachyderme.

Les fourmis ont pour avantages de ne pas requérir de sac (mémoire tampon) et d’être plus flexibles et efficaces que l’éléphant s’il n’y a que quelques grains de sable à déplacer. Au final et pour en finir avec notre analogie, le choix de l’une ou l’autre méthode dépendra du type d’activité et de la quantité de données à transférer. Voyons comment GDI procède pour dessiner le contenu d’un périphérique (par exemple un écran).

On comprend aisément que le recours à un tampon est considérablement plus rapide dès lors qu’il s’agit d’exécuter des commandes de dessin plus complexes. Le problème de cette méthode est qu’elle nécessite un espace de stockage temporaire (nommé Device-Independent Bitmap ou BIB) dont la taille est égale à celle de la zone d’affichage visible.

Fort heureusement, le coût en ressource est généralement plus que compensé par le gain en vitesse de rendu. Bien entendu, lorsque seul un léger changement est nécessaire, il reste nécessaire de transférer l’intégralité du tampon vers la carte graphique ou le gestionnaire de fenêtres (le DWM). Examinons maintenant un exemple de dessin en rendu direct.

Rendu en temps réel lors du déplacement et de la modification d’objets 2D

Si, par exemple, vous souhaitez utiliser la souris déplacer une forme géométrique, disons un polygone, d’un point A à un point B de la surface de dessin, il serait ridicule de redessiner cette forme à chaque étape du chemin entre ces deux points, étant donné que procéder de la sorte nous obligerait à remplir le tampon puis à effectuer le rendu de son contenu. Il est bien plus simple, avec l’aide du ROP (« raster operator »), de faire appel aux techniques de rendu XOR (OU exclusif).

Il faut commencer, à l’aide de l’opérateur XOR, par redessiner l’objet à son emplacement précédent, et ce, directement sur le périphérique d’affichage. Cela provoque comme par magie la disparition de l’objet original de la surface d’affichage. Il faut ensuite dessiner l’objet à son nouvel emplacement, sans utiliser XOR. Répétez ce processus pour chaque étape du mouvement de la souris et vous avez la possibilité de dessiner entre 10 et 50 changements de position par seconde, ce qui est plus qu’assez pour que l’œil humain considère le mouvement comme fluide. Il n’est nécessaire de re-remplir le tampon et d’effectuer le rendu de son contenu à l’écran qu’une fois la position finale atteinte.

Le dessin direct sur le périphérique d’affichage s’appelle « dessin flottant » ; retenez-le, car nous allons y faire référence à la section suivante, où nous expliquerons le comportement des cartes graphiques ATI Radeon HD 5xxx actuelles en 2D.

Un autre sujet de discussion concerne le rendu des « objets flottants », c’est-à-dire les primitives et les points de marquage servant à afficher et à orienter les dessins à l’écran. Lorsque le nombre de ces objets/valeurs devient trop élevé, il est possible de rencontrer des problèmes graphiques. Ils ne représentent pas une constante du dessin à l’écran et, dans la plupart des cas, ne sont pas mis en mémoire tampon par les applications.

Conclusions

Si l’on réexamine les diagrammes de la section précédente, on voit que sous Windows XP l’accélération matérielle de la 2D n’implique aucun détour : le rendu est direct. Sous Windows Vista, peu importe que l’on utilise un tampon ou que l’on tente d’envoyer chaque instruction de dessin au périphérique d’affichage : l’ensemble de la fenêtre est de toute façon mise en mémoire tampon. Sous Windows 7 avec des pilotes WDDM 1.1, par contre, on se débarrasse du deuxième tampon, ce qui signifie que seuls les changements doivent être mis à jour à l’écran.

Symptômes des Radeon HD 5000 sous Win 7

Nous avons dû prouver que le rendu direct et sans tampon de certaines primitives (formes géométriques) GDI prenait bien plus longtemps sous Windows 7 avec une Radeon HD 5870 ou 5750 qu’avec toute autre carte graphique. Avant de tenter d’isoler plus précisément les causes de ce phénomène, nous devions en examiner les symptômes avec soin afin de déterminer s’il touchait tout le monde et sinon, quels utilisateurs risquaient le plus d’être affectés. Fort heureusement, ce problème n’affecte pas systématiquement tous les utilisateurs ; cependant, ceux qui sont touchés devront faire face à une réduction drastique des performances en 2D, ce qui aura toutes les chances d’être particulièrement frustrant.

Problèmes de rendu direct

Comme nous le signalions dans la première partie de cet article, les problèmes de performances des cartes ATI sous Windows 7 concernent essentiellement le rendu des lignes, des courbes, des ellipses et des polygones. Nous n’avons ainsi mesuré qu’environ 4000 courbes par seconde sur notre Radeon HD 5870, sans tampons individuels pour le périphérique d’affichage. Lorsque nous avons voulu déplacer un objet composé de 50 courbes et dessiné en temps réel avec le ROP, elle n’est parvenue à dessiner que 25 images par seconde lors du mouvement (il faut toutefois noter que la technique XOR utilisée pour faire disparaître les objets nécessite un deuxième rendu, donc il s’agit en réalité de 50 opérations).

Si l’objet à déplacer dépasse les 100 courbes, le nombre total de courbes à redessiner (5000 par secondes : 100 courbes x 50 opérations par seconde) est supérieur à la capacité de traitement de la Radeon HD 5870 ! Sachant qu’il est fréquent que les clip arts soient composés de plus de 100 courbes, il devient impossible de déplacer ces objets flottants sans clignotements, ce qui pose de graves problèmes de productivité, même pour les programmes aux graphisme les plus basiques.

En outre, de nombreuses applications font appel à des commandes graphiques simples que les développeurs ne voient pas l’intérêt de mettre en mémoire tampon : ces applications sont les plus touchées par les manquements de la Radeon HD 5870.

Problèmes de dessin avec mise en mémoire tampon

Même lorsqu’un logiciel utilise une mémoire tampon interne et gère la mise à jour des formes géométriques, il reste possible de rencontrer des problèmes de performances. Même chose pour le transfert en blocs du contenu du tampon (la fonction BitBlt), qui fonctionne au ralenti.

Quels types de programmes sont affectés ?

En bref, tout programme de 2D qui émet des commandes GDI pour dessiner des objets à l’écran est susceptible de rencontrer un problème avec les nouvelles Radeon HD, en particulier lorsqu’ils doivent dessiner un grand nombre d’objets. C’est également le cas des logiciels qui manipulent des informations graphiques, comme les programmes de dessin, de planification de projets ou même de bureautique (certains éléments de la suite Microsoft Office sont par exemple affectés).

Avec quels programmes avons-nous rencontré des problèmes concrets ?

• CorelDraw, Adobe Illustrator, Adobe Freehand MX, Nemetschek AllPlan (fonctions 2D)
• Adobe Photoshop CS3/CS4 (objets vectoriels sur plusieurs couches)
• Microsoft Publisher, Microsoft PowerPoint et d’autres logiciels similaires
• Microsoft Excel, lors du rendu de graphiques de grande taille ou de grandes feuilles de calcul comportant des aplats de couleur
• Divers outils de construction, notamment pour le dessin électrique, de plomberie ou d’air conditionné
• Divers outils spécifiques à un secteur donné (annotations de dessins, plans de sites ou d’aménagement urbain, etc.)

Tous ces programmes fonctionnent relativement correctement sur les autres cartes graphiques grand public modernes. Elles n’ont pas non plus besoin de cartes graphiques pour station de travail, de type FireGL ou Quadro ; en fait, nous avons obtenu des résultats satisfaisant sur bon nombre de cartes graphiques d’entrée de gamme vendues moins de 50 €.

Quels programmes ne sont, de manière générale, PAS affectés ?

• Tous les programmes qui effectuent le rendu en 2D à l’aide de Direct2D (mais qui ne fonctionnent donc pas sous Windows XP)
• Tous les programmes de 3D qui utilisent Direct3D et n’effectuent pas de rendu en 2D
• Tous les programmes qui effectuent le rendu en 2D à l’aide d’OpenGL

Résumé et conclusions préliminaires

Nous vous conseillons d’attendre la sortie de nouveaux pilotes (ce qui ne devrait pas tarder : nous sommes en ce moment en train de les tester dans notre laboratoire) puis, seulement, de vérifier quels sont les problèmes, parmi ceux que nous décrivons, qui affecterons votre productivité. Il est inutile de s’affoler : ces problèmes ne concernent que les performances en 2D sous Windows 7 lorsqu’une application utilise GDI ou GDI+ pour effectuer un rendu en 2D. Malheureusement, c’est le cas de la plupart des applications prévues pour Windows XP, mais il faut également prendre en compte le fait que l’accélération matérielle n’apporte de toute façon rien à certaines primitives.

Étant donné qu’en plus de la Radeon HD 5870, la 5750 est également affectée, il y a de fortes chances pour que le problème soit dû aux pilotes et non au matériel (NDLR : ce qu’ATI a confirmé entretemps) et qu’il touche l’ensemble de la gamme Radeon HD 5xxx. Bref, bien qu’il ne s’agisse pas d’une pandémie au sein des nouvelles cartes graphiques, cela reste un problème sérieux pour les utilisateurs concernés, raison pour laquelle nous estimons que les éditeurs devraient mettre à jour leurs logiciels aussi rapidement que possible.

Notre logiciel de benchmark 2D en GDI

Il est maintenant temps de vous présenter notre logiciel de benchmark 2D : tout simple, il génère en sortie des commandes GDI, dont nous analysons les performances.

Remarque importante : les résultats que nous sommes sur le point de présenter ne correspondent pas à ceux de la première partie de cet article, surtout en ce qui concerne le dessin de lignes, parce que nous avons depuis lors apporté plusieurs modifications à notre outil de benchmark.

Configuration requise :

• Windows 2000 ou version supérieure
• 2 Mo d’espace disque
• Une résolution de 1024 x 768 ou supérieure

Ce programme n’a pas besoin d’être installé et est donc extrêmement portable. Toutes les mesures enregistrées dépendent énormément du CPU ! Les applications et services en mémoire ont une influence sur les résultats, qui varient également légèrement d’un lancement à l’autre.

Configuration de test

Pour ces tests, nous avons complètement nettoyé un PC de bureau puis avons créé un nouveau compte utilisateur. Nous n’avons installé aucun gadget, avons évité d’ouvrir la moindre fenêtre et avons désactivé tous les programmes fonctionnant en arrière-plan et services inutiles. Nous avons ensuite lancé le programme Tom2D.exe et l’avons associé à un seul cœur du processeur.

Modes de test

Comme l’indique la capture d’écran ci-dessous, Tom2D autorise deux modes de test : dessin direct sur le périphérique d’affichage ou mise en mémoire tampon DIB.

Éléments testés

Tom2D teste diverses commandes GDI l’une après l’autre et accumule ainsi une série de données. Il suffit alors d’analyser les résultats et de les comparer pour voir où se situent les goulots d’étranglement.

Pour lancer automatiquement tous les tests l’un après l’autre et obtenir un résultat cumulé, il suffit de cliquer sur le bouton « Run complete benchmark ». Le bouton « Copy to clipboard » sert quant à lui à copier les résultats sous forme de texte dans le presse-papier, au cas où vous souhaiteriez les importer dans un autre logiciel.

• Télécharger Tom2D

Dans les pages qui suivent, nous vous présenterons chaque test individuellement et vous expliquerons leur fonctionnement. Nous en profiterons pour vous faire part des résultats que nous avons enregistrés.

Outre les configurations ci-dessus, nous devons également signaler les nombreuses combinaisons que nos lecteurs ont testé sous Windows 98, XP et Vista. Nous ferons un tableau récapitulatif de toutes les valeurs plus loin dans cet article. Notez que nous n’avons aucun résultat pour les chipsets graphiques AMD 780G/785G car nous attendons toujours la sortie de pilotes adaptés.

Merci à vous !

Nous tenons à remercier les nombreux lecteurs qui ont lancé notre benchmark sur leur machine et nous ont fait part de leurs résultats. Toutes ces valeurs (plus de 800 résultats) ont été collectées, comparées à nos propres résultats et intégrées à notre système de classement. À quelques exceptions près, la plupart d’entre elles correspondent tout à fait à nos observations, ce qui tend à confirmer la validité de nos tests.

Tom2D : texte

Notre premier test concerne l’affichage de texte. ClearType a été automatiquement activé dans tous les cas, à l’exception de notre configuration Windows XP sur processeur Atom et de notre machine de test Windows 98 SE.

Contenu du test

Le test consiste en l’affichage de 500 séquences de texte dont la taille varie de 8 à 197 points. La police est toujours Arial, mais les lettres, leur couleur et leur position à l’écran sont sélectionnées aléatoirement. La valeur servant à amorcer le générateur de nombres aléatoire est toujours la même, ce qui signifie que chaque instance de test doit donner les mêmes résultats.

Fonctions GDI appelées

Pour le benchmark d’affichage direct :

SetBkMode
GetTextMetrics
CreateFontIndirect
SetTextColor
TextOut
SelectObject
DeleteObject

Pour le benchmark d’affichage avec mise en mémoire tampon DIB :

CreateCompatibleDC
CreateDIBSection
CreateSolidBrush
Rectangle
BitBlt

Résumé

Rien qui puisse porter à controverse dans ce test : les cartes Radeon ne sont pas trop à la traîne et ne font montre que d’une relative faiblesse.

Tom2D : lignes

Ce test fait appel à la fonction de dessin de lignes en GDI. Dans la premièrepartie de cet article, c’est ici que nous avions noté les écarts les plus flagrants entre les différentes cartes graphiques. N’hésitez pas à lire le résumé au bas de cette page, parce que les problèmes que nous avions décrits il y a quelques jours ont depuis lors été reproduits sur plus de 40 machines, sans compter les résultats que vous nous avez envoyé.

Contenu du test

Ce test consiste à dessiner environ 150 000 lignes dont la longueur, la couleur et la position à l’écran sont aléatoires. La valeur servant à amorcer le générateur de nombres aléatoire est toujours la même, ce qui signifie que chaque instance de test doit donner les mêmes résultats. Tous les objets apparaissent à l’intérieur de la surface de dessin, il n’est donc nécessaire de procéder à aucun découpage.

Fonctions GDI appelées

Pour le benchmark d’affichage direct :

CreatePen
MoveToEx
LineTo
SelectObject
DeleteObject

Pour le benchmark d’affichage avec mise en mémoire tampon DIB :

CreateCompatibleDC
CreateDIBSection
CreateSolidBrush
Rectangle
BitBlt

Résumé

Comme vous pouvez le voir à l’examen des diagrammes ci-dessus, nous avons confirmé les résultats de nos premiers tests, où les ATI Radeon HD 5xxx font montre de performances totalement insuffisantes.

Curieusement, les résultats augmentent lorsque nous désactivons Aero, ouvrons une deuxième fenêtre (par exemple Firefox) et la maximisons avant de repasser à notre outil de benchmark et de lancer le test. La valeur alors obtenue est plus élevée, un phénomène que nous sommes parvenus à reproduire à la perfection sur différentes machines. Si l’on relance le test après quelques instants, par contre, cet effet ne se manifeste plus et on revient aux piètres performances du début.

Ce comportement est une fois de plus symptomatique d’un problème de pilotes. Nous ne pouvons qu’espérer que les pilotes expérimentaux que nous essayons en ce moment permettront de corriger la situation. Les résultats des autres cartes parlent d’eux-mêmes : une fois de plus, l’Atom couplé au GMA 950 (avec Aero activé) affiche des résultats étonnamment bons tandis que la GeForce GTX 285 se traîne en rendu direct avec Aero désactivé. Pour information, tout résultat supérieur à 20 000 lignes est considéré comme suffisant, dans la mesure où, au-delà de cette valeur, on ne voit de toute façon plus vraiment la différence dans une utilisation normale.

Tom2D : splines / courbes de Bézier

Après les lignes, nous sommes passés au rendu de courbes de Bézier. Une fois encore, dans la première partie de cet article, nous avions mis le doigt sur des écarts phénoménaux entre les différentes cartes.

Contenu du test

Notre outil de benchmark dessine 100 000 courbes de Bézier et splines dont la longueur, le rayon de courbure, la couleur et la position à l’écran sont définis aléatoirement. Une fois de plus, la valeur servant à amorcer le générateur de nombres aléatoire est toujours la même, ce qui signifie que chaque instance de test doit donner les mêmes résultats. Comme pour le test précédent, tous les objets apparaissent à l’intérieur de la surface de dessin, il n’est donc nécessaire de procéder à aucun découpage.

Fonctions GDI appelées

Pour le benchmark d’affichage direct :

CreatePen
PolyBezier
SelectObject
DeleteObject

Pour le benchmark d’affichage avec mise en mémoire tampon DIB :

CreateCompatibleDC
CreateDIBSection
CreateSolidBrush
Rectangle
BitBlt

Résumé

Les résultats de ce test sont très semblables à ceux obtenus en rendu de lignes, jusque dans le paradoxe de la hausse de performances enregistrée après l’ouverture d’une autre fenêtre. De manière générale, les chipsets graphiques intégrés d’Intel sont à la traîne, bien que la combinaison Atom / GMA 950 se révèle une fois encore plus que capable.

Tom2D : polygones

Viennent ensuite les polygones. Ici encore, plusieurs cartes graphiques montrent des signes de faiblesse intéressants.

Contenu du test

Dans le cadre de ce test, nous dessinons 60 000 polygones comportant entre 3 et 30 sommets, dont les côtés de longueur aléatoire, dont la surface est colorisée ou vide et dont la position à l’écran est déterminée de manière aléatoire. Comme pour les autres benchmarks, la valeur servant à amorcer le générateur de nombres aléatoire est toujours la même, ce qui signifie que chaque instance de test doit donner les mêmes résultats. Tous les objets apparaissent entièrement à l’intérieur de la surface de dessin, il n’est donc nécessaire de procéder à aucun découpage.

Fonctions GDI appelées

Pour le benchmark d’affichage direct :

CreatePen
CreateSolidBrush
GetStockObject
SelectObject
DeleteObject
Polygon

Pour le benchmark d’affichage avec mise en mémoire tampon DIB :

CreateCompatibleDC
CreateDIBSection
Rectangle
BitBlt

Résumé

Lorsque les polygones sont mis en mémoire tampon, les performances sont identiques qu’Aero soit activé ou non. En dessin direct, les cartes graphiques haut de gamme se retrouvent en queue de peloton. Nous nous demandons vraiment à quel niveau peut bien se situer le goulot d’étranglement dont souffrent les cartes ATI. Et pourquoi la GeForce GTX 285 de Nvidia ralentit-elle, voire gèle-t-elle, quand elle dessine des polygones, au point de se retrouver derrière le couple Intel Atom / GMA 950 et même le chipset graphique intégré G45 ?

Tom2D : rectangles

Les rectangles constituent un élément essentiel de notre test.

Contenu du test

Ce test consiste à dessiner 200 000 rectangles dont la taille, la couleur et la position à l’écran sont aléatoire. La couleur du bord est toujours identique à celle du remplissage. Comme pour les autres benchmarks, la valeur servant à amorcer le générateur de nombres aléatoire est toujours la même, ce qui signifie que chaque instance de test doit donner les mêmes résultats. Et une fois de plus, tous les rectangles apparaissent à l’intérieur de la surface de dessin : il n’est donc nécessaire de procéder à aucun découpage.

Fonctions GDI appelées

Pour le benchmark d’affichage direct :

CreatePen
CreateSolidBrush
Rectangle
SelectObject
DeleteObject

Pour le benchmark d’affichage avec mise en mémoire tampon DIB :

CreateCompatibleDC
CreateDIBSection
BitBlt

Résumé

Apparemment, dessiner des rectangles avec la GDI n’est pas une opération rapide. À notre surprise, l’immense majorité des cartes graphiques le font plus rapidement quand Aero est désactivé. Enfin, elles ralentissent toutes (sans exception) considérablement lorsque nous utilisons la mise en mémoire tampon.

Tom2D : ellipses

Le test suivant est celui des ellipses, dont les résultats sont très proches de celui des rectangles.

Contenu du test

Ce test consiste à dessiner environ 100 000 ellipses dont la taille, la couleur et la position à l’écran sont aléatoires. L’intérieur de certaines ellipses est vide, celui d’autre est colorisé, et pas nécessairement dans la même couleur que le bord. Comme précédemment, la valeur servant à amorcer le générateur de nombres aléatoire est toujours la même, ce qui signifie que chaque instance de test doit donner les mêmes résultats. Et une fois de plus, toutes les ellipses apparaissent à l’intérieur de la surface de dessin : il n’est donc nécessaire de procéder à aucun découpage.

Fonctions GDI appelées

Pour le benchmark d’affichage direct :

CreatePen
CreateSolidBrush
GetStockObject
Circle
Arc
SelectObject
DeleteObject

Pour le benchmark d’affichage avec mise en mémoire tampon DIB :

CreateCompatibleDC
CreateDIBSection
BitBlt

Résumé

Dessiner des ellipses ne semble pas prendre autant de temps que des rectangles. Pour l’écriture directe, les deux cartes ATI se font dépasser par le couple Intel Atom / GMA 950 ; lorsque la mise en mémoire tampon est activée, les résultats sont tous relativement semblables.

Tom2D : blitting

Le « blitting » consiste à copier le contenu d’un bitmap dans d’autres bitmaps. Pour ce test, nous copions des morceaux d’images.

Contenu du test

Ce test consiste à utiliser les commandes de transfert de blocs (« blit ») pour copier 50 000 morceaux d’images dont la taille varie de 1×1 à 500×500 pixels et dont la position d’arrivée est déterminée aléatoirement. Nous utilisons alternativement les différents styles de copie, à savoir copy, invert et paint. Comme toujours, la valeur servant à amorcer le générateur de nombres aléatoire est toujours la même, ce qui signifie que chaque instance de test doit donner les mêmes résultats. Cette fois encore, tous les objets apparaissent à l’intérieur de la surface de dessin et il n’est donc nécessaire de procéder à aucun découpage.

Fonctions GDI appelées

Pour le benchmark d’affichage direct :

BitBlt (copy, invert, paint)

Pour le benchmark d’affichage avec mise en mémoire tampon DIB :

CreateCompatibleDC
CreateDIBSection
SelectObject
DeleteObject

Résumé

Le transfert de blocs semble constituer une faiblesse générale des Radeon HD 5xxx sous Windows XP. L’Atom a été littéralement mis à genoux lors du test de blitting avec mémoire tampon, tandis que les deux cartes les plus haut de gamme (GeForce GTX 285 et Radeon HD 5870) sont pratiquement inutilisables sous XP.

Tom2D : étirement

Dans le contexte des graphismes en 2D, l’étirement désigne une opération de transformation et de copie du contenu d’un bitmap dans d’autres bitmaps. Il s’agit donc de transférer un morceau d’image dépendante du périphérique et de modifier ses dimensions lors de la copie.

Contenu du test

Pour ce test, nous prenons 10 000 morceaux d’images dont la taille varie entre 1×1 et 500×500 pixels, puis nous les copions, les transformons et les affichons à un endroit de l’écran choisi aléatoirement et dont la taille varie également entre 1×1 et 500×500 pixels. Comme pour le test de blitting, nous utilisons alternativement les différents styles de copie, à savoir copy, invert et paint. La valeur servant à amorcer le générateur de nombres aléatoire est toujours la même, ce qui signifie que chaque instance de test doit donner les mêmes résultats. Et une fois de plus, tous les objets apparaissent à l’intérieur de la surface de dessin et il n’est donc nécessaire de procéder à aucun découpage.

Fonctions GDI appelées

Pour le benchmark d’affichage direct :

StretchBlt (copy, invert, paint)

Pour le benchmark d’affichage avec mise en mémoire tampon DIB :

CreateCompatibleDC
CreateDIBSection
SelectObject
DeleteObject

Résumé

Surgie de nulle part, notre vieille Voodoo 4500 prend la première place en rendu direct et fait mordre la poussière à toutes les autres cartes graphiques !

Alors que la Radeon HD 5870 s’en sort honorablement en dessin avec mémoire tampon sous Windows XP, la GeForce GTX 285 est une vraie déception dans les mêmes conditions.

Conclusion

Pour résumer notre analyse, nous avons remarqué que les cartes graphiques haut de gamme actuelles se révèlent franchement décevantes en 2D. Cette conclusion est, certes, en partie due aux performances des Radeon HD 5xxx dans certains cas particuliers sous Windows XP, mais surtout à une sérieuse faiblesse de leur part en matière de dessin en rendu direct sous Windows 7.

Cette dernière faiblesse est d’autant plus frustrante qu’il suffit d’appliquer un petit truc (ouvrir et refermer une autre fenêtre) pour voir les performances augmenter temporairement, comme nous l’expliquions à la page consacrée au benchmark de dessin de lignes. Le problème est donc clairement d’ordre logiciel, non matériel. Nvidia ne fait guère mieux : même la GeForce GTX 285 se voit mettre la pâtée par les chipsets graphiques intégrés. Un comble quand on pense que les cartes graphiques de ce niveau coûtent souvent plus de 300 € !

En parlant des chipsets graphiques intégrés, il est intéressant de noter que ceux-ci se montrent rapides dans un grand nombre de nos tests. C’est particulièrement le cas du nForce 630i, un produit pourtant plus tout jeune mais qui affiche des scores plutôt bons dans tous les benchmarks. Les IGP d’Intel semblent eux aussi particulièrement bien adaptés aux applications 2D, malgré leur réputation peu engageante en matière de 3D. Côté Intel toujours, le CPU Atom souffre de son manque de puissance intrinsèque (ce qui n’a rien de surprenant), qui ralentit forcément le rendu en GDI et le confine bien souvent à la dernière place. Il s’agit malheureusement d’une limitation profondément dommageable pour un processeur si souvent couplé à Windows XP ; il conviendra donc de choisir les applications utilisées sur cette plateforme.

Bien que la GDI ne soit plus aujourd’hui ce qui se fait de mieux en matière de 2D, il ne fait aucun doute que les résultats obtenus lors de nos tests continueront encore à s’appliquer à de nombreux utilisateurs pendant un bon moment, pour les raisons que nous avons expliquées.

Note de la rédaction : Comme promis, ATI nous a recontacté après la publication de la première partie de notre article et nous a fourni un pilote censé régler les problèmes que nous avons rencontré. Nous sommes actuellement en train de tester ce pilote au sein de notre laboratoire allemand et vous ferons part de nos conclusions dans les plus brefs délais.

Si vous souhaitez essayer notre logiciel de benchmark Tom2D, il est disponible à cette adresse.