Introduction
Toutes les cartes graphiques ne sont-elles pas égales en 2D ?
Depuis le lancement de Windows 7 il y a quelques mois, les deux constructeurs de cartes graphiques ont lancé de nouveaux GPU ainsi que des pilotes compatibles. Il a coulé suffisamment d’eau sous les ponts pour que soient réglées les difficultés techniques inhérentes à tout nouveau système d’exploitation (lesquelles ont fort heureusement été beaucoup moins nombreuses par rapport à Vista), ce qui nous a permis d’exécuter bon nombre de benchmarks sans souffrir de biais.
Alors que la 3D est plus que jamais au centre de la scène, nous nous sommes demandés s’il ne serait pas instructif de faire un point sur une composante de l’affichage graphique que l’on tient pour acquise au quotidien sans trop y penser, à savoir la 2D. Cette piste de réflexion n’est pas venue d’une illumination du genre « ajoutons à la suite de tests quelque chose qui n’a pas posé problème depuis l’époque où le RAMDAC impactait significativement les performances » comme on le verra plus loin.
Bien que la réactivité de la GUI (interface graphique utilisateur) Windows constitue notre première intérêt (c’est un des points sur lesquels 7 est salué par rapport à Vista), il nous a fallu reconnaitre malgré nous que la supposée « refonte graphique » de Windows 7 n’a rien de novateur. Par rapport à Windows XP (et même Vista), ATI et NVIDIA ne sont pas encore vraiment parvenus à optimiser les graphismes 2D sous Windows 7 ne serait-ce qu’en ce qui concerne la toute nouvelle implémentation de la GDI (interface des dispositifs d’affichage) que l’API nécessite. En effet, ce que l’on connaît sous le terme « graphismes 2D » va au-delà d’une belle palette de couleurs, des effets de dégradés sur les objets (blending) ou encore des menus animés et ombres portées (drop shadows) : les développeurs doivent mettre les mains dans les pixels, lignes, courbes, rectangles polygones et autres « graphismes primitifs » comme on les appelle parfois.
Note préliminaire
Bien que nous ayons attaché beaucoup d’importance à ne pas jouer sur un registre émotionnel, les pro-ATI ou pro-NVIDIA auront peut-être besoin de lire ce qui suit en redoublant d’attention. Ayant eu nous-mêmes du mal à croire aux résultats de nos propres tests et dans l’intérêt de tous, cet article a été préparé avec minutie et sans contrainte de temps afin d’être aussi objectif que possible comme le protocole de test inédit peut en témoigner. D’autre part, le but était aussi d’avoir une portée aussi large que possible : outre les joueurs, cet article est une contribution et une aide à tout utilisateur se servant d’un PC pour travailler.
Notons que pour le moment, travailler en 2D sous Windows 7 peut s’avérer pénible dans certains cas : nous avons par exemple eu du mal à générer des graphismes vectoriels, effectuer des rendus plus ou moins complexes en CAO, ou même jouer à des titres 2D en qualité graphique élevé avec une Radeon HD 5870. Au-delà du constat, il est intéressant d’analyser la source du problème pour le comprendre autant que possible.
Théorie et pratique
Vu que nous sommes probablement une majorité à manquer d’informations en ce qui concerne l’implémentation et le comportement de l’accélération 2D sous Windows depuis XP jusqu’à Seven, nous avons choisi de séparer cet article en deux parties pour vraiment faire le tour de la question. Ainsi, nous verrons aujourd’hui le contexte et les aspects techniques des graphismes en 2D de manière à ce que l’on puisse avoir une base commune lorsqu’il s’agira d’interpréter les tests et résultats. En parlant de tests, nous sommes allés jusqu’à développer notre propre benchmark (qui sera disponible au téléchargement). Les deux parties se veulent donc être informatives, accessibles et utiles autant que faire se peut.
Commençons par les bases du graphisme en 2D.
Windows : une souris qui sert de lave vitre ?
Revenons en 1985. Mikhaïl Gorbatchev était alors élu secrétaire général du parti communiste de l’Union Soviétique, Robert Ballard retrouvait l’épave du Titanic et Coluche ouvrait les Restos du Cœur. C’est aussi en 1985 que Microsoft Windows 1.0 était lancé sans faire de bruit.
Même en 1985, le fait d’ajouter une interface graphique à un système d’exploitation en lignes de commande n’était pas révolutionnaire. C’est précisément cette approche que des entreprises comme Microsoft et Digital Research ont utilisé pour rendre les PC attractifs au plus grand nombre : l’idée était de créer un logiciel suffisamment accessible pour que les utilisateurs non-avertis puissent s’en servir sans passer par une phase d’apprentissage écœurante. On notera que contrairement à Windows 1.0, GEM permettait d’afficher plusieurs fenêtres superposées en plus d’être multiutilisateurs.
Si 1987 n’avait pas vu la sortie de Windows 2.0 qui était enfin capable d’afficher plusieurs fenêtres superposées, il est tout à fait possible que personne ne connaitrait Microsoft Windows de nos jours. La firme de Redmond doit en fait sa survie au-delà de ses deux premières années d’existence à quelqu’un qui a tout simplement pris la succession de Bill Gates : Steve Ballmer. Sa prestation dans la pub pour Windows 1.0 est tout simplement inoubliable, comme le culot avec lequel il fait passer le prix de l’Os pour une broutille (99 $ en 1985 représentaient une somme considérable, équivalente à 197 $ en 2009) malgré le fait que ce dernier soit incapable de vraiment gérer l’affichage de plusieurs fenêtres. Le personnage a un jeu de scène hors-pair et même un certain génie en terme de marketing.
Depuis la mouture 2.0, Windows a fait preuve de changements allant de l’évolution à la révolution et ce à chaque version majeure, or c’est justement un vrai bouleversement sous Windows 7 qui a attiré notre attention.
Ce sont les questions que Windows 7 a soulevé qui nous ont conduit à revenir aux sources de l’OS, pour des raisons simples et originales à la fois. Grâce aux tests, nous avons appris qu’il y avait deux aspects bien distincts dans l’affichage graphique sous Windows : d’une part l’interface graphique utilisateur (la personnalisation a été délibérément mise de côté pour se concentrer sur l’apparence et le ressenti par défaut), ce qui inclus le mouvement et la gestion des fenêtres, et d’autre part les fonctions graphiques nécessaires pour créer l’environnement bureautique. L’affichage des fenêtres et leur gestion ont beau être liés, il s’agit en fait de deux activités distinctes sous Windows : si l’apparence de l’interface et la prise en main n’a eu de cesse d’évoluer, les fonctions graphiques 2D basiques sous-tendues ont curieusement stagné.
Les plus avertis savent déjà qu’une interface graphique à fenêtres ne cache pas de purs graphismes 2D. Commençons donc par voir le faible de nombre de commandes graphiques 2D, lesquelles doivent être examinées dans l’optique de leur rendu plus ou moins 3D par nature sur un affichage physique.
Les limites de la 2D : un espace confiné et de nombreuses fenêtres
Rendu et accélération 2D sous Windows
Si l’on regarde un rendu 2D au sein d’une fenêtre, il n’y a bien entendu qu’un axe X pour la largeur et Y pour la hauteur et rien quant à la profondeur.
Sous Windows, les graphismes 2D sont rendus par l’interface des dispositifs d’affichage (GDI), laquelle gère tous les langages de haut niveau et inclus les fonctions graphiques nécessaires pour rendre les objets 2D. Les évolutions comme GDI+ et Direct2D n’ont pas de rôle majeur ici vu que GDI est encore le principal outil utilisé par les programmes pour l’affichage de graphismes 2D. Si les fonctions de dessin clef pour les pixels, lignes, courbes, polygones, ellipses et autres étaient toutes calculées par le CPU à l’origine, la progression et spécialisation des GPU a permis aux cartes graphiques d’accélérer calculs et rendus 2D. Cette forme d’accélération reste importante de nos jours, même si la 2D n’est plus son premier objectif. Un troisième axe s’impose pour vraiment tirer parti des ressources matérielles.
Simple rendu de multiples fenêtres sans accélération matérielle
La méthode originelle de rendu 2D qui se cache derrière la juxtaposition de fenêtres est aussi simple que directe. Il faut être conscient de deux choses : d’une part, l’aire au sein d’une fenêtre qui évolue (et doit donc être redessinée) et d’autre part, l’ordre dans lequel les fenêtres/objets se superposent (de façon visible ou invisible). Cette information mène à un affichage en 2,5 dimensions ou graphismes en calques (layered graphics) dès lors qu’une troisième coordonnée prend une valeur 0 (cachée) ou 1 (visible) comme une sorte de dimension alternative. Ceci explique pourquoi on entend parler de graphismes 2,5D.
Une fois que l’ordre ou la visibilité des fenêtres a été déterminé, leur contenu visible peut alors être dessiné avec des fonctions graphiques purement 2D. Reste qu’il est non seulement nécessaire de rendre l’intégralité du contenu des fenêtres, mais aussi de gérer les différents types d’information et éléments visuels. Que se passe t-il par exemple lorsque les fenêtres sont déplacées ? Dès lors que le contenu d’une autre fenêtre se retrouve partiellement/complètement révélé, Windows exécute la routine graphique WM_PAINT pour travailler sur la zone rectangulaire à redessiner (“dirty rectangle”) sur la base d’informations précises qui permettent de l’identifier. Malheureusement, de nombreuses implémentations redessinent intégralement la fenêtre sans discernement quand aux besoins réels malgré l’accès à ces informations, or les performances graphiques peuvent s’en trouver largement impactées. Autre inconvénient, cet effet de flou/dédoublement aussi connu que peu apprécié lorsque l’on bouge rapidement une fenêtre sur une configuration n’ayant pas d’accélération matérielle.
Récapitulons brièvement ce que l’on vient de voir : plusieurs fenêtres sont affichées à l’écran et leur contenu en 2D doit être rendu à l’écran pour les rendre visible. Vu qu’elles peuvent être déplacées librement, on peut les superposer et donc en masquer certaines de façon partielle ou totale. Le contenu visible de toutes ces fenêtres doit être géré et dessiné à l’écran aussi vite que possible. On sait par ailleurs qu’un processeur (y compris des modèles puissants) peut être pris à défaut dans ces exercices complexes. Quoi de plus logique alors que de transférer cette charge à la carte graphique ? La pratique est bien plus complexe que la théorie comme nous allons le voir.
2,5D et le mythe de l’accélération matérielle 2D
Dans un premier temps, les cartes graphiques dédiées se sont imposées dans un contexte exclusivement 2D. Le fait que ces cartes excellent encore aujourd’hui à gérer des rendus complexes n’a rien d’un secret et malgré cela, elles peuvent se retrouver à genoux dans un contexte quotidien. Ceci est particulièrement vrai lorsqu’il s’agit de rendre des effets graphiques complexes avec les dernières versions de Windows. Cette situation s’explique par la complexité des interfaces graphiques de Windows depuis Vista, mais aussi par des fonctionnalités graphiques limitées.
Accélération 2D pour les fonctions de dessin
Intéressons nous à la frange de l’accélération 2D qui s’attèle au rendu natif du signal graphique, de la GDI jusqu’à la carte graphique elle-même. Sont concernés non seulement de simples objets géométriques comme les pixels, lignes, courbes, polygones, rectangles et ellipses, mais aussi leur mise à l’échelle, rendu ou encore les lissages de polices (comme TrueType ou OpenType).
L’accélération matérielle des ces « primitives 2D » ayant disparu des cartes graphiques, on ne la retrouve plus dans les produits destinés aux particuliers depuis un bon moment. De nos jours, l’accélération des graphismes 2D va de pair avec celle de la 3D à la différence près qu’elle est exclusivement géré par les pilotes.
La deuxième partie de cet article nous donnera l’occasion de présenter ainsi que d’expliquer le fonctionnement d’un benchmark que nous avons spécifiquement développé pour les graphismes 2D, lequel teste en profondeur les fonctions graphiques 2D fondamentales. Par ailleurs, celui-ci met en avant le fait que les pilotes graphiques exercent une influence aussi néfaste qu’inattendue sur les graphismes 2D. Nous présenterons également une petite sélection de neuf critères de test.
Accélération 2,5D de la GUI
La traduction de fonctions de dessin ne constitue qu’une partie de l’accélération 2D. Les cartes graphiques 3D actuelles proposent par exemple une accélération aussi sensible qu’appréciable permettant de rendre, gérer et afficher des informations graphiques 2,5D au niveau matériel.
Quel est le principe ici ? Comme c’est le cas pour les affichages en 3D, le contenu des fenêtres (qu’il soit visible ou masqué) est rendu et conservé intégralement comme région virtuelle rectangulaire. Ce même contenu est donc vu en temps réel et ce pour toutes les fenêtres. Ainsi, rien ne nécessite d’être recalculé lorsque les fenêtres sont déplacées ou modifiées ; seules les zones « démasquées » ont besoin d’être dessinées, de même que tout ce qui a pu changer depuis le dernier rafraîchissement. La carte graphique connait en permanence la taille et la position des rectangles virtuels représentés comme fenêtres. Grâce au tampon de profondeur (Z-buffer), elle est également capable d’assurer le suivi de l’ordre et de la priorité d’affichage des fenêtres ou objets affichés à l’écran (ce que l’on qualifie de Z-order). La carte graphique est donc à même de décider ce qui est visible et ce qui doit être rendu tout seul à l’écran.
Résumons brièvement :
L’accélération 2D actuelle comprend non seulement l’implémentation de fonctions clés en dessin 2D, mais aussi de pseudo-3D pour les fenêtres et l’interface graphique utilisateur.
Il serait épuisant et pas forcement pertinent d’examiner chaque version de Windows plus en détail. Etant donné que les problèmes qui nous ont poussés à faire ces tests n’apparaissent que sous Windows 7, nous avons limité notre expérience à XP, Vista et bien entendu Seven.
Windows XP : 2D à l’ancienne et limites de WM_PAINT
On pourra dire ce que l’on voudra au sujet de Windows XP, le fait est que l’accélération de la GDI fonctionne sans accroc à ce jour, et suffit en l’état à bon nombre d’applications. En revanche, XP est incapable de porter des techniques de calques 2,5D sur des cartes graphiques modernes. Comme on l’a vu précédemment, le rendu du contenu des fenêtres dépend directement des programmes.
Cette limitation ne posera pas de problèmes si l’on travaille sur un programme qui ne s’affiche que sur une seule fenêtre, comme c’est typiquement le cas des applications SDI (single device interface). A contrario, les choses se compliquent dès lors que les fenêtres se multiplient à l’écran. Qui ne serait pas intéressé par une technique de calques améliorée qui prendrait en charge les menus, tirerait mieux parti du matériel et serait apte à mieux gérer les fenêtres sur des affichages multiples ? Qui ne serait pas prêt à abandonner les effets de flou/trainées et parvenir à de meilleures performances 2D ?
Bien que les performances purement 2D des programmes de dessin vectoriel comme Corel Draw et les applications CAD soient satisfaisantes (ce qui ne manque pas de sel vu que l’accélération matérielle de la GDI n’est pas supportée), les limites de WM_PAINT sont frappantes : dès que l’interface graphique utilisateur de XP est surchargée d’animations, ombres douces, fenêtres transparentes et autres éléments graphiques, on prend bien la mesure du problème.
Bon nombre d’utilisateurs ont compris qu’il vaut mieux afficher les fenêtres en mode classique lorsqu’on les déplace, de même que faire l’impasse sur les menus animés. D’une manière générale, la préservation des ressources graphiques est une bonne approche sous Windows XP. Malheureusement, de nombreux thèmes de bureau stylisés ont vite trouvé le chemin de la corbeille une fois l’euphorie autour du nouvel Os passée vu que les configurations avaient alors perdu leur capacité à tout rendre sans erreurs ou latences significatives.
Microsoft a rapidement pris conscience du fait que sa technologie 2D (alors incluse dans toutes les versions de Windows, XP y compris) avait besoin d’être remplacée. En parallèle, la généralisation de cartes graphiques 3D de plus en plus puissantes alliée à la démocratisation des coûts montraient bien que les temps (comme les machines) étaient en train de changer.
Il faut aussi prendre note que l’accélération matérielle sous XP n’était pas possible avec les résolutions natives que proposait le chipset AMD 780G non plus. Les fenêtres paraissaient donc lentes et même l’utilisation basique d’Internet s’en trouvait perturbée. Si les pilotes successifs ont tout de même permis d’atténuer les problèmes, le chipset 780G n’a toujours pas un fonctionnement optimal sous XP à l’heure actuelle, contrairement au 740G. Ceci étant, vu que XP est en train de basculer dans l’obsolescence, peut-être qu’il devrait en être de même pour cette digression…
Début 2007, Microsoft commercialisait la version de son système d’exploitation la plus décriée après Millenium : Vista. Qu’on l’aime ou le haïsse, il n’était plus possible de repousser plus longtemps certaines avancées techniques.
En bref
- L’accélération 2D des commandes GDI marche parfaitement sous Windows XP
- Pas d’accélération matérielle pour les calques en 2,5D, rendant ainsi l’interface utilisateur lente
- La nécessité de redessiner le contenu des fenêtres modifiées de façon répétée est chronophage et coûteuse en ressources
Windows Vista : de vrais progrès et l’art de l’omission
Lors de la première installation de Vista, nous avons au du mal à contenir notre impatience.
Mais ce qui semblait révolutionnaire au premier coup d’œil s’est avéré néfaste d’un programme à un autre, pour aller jusqu’à prendre des tournures de cauchemar dans certains cas.
Implémentation de la 2,5D au niveau matériel
Cette technologie fut enfin implémentée pour la première fois dans Windows Vista en 2006. Il faut cependant signaler une petite limitation : l’activation d’Aero était nécessaire pour rendre l’accélération fonctionnelle, de même que les calques 2,5D nécessitaient une carte graphique 3D quand bien même on ne s’adonnait pas aux programmes en 3D ou jeux. Tous ceux qui utilisaient le thème Vista Basic en étaient pour leurs frais : effets de flou/trainées comme sous XP vu que les calques en 2,5D étaient automatiquement désactivés, et ce même en présence d’une carte 3D !
Effet diaporama
Le passage aux calques 2,5D a aussi généré un lot de problèmes pour Microsoft. Vista était perçu comme lent, mais assez stable. Mais que s’est-il passé ? On a déjà vu que la GDI était un élément clé dans la programmation graphique. Le lancement de GDI+, extension (hélas) extrêmement lente de la GDI basée sur C++, n’a jamais été un bouleversement technologique du fait de ses performances et l’on ne pouvait dès lors plus nier le fait qu’un certain chaos était au tournant. A vrai dire, il semblait extrêmement improbable que GDI, GDI+, DirectDraw et Direct3D puissent un jour bénéficier de l’accélération matérielle en simultané.
WDDM & DWM—Windows Display Driver Model et Desktop Windows Manager
En plus d’un nouveau modèle de pilote périphérique, le DWM était crée pour gérer les périphériques d’affichage. L’ensemble était faussement simple et rajoutait une couche logicielle entre les fenêtres et les commandes de dessin d’une part, mais aussi entre pilotes et composants d’autre part. Les communications directes étaient également interrompues à cause du DWM : en partant du principe « tout doit m’obéir », celui-ci coordonnait toutes les interfaces graphiques. Ce virage excluait de fait une fonctionnalité graphique pourtant majeure comme on l’a déjà vu : l’accélération matérielle des fonctions de dessin de la GDI. Complètement incompréhensible et pourtant véridique !
Le gros appétit de Vista en matière de mémoire a souvent été attribué de façon hâtive à Superfetch, alors que cet algorithme n’est qu’une partie du problème. L’omission de l’accélération matérielle 2D charge aussi le CPU de traiter les requêtes de la GDI pour rendre le contenu des fenêtres, lesquelles se retrouvent dans un super-tampon au sein du DWM. Le rendu complet des fenêtres est alors laissé au soin de la carte graphique. Un goulet d’étranglement considérable ne tarde pas à se constituer puisque seule une fenêtre à la fois est capable d’envoyer des commandes GDI au DWM. Les tâches asynchrones n’étant pas permises, il en résulte une file d’attente considérable de requêtes à traiter. En plus d’un temps d’exécution non négligeable, le processus consomme une quantité importante de mémoire vu que toutes les fenêtres actives résident dans le tampon mémoire DWM. Entre la multiplicité des fenêtres et leur poids de100 Mo chacune, on comprend pourquoi la consommation mémoire s’envole. Dans les cas les plus extrêmes, Vista se fige (lorsque l’on ouvre un grand nombre de fenêtres les unes après les autres par exemple). Au pire, rien ne fonctionne plus et il faut alors éteindre la machine pour en reprendre le contrôle.
En bref
- Vista inaugure l’accélération matérielle des calques 2,5D
- Lorsqu’Aero est activé, il n’est plus nécessaire de redessiner le contenu des fenêtres en permanence
- Microsoft a omis l’accélération matérielle pour les fonctions de dessin 2D de la GDI
- Le DWM ne peut pas travailler sur les fenêtres de façon asynchrone, ce qui est extrêmement nuisible aux performances graphiques
- La file de traitement pour les commandes GDI au sein de DWM est un gouffre à RAM
Windows 7 : retour du fils prodigue
Pour beaucoup, Vista tire sa mauvaise réputation de ses insatiables besoins en RAM. Reste qu’un second examen s’impose à la lumière de Windows 7. Il nous faut également observer que Seven est plus qu’un Vista redécoré et inclus ainsi de nombreuses fonctions que l’on peut attendre d’un système d’exploitation moderne. En parallèle aux changements fondamentaux, Windows 7 nous rend ce que Vista avait pris en matière de graphismes, à savoir l’accélération matérielle non restreinte de la 2D y compris les fonctions de dessin propres à GDI.
Grâce à WDDM 1.1, Windows 7 empêche aussi l’utilisation mémoire de doubler (les tampons propres aux fenêtres puis à nouveau chaque fenêtre active dans le DWM). Les besoins en ressources étant plus modestes, on arrive à des configurations moins lourdes. Cette consommation mémoire doublée explique pourquoi la mémoire système devenait si chargée sous Vista.
Pour suppléer GDI sous Windows 7, Direct2D a également été introduit : cette interface permet de convertir un affichage analogique vers Direct 3D pour exploiter l’accélération matérielle tout en gérant en parallèle des jeux de fonctions graphiques plus complexes. Direct 2D profite ainsi de la rapidité d’exécution de GDI et des capacités étendues d’une interface GDI+ mal née. Reste à voir si Direct2D gagnera un soutien massif de la part de développeurs.
Encore aujourd’hui, la grande majorité des programmes utilisent encore l’API GDI pour le rendu et la manipulation d’éléments graphiques 2D, ce qui n’empêche pas de se réjouir du fait que Windows 7 marque le retour de l’accélération matérielle que Vista avait supprimé pour ces commandes.
En bref :
- Transmission directe des commandes de dessin de GDI aux pilotes graphiques via DWM
- Traitement asynchrone et simultané des commandes GDI pour de multiples fenêtres
- Stratégies d’économies de mémoire pour le traitement des files de requêtes graphiques
- Nouveaux pilotes WDDM 1.1
Nécessités pour les fabricants de GPU
Le retour de l’accélération 2D matérielle a aussi pour effet de remettre les fabricants de GPU au cœur de la situation : les pilotes pour Windows 7 doivent être conçus de manière à pouvoir fournir une accélération matérielle pour les commandes GDI en 2D native tout en gérant les calques 2,5D des fenêtres individuelles.
Cette situation est critique pour certaines cartes, comme par exemple les Radeon HD 5000 qui souffrent de difficultés logicielles dans ces deux domaines distincts de l’accélération graphique. Voyons donc les problèmes en questions, comment nous avons mis le doigt dessus et ce que l’on peut en conclure.
L’accélération 2D fait défaut aux Radeon HD 5000 sous Windows 7
ATI a travaillé d’arrache pied pour développer sa dernière génération de cartes graphiques DirectX 11 ; il est tout à fait compréhensible que l’aspect logiciel nécessite du temps pour arriver à maturité (par ailleurs, le fait que les pilotes successifs améliorent les performances et la stabilité de bien des manières n’a rien d’un secret). NVIDIA est aussi concerné puisque l’on trouve un problème similaire avec les ForceWare lorsque l’on utilise des graphismes 2D sur les produits mobiles de la marque au caméléon. Les tests ont été effectués à partir des Catalyst 9.12.
1er problème : ATIKMDAG cesse de répondre avant de se rétablir
On est généralement confronté à ce message d’erreur suite à un retour au bureau après être sorti d’un programme 3D, et tout nous pousse à croire qu’il s’agit d’une erreur venant des pilotes.
Petit rappel : sans Aero, le DWM est désactivé et il n’y a plus d’accélération 2D (ceci s’applique à Windows 7 comme à Vista). Ayant été confrontés à ce problème de manière répétée sur deux configurations de tests avec plusieurs HD 5750 et HD 5870, nous avons fini par désactiver Aero. Le problème n’est alors plus apparu après cette manœuvre d’évasion. Chose intéressante, les mêmes maux (résolus avec la même méthode) sont apparus sur un notebook équipé d’une GeForce. Seul le temps nous dira s’il s’agissait d’une énorme coïncidence ou bien d’un conflit entre DWM, pilotes et accélération 2D matérielle.
Les autres suspects sont les fréquences de fonctionnement relativement basses des cartes ATI en 2D, ou peut-être un BIOS GPU encore trop immature. Le fait de déterminer si ces deux coupables potentiels sont liés ou bien s’ils agissent indépendamment nécessite une observation sur le long terme, ou bien un changement radical de comportement grâce à un nouveau pilote.
2ème problème : ATI n’est pas capable d’assurer une accélération matérielle à la GDI (ne serait-ce que partiellement)
Nous avons mis le doigt sur ce problème en faisant le constat des difficultés que la HD 5870 éprouve à rendre des graphismes 2D. Certes, on pourrait tirer de cette expérience que les cartes 3D sont faites pour jouer et non pas pour des applications 2D, mais en ayant lu les pages précédentes on ne peut qu’être convaincu de l’importance du sujet avec la sortie de Windows 7 (Vista n’est pas concerné). Pour être plus explicite, il faut voir que la plupart des cartes 3D s’en tirent assez bien en 2D actuellement. Mais si l’on met face à face une GTX 285 et une HD 5870, la GeForce devance la Radeon au niveau des capacités 2D. Même une solution graphique embarquée comme la GeForce 7050 (nForce 610i) fait mieux malgré son manque de frame buffer dédié.
La situation est encore plus intéressante lorsque DWM est désactivé : bien qu’aucune accélération 2D ne soit possible dans ce cas, la Radeon reprend les devants. Même CorelDraw et AutoCAD tournent bien plus vite avec une HD 5870 lorsque DWM est désactivé. Non seulement ceci est en contradiction avec la logique et l’expérience de test précédemment exposées, mais en plus on cherche maintenant à voir ce qui ne va pas du côté de NVIDIA.
Au vu de la situation, nous avons donc répété les tests sous PassMark.
Manque de chance, aucun des tests n’a permis de préciser les problèmes que nous venions de constater ni de nous donner la moindre piste relative aux performances disparates. Ceci nous a donc mené a créer notre propre benchmark.
Radeon HD 5870 contre GTX 285 sous Windows 7
Configuration de test | |
---|---|
Processeur | Intel Core 2 Quad Q6600, 2,4 GHz @ 3,2 GHz, stepping G0, 8 Mo de cache L2, LGA 775 |
DRAM | A-Data Vitesta Extreme : 4 Go de DDR2-1066 CAS 5 |
Carte mère | DFI Lanparty DK X48-T2RS |
Système d’exploitation | Windows 7 Ultimate 64 bits |
Cartes graphiques | Radeon HD 5870, GeForce GTX 285 |
Pilotes | Catalyst 9.12, ForceWare 195.62 |
Carte graphique | Fréquence GPU avec Aero/DWM | Fréquence GPU 2D |
---|---|---|
ATI Radeon HD 5870 | 850 MHz | 157 MHz |
NVIDIA GeForce GTX 285 | 648 MHz | 300 MHz |
En plus des cartes graphiques, les tests ont également été exécutés sur un vieux chipset nForce 610i avec GeForce 7050 intégrée comme base de comparaison. Toutes les mesures ont été faites avec le même processeur, les mêmes 4 Go de RAM et Windows 7 en version 64 bits. Enfin, nous avons également intégré la HD 4870 comme carte témoin aux tests de plateforme.
1er test : rendu des polices TrueType et OpenType
Pas d’écart phénoménal ici, même si l’on est curieux d’avoir le point de vue de NVIDIA quant au fait qu’un de ses IGP soit meilleur en rendu 2D qu’une GTX 285, quand bien même l’écart est faible. La HD 4870 se place en deuxième partie de tableau sans pour autant témoigner d’une réelle faiblesse.
2ème test : dessin de lignes
Surprise : la HD 5870 est incapable de fournir une accélération matérielle correcte pour le rendu des lignes.
Si les deux cartes les plus récentes fournissent des performances acceptables et relativement comparables lorsque le CPU prend le relais de l’accélération 2D désactivée, un gouffre se creuse lorsque l’on active Aero : la GTX 285 fait 11 fois mieux que la HD 5870. Pire encore, le circuit graphique intégré d’une carte mère à 40 euros qui affiche presque deux ans au compteur distance largement une carte graphique à 350 euros.
D’autre part, les relevés de la HD 4870 montrent un très faible écart entre Windows 7 avec Aero et Basic (sans accélération), ce qui suggère une absence d’accélération matérielle pour le dessin de lignes sous Seven. Cette carte est assez nettement derrière GTX 285 et GeForce 7050, mais tout de même devant la HD 5870 dans les deux cas de figure.
Tests 2D (suite)
3ème test : courbes de Bézier
On retrouve la même situation : la HD 5870 ferme la marche et renforce nos suspicions quand à son incapacité à correctement gérer les applications 2D, ce qui est inacceptable y compris pour les particuliers.
Une fois Aero et DWM activés, la GTX 285 affiche des performances 9 fois supérieures. Le circuit graphique intégré est à nouveau hors d’atteinte pour la HD 5870 et la comparaison avec la HD 4870 ne manque pas d’intérêt : quand bien même les résultats restent inférieurs à ceux des solutions NVIDIA, cette dernière est bel et bien capable d’accélérer le rendu des courbes au niveau matériel.
4ème test : rectangles
Etant donné que la HD 5870 souffre de problèmes avérés lorsqu’il s’agit de rendre des lignes (a fortiori lorsqu’elles sont épaisses), le test des rectangles a sans surprise confirmé les précédentes observations mais en partie seulement.
On voit que cette fois, l’activation de l’accélération permet à la HD 5870 de pratiquement doubler ses performances, ce qui ne l’empêche pas de rester en retrait de la GeForce 7050.
Ce test est le seul qui ait fait transparaitre une accélération matérielle du côté des cartes ATI, ce qu’il faut souligner. La HD 4870 s’en tire encore mieux que sa successeur dans les mêmes conditions et se retrouve ici bonne dernière une fois l’accélération désactivée.
5ème test : polygones
Cette fois, la victoire revient sans conteste au vieux circuit graphique intégré : le nForce 610i survole toutes les cartes graphiques avec une aisance étonnante, et ce alors que l’accélération soit activé ou pas. Il est par ailleurs intéressant d’observer que l’accélération des polygones ne marche pas du tout sur les deux cartes les plus puissantes en 3D.
Avec Aero, la GeForce 7050 fait environ 11 fois mieux que la HD 5870. La comparaison de cette dernière avec la HD 4870 est intéressante : les deux cartes sont très proches sans accélération, tandis qu’avec Aero, la HD 4870 fait plus que doubler le score de sa remplaçante.
6ème test : cercles, arcs et ellipses
Pas de bouleversement : l’accélération matérielle est quasi inexistante pour les deux cartes haut de gamme, tandis que le nForce 610i brille à nouveau. La HD 5870 ferme la marche et la HD 4870 vient s’intercaler au milieu.
Notes
Nous avons globalement observé les mêmes résultats avec la HD 5750, ce qui exclut tout défaut de fonctionnement spécifique à la HD 5870. La comparaison entre Catalyst 9.11 et 9.12 a permis de constater un gain de performances en faveur de la version la plus récente que l’accélération matérielle soit activée ou non. Reste la comparaison entre Windows 7 et Vista qui nous a réservé quelques surprises, mais nous y viendrons dans la seconde partie de ce dossier.
Conclusion de la première partie
L’analyse de la situation actuelle nous mène au constat suivant : les Radeon HD 5000 sont à la peine avec les graphismes en 2D. Il y a aussi quelque chose de perturbant à voir un vieux circuit graphique intégré plus performant dans certains domaines (face aux cartes ATI et NVIDIA). Il ne s’agit pas seulement d’une déficience mineure, mais aussi un constat que tous ceux qui travaillent avec des graphismes 2D peuvent faire au quotidien. Par ailleurs, on a du mal à concevoir qu’une HD 4870 puisse être aussi proche voir supérieure à une HD 5870 dans autant de tests.
Alors que l’accélération 2D (y compris les calques 2,5D) donne de bons résultats, ATI n’a pas encore réussi à implémenter quelques fonctions GDI pures dans les Radeon HD 5000. En tenant compte du nombre de pilotes successifs depuis le lancement de Windows 7, il est difficile d’accepter de tels problèmes en 2D quand on a dépensé plusieurs centaines d’euros dans une carte graphique dernier cri. Il faut souligner que ceci s’applique non seulement à notre benchmark synthétique, mais aussi à divers programmes bien connus comme AutoCAD, Corel Draw, Adobe Illustrator, Photoshop CS3/CS4, Microsoft Publisher, PowerPoint et plus encore. Le besoin de changements radicaux est aussi indéniable qu’urgent, d’autant plus que Vista permet d’arriver à de biens meilleurs scores que Windows 7 (on y viendra lors de la seconde partie).
Lors de la préparation de ce dossier puis au fil des tests, nous avons eu plusieurs échanges avec Antal Tungler (responsable technique Europe des relations presse chez AMD) au sujet des performances sous Windows 7 des Radeon HD 5000 en 2D. Après avoir pensé que le problème trouvait son origine au niveau de la GDI (que pratiquement n’importe quel programme doit gérer pour afficher des fenêtres sur le bureau), il nous a fallu revoir notre opinion vu qu’un circuit graphique intégré a montré sa capacité à gérer les graphismes 2D de manière bien plus efficace.
On ne peut que supposer (et espérer) que ce problème trouve sa source au niveau des Catalyst, même chose pour le remède potentiel. Si c’est bien le cas, ATI devrait alors être en mesure de remettre les choses en ordre assez facilement. Vu que les déclinaisons les plus accessibles des Radeon HD 5000 ont été lancées récemment, il est probable que toute la gamme soit atteinte par ces problèmes de performance en 2D. Ce qui nous a le plus dérouté au cours des tests est le fait que les rectangles bénéficient d’une vraie accélération matérielle alors qu’il n’en est rien pour les autres figures géométriques (lignes et courbes en particulier). D’un autre côté, un effondrement des performances lorsque l’accélération matérielle est activée n’indique rien de bon. On ne peut pas dire que la GTX 285 ait brillé lorsqu’il s’agissait de rendre ellipses et polygones, ce que nous avons également envie de comprendre.
Pour le moment, le mieux reste encore de désactiver Aero lorsque l’on travaille sur des programmes de dessin 2D avec une Radeon HD 5000. Certes, l’aspect visuel des fenêtres en prend un coup, mais les performances compenseront en allant jusqu’à tripler. La meilleure solution est donc de désactiver Aero uniquement pour les programmes concernés et non pas pour tous.
Désactiver Aero pour un programme spécifique
Un clic droit sur l’icône du programme, puis choisir « propriétés » en bas du menu déroulant. Une nouvelle fenêtre s’ouvre, cliquer ensuite sur l’onglet « compatibilité » puis cocher « désactiver les thèmes visuels ».
A venir
La deuxième partie nous donnera l’occasion d’approfondir avec un panel de cartes et circuits graphiques intégrés bien plus large. Dans l’intervalle, nous continuons à échanger avec ATI et NVIDIA par rapport aux résultats obtenus jusqu’ici.
Vu le terrain miné sur lequel on se trouve, autant utiliser ce benchmark sur Windows XP, Vista & Seven avec un plus grand nombre de solutions pour avoir une meilleure vue d’ensemble (ce qui passera aussi par de vieilles cartes graphiques S3 et Voodoo !).
On sait d’ores et déjà que l’on en tirera plusieurs éclaircissements mais aussi des déceptions. Cette seconde partie nous permettra aussi de décrire plus précisément les benchmarks, l’interprétation des résultats et surtout de rendre le benchmark accessible à tous en téléchargement. Vu la disparité des performances entre les différents Os et cartes graphiques, le fait que chacun puisse faire le point sur sa propre configuration nous semble particulièrement intéressant.
MAJ – AMD est revenu vers nous après avoir pris connaissance de ces résultats :
- Tom’s Hardware est tombé sur un domaine (lignes 2D etc.) que nous n’avons pas encore optimisé
- Jusqu’à ce benchmark, nous n’avions pas encore vu d’applications limitées par cette optimisation et n’avions donc pas concentré nos efforts sur cette situation
- Notre analyse préliminaire indique qu’il n’y a pas de limitations matérielles dans ce domaine
- L’équipe de développement logiciel travaille maintenant à optimiser cette approche pour aboutir à un nouveau pilote qui puisse résoudre le problème
- Nous avons déjà trouvé une méthode assez simple pour augmenter significativement les performances de nos cartes et essayons à présent de l’implémenter dans une prochaine version des Catalyst (il faut développer le code, le valider, s’assurer qu’il ne rentre pas en conflit avec quoi que ce soit etc.).