|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Aux tous débuts, l'Amiga était une machine offrant une profusion de pixels et de couleurs, avec ses résolutions en 320x256 jusqu'à 640x512 plus le suraffichage (overscan), ses 32 couleurs pouvant par la magie Amiga devenir 64 voire 4096. Les manipulations de l'image au Blitter et au Copper permettaient de faire danser le tout sous les yeux ébahis des copains qui avaient eu le malheur d'avoir acheté un PC ou un Amstrad. Il faut voir qu'à l'époque, les PC étaient le plus souvent en mode texte, et les Mac hors de prix n'avaient que leur noir et blanc à offrir... Après une longue période où les autres machines évoluaient en grignotant l'écart tandis que les amigaïstes ne pouvaient guère que pester contre la lenteur des développements de chez monsieur Commodore, les constructeurs de matériel ont fini par prendre eux-mêmes les choses en main, chacun de son côté, et aujourd'hui les cartes graphiques fleurissent dans le désordre le plus complet. De principes, de performances, de résolutions, de prix très variables, leur comparaison est au premier abord difficile et il n'est guère aisé de faire un choix. Elles ne sont bien sûr pas compatibles, ce qui alourdit l'écriture des logiciels qui doivent les prendre en compte une à une, limitant ainsi le parc d'applications acceptant une carte donnée. Pour simplifier le tout, la machine se met à nouveau à évoluer et propose de nouveaux modes un peu plus fins, un peu plus colorés, et un peu plus rapides, eux-mêmes peut-être bien provisoires (ECS, AGA, AAA)... Mais il est de moins en moins possible d'en faire bénéficier les machines existantes. De plus, on entend vaguement parler d'un futur standard, le RTG, qui un jour devrait balayer ce problème d'incompatibilité entre les cartes, standard qui aurait plutôt du être imposé avant leur profusion... Difficile d'y voir clair C'est pourquoi nous allons aujourd'hui nous risquer à classifier et comparer les cartes, mais surtout à donner quelques critères et proposer quelques pistes de réflexion. Car il n'y a bien sûr pas de "meilleure carte", tout dépend des besoins. Ces propos ne sauraient avoir valeur de vérité absolue, dans la mesure où les différentes personnes qui ont nourri cette analyse ont chacune ses préférences... Ainsi, même si l'on parlera un peu de vidéo, l'optique générale concerne essentiellement les applications de type palette graphique. Disons que ces pistes et mises en garde pourront vous aiguiller dans les tests que vous ferez avant d'acheter. Commençons par quelques critères de choix La résolution Voilà un vrai critère, à condition d'avoir suffisamment de mémoire sur la carte pour y avoir réellement accès, et un moniteur capable de l'afficher... De plus, tracer beaucoup de points demande à priori plus de temps ou plus de puissance. Il vaut mieux également que le pixel soit à peu près carré, faute de quoi la finesse horizontale est gâchée par le crénelage vertical (ou l'inverse), et l'épaisseur des droites varie avec leur orientation (VD2001). Le ratio largeur/hauteur doit approcher celui des moniteurs, normalement de l'ordre de 1,3. Le nombre de couleurs 16 millions de couleurs, c'est le nirvana mais c'est peut-être aussi du luxe : 15 bits avec un tramage donnent presque le même rendu, voire 12 bits si l'on ne met pas le nez sur l'écran (au lieu de bandes d'iso-couleur bien marquées, cette opération donne alors un dégradé légèrement granuleux). Mais bien sûr, encore faut-il utiliser un logiciel disposant du tramage, ce qui ralentira un peu les traitements. Et à nouveau, 16 bits se transfèrent à priori plus vite que 32. La mémoire Il en faut suffisamment sur la carte pour bénéficier des résolutions promises. Mais plus, c'est rarement utile, sauf pour les cartes à processeur ou pour quelques applications très spécifiques. N'oublions pas également que le plus souvent les logiciels travaillent en mémoire centrale, puis transfèrent les modifications à la carte. Il faut donc également disposer de mémoire centrale et d'espace disque ! Une image 1024x768 en 32 bits prend 3 Mo... La vitesse Voilà un autre vrai critère ! Combien de temps faut-il pour afficher toute une image ? L'interactivité est-elle possible ? Le transfert est-il efficace ? Le test présenté plus bas donne deux mesures originales : sachant que la plupart des programmes actuels transfèrent les parties utiles de leur mémoire de travail vers la carte considérée comme une mémoire d'image, plutôt que d'utiliser d'éventuelles fonctions de tracé incorporées, c'est bien le transfert qui va conditionner les performances effectives. Ce transfert dépend d'une partie matérielle (vitesse de l'électronique de la carte, utilisation du port Zorro II (2 Mo/s) ou Zorro3 III (8 Mo/s), etc.) et une partie logicielle (efficacité des bibliothèques qui gèrent la carte). La rapidité dépend donc également de la machine : il vaut mieux avoir un processeur puissant et rapide, suffisamment de mémoire, et un port Zorro III (sur A3000 et A4000). Il est dommage que les cartes ne sachent pas prendre d'elles-mêmes leurs données en mémoire par DMA : il faut que le processeur de l'Amiga le fasse, et c'est moins rapide (ceci montre bien que la vitesse de transfert dépend aussi du processeur). Les tests Notre premier test évaluera donc le temps nécessaire au transfert de gros blocs (mesure du débit), tandis que le second s'intéressera aux petits (coût de traitement). Le premier critère rend compte des opérations de type fenêtrage, manipulation globale de l'image, voire animation, tandis que le second reflète la souplesse du tracé et de l'interactivité. Pour être efficace, une véritable carte graphique doit bien entendu permettre un accès au pixel près, et pas seulement le chargement de tout l'écran. Le logiciel intervient plus qu'on ne pourrait le croire : la VD2001 n'offre presque aucune gestion du matériel (juste lecture/écriture de pixel), l'A2410 de Commodore passe par un périphérique logique, bien plus lent qu'une bibliothèque, le prototype de la Vivid 24 n'atteint pas encore la vitesse offerte par le Zorro III (mais c'est provisoire)... À propos de taux, il faut prendre garde en considérant ceux des tampons mémoire d'image (AVideo, Impact Vision 24, OpalVision) dont on reparlera plus bas : il faut autant de temps pour modifier un pixel que toute l'image, et les temps de transfert maximum sont donc peu révélateurs de la souplesse d'utilisation. Les gadgets Deuxième page graphique, défilement matériel, genlock ou fonction de capture vidéo incorporés sont autant de fonctions sur lesquelles la publicité peut appuyer mais qui sont la plupart du temps de peu d'utilité pour un graphiste, sauf application spécifique (à la rigueur, le défilement est un plus en cas d'écran virtuel, plus grand que le moniteur). Rien n'interdit d'avoir une bonne carte, et un bon appareil de capture séparé ! Il faut bien se rendre compte en effet que l'opération de capture dure bien moins longtemps que le temps passé en retouche d'image, et qu'il ne faut donc pas négliger l'ergonomie de cette deuxième phase juste pour le plaisir d'économiser un port... La gestion d'Intuition est par contre bien agréable (tampons mémoire d'image, Domino, Retina, systèmes EGS), on traitera de cet aspect plus bas. Certaines cartes sont munies d'un pointeur matériel pour la souris, ce qui économise des transferts (faute de quoi le programme doit lui-même dessiner la souris et restaurer l'image masquée). Enfin, beaucoup de cartes se vendent maintenant accompagnées de logiciels, ce dont il faut tenir compte (s'ils sont valables et si vous en avez l'usage !). Codage des couleurs et performances Il y a plusieurs façons de coder les couleurs. La forme HLS, chrominance (couleur pure), luminance (intensité), saturation (opposé de la blancheur) ou l'une des nombreuses variantes serait sans doute plus adaptée au réel et plus compacte ; mais la forme RGB, rouge, vert, bleu (décomposition de l'intensité dans ces trois couleurs) est beaucoup plus simple à manipuler et à afficher. Le RGB est donc quasi universellement employé pour la mémoire écran des ordinateurs. Pour représenter ces informations, on dispose d'un certain nombre de bits, conditionnant le nombre de couleurs différentes affichables. Mais comme on l'a dit, les codages ne sont pas équivalents et il faut donc se méfier de ce nombre : d'une part l'oeil ne distingue pas 16 millions de couleurs, mais d'autre part paradoxalement, les 16 millions de couleurs qu'on nous propose de nos jours ne rendent pas compte de tout ce que l'oeil est susceptible de percevoir... Car, foin de binaire et d'arithmétique esthétique, l'oeil n'est pas du tout un capteur linéaire. Nous percevons le vert deux fois mieux que le rouge et six fois mieux que le bleu, nous distinguons mal les couleurs sombres ou blanchâtres. C'est donc du gaspillage que de répartir les bits à équité. Réciproquement, le blanc maximum en RGB est trois fois plus lumineux que peuvent l'être chacune des trois couleurs isolément, aussi faudrait-il théoriquement veiller à ce que la somme des composantes ne dépasse pas la valeur maximum pour une composante seule... Mais ces commentaires anecdotiques ont peu de conséquences puisqu'on n'a pas de prise sur ces paramètres, et ne servent qu'à relativiser les choses... Ensuite, on peut travailler en "vraies couleurs" (True Color), la valeur d'un pixel correspondant réellement à sa teinte, ou en "table de couleurs" (LUT, ColorMap), auquel cas on indique un numéro de couleur à chaque pixel, ce numéro étant défini dans une palette. Enfin, la mémoire écran peut regrouper les données par pixels (écran = suite de valeurs ou "chunks") ou par plans de bits (les bits composant un pixel sont répartis dans les différents plans). Le concept des plans de bits était très adapté il n'y a pas si longtemps : le coût en place et en temps limitant le nombre de couleurs, il n'y avait guère d'intérêt à imposer un ou des octets entiers pour décrire un seul pixel, alors que les plans de bits permettaient bien plus de souplesse : nombre de plans variable, défilement de certains plans, avant plan (pop-up)... Maintenant que la puissance augmente et que le prix de la mémoire diminue, il n'est plus choquant de vouloir consacrer 16 ou 32 bits par pixel. Cet alourdissement du pixel permet de lui consacrer une unité de mémoire entière (octet, mot ou mot long), alors qu'un nombre élevé de plans de bits rend les traitements plus coûteux : pour écrire un seul pixel, il faut décomposer la valeur en bits, puis insérer ces bits dans les mots correspondants de chaque plan de bits, et réciproquement pour le relire. Tracer une droite en 24 plans de bits revient à tracer 24 droites, plus le masquage et l'insertion de chaque point qui nécessitent plusieurs opérations logiques (puisqu'il faut modifier un seul bit à chaque emplacement mémoire)... Avec leurs processeurs bien plus rapides qu'autrefois, alors que le matériel de l'Amiga a peu évolué, les machines simplistes qui laissent au processeur le soin de s'occuper des dessins affichent aujourd'hui plus vite dans les conditions de tracé intense. Les cartes graphiques, ayant cette organisation en "chunk", elles gagnent automatiquement en vitesse (une Domino, qui est une simple carte VGA fichée sur une carte Amiga, permet de dessiner plusieurs dizaines de fois plus vite qu'en mémoire Chip). Mais sans doute les circuits de l'Amiga suivront-ils un jour cette voie. Classification des cartes graphiques Les tampons mémoire d'image ("buffers") Ils prolongent les circuits vidéo de l'Amiga en se branchant sur le bus vidéo. Les résolutions sont donc celles de l'Amiga, l'objectif étant d'ajouter plus de couleurs. Le principe consiste à utiliser les images 6 ou 8 plans de bits classiques de la machine, via un codage idoine des couleurs, pour transférer en plusieurs fois les 12 ou 24 bits dans la carte. L'Impact Vision 24 envoie successivement le rouge, le vert et le bleu, l'AVideo 24 envoie les poids forts (le plus lumineux) puis les poids faibles (les nuances), l'OpalVision entrelace... Dans un cas comme dans l'autre, il faut plusieurs trames pour obtenir une image achevée quelle que soit la taille de l'élément modifié, mais les deux dernières stratégies sont plus agréables visuellement dans la mesure où les images intermédiaires gardent un sens et semblent se raffiner progressivement. Le DCTV, un peu différent, utilise un codage exploitant les défauts du PAL pour gagner des couleurs. AVideo 24 Intéressantes au début car peu onéreuses, on leur préférera aujourd'hui les "véritables" cartes graphiques (voir ci-dessous) pour les applications de type palette et plus généralement celles qui s'appuient sur l'interactivité (on doit voir immédiatement les conséquences de chaque geste). Par contre, ces cartes sont aux normes vidéo, puisqu'elles se greffent sur les signaux de l'Amiga qui suivent déjà ces normes, ce qui les rend utiles pour cet usage. Nous reparlerons plus bas des considérations liées à la vidéo. Les cartes graphiques à processeur Les "véritables" cartes graphiques se distinguent selon la présence ou non d'intelligence sur la carte. Le processeur est le plus souvent un TI34010 ou 34020 de Texas Instruments (permettant respectivement 16 et 32 bits), ce dernier pouvant se faire assister d'un ou plusieurs coprocesseurs TI34082. Avec ses quatre coprocesseurs, la Vivid 24 dispose de 160 MFlops ! Encore faut-il pouvoir s'en servir... Ces processeurs relativement généraux (même le coprocesseur dispose d'une certaine indépendance) sont à peu près équivalents à un 68020 ou 68030 assisté d'un Blitter. Sous réserve que le fabricant de la carte les ait programmées, ils permettent d'implémenter directement les fonctions de tracé, comme le fait le Blitter de l'Amiga (droites, remplissage, copie et traitement de blocs) (TIGA), mais également de gérer le 3D (changement de repère, détourage, projection, facettes triangulaires ombrées, Gouraud, tampon de profondeur...) (Vivid 24, Rambrandt, à des degrés divers). Un certain nombre de fonctions sont fournies, mais on peut tout à fait programmer soi-même ce matériel selon les besoins. Ainsi, le protocole TIGA (SAGE pour la partie Amiga) est une bibliothèque graphique 2D standard pour TI340x0 que la machine hôte stocke dans la carte à son démarrage. SAGE/TIGA se retrouve sur toutes les cartes utilisant cette technologie (Rambrandt, Resolver, A2410, Vivid 24). Cependant, il n'existe actuellement aucune application faisant appel à ces possibilités (c'est dommage car un modeleur 3D en filaire voire en faces pleines pourrait manipuler les objets en temps réel, comme sur les stations. Mais c'est toujours pareil, les éditeurs ne s'occupent que des matériels répandus). A moins que l'on fasse sa propre application, le surcoût ne semble donc pas justifié, du moins pour l'instant. Les cartes et la vidéo Qui dit haute résolution dit adieu au standard vidéo, par définition. Les tampons mémoire d'image ont l'avantage d'être à ce format (on les appelle d'ailleurs parfois "cartes vidéo"), et de se superposer à la vidéo de l'Amiga (ceci permet par exemple de générer des animations Amiga classiques, apparaissant en avant-plan d'une image 12 ou 24 bits fixe). Ces cartes mettent donc à disposition une image vidéo directement utilisable en régie, et offrent parfois des fonctions de capture ou de genlock. Elles sont en outre suffisantes lorsqu'il s'agit de visualiser des images fixes (images numérisées, images de synthèse au format vidéo mais en 24 bits...). Certaines cartes à résolution programmables acceptent ce format vidéo (Harlequin), et les cartes Rambrandt et VD2001 offre quelques adaptations de ce type (capture temps réel). Mais il ne faut pas hésiter à séparer les rôles, et à prendre une bonne carte plus une bonne capture d'images, ou une "vraie" carte graphique plus un tampon mémoire d'image sur le bus vidéo de l'Amiga, plutôt qu'un mauvais mélange des deux... Au passage, la capture temps réel implique que l'on dispose d'une très bonne source. Pour des images fixes, un scanner donne souvent de meilleurs résultats si l'on ne peut consacrer qu'un petit budget. L'animation temps réel est utile pour certaines applications particulières. Mais on peut faire une sortie image par image... ou se limiter à sortir ses images sur support magnétique et à les monter sur bande vidéo en utilisant les services d'une régie professionnelle. Le DCTV offre des mécanismes de décompression en temps réel au prix d'une image moins nette en utilisation graphique. Une remarque en passant : les "vraies" cartes graphiques n'étant pas sur le port vidéo, rien n'interdit d'en installer plusieurs... Les cartes et Intuition Les tampons mémoire d'image se superposant aux signaux de l'Amiga, Intuition apparaît en avant-plan tout naturellement. En général, les autres cartes ne se soucient pas d'Intuition (auquel cas il vaut mieux consacrer un moniteur pour la carte et un moniteur "normal" pour le Workbench, ou à la rigueur utiliser un commutateur pour brancher alternativement le moniteur à la sortie de la carte ou à celle de l'Amiga). Quelques cartes émulent néanmoins Intuition à des degrés divers : en attendant que Commodore finalise le RTG (Retargetable Graphics) dans environ un an, qui permettra d'exécuter la plupart des opérations graphiques - donc Intuition aussi - sur n'importe quelle carte de façon transparente, le protocole EGS construit dans le même esprit par la société allemande Viona (et depuis racheté par GVP) est disponible depuis déjà quelque temps sur un certain nombre de cartes (Visiona, Rainbow 3, la future EGS de GVP). Comme c'est un standard, les logiciels n'ont en principe pas à se soucier de la marque de la carte à partir du moment où ils acceptent ce protocole. EGS s'offre même le luxe d'apporter quelques plus à Intuition (fenêtres se translatant en temps réel avec leur contenu, pouvant partiellement sortir de l'écran, souris changeant de moniteur en sortant du cadre de l'écran...), par contre il est hors de question d'abaisser un écran (ça c'était la magie du Copper), et il n'y a que du simple rafraîchissement dans les fenêtres (quand une fenêtre réapparait, le programme propriétaire doit la redessiner lui-même). "L'émulation" est donc plus ou moins fidèle. La Retina émule elle aussi Intuition, mais comme toute émulation elle a ses limites (un programme comme Deluxe Paint qui modifie directement la mémoire écran sans passer par des instructions de la graphics.library peut difficilement voir son affichage redirigé de façon transparente !). La Domino est une carie un peu à part, sur laquelle on peut travailler sous Intuition sans trop de problèmes : comme elle est capable d'alterner entre son affichage et celui de l'Amiga, elle est accompagnée d'un fichier "liste de montage" modifiable qui permet de choisir le mode dans lequel chaque application va tourner. Conséquemment, à moins d'utiliser un tampon mémoire d'image ou une Domino, il est quasiment indispensable de se munir de deux moniteurs, pour la carte et le Workbench, ou d'un boîtier commutateur... (Cf. le chapitre sur les moniteurs). Tant qu'on en est à l'ouverture, signalons que peu de cartes sont utilisables sous Unix. Les cartes A2410 et Resolver disposent des pilotes adéquats, la première pouvant difficilement servir à autre chose étant donné la lenteur de son périphérique logique côté Amiga. Les moniteurs Disposer d'une forte résolution c'est bien, pouvoir l'afficher c'est encore mieux ! Il y a là aussi quelques pièges : les moniteurs se caractérisent surtout par leur bande passante. On peut jouer sur quatre paramètres :
Les formats PAL et SVGA contraignent la fréquence ligne (à respectivement 15,5 et 31,5 kHz, 15,5 k = la moitié de 625 lignes tous les 50e de seconde), les multisynchros courants ont une plage qui va généralement de 24 à 60 kHz. Pour une résolution horizontale donnée, les cartes peuvent ensuite atteindre une résolution verticale sans dépasser la plage des moniteurs courants en jouant sur la fréquence trame (40 à 75 Hz) et le piqué du pixel. La Retina parviendrait ainsi à obtenir 1152x852 sur un moniteur SVGA. La plupart des moniteurs SVGA (ils doivent se synchroniser, et descendre jusqu'à 29 kHz), bon marché (environ 2000 FF), sont donc utilisables sur la plupart des cartes, ainsi que sur un désentrelaceur (ou en Euro72, ou en DoublePAL). Mais on obtiendra rarement des performances extraordinaires (très haute résolution et piqué simultanément). Les moniteurs qui montent à 1280x1024 sont chers, et la plupart des multisynchros ne gèrent pas les modes de base (format PAL). De plus, certains multisynchros sont en fait des tri ou quadrisynchrones, qui n'acceptent pas n'importe quel format d'image). Les cartes graphiques ayant leur propre sortie, il faut en principe deux moniteurs quand Intuition n'est pas émulé. Mais si l'on ne passe pas sans arrêt de l'un à l'autre, on peut se munir d'un commutateur permettant de basculer l'affichage entre la carte et l'Amiga. Hélas, cela s'accompagne souvent d'une perte de signal (contraste affaibli). Si l'on compte utiliser un seul moniteur, le format PAL doit être reconnu (pour les applications "de base", notamment les jeux !), à moins que l'on ne travaille qu'avec Intuition désentrelacé (29 kHz, soit pratiquement SVGA). Et là le bât blesse car il n'y a pas beaucoup de choix. Le moniteur 1960 de Commodore constitue un bon compromis, dans la mesure où il est bon marché (environ 3500 FF) et affiche du format PAL (740x576) au 1024x768 (entrelacé). Hélas, à l'heure où nous écrivons ces lignes, Commodore International est en rupture de stock depuis plus d'un mois... Les nouveaux Nec ne gèrent plus ce format, et en matière de moniteur il est risqué d'acheter d'occasion (ils vieillissent mal et leurs qualités se dégradent). Il y aurait bien également certains "super" moniteurs, comme l'Eizo 1235, mais ils coûtent pratiquement le même prix que l'A4000... Quant aux applications vidéo sur tampon mémoire d'image, elles utiliseront bien sûr les habituels écrans 1084 ou dérivés, et ne sont donc pas concernées par ces tracas... Tableau comparatif Ce tableau n'est pas exhaustif, et ne retient qu'une famille de critères généraux, l'application visée étant de type palette graphique. Les atouts correspondant à des usages spécifiques n'y sont donc pas mentionnés. Rappelons que le test 1 mesure la vitesse de transfert de petits blocs, et le test 2 celle des gros blocs. On fait les mesures avec la palette graphique TVPaint, qui est assez typique de ce qu'on peut demander à une carte de gérer. Le premier test consiste en un programme ARexx qui évalue le temps nécessaire pour tracer 10 cercles d'épaisseur 10 et de rayon 200. Le second charge toute l'image plusieurs fois et en déduit le taux de transfert en milliers de pixels par seconde. En un mot, le premier chiffre doit être petit et le second important... On essaie de viser une qualité d'image constante, le tramage est donc utilisé pour les cartes à moins de 24 bits. Toutes les cartes ont bien sûr été testées dans le même Amiga 3000, 68030 à 25 MHz, muni de 14 Mo de mémoire.
Remarques La lecture de l'article aura fait comprendre à quel point toutes ces valeurs sont subjectives (résolution maximale réellement utilisable, etc.). Ce tableau sert donc essentiellement à fixer les idées en donnant quelques ordres de grandeur.
En guise de résumé
|