Il était une fois, une société de San Jose, en Californie, appelée 3dfx Interactive™ dominait le marché des cartes vidéo destinées au jeu. En octobre 1996, elle a mis sur le marché la Voodoo I, qui a connu un succès phénoménal. C'était la première carte proposant une accélération matérielle, mais elle n'effectuait que du rendu 3D ; il fallait une seconde carte vidéo 2D de haute qualité pour effectuer le rendu 2D (Matrox était immensément populaire à l'époque) alors que les informations 3D (voyez Glide2, à la Section 3.1, « Glide2 ») sont transmises à la Voodoo I et rendues, en utilisant le matériel rapide de la Voodoo pour effectuer les calculs graphiques nécessaires. La Voodoo Rush est sortie en avril 1996. Elle aurait dû être plus puissante, avec un GPU cadencé à 50 Mhz et 8 Mo de RAM. Mieux encore, elle constituait leur première carte combinée 2D/3D, libérant un port PCI précieux (la plupart des PC n'avaient que deux ports PCI à l'époque) mais la Rush n'a pas été aussi populaire. 3dfx a supprimé l'unité multi-textures de la Rush, qui a dès lors été surclassée par la Voodoo I. Pendant ce temps-là, ATI produisait sa série de Rage et nVidia celle de Riva 128, mais la Voodoo I dominait toujours largement.
C'était une belle époque pour Linux. id Software avait libéré le code source de Doom et porté Quake I sous Linux (décembre 1996). Nous goûtions pour la première fois au jeu commercial réel. Le choix était vite fait : vous achetiez une Voodoo. Et vous vous sentiez bien, car 3dfx avait ouvert ses pilotes. La reine des cartes vidéo fonctionnait grâce à des développeurs Linux. Non seulement nous disposions des meilleures cartes vidéo, mais de plus leurs pilotes étaient tous open source.
En mars 1998, 3dfx lançait la Voodoo II, avec sa bande passante mémoire de 3.6 Go/sec, 12 Mo de mémoire vidéo et un cœur fonctionnant à 90 MHz. Elle permettait des résolutions allant jusqu'à 1024x768. C'était 3dfx à son apogée. Comme la Voodoo I, la Voodoo II était une carte ne s'occupant que de la 3D, et se reposant sur une autre carte vidéo pour la 2D. La Voodoo Banshee est sortie en septembre 1998 comme une carte combinée 2D/3D, comme la Rush. Malgré un cœur plus rapide fonctionnant à 100 MHz, la Banshee était dépassée par la Voodoo II du fait de la suppression de l'unité multi-textures, comme pour la Rush. Et à nouveau, comme la Rush, elle n'était pas populaire. Mais 3dfx régnait en maître, et personne ne pouvait leur faire de l'ombre.
La Voodoo III est sortie en avril 1999. Il y en a eu plusieurs, au cœur variant de 143 à 183 MHz. Certaines versions disposaient d'une sortie TV. Il y avait des versions PCI et AGP (c'était la première carte vidéo AGP). C'était un autre succès, mais 3dfx commençait à perdre du terrain au profit de nVidia, qui produisait la TNT 2. Celle-ci surclassait la Voodoo II, et offrait une accélération 3D avec des couleurs 32 bits, alors que les Voodoo étaient limitées aux couleurs 16 bits. Mais la vie était toujours belle pour Linux. Nous disposions d'une carte qui était pratiquement au coude à coude avec nVidia, nos pilotes étaient open source et, en décembre 1999, id Software nous a fait un grand cadeau : ils ont ouvert le code source de Quake I.
Ensuite, la GeForce 256 de nVidia est apparue en octobre 1999. La Voodoo IV de 3dfx, son concurrent direct, avait à peu près une année de retard, ce qui est pour le moins ennuyeux quand on se bat sur un marché « de pointe ». Alors que les travaux en recherche et développement de nVidia étaient appliqués à ses cartes, 3dfx ne faisait qu'ajouter de la RAM plus rapide. Les Voodoo IV et V rendaient les couleurs 32 bits, prenaient très bien en charge l'anti-crénelage, proposaient un second GPU, plus de mémoire, et étaient pour ainsi dire supérieures aux autres cartes vidéo. Néanmoins, la sortie tardive des Voodoo IV et V couplée au fait qu'on pouvait obtenir la GeForce pour moitié moins explique le naufrage rapide de 3dfx. Pour Linux, les plus récentes Voodoo ne pouvaient accélérer que pour les couleurs 16 et 24 bits. Pire encore, le second GPU de la Voodoo V n'était pas exploité par le pilote Linux (et, à ce jour, la Voodoo V est fonctionnellement équivalente à la Voodoo IV sous Linux). La plupart des utilisateurs Windows sont passés à nVidia et, bien que les pilotes de cette dernière étaient propriétaires, même les utilisateurs Linux commençaient à la choisir. VA Linux, le plus grand vendeur des serveurs Linux, plaçait des nVidia dans ses machines.
Ensuite, en avril 2000, 3dfx a été attaqué sur un autre front : ATI commençait à produire sa première génération de Radeon. Auparavant, ATI avait toujours été un fabricant de puces graphiques innovant (leurs propres puces accélératrices 3D datent de 1996, à peu près au même moment que 3dfx), mais fort discret. Les Radeon étaient leur première carte accélératrice 3D à réellement intéresser les joueurs. Leurs Radeon écrasaient à la fois nVidia et 3dfx. Ils ont collaboré avec des développeurs Linux, ont ouvert le code source de tous leurs pilotes et ont été acclamés comme le grand espoir pour le jeu sous Linux. nVidia revint à la charge, et c'en était trop pour 3dfx. Entre la défaite dans les bancs d'essais contre la GeForce et la Radeon, leurs nouvelles cartes en retard et leurs prix élevés, 3dfx avait perdu sa part de marché et n'avait plus les fonds nécessaires pour continuer ses activités. Le 18 avril 2001, ils ont vendu la plupart des leurs avoirs et technologies à nVidia et, en octobre 2002, ont finalement fait aveu de faillite.
La disparition de 3dfx était très soudaine et une gifle pour la communauté open source. Je me souviens toujours de mon ami Gabe Rosa m'envoyant un courriel avec ces simples mots « Look at /. » (Va voir sur slashdot) et la vision de la nouvelle. C'était le 2e jour le plus sombre de l'histoire du jeu sous Linux (après la mort de Loki). Et c'était aussi vraiment dommage. 3dfx était sur le point de sortir une nouvelle Voodoo V avec 4 GPU qui aurait écrasé les offres de ATI et nVidia, ainsi qu'une nouvelle carte au nom de code « Rampage » qui les auraient ramené sur le devant de la scène. On raconte que la technologie de Rampage (qui a été vendue à nVidia) s'est retrouvée dans la GeForce 5900. Pas trop mal pour une technologie vieille de 3 ans !
Au début, tout était simple. Les joueurs Linux gardaient soit leurs Voodoo open source, acquéraient une Radeon open source ou une GeForce propriétaire. Néanmoins, les jeux grossissant et s'améliorant, ce n'était qu'une question de temps avant que les Voodoo ne soient plus viables pour les jeux modernes. Certains utilisaient toujours des Voodoo, mais ces personnes étaient pratiquement hors du coup en ce qui concerne le jeu.
ATI a produit un nombre incroyable de versions de chaque carte vidéo, et il devenait difficile de suivre l'évolution de leur terminologie. ATI et nVidia dominaient le marché. Leurs produits ont toujours été au coude à coude depuis lors, la GeForce prenant l'avantage un peu plus souvent que la Radeon. Mais les pilotes de la Radeon étaient open source, et de nombreux utilisateurs Linux lui restaient fidèles. Ensuite, cela s'est compliqué.
ATI a commencé à devenir de plus en plus réticent aux pilotes open source pour leurs nouvelles cartes et, soudainement, il n'était plus facile de savoir qui était le « bon ». L'excuse de nVidia était qu'une partie de leur code GL est sous licence d'une autre société, et ne peut par conséquent pas être « libérée ». Vraisemblablement, ATI ne veut pas collaborer afin de conserver ses secrets de fabrique. Et cela ne s'arrange pas. Les pilotes ATI Linux ont souffert de performances extrêmement faibles. Même quand une offre de ATI est meilleure que celle de la GeForce du moment pour Windows, la carte est toujours écrasée par la GeForce sous Linux. Du fait de pilotes ATI Linux calamiteux, les utilisateurs Linux ne peuvent se fier aux bancs d'essais ou aux tests de cartes prévus pour MS Windows. Ils ne sont tout simplement pas appropriés. Et c'est à peu près au point où nous en sommes pour le moment.
Finalement, le seul véritable banc d'essais des cartes vidéo sous Linux date malheureusement, à ma connaissance, de mars 2001, entre une Radeon 32 DDR et une GeForce 2. Vous pouvez le consulter vous-même sur http://www.linuxhardware.org/features/01/03/19/0357219.shtml, mais la conclusion est que la GeForce 2 domine de la tête et des épaules la Radeon 32 DDR.
La dernière offre de nVidia est la GeForce 5900, basée sur le jeu de composants NV35. Elle est bien prise en charge sous Linux par des pilotes de haute qualité mais propriétaires. Ils ne fournissent pas d'informations aux développeurs Linux, et vous ne pourrez donc utiliser que leurs pilotes binaires ; ils ne font pas partie de XFree86. nVidia utilise une architecture unifiée pratique : leurs pilotes prennent en charge de la TNT 2 à la GeForce 5900.
ATI a travaillé avec les développeurs Linux pour toutes les Radeon jusqu'à la Radeon 9200. Ces cartes font l'objet d'une prise en charge 2D et 3D dans XFree86. Je ne suis pas entièrement sûr de la qualité de ces pilotes open source ; néanmoins, Soldier of Fortune I™ et Heavy Metal™ ont toujours des problèmes de textures opaques avec la première génération de Radeon. Après la 9200, vous devez utiliser les pilotes binaires propriétaires, disponibles au format rpm, depuis le site web de ATI. Ces pilotes sont abominables : un de mes amis m'affirme que sa GeForce 4400 surclasse sa Radeon 9700 pro. C'est une honte !
Sur le papier, et selon les bancs d'essais pour Windows, la Radeon 9800 écrase la mal-conçue GeForce 5800 et dépasse légèrement la GeForce 5900. Sur le papier, elle est tout simplement la carte la plus impressionnante. Mais, à nouveau, le problème des pilotes ne nous permet pas d'en bénéficier. Si vous désirez acheter la meilleure carte pour Linux, vous devrez utiliser la GeForce 9800. Préparez-vous simplement à manger des nouilles pendant quelques mois : les deux cartes sont excessivement chères.
Au 30 juin 2002, la prise en charge par la SVGAlib des cartes Radeon est problématique. Les développeurs ont rapporté que SVGAlib fonctionne avec les Radeon 7500 et Radeon QD (modèle 64 Mo DDR) mais a quelques soucis avec la Radeon VE.
Je ne dispose pas d'informations concernant les cartes GeForce.
La réponse était très difficile l'an dernier, mais voici mon opinion :
Toutes les cartes GeForce requièrent un pilote propriétaire qui « salit » votre noyau. Néanmoins, c'est également la cas de toutes les cartes ATI suivant la Radeon 9200.
nVidia a prouvé qu'elle se souciait suffisamment de Linux pour écrire et actualiser des pilotes vidéo de haute qualité pour Linux. Même quand ATI a ouvert le code source de ses pilotes, ils se reposaient sur les développeurs Linux pour faire le sale boulot. Leurs pilotes propriétaires actuels sont ignobles.
La Radeon 9800 actuelle bat tout juste la GeForce 5900 dans les bancs d'essais et sur le plan des spécifications, mais les utilisateurs Linux ne pourront en bénéficier du fait de la faiblesse des pilotes de la 9800.
ATI a depuis longtemps l'habitude d'abandonner le support de son matériel dès que c'est possible.
Sous MS Windows, quand la GeForce bat son principal adversaire Radeon, les critiques affirment généralement que les graphismes de la Radeon étaient plus soignés. Je ne sais pas si cela se ressent également sous Linux.
En fin de compte, la plupart devrait acheter une GeForce pour le moment.
Parlons à présent de la terminologie des cartes vidéo et des graphiques 3D. Ce n'est pas primordial pour faire fonctionner un jeu en pratique, mais cela peut vous aider à décider quelles options matérielles et logicielles vous conviennent le mieux.
Une scène rendue est constituée à la base de polygones et de lignes. Une texture est une image 2D (habituellement une bitmap) recouvrant les polygones d'un monde 3D. Pensez à une couche de peinture sur les polygones.
Le T&L (transformation et éclairage) est le processus de traduction de toutes les informations du monde 3D (position, distance et sources de lumière) en une image 2D effectivement affichée à l'écran.
L'anti-aliasing (anti-crénelage) est le lissage de l'effet d'escalier d'une courbe ou d'un polygone, apparaissant lors du dessin d'une ligne brisée ou d'une courbe composée de pixels (de forme rectangulaire), aussi appelé « crénelage ». Il se produit quand les pixels forment une ligne crénelée plutôt qu'une courbe ou une ligne lisse. L'AA utilise un filtrage gourmand en temps CPU pour lisser de tels contours crénelés. Cela améliore l'aspect visuel d'un jeu, mais peut également grever dramatiquement les performances.
L'AA est utilisé dans différentes situations. Par exemple, quand vous grossissez une image, vous pouvez remarquer que des lignes qui étaient lissent deviennent crénelées (essayez avec The Gimp). Le rendu des polices de caractères est une autre grande application pour l'AA.
L'AA peut être fait soit par l'application elle-même (comme avec The Gimp ou le système de polices de XFree86), soit par le matériel, si votre carte le supporte. Puisque l'AA est gourmand en temps CPU, il vaut mieux l'effectuer en matériel, mais si nous parlons d'applications semi-statiques, comme The Gimp, cela ne pose pas vraiment de problème. Pour les situations dynamiques, comme les jeux, effectuer l'AA en matériel peut être crucial.
Le FSAA (anti-crénelage plein écran) implique habituellement le dessin d'une version grossie de l'écran entier dans un framebuffer séparé, en effectuant l'AA sur l'image entière puis en la ramenant à la résolution normale. Comme vous pouvez l'imaginer, c'est extrêmement gourmand en temps CPU. Vous ne verrez jamais de FSAA non accéléré matériellement.
Le « mip mapping » est une technique consistant à stocker diverses copies à l'échelle de la même texture dans la mémoire de la carte vidéo, afin de représenter la texture à différentes distances. Quand la texture est très éloignée, une plus petite version de la texture est utilisée. Quand la texture est proche, une plus grande est utilisée. Le mip mapping peut être utilisé quelle que soit la méthode de filtrage. Il réduit non seulement les besoins en bande passante mémoire (puisque les images sont stockées sur le matériel), mais offre également une meilleure qualité d'image.
Le filtrage de textures est la fonctionnalité fondamentale requise pour fournir des graphiques 3D agréables. Il a plusieurs applications, comme mélanger sans encombre des textures adjacentes, et rendre réaliste des textures vues depuis un angle (p.ex. regarder un panneau d'affichage depuis un angle extrême). Il existe plusieurs techniques de filtrage de textures incluant l'échantillonnage de points et les filtrages bilinéaire, trilinéaire et anisotrope.
Quand je parle de « dégradation de performances », gardez à l'esprit qu'elle dépend de la résolution utilisée. Par exemple, à une basse résolution, l'impact sur les performances de l'utilisation du filtrage trilinéaire au lieu du filtrage bilinéaire est négligeable. Mais à de hautes résolutions, il peut être énorme. De plus, je ne connais aucune carte qui utilise le filtrage de textures anisotrope. Les pilotes TNT le prétendent, mais j'ai lu que ces pilotes utilisent toujours le filtrage trilinéaire au moment du rendu réel d'une image à l'écran.
L'échantillonnage de points est rare de nos jours, mais si vous exécutez un jeu avec le « rendu logiciel » (ce que vous devrez faire si vous exécutez un jeu avec accélération 3D sans carte accélératrice 3D), vous constaterez probablement son utilisation.
Le filtrage bilinéaire est un filtrage de textures peu exigeant en temps de calcul mais de basse qualité. Il approxime les différences entre les textures en échantillonnant la couleur des quatre texels les plus proches (supérieur, inférieur, gauche et droit). Toutes les cartes vidéo accélératrices 3D modernes peuvent effectuer du filtrage bilinéaire en matériel sans chute des performances.
Le filtrage trilinéaire est un filtre bilinéaire de haute qualité qui utilise les quatre pixels les plus proches du deuxième niveau de mip map (mip map level) le plus approprié pour produire des transitions plus douces entre les niveaux. Le filtrage trilinéaire échantillonne à partir de huit pixels et les intègre avant de calculer le rendu. Le filtrage trilinéaire utilise toujours le mip mapping. Il élimine l'effet de bandes qui apparaît entre des niveaux adjacents. La plupart des cartes vidéo accélératrices 3D peuvent effectuer du filtrage trilinéaire en matériel sans impact sur les performances.
Le filtrage anisotrope est la meilleure mais la plus demandeuse en temps de calcul des trois méthodes habituelles de filtrage de textures. Le filtrage trilinéaire est capable de produire de beaux résultats, mais il ne fait qu'échantillonner à partir d'une zone carrée, ce qui n'est pas toujours la méthode idéale. Anisotrope (signifiant « depuis n'importe quelle direction ») échantillonne à partir de plus de 8 pixels. Le nombre de pixels utilisés et lesquels sont utilisés dépendent de l'angle de vision de la surface par rapport à votre écran. Il fait des merveilles lors de la visualisation de caractères alphanumériques depuis un certain angle.
Un Z-buffer est une partie de RAM qui représente la distance entre l'observateur (vous) et chaque pixel d'un objet. Beaucoup de cartes accélératrices 3D modernes disposent d'un z-buffer dans leur RAM vidéo, ce qui accélère considérablement les choses, mais il peut également être pris en charge par le moteur de rendu de l'application. Néanmoins, ce type de choses devrait clairement être fait en mémoire à chaque fois que c'est possible.
Chaque objet possède son ordre d'empilement, à la manière d'une pile de cartes. Quand des objets sont rendus dans un framebuffer 2D, le moteur de rendu supprime les surfaces cachées en utilisant le Z-buffer. Il y a deux façons de s'y prendre. Les moteurs stupides dessinent d'abord les objets éloignés puis seulement les objets proches, cachant les objets situés en dessous d'eux dans le Z-buffer. Les moteurs intelligents calculent quelles portions des objets seront cachées par les objets situés au-dessus et ne rendent tout simplement pas les portions que vous ne verriez de toute façon pas. Pour les textures compliquées, cela offre des grandes économies en temps processeur.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:17