Comparatif : 7 Cartes 3D Pro PCI Express

Drivers

Les drivers des Quadro et des FireGL sont différents de ceux des GeForce et des Radeon bien que généralement basés sur des fichiers identiques. Une partie du code des drivers est réservé aux cartes professionnelles, bridant ainsi les cartes grand public. Il faut savoir que la majorité des applications de création 3D se contentent de surcharger la carte graphique au niveau géométrique, le filtrage des textures et les shaders passent au second plan et de loin, ce qui est complètement l’inverse dans le monde du jeu vidéo. Bien entendu ce n’est qu’une généralité, contredite par certains cas spécifiques, mais dans l’ensemble elle permet à ATI et NVIDIA d’optimiser leurs drivers pour ce cas de figure.

Une autre caractéristiques des applications professionnelles est leur manière de gérer l’affichage tridimensionnel qui diffère souvent fortement de celui des jeux vidéos. Le processeur y joue un rôle bien plus important et souvent le rendu n’est pas complètement pipeliné, c’est-à-dire que l’image 2 ne commence à être construite que quand l’image 1 est terminée. Ainsi, dans des scènes complexes, le processeur et la carte graphique restent souvent un facteur limitant, peu importe la puissance de l’autre. Réduire la charge processeur est donc très important, même dans les cas de figure qui poussent les GPU dans leurs limites. Si une partie de la charge CPU est fixée par l’application elle-même, une autre vient de l’API et du drivers. ATI et NVIDIA peuvent optimiser cette partie du traitement via leurs drivers ce qui augmente encore l’importance de ceux-ci et ce qui peut donner un très net avantage à l’un ou l’autre d’après le niveau d’efficacité du driver.

Tous deux proposent également des optimisations spécifiques à un grand nombre d’applications ainsi qu’un profil dédié qui se charge de paramétrer le driver correctement.

OpenGL

OpenGL est l’API 3D la plus courante, et de très loin, dans le monde professionnel. NVIDIA jouit d’un driver OpenGL dont la qualité a été maintes fois reconnue, contrairement à ATI qui tente depuis quelques années de redresser la barre à ce niveau. Heureusement pour ce dernier, la qualité de son driver a fortement progressé, mais NVIDIA reste la référence absolue à ce niveau. Il faut savoir qu’au départ, le driver OpenGL professionnel d’ATI était développé à part, en Allemagne, et a été fusionné au driver OpenGL grand public, lui-même en grand chantier, il y a quelques trimestres. Cette fusion a déplacé son développement en Californie, là où est développé le driver Direct3D, dont la qualité est, elle, clairement reconnue. Mais ce transfert, bien que Ben Bar-Haim, VP Software d’ATI, ait démenti ce fait, a causé de gros changements dans l’équipe de développement puisque seuls quelques-uns des développeurs de l’équipe FireGL ont rejoint la nouvelle équipe de développement. Il semble logique que la nouvelle équipe même assistée de quelques anciens de FireGL n’ait pas pu être complètement efficace dès le départ face au code de FireGL qu’ils ne connaissaient pas. Lors d’une visite du centre de développement Californien d’ATI, Joe Chien, qui dirige le développement des drivers, nous a indiqué qu’il avait bien l’intention d’élever la qualité du driver OpenGL au niveau de celle du driver Direct3D, que de nombreuses améliorations avaient déjà été apportées et que l’évolution serait continue au cours des prochains mois. Ce test sera l’occasion de voir où se situe le driver OpenGL ATI par rapport au driver NVIDIA.

Nous avons également vérifié l’état actuel du support du langage de programmation de shader du haut niveau en OpenGL, le GLSL. 3DLabs fournit un utilitaire qui vérifie le bon fonctionnement de chaque point mais vérifie également que les fonctions de GLSL ne puissent pas être utilisées d’une manière inattendue, par exemple en passant à une fonction un paramètre de type incorrect. Si ATI obtient un joli 98%, NVIDIA doit se contenter de 48%, la majorité des tests n’étant pas passés avec succès. Interpellé à ce sujet, NVIDIA nous a indiqué que le problème vient du fait que l’utilitaire de 3DLabs est trop strict. Pourtant, jusqu’à preuve du contraire il suit les spécifications définies par l’ARB OpenGL et il semble donc que ce soit plutôt le driver de NVIDIA qui soit laxiste et permette des choses qui ne correspondent pas aux spécifications. Qui plus est cette explication n’est valable que pour une partie des tests qui échouent. Qu’est-ce que cela implique ? Principalement que rien ne garanti que des shaders GLSL développés sur les drivers NVIDIA fonctionneront sur d’autres drivers qui supportent GLSL ce qui est pourtant l’intérêt d’un langage standardisé…

Quoi qu’il en soit, les quelques démos technologiques qui utilisent des shader écrits en GLSL tournent sans problème tant chez NVIDIA que chez ATI. Signalons toutefois que la majorité des démos de 3DLabs utilisent des shaders trop complexes pour les GPU actuels d’ATI et sont donc rendus en software.

Il est utile de rappeler que NVIDIA dispose de son langage de programmation de haut niveau propriétaire (mais qui permet malgré tout de compiler les shaders vers le modèle ASM standard d’OpenGL), Cg. Celui-ci est très bien intégré dans le milieu professionnel et utilisé dans de nombreuses applications, ce qui est un avantage stratégique pour NVIDIA.

Les plus des cartes pro

Outre les optimisations qui concernent les performances, les drivers proposent également des fonctions supplémentaires.

La plus importante concerne l’accélération en hardware de l’anti-aliasing des points et des lignes qui diffère légèrement de l’anti-aliasing utilisé dans les jeux et qui n’est pas activée sur les GeForce et Radeon qui devraient donc voir leurs performances chuter lorsque cette option est activée.

Un mode quad-buffered stereo qui permet comme c’est le cas sur un nombre réduit de cartes grand public, de donner une impression de profondeur à l’image. Pour cela il faut bien entend disposer soit de lunettes stereo soit d’un écran avancé. Le principe est d’afficher en alternance des images dont le point de vue est légèrement modifié de manière à simuler la vision de chaque œil. Les lunettes, par exemple, se chargent de masquer à l’œil gauche les images destinées à l’œil droit et vice versa. Comme son nom l’indique, ce mode utilise 4 buffers au lieu des 2 buffers habituels (back buffet et front buffer) et utilise ainsi plus de mémoire mais demande également plus de puissance puisque pour conserver un nombre d’images par seconde "vues" identique à celui de l’affichage standard, l’image doit être calculée deux fois plus de fois.

Autre grosse différence, la gestion des affichages d’application est plus avancée, tout d’abord au niveau de la mémoire mais aussi au niveau de la réduction de certains calculs inutiles. Par exemple il est possible de faire afficher un menu (via les overlay planes) sur un affichage 3D sans toucher au contenu de cet affichage 3D et ainsi sans devoir recalculer l’image une fois le menu disparu. D’autres fonctions semblables existent, mais tout ceci n’est utile que dans des cas bien spécifiques étant donné qu’en temps normal le recalcul de ce qui était masqué temporairement par le menu, voir de l’image entière ne pose pas de problème.