voilla j´ais trouver un truc interresant au sujet du vertex shader de la x-box et des carte 3d actuelle.
je serrais interresser de conaitre votre avis sur ce texte (www.onversity.com)qui est je pense tres serieu
ANALYSES et ACTUALITÉS Août
2002
To be or not to be vertex shader ?
Optimisation de programmation
--------------------------------------------------
---------
---------------------
To be or not to be vertex shader ?
Informatique Ecrit par JF Maquiné le 02 Août 2002
Les calculs nécessaires pour produire une animation 3D peuvent se scinder en 2 groupes : les calculs de géométrie et les calculs de rendu. Les premiers sont dévolus au microprocesseur de l´ordinateur et les seconds au processeur graphique. Toutefois, depuis 1999, on a intégré dans les processeurs graphiques 3D ludiques (dont les GeForce 256 et Savage 2000 furent les premiers) des unités de géométrie. Aujourd´hui, des processeurs comme le R300 d´ATI équipant l´ATI 9700, disposent d´une unité de géométrie programmable, le vertex shader, d´unités pour modifier la tessalation et du displacement mapping.
Le fait de déporter une partie des calculs de géométrie vers le processeur graphique permet d´optimiser certaines tâches et de soulager le microprocesseur principal. Ce transfert de calcul, du microprocesseur vers le processeur graphique, est présenté comme une évolution importante par les constructeurs de carte graphique. Toutefois, cette démarche ne va pas de soi et si elle est fortement contestée par certains développeurs qui souhaiteraient conserver l´ensemble des calculs de géométrie pour le microprocesseur de l´ordinateur, quasiment tous s´accordent à dire que des fonctions comme le truform ou le displacement mapping posent de sérieux problèmes conceptuels.
Prenons l´exemple du truform qui permet de produire une courbure sur un objet ou un personnage produit par la géométrie de base. Apparemment, c´est super le truform, mais admettons qu´à présent on souhaite faire l´ombre projetée précise de la tête ayant subit le truform, que se passerait-il ? Eh bien l´ombre étant calculée par le microprocesseur de l´ordinateur, le contour de l´ombre aurait un aspect anguleux ! Pourquoi ? Parce que lorsqu´une fonction comme le truform modifie la géométrie, elle n´informe pas le microprocesseur de l´ordinateur des modifications effectuées. On a un problème similaire avec le displacement mapping et la gestion des collisions.
Y a-t-il une solution ? On pourrait penser qu´il suffirait de tranférer les modifications de géométrie faites par le processeur graphique vers le microprocesseur, mais l´architecture des ordinateurs serait incapable de supporter ces tranferts d´information supplémentaire. C´est en mettant le doigt sur ce genre de problème que certains développeurs souhaitent un retour des calculs de géométrie vers le microprocesseur, d´autant plus qu´il existe à présent un exemple célèbre, la console de jeux PS2. Effectivement, celle-ci centralise la totalité des calculs sur ses processeurs vectoriels et le processeur graphique n´est qu´un processeur de rendu.
Alors, il n´y a pas de solution ? En fait, ce qui pose problème ce sont les calculs d´ombre et plus généralement d´éclairage qui se font après modification de la géométrie. La solution consisterait donc à intégrer une unité de calcul d´éclairage dans le processeur graphique. Cela justifierait d´autant plus la présence actuelle de fonctions comme le truform ou le displacement mapping, mais ne résoudrait pas tous les problèmes. Ainsi les collisions poseraient toujours un problème insoluble dans la mesure où ces calculs ne peuvent être exécutés que par le moteur de jeux 3D qui lui s´exécute dans le microprocesseur de l´ordinateur. Et ça, même dans 10 ans, on est pas près de pouvoir intégrer un moteur de jeux 3D dans un processeure graphique.
Il n´empêche que l´intégration d´une unité de calcul d´éclairage et d´ombrage dans les processeurs graphiques semble inévitable à terme. Toutefois, c´est là un défit important car ces calculs sont complexes et leur intégration dans un microprocesseur se heurte non seulement à des problèmes algorithmiques mais aussi à la technologie de fabrication des processeurs actuels qui ne permet pas d´intégrer les quelques millions de transistors supplémentaires nécessire à cette fonction.
Alors, le ray-tracing dans les processeurs graphiques ? Pas impossible, mais il faudra attendre un peu avant de voir des solutions efficaces et exploitables. De même que le filtrage anisotropique ou le FSAA sont apparus en 1999, il a fallu attendre la nouvelle génération de processeur graphique de cette année (R300, NV30) pour pouvoir les exploiter correctement. Alors oui pour le ray-tracing ou quelque chose de semblable, mais pas exploitable vraiment avant 2004/2005. Mais bon vu la concurrence acharnée que se livre ATI et Nvidia en ce moment il n´est pas impossible que . . . bah, qui vivra verrra ; )
t´aurais pas pu faire plus long c trop court
