* * * Forum OXMO Message * * * -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Titre : [ARTICLE] Architecture et fonctionnement d'un GPU Lancé le 11-05-2005 19:01 par kyro Téléchargé de https://www.forum.oxmo.org/showthread.php?threadid=34168 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- [Post 1] Auteur : kyro Date : 11-05-2005 19:01 Titre : [ARTICLE] Architecture et fonctionnement d'un GPU [B]Architecture et fonctionnement d'un GPU - 1° partie (par Ashe - 11/05/2005)[/B] [SIZE=3][COLOR=orangered][B]Introduction[/B][/COLOR][/SIZE] ImageDe nos jours, n'importe quel ordinateur disponible sur le marché dispose d'une carte graphique capable d'accélérer l'affichage 3D. Ces cartes qui il n'y a pas si longtemps que ça ne pouvaient effectuer que des opérations assez basiques, ont très vite évolué vers des systèmes de plus en plus complexes, de plus en plus puissants, et de plus en plus performants. Ces évolutions ont été accompagnées de nombreux termes techniques, ainsi que d'aussi nombreux (voire plus) termes marketing. Entre les Hyper Machins, les Ultra Choses et les Extreme Trucs, difficile de s'y retrouver. Le but de cet article est donc d'éclaircir un peu les esprits, en expliquant pas à pas l'architecture des cartes graphiques, ainsi que leur fonctionnement. Par souci de clarté, ce dossier sera scindé en deux parties, la seconde partie devant être publiée peu après cette première partie. Il est évident que l'architecture de chaque carte est très complexe, et cela prendrait des mois à expliquer tout dans le moindre détail. Cet article se limitera donc à une vue d'ensemble de chaque élément majeur de l'architecture d'un GPU. Cette architecture sera celle d'un GPU générique et non celle d'un GPU en particulier, bien entendu. Mais d'abord, qu'est-ce qu'un GPU ? En fait, il s'agit tout simplement du processeur de la carte graphique. L'acronyme GPU signifie en effet Graphics Processing Unit (unité de traitement graphique). Signalons d'emblée que nous ne nous occuperons pas de la mémoire ou des autres composants. Il faut dire que le GPU est l'élément principal d'une carte graphique, et de loin le plus complexe. Ces processeurs ont vu leur complexité augmenter exponentiellement, au point de rapidement rattraper les processeurs de nos ordinateurs. Les GPUs sont d'ailleurs nettement plus performants que les CPUs lorsqu'il s'agit d'affichage et de rendu 3D, malgré la grande différence au niveau des fréquences de fonctionnement. C'est dû au fait qu'un CPU est prévu pour effectuer toutes sortes de tâches très différentes, alors qu'un GPU est un processeur optimisé pour la 3D. Au fil des pages, vous pourrez comprendre pourquoi ils sont devenus tellement performants, ce qui peut limiter leur performance, où encore ce qu'ils sont capables de faire. Une fois toutes ces informations en votre possession, vous comprendrez non seulement ce qui se passe dans votre ordinateur, mais vous serez également plus à même de choisir votre prochaine carte graphique de façon judicieuse. [B]Vue d'ensemble[/B] Mais commençons par le commencement : un GPU est constitué de nombreux composants, les deux plus importants étant le vertex pipeline et le pixel pipeline. Le premier s'occupe des vertices (pluriel de vertex), alors que le second s'occupe des pixels. D'une façon plus générale, la gestion des vertices, des primitives, la tessellation, le vertex pipeline, le clipping, le culling et le tramage font partie du traitement de la géométrie. Le pixel pipeline, le test de profondeur, le test alpha, le test brouillon, le brouillard et l'alpha blending, quant à eux, font partie du rendu. Chaque composant traite l'information reçue, la modifie si nécessaire, et passe les informations au composant suivant. Cet article est conçu de manière à suivre le flux des informations au sein du GPU. Ainsi, chaque tête de chapitre correspondra à un élément, en suivant les flêches du schéma ci-dessous.
[SIZE=3][COLOR=orangered][B]Données vertices[/B][/COLOR][/SIZE] Les vertices sont à la base de tout affichage. Ils permettent en effet de créer des formes géométriques. Un vertex contient ainsi un certain nombre d'informations, nombre qui peut varier selon l'utilisation qui sera faite du vertex. Les seules informations requises sont les coordonnées du vertex. Ces coordonnées se présentent sous la forme d'un simple vecteur à deux, trois ou quatre composantes : * X, la gauche et la droite * Y, le haut et le bas * Z, la profondeur * W, la coordonnée homogène Les trois premières se passent probablement de commentaires, il s'agit simplement de la position du vertex, en trois dimensions. La quatrième, par contre, est généralement moins connue. Elle agit comme simple modificateur sur X, Y et Z. Ainsi, les coordonnées finales sont X' = X / W, Y' = Y / W, Z' = Z / W. Par défaut, la coordonnée homogène vaut 1, ce qui n'affecte donc pas les coordonnées. Chaque vertex peut également posséder de nombreuses autres informations. Depuis l'avènement des GPUs programmables (vertex shaders), il est même possible d'ajouter au vertex des informations qui n'ont aucune signification particulière pour la carte graphique. Voici cependant une courte description des informations les plus courantes : [B]Couleur diffuse et spéculaire[/B] Ces informations sont quasiment toujours présentes, et définissent la couleur d'un vertex. En imaginant qu'un vertex fait partie du modèle d'un vase, la couleur diffuse est la couleur qu'aura le vase là où se trouve le vertex lorsque celui-ci est éclairé avec de la lumière parfaitement blanche. La couleur spéculaire, quant à elle, est la couleur réfléchie par le vase où se trouve le vertex lorsque la lumière entre en contact avec celui-ci. Les deux types de couleurs sont définis par trois ou quatre composantes : * rouge * vert * bleu * alpha (utilisé notamment pour la transparence) [B]Normale[/B] Image La normale est également quasiment toujours présente. Elle est en effet très importante, mais surtout très utile. En imaginant que trois vertices forment une surface plane (un triangle), la normale est le vecteur perpendiculaire à cette surface. La normale est ainsi utilisée à de nombreuses reprises lors de calculs permettant de calculer les éclairages, entre autres. Le calcul d'une normale est assez simple, puisqu'il s'agit d'un produit vectoriel (en anglais cross product) : la multiplication entre eux de tous les composants de deux vecteurs définissant le plan auquel la normale doit être perpendiculaire. Les vertex shaders disposent d'une instruction capable de faire un produit vectoriel. [B]Coordonnées de textures[/B] Les coordonnées de textures permettent de positionner une texture sur une primitive. Ainsi, pour afficher une image simple, il suffit d'avoir quatre vertices formant un carré. Le vertex se trouvant en bas à gauche possèdera les coordonnées correspondant au côté gauche en bas de la texture. Ce système permet de nombreuses astuces lorsqu'une texture est appliquée à un objet. Ces coordonnées sont donc deux (ou trois dans le cas des textures 3D) composantes : U et V. Sur l'axe des abscisses (horizontal), 0 se trouve a gauche, 0.5 au milieu, et 1.0 à droite. En effet, les valeurs sont normalisées, excepté dans certains cas particuliers. A noter qu'il est courant qu'un vertex possède plus d'un jeu de coordonnées de textures. Ainsi, lors de l'application de plusieurs textures, chaque jeu de coordonnées sera utilisé pour la texture y correspondant. [B]Taille du point[/B] Déjà plus rare, cette information est utilisée dans les systèmes de particules. Elle permet de donner une taille à un point, ce qui améliore grandement les performances puisqu'au lieu d'afficher un carré ou cercle (et donc de passer de nombreuses vertices), il est possible d'envoyer à la carte un seul vertex et la taille du point voulu. [B]Poids du vertex[/B] Il s'agit de la dernière, mais surtout de la plus complexe des informations. Tout comme les coordonnées de textures, il peut y en avoir plusieurs. Il s'agit de matrices définissant le poids d'un vertex. Cependant, aucun rapport avec le chiffre indiqué par la balance, il s'agit ici d'une valeur prise en compte lors de l'affichage des vertices afin d'effectuer du vertex blending. Pour faire simple (il y aurait de quoi remplir 80 pages) le vertex blending permet d'obtenir un mouvement fluide des vertices lors de l'animation de modèles, ainsi que d'éviter que des "trous" apparaissent aux jointures. [B]Impact sur les performances[/B] Toutes ces informations ont une certaine taille en mémoire. Ainsi, les coordonnées font généralement 16 octets, la couleur 4 octets, la normale 12 octets, etc. Rien qu'avec ces trois informations, assez basiques, on arrive à 32 octets. La carte graphique dispose d'une sorte de cache, où vont les vertices. Ce cache a une certaine taille, et l'utilisation d'un vertex faisant exactement sa taille est l'idéal. Bien sûr, il est impossible de le connaître, et quand bien même ce serait possible, il serait inconcevable d'adapter le rendu afin d'utiliser moins d'informations. De nos jours, les cartes peuvent sans problème gérer des vertices de 64, 128 voire même 256 octets. Ce ne fut pas toujours le cas, et le dépassement de cette taille "idéale" pour la carte graphique réduisait grandement les performances. [SIZE=3][COLOR=orangered][B]Données primitives[/B][/COLOR][/SIZE] Une primitive est une forme géométrique simple, allant du point au polygone. Le type de primitive le plus utilisé est le triangle ainsi que ses dérivés : le triangle fan et - surtout - le triangle strip. Les vertices permettent de former ces formes géométriques. Ainsi, dans le cas d'une primitive de type point, un seul vertex correspondra à une seule primitive. Dans le cas d'un triangle, il en faudra trois pour former la primitive. Il existe quelques types de primitives et les plus utilisées sont : * point * ligne * triangle * triangle fan * triangle strip [B]Les points[/B] Pendant longtemps, les points étaient une primitive quasiment inutilisée, excepté dans les logiciels de conception assistée par ordinateur. Dans les jeux, cependant, des billboards étaient généralement utilisés à leur place pour créer des effets de particule. Un billboard est un simple carré qui a la particularité d'être aligné par rapport à la caméra de façon à toujours lui faire face. [B]Les point sprites[/B] Mais depuis maintenant quelques générations de GPU, il existe des primitives nommées point sprites. Celles-ci fonctionnent exactement comme les points, sauf que le GPU va créer lui-même le billboard. Ainsi, au lieu de fournir 4 vertices à la carte pour un carré, un seul sera fourni pour chaque point, ce qui améliore grandement les performances et permet ainsi d'afficher plus de particules. [B]Les lignes[/B] Les lignes sont utilisées en tant que telles. Il s'agit en fait d'une primitive assez simple, qui nécessite deux vertices. Elle possèdera cependant les mêmes propriétés qu'un triangle : une texture, une couleur, etc. A noter que pour afficher en mode "fil de fer", il ne faut pas modifier tout le système d'affichage pour utiliser des lignes : la carte graphique est capable de créer les lignes a partir de toutes les autres primitives. [B]Le triangle strip[/B] Les triangle strips sont généralement utilisés à la place des triangles, puisque les performances sont meilleures lors de leur utilisation. En effet, pour un triangle, il faut trois vertices. Pour deux triangles, six vertices, etc. Le nombre de vertices est donc égal au nombre de primitives multiplié par trois. Les triangle strips, quant à eux, utilisent les trois premiers vertices pour le premier triangle, et ensuite un seul vertex supplémentaire pour les triangles suivants. A chaque fois, les trois derniers vertices sont utilisés pour définir le triangle. Le nombre de vertices est donc égal au nombre de primitives + deux. L'avantage est donc très net : pour 150 000 triangles, en utilisant des primitives de type triangle, il faudrait 450 000 vertices. En utilisant un triangle strip, il n'en faudrait que 150 002. Un tiers de données à transférer, plutôt pas mal comme optimisation. [B]Le triangle fan[/B] Le second type de primitive dérivé du triangle, le triangle fan, est proche du triangle strip. Au lieu d'utiliser les trois derniers vertices pour créer chaque primitive, ce sont les deux derniers vertices ainsi que le premier qui sont utilisés. Moins souvent utilisés que les triangle strips, les triangles fans permettent néanmoins de facilement créer des cercles, halos de lumière, etc. Au niveau des performances, ils sont similaires aux triangle strips. [B]Les tampons d'indexation[/B] Une dernière technique très utile afin de diminuer la quantité de données à envoyer à la carte graphique est l'utilisation d'un index. Ainsi, dans une forme complexe (le modèle du héros d'un jeu, par exemple), il arrive souvent qu'un même point soit utilisé par plusieurs primitives, et le vertex s'en retrouve ainsi dupliqué. L'utilisation des index permet de se passer de ces copies en disant à la carte graphique quel vertex utiliser via un numéro, en quelque sorte. L'avantage étant que là où un vertex fait très vite 32 voire 64 octets, un index ne fait que 2 ou 4 octets. [SIZE=3][COLOR=orangered][B]La Tessellation[/B][/COLOR][/SIZE] La tessellation est une technologie plutôt récente sur les cartes graphiques. L'idée de base est assez simple : générer des vertices afin d'augmenter leur nombre et ainsi augmenter la finesse de la surface dont ils font partie. Pour ce faire, la partie du GPU qui s'occupe de la tessellation (le tessellateur) n'a besoin que de deux informations : la position du vertex, et la normale. Si vous avez bien compris la page sur les vertices, vous savez qu'une normale représente simplement un vecteur perpendiculaire au vertex. Le tessellateur va interpoler la position et la normale afin de générer de nouvelles vertices entre deux vertices existantes. Il existe plusieurs algorithmes de tessellation, qui vont définir où et quand il faut augmenter le nombre de vertices. Le plus simple est évidemment un tessellateur qui augmente le nombre de vertices jusqu'à arriver à une certaine résolution, mais ce n'est pas très utile : les objets distants seraient très détaillés mais les détails ne seraient pas visibles. Bref, du gâchis. Une méthode plus adéquate consiste à faire varier le nombre de vertices afin que les objets proches en possèdent beaucoup et que les objets distants en possèdent peu. L'idéal serait augmenter le nombre de vertices afin que chaque vertex corresponde à un pixel à l'écran, mais cela demanderait enormément de ressources. Sur l'image ci-dessous, on peut voir l'effet des triangles PN (Point-Normal). Ces derniers ont été initialement présentés par ATI et sont également appelés N-Patches (Normal Patches). NVIDIA a préféré l'utilisation de primitives appelées les RT-Patches (Real-Time Patches). Cependant, bien que DirectX supporte toujours ces deux types de primitives, ils ont tous les deux plus ou moins abandonné le support de la tessellation, même sur leurs cartes les plus récentes.
[I]Les triangles PN (ou N-Patches) d'ATI[/I]
Le chiffre en haut de chaque triangle représente le niveau de détail. Le niveau 0 est le niveau de "base", c'est à dire qu'il n'y a aucune tessellation. Ensuite, pour chaque niveau, le tessellateur interpole les vertices et augmente ainsi le nombre de triangles. Dans le cas d'une surface plane comme sur l'illustration, la différence entre le niveau 0 et le niveau 5 ne sera pas visible, puisque la surface sera toujours plane. Si la surface est courbe, cependant, la différence sera très visible, comme vous pouvez le voir sur l'illustration suivante. [B]La tessellation d'un modèle plus complexe[/B] Il s'agit cette fois-ci d'une mesh (en français maille), un ensemble de primitives. En plus d'interpoler les coordonnées, le tessellateur a également interpolé les normales qui, souvenez-vous, font partie de l'équation qui calcule la lumière. C'est pourquoi l'éclairage de la surface s'adapte correctement au fur et à mesure que le nombre de triangles augmente.
[I]La tessellation d'un modèle plus complexe[/I]
Bien que la tessellation ait été introduite il y a déjà quelques temps, elle est toujours très peu utilisée. D'abord, les constructeurs semblent avoir abandonné leur support. Ensuite, seul DirectX supporte la tessellation - ou de façon plus générale les surfaces de haut niveau - depuis sa version 8, alors qu'OpenGL ne possède toujours pas de support standardisé pour ces fonctionnalités. ATI et NVIDIA avaient à une époque introduit des extensions propriétaires afin d'utiliser ces possibilités, mais les pilotes actuels ne possèdent plus les extensions en question. Matrox avait également annoncé une carte exploitant la tessellation (la Parhelia), mais a fini par retirer ces informations de son site et désactiver le support de la tessellation dans le pilote. [SIZE=3][COLOR=orangered][B]Le Vertex Pipeline[/B][/COLOR][/SIZE] L'un des éléments les plus importants d'un GPU est probablement le vertex pipeline. Ce pipeline reçoit simplement les données d'un vertex pour les traiter. Il existe deux types de pipelines : les fixes et les programmables. Un pipeline fixe est ce qui existe sur les cartes graphiques depuis bien longtemps, et a pour principal but d'effectuer des transformations. Ces transformations permettent d'effectuer des translations (déplacer), des rotations (tourner) et des changements d'échelle (redimensionner) sur les coordonnées des vertices. Ainsi, en imaginant qu'un jeu vidéo charge les données d'un objet (par exemple, le kit de survie de Quake), il obtiendra une série de coordonnées qui correspondront chacunes à un vertex. Si l'objet était déplacé ou si il devait tourner (ce qui est fréquent pour les objets dans un jeu comme Quake), toutes les coordonnées devraient être modifiées, ce qui prendrait du temps. A la place, une matrice 4x4 (pour ceux qui n'aiment pas les maths, ce n'est pas une voiture) est générée. Cette dernière comprendra les données de la translation et de la rotation. Des matrices sont utilisées à cause de leurs propriétés. En effet, si une matrice représente une translation et qu'une autre représente une rotation, en les multipliant on obtient une matrice qui représente la translation ET la rotation. Le pipeline va donc pouvoir transformer les coordonnées du vertex en utilisant cette matrice. D'autres types de traitement sont effectués par le vertex pipeline, notamment au niveau de l'éclairage, mais ceci sera expliqué au prochain chapitre. [SIZE=3][COLOR=orangered][B]Le Vertex Pipeline - version fixe[/B][/COLOR][/SIZE] Le pipeline fixe est en quelque sorte un vertex shader préprogrammé dans la carte graphique. Selon les données disponibles dans le vertex qu'il reçoit en entrée et les paramètres de la carte graphique, il fera différentes choses. Evidemment, cela limite grandement les possibilités par rapport à un vertex shader. Les données du vertex sont également peu flexibles. Ainsi, les couleurs seront obligatoirement au format RGBA (rouge, vert, bleu et alpha), les coordonnées du vertex doivent contenir quatre composantes (X, Y, Z et W), etc. Si les données nécessaires au rendu entrent dans cette norme, et que l'algorithme de rendu est conforme à ce qu'il peut effectuer, le pipeline fixe a de grandes chances d'être plus performant qu'un vertex shader réalisant les mêmes opérations. Il est en effet très probable qu'un circuit dédié soit présent dans le GPU et qu'il sera utilisé par le pipeline fixe, alors qu'un vertex shader demanderait plus de travail de la part du GPU, à cause de sa flexibilité. C'est la raison pour laquelle les développeurs qui programment les cartes graphiques n'utilisent pas les vertex shaders dans toutes les situations, mais uniquement lorsqu'ils ont besoin de la flexibilité offerte par ceux-ci. Malgré sa simplicité face aux vertex shaders, le pipeline fixe est tout de même capable de bien des choses. Il suffit de regarder les jeux qui n'exploitent pas les shaders pour s'en rendre compte, et il y en a encore beaucoup. Pourtant, il ne fait pas grand chose. D'abord, il transforme les coordonnées du vertex (sa position) à l'aide de matrices, qui définissent la translation, la rotation ou encore l'échelle à appliquer aux coordonnées. Ensuite, il peut effectuer de simples calculs au niveau de l'éclairage, en se basant sur la position de la lumière et la normale du vertex. Ceci n'empêche pas de réaliser des effets comme du bump mapping, des éclairages dynamiques ou encore des ombres, mais ceci correspond plus au pixel pipeline, dont nous parlerons plus tard. Il n'y a pas grand chose de plus à dire sur le pipeline fixe, nous pouvons donc passer au pipeline programmable, qui est un chapitre beaucoup plus imposant. [SIZE=3][COLOR=orangered][B]Le Vertex Pipeline - version programmable[/B][/COLOR][/SIZE] Le pipeline programmable est assez proche du pipeline fixe, sauf que les développeurs peuvent remplacer le mécanisme de traitement des vertices par leurs propres programmes. L'avantage principal est une énorme flexibilité au niveau des algorithmes de rendu, qui tendent de nos jours à se rapprocher de ce qui est utilisé dans les films en images de synthèse, même si les performances ne permettent pas de réaliser la même chose en temps réel. A noter que les noms utilisés pour les registres sont ceux utilisés par DirectX, bien que le fonctionnement reste le même pour OpenGL.
[B]Registres[/B] Un vertex shader est composé de différents élements. D'abord, des registres. Ces registres vont contenir des valeurs. Ils font 128 bits, et stockent quatre valeurs. En fait, ils sont assez proches des registres dédiés au SSE présents sur les processeurs de nos machines. En effet, lorsque le vertex shader effectue des opérations sur ces registres, elles sont effectuées en parallèle sur chaque groupe de 32 bits. Ces registres ont pour rôle de contenir des valeurs sous forme de 4 nombres en virgule flottante. Dans le cas des coordonnées, chaque composante ira à sa place, alors que dans le cas des couleurs, le rouge correspondra à X, le vert à Y, le bleu à Z et la composante alpha à W. Certains éléments plus importants (comme le poids du vertex) pourront être répartis sur plusieurs registres. Il existe différents types de registres, bien que leur fonctionnement soit identique. [B]Registre v0-v??[/B] D'abord, il y a les registres qui contiennent les informations du vertex à traiter et sont appelés les registres d'entrée. Ils vont donc amener au vertex shader des informations telles que la position du vertex, sa couleur diffuse et spéculaire, sa normale, etc. Leur nombre est limité à 16, pour n'importe quelle version des vertex shaders. Un nombre supérieur serait peu utile, et réduirait probablement les performances (16 registres représentent déjà 256 bytes). [B]Registre r0-r?[/B] Second type de registres, les r0-r? vont récupérer différentes valeurs issues des opérations qui vont être effectuées par le vertex shader. Ces registres sont appelés les registres temporaires. Ils peuvent contenir plus ou moins n'importe quelle information. Bien qu'initialement disponibles en un nombre plutôt limité (12 pour les vertex shaders 1.0 et 2.0), par la suite un nombre variable fut disponible (minimum 12 pour les vertex shaders 2.x et 3.0). [B]Registres c0-c?, i0-i?, b0-b?[/B] Troisième type de registres : les registres constants. Ceux-ci permettent de définir des valeurs qui ne vont pas changer d'un vertex à l'autre, mais qui seront globales à l'exécution d'un seul et même vertex shader. Ces constantes contiennent notamment les matrices utilisées pour transformer la position des vertices (translation, rotation, etc.), mais peuvent également contenir tout type d'information utile au vertex shader (vitesse du vent, contraintes physiques, etc). Ces registres ont la particularité d'exister en trois versions (excepté pour les vertex shaders 1.0, qui ne disposent que des registres c??). Ainsi, les registres c?? pourront contenir des nombres à virgule flottante, le type de données le plus courant en 3D. Les registres i?? pourront contenir des nombres entiers. Les registres b??, quant à eux, pourront contenir des valeurs booléennes (vrai ou faux). Les registres c?? sont probablement les plus nombreux disponibles (minimum 96 pour les vertex shaders 1.0, minimum 256 pour les vertex shaders 2.0 et 3.0). Les registres i?? et b??, quant à eux, ne sont disponibles qu'à partir des vertex shaders 2.0, et sont chacun au nombre de 16.
[I]Vertex shader de perturbation des vertices (nVIDIA)[/I]
[B]Registres s0-s3[/B] Uniquement disponibles dans les vertex shaders 3.0, ces registres (appelés registres d'échantillonage) n'ont qu'une utilité : permettre à l'unique nouvelle instruction des vertex shaders 3.0 d'accéder aux données des textures. Ainsi, chaque registre représente une texture, et la nouvelle instruction - texldl - peut récupérer les données provenant de cette texture. Ces registres ne sont présents qu'en 4 exemplaires, ce qui permet tout de même d'accéder aux données de quatre textures différentes à partir d'un vertex shader, alors que précédemment seuls les pixel shaders pouvaient accéder aux textures. [B]Registres a0, aL, p0[/B] Ces registres sont un peu spéciaux, et leur fonctionnalité est unique. De plus, seul a0 est disponible dans toutes les versions des vertex shaders : aL est apparu avec les vertex shaders 2.0, et p0 avec les vertex shaders 2.x. Mais commençons par a0. Il s'agit du registre d'adressage : pour faire simple, au lieu d'accéder à un registre (r0 par exemple) directement, le registre a0 va "pointer" vers r0, et on pourra y accéder indirectement. Il est ainsi possible de choisir selon certaines conditions un registre ou un autre, sans pour autant devoir doubler la taille du vertex shader. Ensuite, aL : le registre compteur de boucle. Il n'existe qu'à partir des vertex shaders 2.0 parce que les boucles (la possibilité de répéter des opérations) n'ont été disponibles qu'à partir de cette version. Il s'agit d'une simple valeur entière qui augmente à chaque itération de la boucle. Vient enfin p0, le registre attribut. Il est utilisé avec les instructions permettant de faire des branchements conditionnels, tels que "si plus grand que", "si plus petit que" ou "si égal à". Il peut ensuite être utilisé pour avoir plus de contrôle sur les instructions traditionnelles. [B]Instructions[/B] Avoir des registres où mettre des valeurs, c'est bien, mais si on peut les manipuler, c'est beaucoup mieux. C'est à ça que vont servir les instructions. Il n'en existe pas beaucoup, comparé à un processeur plus général comme un x86, mais elles sont à peu près toutes en rapport avec la 3D ou au moins l'arithmétique. Nous n'allons pas ici énumérer toutes les instructions, mais sachez qu'il y a des racines carrées réciproques, des produits scalaires, des multiplications, additions, etc. Le fait qu'il y en ait peu est à la fois un avantage et un inconvénient. Un avantage car la complexité des GPUs est réduite, mais un inconvénient car cela limite également les possibilités. Cependant, à partir des vertex shaders 2.0 et 2.x, beaucoup plus de choses peuvent être réalisées.
[I]Vertex shader de réflection/réfraction (nVIDIA)[/I]
Ainsi, les vertex shaders n'avaient aucune instruction permettant le contrôle de flux. Du coup, le GPU exécutait "bêtement" les instructions les unes après les autres. Il arrivait donc souvent que plusieurs vertex shaders offrant des fonctionnalités quasiment identiques soient créés, avec seulement une ou deux instructions différentes. La possibilité de contrôler le flux des shaders a commencé avec [B]les boucles[/B], qui permettent de répéter certaines instructions plusieurs fois. Auparavant, si l'on voulait exécuter vingt fois la même instruction, il fallait taper l'instruction vingt fois. Avec les boucles, il suffit de taper l'instruction une seule fois. Cela permet également d'économiser des instructions, puisque le nombre d'instructions est limité (bien que cette limite soit très haute avec les derniers GPUs). Second type de contrôle de flux, [B]les branchements conditionnels[/B] permettent d'effectuer certaines instructions sous certaines conditions, réduisant cette fois-ci le nombre de shaders différents à écrire, plutôt que le nombre d'instructions. Bien qu'un vertex shader soit censé traiter un vertex uniquement grâce aux informations de ce dernier ainsi qu'aux constantes qui peuvent être fournies au vertex shader, les vertex shaders 3.0 possèdent une instruction capable de récupérer les informations d'une texture, chose normalement possible uniquement dans un pixel shader. Cette instruction est encore très peu utilisée, notamment car les cartes supportant vertex shaders 3.0 sont peu répandues. L'utilité principale d'accéder aux données d'une texture est de pouvoir faire du displacement mapping de façon très simple (il est possible de faire du displacement mapping avec les versions précédentes des vertex shaders, mais c'est plus compliqué et demande plus de ressources). [B]Versions[/B] On entend souvent parler de "Shader Model 3.0" et autres termes relatifs aux shaders. De manière générale, "shader model" signifie simplement vertex ET pixel shader. Les versions, quant à elles, sont assez nombreuses. Dans ce chapitre nous ne nous occuperons évidemment que des vertex shaders, les pixel shaders viendront plus tard. Les cartes supportant les vertex shaders supportent au minimum les versions 1.0 et 1.1. La version 1.0 est d'ailleurs pratiquement tombée dans l'oubli. La version 1.1 ne fait qu'ajouter quelques instructions (qu'il était possible d'effectuer avec la version 1.0, d'une façon un peu détournée). Cette version correspond aux débuts des vertex shaders, qui n'étaient qu'une suite d'instructions assez simple, sans contrôle de flux, mais capables de réaliser pas mal de choses. Cette version correspond à DirectX 8. Ensuite sont venus plus ou moins en même temps, avec DirectX 9, les vertex shaders 2.0, 2.x et 3.0. Les vertex shaders 2.0 possèdent plus d'instructions, plus de registres, et le support des boucles. Ceci permet de réaliser des shaders légèrement plus complexes, tout en simplifiant leur création. Les vertex shaders 2.x sont un peu spéciaux, et font le lien entre les vertex shaders 2.0 et 3.0. Ainsi, les vertex shaders 2.x correspondent aux vertex shaders 2.0 auxquels sont ajoutées la plupart des fonctionnalités des shaders 3.0, mais de manière optionnelle. Ainsi, une carte supportant toutes les options des vertex shaders 2.x est en quelque sorte une carte supportant les vertex shaders 3.0. Parmi ces nouvelles fonctionnalités, on trouve notamment de nouvelles instructions au niveau du contrôle de flux. Enfin, les vertex shaders 3.0 correspondent plus ou moins aux vertex shaders 2.x, avec toutes les options disponibles, et une instruction de plus permettant d'accéder aux données disponibles dans les textures, comme expliqué un peu plus haut. Les nouvelles versions des vertex shaders n'arriveront pas dans l'immédiat, ce qui n'est pas une mauvaise chose, et ce pour plusieurs raisons. Non seulement la dernière version offre de très nombreuses possibilités, mais les développeurs ont du mal à suivre, avec sur le marché des cartes supportant trois versions différentes des vertex shaders. [SIZE=3][COLOR=orangered][B]Le Vertex Pipeline - performances[/B][/COLOR][/SIZE] Pas mal de choses peuvent influencer les performances du vertex pipeline. Il est donc intéressant de savoir ce qui peut faire qu'une carte graphique sera plus rapide qu'une autre. Aussi, voici quelques éléments de réponse à la question : "qu'est-ce qui fait qu'une carte graphique est rapide ?". Mais uniquement au niveau du vertex pipeline. [B]Unités de traitement des vertices[/B] Ou vertex units, pour les anglais. Chaque unité représente en quelque sorte un vertex pipeline. Puisqu'un vertex pipeline (ou un vertex shader) ne traite qu'un seul et unique vertex à la fois, l'ajout de plusieurs de ces unités de traitement permet de traiter plusieurs vertices en parallèle. L'avantage est évidemment considérable, puisqu'au niveau du traitement des vertices les performances augmentent de façon pratiquement linéaires.
[I]Vertex shader d'éclairage anisotropique (nVIDIA)[/I]
En effet, la carte graphique reçoit généralement un très grand nombre de vertices à la fois (plusieurs milliers, voire millions), et il est donc très simple de traiter 2, 4, 8, 12 ou 16 vertices d'un coup au lieu d'une seule. Les performances sont ainsi doublées, quadruplées, etc. [B]Taille et vitesse du bus mémoire[/B] Il s'agit, dans les spécifications de la carte graphique, du "128-bit" ou "256-bit" qui se trouve à côté de la quantité de mémoire présente sur la carte. Cette taille influence la quantité de données pouvant être transféree entre la mémoire et le GPU. On pourrait se dire que seules les textures se trouvent dans la mémoire de la carte graphique, mais il est en fait possible d'y mettre plus ou moins n'importe quel type d'information, y compris des vertices. L'avantage est évidemment d'avoir les données à promixité du GPU, et de pouvoir ainsi y accéder très rapidement. La taille du bus mémoire et sa fréquence détermineront à quelle vitesse les vertices peuvent être envoyés au GPU. Il faut cependant faire attention lors de la lecture de ces informations. Ainsi, une carte disposant d'un bus 128-bit et de mémoire à 300 MHz sera plus lente qu'une carte disposant d'un bus 256-bit et de mémoire à 200 MHz. Le plus simple est de multiplier le nombre de bits par la fréquence pour obtenir une valeur permettant de donner un ordre de performance. [B]Taille des vertices[/B] Probablement pas l'élément le plus important à prendre en compte au niveau des performances, il a pourtant un certain impact sur les performances. Comme expliqué dans le chapitre concernant les vertices, ceux-ci ont une taille variable. Si cette taille dépasse une certaine valeur, qui est en général spécifique à une génération de chipset, les performances seront réduites. Le problème, dans ce cas-ci, c'est que les constructeurs ne communiquent généralement pas ces valeurs aux consommateurs (vous ne verrez jamais cette valeur sur la boite de la carte graphique), et les développeurs de jeux ne communiquent jamais la taille des vertices utilisée dans leurs jeux, puisque celle-ci est variable. Il est donc au final inutile de tenir compte de cet élément lors de l'achat d'une carte graphique, mais il est intéressant de savoir qu'il existe. [B]Nombre d'instructions d'un shader[/B] Le nombre d'instructions d'un vertex shader a beaucoup d'influence sur les performances de celui-ci. En effet, sans même tenir compte du fait que certaines instructions prennent plus de temps que d'autres, les performances d'un vertex shader diminuent très vite avec l'augmentation du nombre d'instructions. Encore une fois, tout comme pour la taille des vertices, ce type d'information est difficile à obtenir, aussi bien au niveau des constructeurs que des développeurs. [SIZE=3][COLOR=orangered][B]Culling, Clipping et Tramage[/B][/COLOR][/SIZE] Une fois le vertex traité par le vertex pipeline, il reste quelques petites opérations à effectuer afin de préparer les nouvelles données. Une fois cette préparation effectuée, les données seront envoyées au pixel pipeline, si elles remplissent certaines conditions. [B]Culling[/B] Première opération possible, le culling. Cette technique permet de ne pas afficher certaines primitives, car celles-ci ne seraient pas visibles. En effet, lorsque les primitives sont affichées, les vertices sont spécifiés dans un certain ordre. Cet ordre peut être dans le sens des aiguilles d'une montre ou l'inverse. Cependant, ce sens détermine la "face avant" et la "face arrière" d'une primitive. Du coup, si la face arrière est visible et non la face avant, les données n'iront pas plus loin. Ceci permet d'augmenter les performances, puisque lors de l'affichage d'un modèle, l'arrière de celui-ci ne sera pas affiché. A noter tout de même que le culling peut être désactivé, puisqu'il est parfois utile d'afficher les faces arrières des primitives, par exemple pour afficher des brins d'herbe sans devoir leur donner un volume. [B]Clipping[/B] Seconde opération permettant également de diminuer la quantité de données à afficher en déterminant leur visibilité, le clipping. En fait, il existe plusieurs types de clipping. Le premier est assez simple : lorsqu'un vertex devrait être affiché "hors" de l'écran, il ne passe pas le test de clipping, et n'est donc pas affiché. Deuxième type de clipping, il est possible de définir des plans de clipping. Ces plans permettront de définir une zone en dehors de laquelle les informations ne passeront pas le test de clipping. Cette seconde méthode est plus compliquée à mettre en oeuvre, mais offre bien plus de flexibilité et est généralement beaucoup plus efficace. Tout comme le culling, le clipping peut également être désactivé, même si l'intérêt est cette fois très limité. [B]Tramage[/B] Dernière étape avant le pixel pipeline : le tramage. Le tramage est en fait la construction des primitives à partir des vertices. Un certain nombre de pixels sera ainsi créé. A noter que certains types d'anti-aliasing peuvent déjà être utilisés lors de cette étape, afin notamment de rendre le contour des primitives plus lisse. Un anti-aliasing complet, quant à lui, n'est effectué que bien après le pixel pipeline. Une fois ces pixels générés, leurs données (obtenues à partir de celles venant du vertex pipeline, certaines informations étant interpolées, comme la couleur) sont envoyées au pixel pipeline. La suite de ce dossier sera publiée dans quelques semaines. En attendant, voici la table des matières de cette seconde partie : [I]- Le pixel pipeline : vue d'ensemble - Le pixel pipeline : version fixe - Le pixel pipeline : version programmable - Le pixel pipeline : performances - Test alpha, test de profondeur et test brouillon - Brouillard et alpha blending - Rendu final - Performances globales - Evolutions futures - Conclusion[/I] [B]Architecture et fonctionnement d'un GPU - 2° partie (par Ashe - 20/06/2005)[/B] [SIZE=3][COLOR=orangered][B]Introduction[/B][/COLOR][/SIZE] Voici donc la seconde partie de l'article consacré à l'architecture et au fonctionnement des GPUs. Lors de la publication de la première partie, il y a eu deux types de réaction face à l'article : soit c'est incompréhensible, soit c'est très bien fait. Au moins personne n'a dit que c'était mal fait, mais si personne ne comprend, ca ne sert a rien de publier des articles. Nous avons donc tenu compte des quelques remarques que nous avons pu recevoir afin de rendre cette seconde partie plus accessible... Mais avant d'entrer dans le vif du sujet, cette introduction va également servir de rappel, histoire de se remettre dans le bain. La première partie concernait donc le vertex pipeline. Il s'agit de toute la partie du GPU qui va construire les primitives (des formes géométriques basiques) qui, une fois mises côte à côte, formeront tout ce qui est visible dans la scène affichée. Pour créer ces primitives, il faut des vertices. Les vertices contiennent les coordonnées des sommets des primitives, mais aussi leur couleur ainsi que d'autres propriétés. Une fois ces données envoyées à la carte graphique, elles passent dans le tesselateur qui va générer de nouvelles vertices. Le but principal étant de lisser les modèles en augmentant le nombre de sommets qui les compose. Une fois les nouvelles vertices créées, elles vont passer dans le vertex pipeline. Celui-ci existe en deux versions : le fixe, et le programmable. Le pipeline fixe correspond aux anciennes cartes graphiques ne disposant pas de vertex shaders, alors que le programmable correspond aux vertex shaders. Dans les deux cas, le rôle de ce pipeline est de modifier les vertices selon divers paramètres, comme les transformations appliquées à la scène ou encore l'éclairage. Enfin, quelques étapes permettant d'augmenter légèrement les performances sont effectuées, telles que le clipping et le culling. L'étape finale est le tramage, qui consiste à générer des pixels à partir de la géométrie. Nous allons donc maintenant voir ce qui arrive à ces pixels... [SIZE=3][COLOR=orangered][B]Le Pixel Pipeline : vue d'ensemble[/B][/COLOR][/SIZE] Le pixel pipeline a un rôle très simple, dans l'idée, même si il s'agit finalement d'opérations complexes à effectuer. A la base donc, le pixel pipeline reçoit un pixel, ainsi que quelques informations l'accompagnant (les coordonnées des textures, par exemple). A partir de ces informations, il va falloir construire un pixel complet. Tout comme le vertex pipeline, il existe deux versions du pixel pipeline. Une version fixe comme sur les anciennes cartes graphiques, et une version programmable : les pixel shaders. Le pipeline fixe ne peut réaliser que quelques opérations de base, mais c'est néanmoins suffisant pour beaucoup d'opérations, comme nous allons le voir dans le chapitre suivant. Le pipeline programmable, quant à lui, est évidemment beaucoup plus flexible, mais également plus lent : la version fixe effectuant toujours les mêmes tâches, elle est optimisée pour ces opérations. Le pipeline programmable doit par contre réaliser un énorme nombre d'opérations différentes, dans un ordre qui n'est pas connu à l'avance. Les pixel shaders ont également généralement un impact plus grand sur les performances, puisqu'il y a beaucoup plus de pixels à traiter qu'il n'y a de vertices. Les opérations du pixel shader sont également généralement plus gourmandes, par exemple lorsqu'il faut accéder aux données présentes dans les textures. [SIZE=3][COLOR=orangered][B]Pixel Pipeline : version fixe[/B][/COLOR][/SIZE] Le pixel pipeline fixe n'a finalement pas grand chose à faire. Les calculs au niveau de l'éclairage ont déjà été effectués par le vertex pipeline, il ne reste au final qu'à s'occuper des textures. Une carte graphique est capable de stocker un nombre important de textures, mais ne peut en utiliser qu'un certain nombre simultanément. Sur les cartes actuelles, la moyenne doit tourner autour de 4 à 8 textures simultanées. Evidemment, il s'agit d'un nombre maximum, cela ne veut pas dire qu'il faut à chaque fois appliquer 4 à 8 textures sur chaque objet d'une scène. [B]Accès aux textures[/B] Pour chaque texture à utiliser, il y a un jeu de coordonnées de texture correspondant (les coordonnées UV). Elles permettent d'accéder à une valeur présente dans la texture en utilisant les coordonnées UV. Il existe également des textures 3D (une troisième coordonnée est alors présente), mais celles-ci sont rarement utilisées, excepté peut-être en imagerie médicale.
[IMG]http://kyro1.free.fr/divers/dossier.GPU.matbe.com/000000010904.jpg[/IMG] [I]L'utilisation de Lightmap, visible à gauche[/I]
Grâce à ces coordonnées donc, le pixel pipeline va aller chercher une valeur dans les textures et va pouvoir les appliquer au pixel. Cependant, les valeurs ne sont pas appliquées n'importe comment : le pipeline fixe permet de choisir de quelle façon elles seront appliquées. [B]Mélange des textures[/B] Et c'est à ça que sert le mélange des textures. Pour chaque texture, une opération différente est spécifiée. Par exemple, pour la première texture, il peut s'agir d'additionner la couleur actuelle du pixel à la couleur obtenue dans la texture. Ensuite, pour la deuxième texture, il s'agira de multiplier uniquement la composante alpha. Et ainsi de suite, pour chaque texture. L'air de rien, même si ces opérations sont assez basiques, elles ont longtemps été suffisantes. Un exemple d'une utilisation classique du mélange de texture sont les lightmaps. Dans un jeu comme Counterstrike par exemple, les niveaux ne sont au départ pas éclairés. Ils possèdent donc des textures de base, sans la moindre ombre ou sans le moindre changement de luminosité. Un calcul va être effectué lors de la création du niveau afin de savoir quelles zones doivent être dans l'ombre. A partir de là, des textures en niveau de gris sont créées : du noir à l'endroit le plus sombre, et du blanc à l'endroit le plus clair. Il suffit ensuite de multiplier la valeur de la texture de base avec la valeur de la texture en niveaux de gris (la lightmap) pour obtenir le résultat final. [SIZE=3][COLOR=orangered][B]Pixel Pipeline : version programmable[/B][/COLOR][/SIZE] Le pixel pipeline programmable (ou plus simplement : les pixel shaders) a un fonctionnement très proche du vertex pipeline programmable. Des valeurs arrivent en entrée (les données d'un pixel), un traitement est effectué, et les valeurs modifiées ressortent. Les dernières versions des pixel shaders les ont amenées à un niveau très proche des vertex shaders au niveau des fonctionnalités, comme il sera expliqué plus bas. Il existe néanmoins des instructions qui sont spécifiques aux pixel shaders et qu'il est intéressant de décrire, puisqu'elles affectent grandement le fonctionnement du pixel pipeline. [B]Instructions[/B] Ces instructions vont donc réaliser des opérations sur les valeurs qui leur sont fournies (par exemple une couleur). D'autres informations sont disponibles comme les coordonnées U/V des textures dont il avait été question dans la première partie de cet article. Pour rappel, elles donnent une position sur une texture (U pour l'axe des abscisses, V pour les ordonnées). Texld Cette instruction (texture load) permet d'aller chercher des données dans les textures. Ces données peuvent être de simples couleurs, pour l'utilisation la plus classique des textures, ou tout autre type de données. Par exemple, dans le cas du bump mapping, la texture - ou bump map - contiendra des valeurs qui sont des perturbations utilisées lors des calculs du bump mapping. A noter que cette instruction a longtemps été réservée aux pixel shaders, mais qu'elle est disponible dans les vertex shaders 3.0 (c'est d'ailleurs pratiquement la seule différence avec les vertex shaders 2.x). Texkill Une instruction qui pourrait paraître toute bête, mais qui finalement est une des plus puissantes, puisqu'elle contrôle le flux du pixel pipeline. En effet, elle permet de "tuer" un pixel, c'est à dire d'annuler son rendu. C'est non seulement très utile pour certaines techniques d'affichage, mais cela permet également d'augmenter les performances puisque le pixel n'ira pas plus loin dans le processus de rendu. [B]Versions[/B] Il y a plus de versions de pixel shaders qu'il n'y a de versions de vertex shaders. Allant de la version 1.0 à 1.4, pour ensuite passer aux versions 2.0, 2.x et 3.0, toutes ces versions - surtout les premières - ont été un véritable casse-tête lors du développement des premiers jeux exploitant les pixel shaders. Nous pouvons passer les versions antérieures aux pixel shaders 1.3, puisque ces derniers représentent plus ou moins la première version vraiment utilisée et supportée par toutes les cartes graphiques supportant les pixel shaders. Pixel Shaders 1.3 Cette "première" version possédait très peu de registres ainsi que très peu d'instructions, ce qui la rendait assez limitée. Il faut savoir qu'un pixel shader est généralement beaucoup plus complexe et plus gourmand en ressources qu'un vertex shader, ce qui est d'ailleurs une des raisons pour laquelle il n'existe pas de version logicielle des pixel shaders. Pixel Shaders 1.4 Version mutante, elle a été utilisée principalement par ATI et mise en avant lors de la sortie de la Radeon 8500. Elle est beaucoup plus puissante que la version précédente puisqu'elle peut aller chercher les données présentes dans les textures. Elle fût malgré tout beaucoup moins utilisée puisqu'elle n'était pas supportée par les cartes NVIDIA de l'époque. Pixel Shaders 2.0 et 2.x Avec cette version, les pixel shaders commencèrent enfin à être utilisables, notamment parce que de nombreuses instructions ont été ajoutées. Ce nouveau jeu d'instructions correspond plus ou moins à ce qui était disponible dans les vertex shaders 1.0, tout en gardant les possibilités des pixel shaders 1.4 et en les simplifiant. Bref, c'est beaucoup mieux, mais finalement en retard par rapport aux vertex shaders puisque ne possèdant pas de contrôle de flux. Contrôle de flux qui est justement arrivé avec la version 2.x. Pixel Shaders 3.0 Enfin, la version 3.0 ajoutera quelques registres et quelques nouvelles instructions, amenant le jeu d'instructions des pixel shaders 3.0 plus ou moins au même niveau que celui des vertex shaders 3.0, avec évidemment plus d'instructions au niveau de l'accès aux textures. [SIZE=3][COLOR=orangered][B]Pixel Pipeline : performances[/B][/COLOR][/SIZE] [B]Nombre de pixel pipelines[/B] Les performances du pixel pipeline ne dépendent finalement pas de grand chose. Plus il y a de pixels à traiter, plus c'est lent. Plus il y a de pipelines capables de les traiter, plus c'est rapide. Les performances sont donc en grande partie définies par le nombre de pipelines disponibles. L'augmentation des performances apportées par ces pipelines supplémentaires tend même à être linéaire, les performances étant pratiquement doublées si le nombre de pipelines est doublé (dans le cas bien sur où le traitement des pixels est la partie la plus lente du rendu). Sur la prochaine génération de carte graphiques, il y aura jusqu'à 32 pixel pipelines, ce qui permet en pratique de traiter 32 pixels simultanément. En fait, cette façon d'augmenter les performances en effectuant les tâches en parallèle est visible dans tous les autres composants de l'ordinateur (dual core, dual channel, disques durs en RAID). Il faut savoir que le traitement des pixels est généralement le facteur qui limite la vitesse d'affichage dans les jeux actuels, le vertex pipeline étant généralement capable de traiter les vertices sans difficulté. [B]Anti-aliasing[/B] L'anti-aliasing est une opération qui était gourmande lors de son apparition il y a quelques années. Les performances étaient grandement dégradées, et l'anti-aliasing n'était pas vraiment utilisable. Depuis maintenant quelques générations de cartes graphiques, c'est beaucoup mieux et l'utilisation de l'anti-aliasing peut être une alternative à l'utilisation d'une plus haute résolution. Les performances de l'anti-aliasing ne dépendent pas réellement des spécifications de la carte graphique, et il est donc difficile de deviner à quel point les performances seront affectées, il vaut mieux se tourner vers des benchmarks. [B]Filtrage anisotropique[/B] Le filtrage anisotropique est une technique permettant d'interpoler les pixels afin de lisser les textures, tout comme les filtrages bi-linéaires et tri-linéaires. Le filtrage anisotropique a cependant une certaine influence sur les performances de la carte graphique, bien que de nos jours il ne s'agisse que de quelques images par seconde perdues (et encore). Tout comme l'anti-aliasing, il est impossible de connaitre les performances du filtrage anisotropique avec seulement les spécifications de la carte graphique, et il faut une fois de plus se tourner vers des benchmarks. [SIZE=3][COLOR=orangered][B]Tests Alpha, de profondeur et brouillon[/B][/COLOR][/SIZE] Une fois les pixels modifiés par le pixel pipeline, il reste quelques opérations à effectuer, mais on approche de la fin ! Parmi ces opérations, il y a ces trois tests. Ils n'ont pas énormément d'incidence sur les performances, puisque le "gros" du travail est déjà effectué (les deux pipelines), mais peuvent néanmoins grapiller quelques images par secondes dans le meilleur des cas. Ils sont de toute manière utilisés pour différentes techniques de rendu. Test alpha Les couleurs sont composées de rouge, vert, bleu, mais aussi d'une composante alpha. Cette composante alpha est plus ou moins générique, mais utilisée principalement pour des effets de transparence. Le test alpha permet de contrôler l'affichage des pixels d'après cette composante alpha. Ainsi, il est possible de ne pas afficher les pixels où la composante alpha est à moins de 50%, par exemple. A noter également que l'utilisation de la transparence consomme une certaine quantité de bande passante, puisqu'il y a techniquement plus de pixels à afficher. Le fillrate s'en voit donc affecté. [B]Test de profondeur[/B] Le test de profondeur agit plus ou moins comme le test alpha, mais au lieu de se baser sur la composante alpha, il se base sur la profondeur du pixel. Ainsi, un pixel garde les informations concernant sa position en 3D. Le test de profondeur permet surtout de ne pas avoir à afficher les pixels qui ne seront pas visibles. En effet, si un pixel est déjà présent à une certaine profondeur (chose vérifiée à l'aide du tampon de profondeur), un autre étant au même endroit mais à une plus grand profondeur n'a aucune raison d'être affiché puisqu'on ne le verra pas. Dans le cas de la transparence, on pourrait se dire qu'il a besoin d'être affiché, mais la transparence est généralement effectuée en affichant d'abord le pixel qui est à la plus grande profondeur. Dans le cas contraire, les calculs de transparence seraient faussés.
[IMG]http://kyro1.free.fr/divers/dossier.GPU.matbe.com/000000010915.jpg[/IMG] [I]Le Z Buffer - (blanc: proche; noir: loin)[/I]
[B]Test brouillon[/B] Le test brouillon (en anglais stencil test) fonctionne comme le test de profondeur, mais au lieu de tester la profondeur il va tester la valeur qui se trouve dans le tampon brouillon (stencil buffer). Cela a de nombreuses utilités, mais est principalement utilisé pour créer des ombres ou autres effets où la forme ou le contour d'un objet sont requis. [SIZE=3][COLOR=orangered][B]Brouillard et mélange alpha[/B][/COLOR][/SIZE] Après tous ces tests, il y a encore le brouillard et le mélange alpha. Arrivé à ce point, tous les pixels qui ont passé les trois précédents tests seront affichés. [B]Brouillard[/B] Le brouillard, ce n'est pas du brouillard comme si vous vous baladiez au milieu de Londres, ou le brouillard que l'on voit par exemple dans certains niveaux de Quake 3. Il s'agit là de brouillard volumétrique, qui est une technique de rendu. Dans ce cas-ci, le brouillard est quelque chose de beaucoup plus simple : c'est ce bon vieux brouillard que l'on voit au loin, pour que les objets n'apparaissent pas d'un coup. Il est tout de même légèrement configurable, et plusieurs formules mathématiques peuvent être utilisées pour choisir où se trouve le brouillard ou sa couleur. [B]Mélange alpha[/B] Voici donc ce qui permet de faire de la transparence, le mélange alpha (en anglais alpha blending). Différentes formules sont disponibles, permettant de choisir ce qui sera pris en compte, à partir de deux pixels, lors du calcul du pixel qui en résultera. Ces deux pixels sont les pixels de source et de destination (le nouveau pixel et celui qui était déjà présent). Le mélange alpha a un impact sur les performances des cartes graphiques, mais pas un impact direct. Ainsi, n'importe quelle carte graphique peut mélanger deux pixels sans la moindre difficulté et en quelques nanosecondes. Par contre, dans une scène complète, il y a beaucoup de pixels, et il faut chaque fois mettre à jour les pixels qui seront modifiés par cette transparence. De plus, si une surface est transparente, il faut afficher ce qui se trouve derrière. Cette augmentation du nombre de calculs à effectuer et de pixels à afficher peut dégrader les performances. [SIZE=3][COLOR=orangered][B]Rendu final[/B][/COLOR][/SIZE] Ca y est, on y est presque ! Plus ou moins toutes les manipulations ont été effectués, il ne reste plus qu'à afficher. [B]Transformation du viewport[/B] Le viewport est une forme géométrique (généralement un rectangle) qui définit où les pixels vont se retrouver dans la fenêtre. En effet, même lorsqu'un jeu est en plein écran, il est toujours dans une fenêtre qui n'a simplement pas de bord ni de barre de titre. Ainsi, ce viewport peut faire en sorte que toute la scène ne soit affichée que sur un morceau de la fenêtre, ce qui peut être utile pour les jeux où l'écran est partagé en deux. Dans ce cas, la scène est affichée une première fois sur le haut de la fenêtre, puis une seconde fois sur le bas de la fenêtre. Cependant, la plupart des jeux affichent simplement sur toute la fenêtre.
[IMG]http://kyro1.free.fr/divers/dossier.GPU.matbe.com/000000010905.jpg[/IMG] [I]Mario Kart, 4 viewports distincts[/I]
[B]Anti-aliasing[/B] Il existe plusieurs types d'anti-aliasing. Celui qui nous intéresse (appelé "fullscene anti-aliasing") s'applique, comme son nom l'indique, à toute la scène, contrairement à d'autres types d'anti-aliasing qui ne s'appliquent qu'aux lignes, par exemple. Le but de l'anti-aliasing est de lisser le rendu de manière à ne pas avoir droit aux fameux effets d'escalier. Il existe diverses méthodes pour réaliser cet anti-aliasing, les deux principales étant le multisampling et le supersampling. Dans le cas du multisampling, la scène est rendue plusieurs fois et les rendus sont légèrement décalés les uns par rapport aux autres. Les valeurs de chaque pixel sont ensuite mélangées. Le terme multisampling (échantillonage multiple) vient donc de cette utilisation de plusieurs rendus. Dans le cas du supersampling, la scène est rendue en plus haute résolution, pour ensuite être réduite à sa résolution "normale". De part sa plus haute résolution, les valeurs des pixels peuvent être interpolées et l'image est lissée. [B]Deferred rendering/shading/lighting[/B] Depuis longtemps, il est possible de faire en sorte que le rendu d'une scène soit fait sur une texture plutôt qu'à l'écran, textures qui peuvent ensuite être utilisées dans la scène comme n'importe quel type de texture. Sur les dernières générations de cartes graphiques, il est même possible de manipuler directement le framebuffer (l'endroit où se trouvent les pixels qui vont être affichés). Cette technique permet d'effectuer des effets de post-processing. Ce système de post-processing présente de nombreux avantages. Premièrement, certaines techniques de rendu nécessitent d'avoir l'image finale à disposition. Ensuite, l'utilisation du post-processing peut augmenter les performances de certains effets qui n'auront pas à être réalisés dans les vertex ou pixel shaders. Et c'est là que les termes de deferred rendering, shading et lighting interviennent. Deferred signifie "reporté". Le traitement sera ainsi reporté à la fin du processus d'affichage. L'utilisation la plus fréquente, même si cette technique est encore peu utilisée, est de réaliser les calculs d'éclairage lorsque la scène est complètement rendue. La gestion de l'éclairage est alors beaucoup plus flexible, il est possible de réaliser plus d'effets, et c'est généralement plus rapide que l'utilisation de vertex shaders ou pixel shaders. Et voilà, l'image est affichée. Il reste cependant encore quelques pages, mais celles-ci sont consacrées à ce qui affecte les performances d'une carte graphique ainsi qu'aux futures évolutions de celles-ci. [SIZE=3][COLOR=orangered][B]Performances globales[/B][/COLOR][/SIZE] Les performances : un critère important lors de l'achat d'une carte graphique. Il est évident qu'il est impossible de connaître les performances exactes d'une carte graphique simplement à l'aide des spécifications. Elles permettent au mieux de se faire une idée. Pour vraiment connaitre les performances, il vaut mieux se tourner vers les différents benchmarks effectués partout sur le web, y compris chez nous. [B]Fréquence du processeur[/B] C'est un peu évident, c'est comme pour un CPU. Plus la fréquence est élevée, plus la carte est performante. Cependant, tout comme pour un CPU, une architecture ne vaut pas une autre. Il n'y a qu'à comparer la fréquence d'un Athlon 64 à celle d'un Pentium 4. La différence est cependant bien moins importante au niveau des cartes graphiques, et les performances se valent plus ou moins à fréquence égale, à condition bien sur que les autres composants de la carte graphique soient les mêmes (même mémoire, largeur de bus, etc.). [B]Fréquence de la mémoire[/B] Un peu comme le processeur, la carte graphique sera évidemment plus performante si la mémoire est plus rapide. Il y a pourtant un point beaucoup plus important que sa fréquence, et qui est pourtant souvent moins visible : la largeur de bande. Ainsi, il vaut mieux avoir de la mémoire à 100 MHz sur un bus 128-bit que de la mémoire à 150 MHz sur un bus 64-bit. Sur certains modèles de carte graphique, il est assez difficile de voir ce type d'information, il vaut mieux donc bien se renseigner avant d'acheter une carte. [B]Unités de shader / vertex pipelines[/B] Les unités de shader s'occupent d'exécuter les vertex et pixel shaders. Lorsque des vertices sont envoyés à la carte graphique, ce n'est pas un seul à la fois, mais bien des milliers. Il est donc très simple d'effectuer leur traitement en parallèle. Du coup, plus y a d'unités de shader, plus vite les vertices sont traités. L'augmentation de performance apportée est assez linéaire, c'est à dire que si elle doublait en passant de quatre à huit unités, elle quadruplera en passant de quatre à seize. [B]Unités de texture / pixel pipelines[/B] Les unités de texture s'occupent de gérer les textures. Chaque unité peut contenir une texture. Lors de l'affichage de primitives possédant plus d'une texture, il faut autant d'unités de texture qu'il y aura de textures sur la primitive. Cependant, si il y en a moins (par exemple, il y a quatre unités de texture et six textures doivent être affichées), la primitive devra être affichée une première fois avec les quatre premières textures, puis une seconde fois avec les deux textures restantes, ce qui dégrade grandement les performances. [SIZE=3][COLOR=orangered][B]Evolutions futures[/B][/COLOR][/SIZE] Les nouvelles générations de cartes graphiques sont sur le point d'être disponibles, alors à quoi peut-on s'attendre dans un futur assez proche, voire pas si proche que ça ? [B]Augmentations de la complexité et des performances[/B] Les cartes graphiques sont de plus en plus complexes, c'est indéniable. A un point tel qu'elles finiront probablement, d'ici quelques années, à entrer en "collision" avec les microprocesseurs de nos machines. La Convergence des CPUs et GPUs Il est intéressant de voir comment les microprocesseurs et les cartes graphiques vont vers une rencontre. Les microprocesseurs se tournent vers le parallèlisme (MMX, 3DNow!, SSE) et vers la multiplication des cores (dual core), chose déjà présente depuis longtemps dans les cartes graphiques qui travaillent principalement sur des vecteurs et des matrices (parallèlisme) et possèdent plusieurs unités de textures et de shaders (sorte multiplication des cores). Les cartes graphiques, quant à elles, disposent de plus en plus de fonctionnalités, leur permettant de réaliser de plus en plus de choses, ce qui les rapproche d'un microprocesseur capable de réaliser des tâches génériques. Nouveau Shader Model Cette augmentation de complexité se caractérise principalement par l'augmentation des possibilités apportées par chaque nouveau shader model. Le shader model 4.0 est en chemin, et apporte une nouvelle fois son lot de nouveautés, notamment la généralisation du système des shaders (ainsi, il n'y aura plus de différence entre un vertex shader et un pixel shader, du point de vue des fonctionnalités). Unités de Texture et de Shader Un autre facteur est l'augmentation des unités de texture ou de shader. La génération qui va bientôt être disponible disposera de jusqu'à 32 unités de shader. La GeForce 3 n'en avait qu'une. Ce n'est peut-être pas la façon la plus élégante d'augmenter les performances d'une carte graphique, mais c'est certainement une des plus efficaces. Le SLI Mettre tout par deux, c'est à la mode. Le SLI est déjà disponible depuis un moment chez NVIDIA, et maintenant chez ATI aussi. Pour le moment, c'est principalement deux cartes qui sont utilisées, mais il est probable qu'il sera un jour possible d'en mettre quatre, ou au moins deux cartes possédant chacune deux GPUs. [B]Améliorations du rendu[/B] Aller vite, c'est bien, mais il est préférable que ce soit joli à regarder. Les cartes graphiques sorties à l'époque de DirectX 8.0 possédaient une fonctionnalité appelée "surfaces de haut niveau" : un système permettant de décrire des surfaces courbes, et donc de les afficher. Le support de cette fonctionnalité a disparu des pilotes depuis longtemps. Plus tard, avec 9.0, la tesselation est apparue. Il s'agit du tesselateur décrit dans la première partie de cet article. Le support de cette technologie a également disparu des pilotes. Et bien voici la troisième étape - ou version - de ce système : les geometry shaders et les nouvelles surfaces de haut niveau. Les Geometry Shaders Au départ, il avait été prévu de créer ce qui s'appelle un topology processor, en français processeur de topologie. Son rôle était de générer de nouvelles vertices de façon programmable, contrairement au tesselateur. Cependant, il y avait de nombreuses restrictions, et il fallait que la génération des nouvelles vertices se fasse le plus tard possible dans le pipeline. Apparemment, cette idée ne plaisait pas beaucoup, et le topology processor aurait probablement vécu aussi longtemps que ses prédécesseurs cités plus haut. A la place, nous aurons droit aux geometry shaders. Ces shaders permettent de créer des vertices de façon programmable, mais sans aucune limitation. Il est même possible d'envoyer des vertices à la carte graphique, de leur appliquer un vertex shader (modifiant les vertices), d'appliquer un geometry shader sur les vertices ainsi modifées, et d'appliquer à nouveau un vertex shader. Les possibilités sont donc énormes. Nouvelles Surfaces de Haut Niveau Les geometry shaders sont là pour générer des vertices, mais le tesselateur existe toujours. Et celui-ci a été grandement amélioré. En effet, la précédente version n'était pas très pratique. Avec cette nouvelle version, de nombreux types de surfaces de haut niveau sont disponibles. L'avantage est qu'elles seront beaucoup plus simples à utiliser pour les développeurs de jeux, et du coup il y a beaucoup plus de chances pour qu'elles soient présentes dans les nouveaux jeux.
[IMG]http://kyro1.free.fr/divers/dossier.GPU.matbe.com/000000010913.jpg[/IMG] [I]Le NURBS, un type de surface de haut niveau[/I]
Ces surfaces de haut niveau permettront ainsi d'avoir des surfaces courbes au lieu de triangles qui commencent à se faire vieux (même si en interne, il s'agira toujours de triangles). Les applications utilisant ces fonctionnalités devraient donc être beaucoup plus belles. [B]Microsoft XNA et DirectX Next[/B] Maintenant voyons un peu ce qui va se passer au niveau logiciel. DirectX Next (ou un de ses nombreux autres noms) est la prochaine version de DirectX, prévue pour l'année prochaine, alors que XNA est un système de développement. Un des avantages d'XNA est qu'il est multi-plateformes. Nous en voyons déjà imaginer utiliser les jeux XNA sous Linux, mais ce n'est pas comme ça que ça marche, c'est du multi-plateforme à la sauce Microsoft. Traduction : fonctionne sous les systèmes Windows et la Xbox 360. Et oui, deux plateformes, c'est du multi-plateformes. Shader Model 4.0 Mais revenons à DirectX, qui nous intéresse beaucoup plus, puisque c'est lui qui affectera le look des jeux. Premier changement, le shader model 4.0. A la différence des versions précédentes où il y avait des vertex shaders et des pixel shaders, la version 4.0 est unifiée, c'est à dire que les vertex et pixel shaders ont les mêmes fonctionnalités (mais évidemment pas le meme rôle). Les avantages sont multiples : plus d'effets sont possibles et les unités de shader seront les mêmes d'un point de vue hardware. Mémoire Vidéo Virtuelle Seconde nouveauté, la mémoire vidéo virtuelle. Celle-ci permet plus ou moins de palier aux problèmes de transfert de mémoire entre la RAM et la carte graphique. En effet, la bande passante de l'AGP, voire même du PCI Express, est facilement dix fois plus faible que celle de la carte graphique en interne. Sans entrer dans les détails, ce système est assez proche de celui du processeur, et montre une nouvelle fois que les GPUs se rapprochent de plus en plus des CPUs. L'avantage pour le consommateur : des jeux plus rapides, et quasiment plus aucune limite au niveau des ressources de la carte graphique. Cette fonctionnalité était déjà présente sur les cartes Wildcat VP de 3DLabs, ce qui leur permet d'accéder à 16 Go de données au maximum. Nouveau Tesselateur L'ancien tesselateur (pour rappel, c'est ce qui génère des vertices afin de "lisser" les modèles) n'a pas eu beaucoup de succès. Une nouvelle version arrive, qui devrait en avoir beaucoup plus, puisque beaucoup plus flexible et possèdant beaucoup plus de fonctionnalités. Ainsi, DirectX Next supportera les surfaces de haut niveau les plus courantes telles que Catmull-Rom, Bezier ou B-Spline, ainsi que bien d'autres. Il est donc probable que les jeux utilisant DirectX Next soient tout en courbes, et que l'on peut finalement dire adieu aux modèles qui ont l'air "découpés". Parfait pour le SLI Comment ça parfait pour le SLI ? Sans entrer dans les détails, les nouvelles fonctionnalités de DirectX - notamment la mémoire vidéo virtuelle - ont de nombreux avantages lorsqu'il s'agit de découper l'affichage en plusieurs morceaux, chaque morceau pouvant ainsi être traité par un GPU différent. Il est donc probable qu'à l'avenir, l'augmentation de performance apportée par SLI soit plus grande que maintenant. Cette architecture où l'affichage est découpé rappelle également celle des cartes graphiques PowerVR. Peut-être verra-t-on un retour de PowerVR sur le marché des cartes graphiques, qui sait. [SIZE=3][COLOR=orangered][B]Conclusion[/B][/COLOR][/SIZE] Ainsi se termine cet article. Nous espérons que la seconde partie aura été plus accessible que la première, et qu'au final vous aurez appris beaucoup de choses. C'était notre premier article pointu sur le monde des cartes graphiques et nous espérons qu'il vous a plu. Si c'est le cas, peut-être y en aura-t-il d'autres. Avec les nouvelles cartes (et les nouvelles consoles) qui arrivent, l'évolution des cartes 3D n'est pas près de s'arrêter, ni même de ralentir. Etant donné que dans ce type d'article nous ne pouvons pas vous donner une note ni même notre avis sur un matériel testé (puisqu'il n'y en a pas), cette conclusion fera également office de glossaire. Si vous avez des questions, n'hésitez pas à les poser sur le forum dans le topic dédié à cet article. [B]Glossaire[/B] [B]Alpha :[/B] la composante alpha fait partie des couleurs et est une composante générique qui peut contenir n'importe quelle information, contrairement aux composantes rouge, vert et bleu. Elle est généralement utilisée pour des effets de transparence. [B]Anti-aliasing : [/B]l'anti-aliasing consiste à atténuer les effets d'escalier en effectuant plusieurs fois le rendu de la scène ou en effectuant le rendu dans une plus haute résolution. [B]Deferred rendering :[/B] une technique consistant à reporter certains calculs à la fin du processus d'affichage afin de réaliser ces calculs sur l'image complète de la scène. [B]Filtrage anisotropique :[/B] un filtrage des textures afin de ne pas voir les pixels comme si il s'agissait de gros blocs lorsque la texture est proche. L'avantage du filtrage anisotropique sur les anciens types de filtrage est qu'il y a moins de déformation lorsque les pixels sont à une certaine profondeur, offrant ainsi un meilleur rendu. [B]Frame buffer :[/B] le frame buffer contient les pixels qui vont être affichés à l'écran. C'est dans ce tampon qu'ils sont mis juste avant d'être affichés. Il est également possible qu'une texture soit utilisée comme frame buffer. Dans ce cas, l'affichage se fait sur la texture, qui peut par la suite être utilisée normalement. [B]Pixel shader : [/B]c'est un programme exécuté par le pixel pipeline programmable, qui va pouvoir modifier chaque pixel qu'il reçoit. Il existe plusieurs versions offrant diverses possibilités. [B]Primitive : [/B]une primitive est une forme géométrique de base : un point, une ligne, un triangle. Ces primitives sont formées de plusieurs vertices, un par sommet. Elles forment la base du rendu 3D. [B]Stencil buffer :[/B] le tampon brouillon. Il contient des valeurs génériques, chacune associée à un pixel du frame buffer (voir plus haut). Ces valeurs peuvent être utilisées pour de nombreuses choses, mais le plus souvent c'est pour créer des ombres. [B]Surface de haut niveau : [/B]une surface de haut niveau possède un rôle similaire à celui des primitives. Cependant, au lieu de décrire une surface à l'aide de plusieurs primitives, une formule mathématique est utilisée. De cette façon, la position de tous les points de la surface est connue, contrairement aux primitives où seule la position des sommets est connue. [B]Texel : [/B]vient du terme "texture pixel", il s'agit simplement des pixels d'une texture. En général, lorsqu'une texture est utilisée, la position des texels ne correspond pas à celle des pixels à l'écran, et la carte graphique doit interpoler les valeurs. [B]Texture :[/B] une surface contenant des données. La plupart du temps, ces données représentent des couleurs. Elles peuvent cependant avoir n'importe quelle signification. [B]Vertex :[/B] un groupe de données concernant le sommet d'une primitive : sa position, sa couleur, etc. Ces vertices sont envoyés à la carte graphique qui va les transformer et assembler des primitives. [B]Vertex shader :[/B] c'est un programme exécuté par le vertex pipeline programmable, qui va pouvoir modifier chaque vertex qu'il reçoit. Il existe plusieurs versions offrant diverse possibilités. [B]Viewport :[/B] une forme définissant de quelle manière une scène, qui est en 3D, est affichée dans une fenêtre qui est quant à elle en 2D. [B]Z-buffer :[/B] le tampon de profondeur. Il stocke la profondeur de chaque pixel présent sur le frame buffer (voir plus haut). Il est utilisé principalement pour savoir si un pixel doit être affiché ou non. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- [Post 2] Auteur : kyro Date : 11-05-2005 19:06 superbe cet article, du magnifique boulot qui vient de [URL=http://www.matbe.com/articles/cg/gpu/page10.php]www.matbe.com[/URL] et encore ce n'est que la premiere partie §love3§ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- [Post 3] Auteur : Zakath Date : 11-05-2005 22:47 Bravo ! J'ai parcouru en diagonale et ça a l'air vraiment intéressant. Tu peux être sûr que je lirai ça dans le détail dès que j'ai le temps ! -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- [Post 4] Auteur : soul^keeper Date : 21-06-2005 14:55 ok ok.... mais kyro, juste un truc.... tu as hot-linké toutes les images du site d'origine... c'est mal 8-)... si tu recopies l'article, il faut que tu héberges toutes les images ailleurs, par ex sur imageshack.us... de plus agir comme cela est la meilleure manière de se faire pister en 2 temps 3 mouvements, car ils vont voir énormément de hits en provenance du forum.... si l'article est ©, y'aura bien un gars de chez eux pour nous chercher des poux... Linker à la limite UNE image de temps à autre, ça peut passer, mais pour des dizaines d'images comme ici, là faut vraiment éviter. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- [Post 5] Auteur : kyro Date : 21-06-2005 15:26 ouais tu as raison j'y pensé justement pendant que je faisais la copie ... de plus si un jour matbe.com décide de changer d'emplacement leurs images on aurrait plus rien qui s'afficherait ici :-\ pas grave je vais toutes les copier sur mon espace perso ... §tournis2§ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-