A l'occasion du salon Siggraph 2004 (salon de l'image de synthèse, aux USA), a été présenté aux développeurs la version finale de ce qui sera présent dans OpenGL 2.0.
Après plusieurs mois de travail, l'ARB (architecture review board, qui dirige l'évolution du standard OpenGL) a entériné les différentes propositions qui lui ont été faites pour inclusion dans cette nouvelle version de l'API. L'évolution majeure de cette API concerne les derniers effets à la mode dans les cartes vidéos, à savoir les "shaders". C'est à dire des programmes exécutés par le GPU (processeur de la carte graphique), et modifiant le rendu des polygones affichés. Deux avantages: d'une part on décharge le CPU de ces calculs, et d'autre part, le rendu est plus réaliste (un polygone n'est plus plat comme avec du bump mapping, mais est réellement gondolé visuellement).
Auparavant, l'utilisation de ces capacités devait se faire au travers des fameuses extensions OpenGL différentes selon les constructeurs qui l'implémentaient spécifiquement pour leurs cartes, de manière incompatibles entre elles. Maintenant, tout le monde utilisera une interface unique pour gérer ces "shaders".
- Multiple render targets:
Pour ces "shaders", ceux-ci pourront effectuer leur rendu dans différents buffers, en une seule passe.
- Non power of two textures:
Les dimensions des textures n'ont plus à être des puissances de 2 (là aussi présentes sous formes d'extensions pour certaines cartes vidéos).
- 2-sided stencil:
Deux opérations différentes pourront être effectués sur le tampon de stencil, l'une sur les faces avant, l'autre sur les faces arrières. C'est utilisé pour les ombres volumétriques, comme dans Doom 3 par exemple.
- Point sprites:
C'est utilisé pour dessiner les effets de particules, ou l'on a beaucoup d'objets identiques à dessiner.
L'un des autres intérêts de OpenGL 2.0 est de définir de cette manière un ensemble de fonctions qui seront à coup sûr supportés par les cartes vidéos et leurs drivers, et donc simplifiera le travail des programmeurs, qui n'auront plus à gérer autant d'extensions pour utiliser les cartes actuelles. C'est particulièrement important sous Windows, où l'on n'a accès directement qu'aux fonctions OpenGL 1.1, tout le reste devant s'effectuer par l'usage des extensions.
Et c'est plus simple d'écrire 'OpenGL 2.0 minimum' sur la boîte de DukeQuake 12, car on sait qu'il tournera bien sur une carte qui le supporte (ça c'est pour le côté marketing de la chose).
Aller plus loin
- Tout sur OpenGL (23 clics)
- L'annonce sur le site de Silicon Graphics (7 clics)
- Mesa, une implémentation libre de OpenGL (4 clics)
- Le Siggraph 2004 (2 clics)
- L'ARB (et résumés de ses conférences: meeting notes) (1 clic)
- Les ombres volumétriques par le tampon stencil (3 clics)
# un peu en retard pour doom3...
Posté par _ . Évalué à -2.
[^] # Re: un peu en retard pour doom3...
Posté par Fouki . Évalué à 4.
On peut dire en quelque sorte que les devellopeurs on fait 2 fois plus de boulots...
[^] # Re: un peu en retard pour doom3...
Posté par Patrice Mandin . Évalué à 4.
Vu sur linuxgames:
C'est aussi l'avis des développeurs de NeverwinterNights 2, pour lequel le retard dans la définition de OpenGL 2.0 (et des drivers correspondant) ne permet pas le développement d'un moteur de rendu l'utilisant, et le fait de programmer pour OpenGL 1 (avec les extensions spécifiques à chaque constructeur) prend beaucoup de temps:
http://forums.obsidianent.com/index.php?showtopic=2607&view=fin(...)
[^] # Re: un peu en retard pour doom3...
Posté par tuan kuranes (site web personnel) . Évalué à 3.
?? faut pas exagerer. Developper un jeu en OpenGL est tout a fait possible actuellement (Doom III ?)
Les extensions ne sont pas si rebutantes que ca, C'est quand meme assez rapide a utiliser et implementer.
Ce qui prend le plus de temps, c'est bien de developper en fonction de chaque generation de cartes graphiques... et La il y a plus que deux fois plus de boulot (Nvidia, Ati, Intel, matrox, powerVR)
La memoire video dispo, vitesse AGP, le nombre d'unites de texture dispo (rendu simple passe, multipasses), les differents paths de rendu selon les cartes (avec shaders, registers, etc...), les optimisations specifiques aux cartes video (vertex cache ou pas, Triangle stripping ou pas, etc...)
Et ce probleme est commun a Direct3d et OpenGL.
Exemple : L'excellent moteur 3D LGPL "Ogre"permets l'utilisation de DirectX et OpenGL (avec ses extension) et le plus problematique, c'est bien le support de toutes les cartes graphiques, voire des differentes version de drivers, pas les extensions !
[^] # Re: un peu en retard pour doom3...
Posté par Mark Havel . Évalué à 1.
[^] # Re: un peu en retard pour doom3...
Posté par Krunch (site web personnel) . Évalué à 5.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: un peu en retard pour doom3...
Posté par Yusei (Mastodon) . Évalué à 6.
[^] # Re: un peu en retard pour doom3...
Posté par GhZaaark3 . Évalué à 1.
tu oublies les cartes XGI, une rumeur disait qu'ils allaient filer leur specs.
[^] # Re: un peu en retard pour doom3...
Posté par Rémi Hérilier . Évalué à 2.
1/ ils sont (quasiment) les seuls à ajouter des extensions à OpenGL
Cf http://www.delphi3d.net/hardware/allexts.php(...)
2/ les applications OpenGL bien conçues font une truc du genre :
si extension ATI
l'utiliser
sinon
si extension NVidia
l'utiliser
sinon
si extension ARB
l'utiliser
sinon
utiliser une astuce ou renvoyer un message d'erreur
XGI, pour sa part, ne fais que suivre les specs énoncés par l'ARB (aucune extension au préfixe GL_XGI). Développer seulement avec les extensions ARB, ça marchera de partout (où c'est supporté bien sûr;) mais pourquoi défavoriser ceux qui ont une ATI ou une Nvidia ?
Donc pas de soucis à avoir : les programmes de Mark Havel marcheront surement sur une XGI. Après, tout n'est qu'une question de puissance de calcul ;)
[^] # Re: un peu en retard pour doom3...
Posté par GhZaaark3 . Évalué à 1.
Oui mais est-ce qu'ils fournissentl vraiment des pilotes ouverts?
enfin, j'pense qu'on en aurait fait une dépêche si c'était le cas...
doux rêve...
[^] # Re: un peu en retard pour doom3...
Posté par Rémi Hérilier . Évalué à 2.
Qui ? l'ARB énoncent des specs qui sont publiées sur http://www.opengl.org(...) et n'importe qui est libre de développer ses propres pilotes ouverts (Cf MesaGL). Si c'est de XGI dont tu parles, je n'en sais absolument rien. Il faudrait que tu retrouves tes fameuses rumeurs et chercher à partir de là.
Personnellement, je ne vois ce que la diffusion des specs des GPUs XGI va changer au développement graphique basé sur OpenGL ?!
# details
Posté par tuan kuranes (site web personnel) . Évalué à 10.
Ca, c'est juste unes des utilisations des shaders, plus precisement ici, des vertex shaders. C'est la technique dite du "displacement mapping".
Les shaders sont divises en deux parties : une pour traiter les vertex (les points des polygones) et une pour les pixels, donc les effets de textures.
L'avantage d'OpenGL 2.0, c'est aussi de presenter un langage haut niveau (genre C) pour programmer les shaders.
Avant fallait passer par de l'assembleur, qui restait tres simple touttefois. Ou par des langages appartenant a ATI ou Nvidia. Ici le nouveau langage GLSL est de haut niveau et le meme pour toutes les cartes supportant OpenGL 2.0.
OpenGL 2.0 est un peu decevant car juste c'est juste une compilation des differentes extensions... Pas de nouveautes revolutionnaires, donc.
Un OpenGL plus modulaire, et facile a decliner aurait ete bien.
(plutot que plusieurs openGL separes : OpenGL OpenGL ES, OpenML, OpenVG, OpenMAx, etc... cf http://www.khronos.org/(...))
[^] # Re: details
Posté par Edouard Gomez (site web personnel) . Évalué à 8.
Faux, le displacement mapping n'utilise pas de vertex shaders, mais des fragment shaders (d'ailleurs il me semble que la litérature OpenGL parle de fragment shaders et non pixel sharders, employé dans Direct3D, détail insignifiant vu que ce sont deux termes différents pour désigner un même ensemble de fonctionnalités).
En effet, lors de displacement mapping, la position des vertex du mesh reste identique, ce qui change c'est le rendu des fragments composant la surface des triangles en utilisant une heightmap map, de telle sorte qu'un pixel n'est pas rendu sur la surface mais à surface+heightmap.n-> où surface représente le fragment de la surface "tel quel" (transformation normale), heightmap la perturbation d'hauteur à appliquer au pixel, et n->, la normale à la surface en ce fragment (lui même pouvant être perturbé par un bump mapping).
Y a un bon article qui explique tout ca brievement:
http://www.delphi3d.net/articles/viewarticle.php?article=bumpmappin(...)
[^] # Re: details
Posté par tuan kuranes (site web personnel) . Évalué à 5.
tu confond deux techniques : le "offset mapping" (anciennement apelle le "parallax mapping" qui utilise les pixels shaders) et le "displacement mapping" (vertex shader).
c'est dit dans ton lien :
displacement mapping : "You could displace vertices by reading the displacement map in the vertex shader and moving the vertex in the direction of its normal."
Parallax mapping : " will give you a proper parallax effect when the camera pans across a surface, but it will not modify your geometry like displacement mapping does"
fragment shader est beaucoup moins parlant que pixel shader.
(puisqu'un fragment shader ne peut modifier que des pixels...)
Il est vrai que les techniques deviennent de plus en plus nombreuses et il est devient difficile de s'y retrouver.
Relis ton lien, ou mieux lis en francais la doc :
http://www.onversity.com/cgi-bin/progactu/actu_aff.cgi?Eudo=bgteob&(...)
[^] # Re: details
Posté par Gaël GUENNEBAUD (site web personnel) . Évalué à 3.
non, selon la terminologie d'OpenGL, le terme "fragment shader" est beaucoup plus approprié puisque qu'il manipule bien des fragments qui sont issues de la rastérization. Un "fragment" ne devient "pixel" que lorsqu'il a passé les différents tests avec succès (effectués après le fragment shader) et qu'il est écrit dans le frame buffer.
[^] # Re: details
Posté par tuan kuranes (site web personnel) . Évalué à 2.
En entree d'un fragement shader : un pixel en rgba (que l'on peut appeler fragment)
en sortie, un pixel en rgba
Entre les deux, des operations sur des pixels en rgba (que l'on peut appeler fragment)
Je critique pas l'appelation OpenGL, mais je la regrette. deja que c'est pas simple, mais si on complique avec des termes inconnus (pixel est plus connu qu'un fragment.)
[^] # Re: details
Posté par Rémi Hérilier . Évalué à 5.
Même en restant que dans le graphisme, les algorithmes à plusieurs passes sont de plus en plus utilisé et ce n'est souvent que la dernière passe qui peut se définir comme traitant des pixels, les autres s'occupant de champs scalaires ou vectoriels quelconques.
Quelques exemples d'applications des gpu (je sais, je parle surtout de recherche:) :
- faire du calcul vectoriel,
- simulation de fluide
- rendu basé sur le lancer de rayons (les textures servent à stocker la géométrie et une table d'index pour accélérer la recherche d'intersection).
D'autre part, avec l'arrivée du support des nombres flottants pour les buffers, on peut aisement représenter autre chose que de simple pixels. De plus, avec la possibilité qu'un shader écrive dans plusieurs buffers en une seule passe (nouveauté de cet ogl2), la sortie ne peut plus vraiment s'appeler un pixel.
Mais bon, ce n'est qu'un avis personnel et je ne sais pas quelles ont été les réelles motivations de l'ARB =)
[^] # Re: details
Posté par tuan kuranes (site web personnel) . Évalué à 2.
on ne peut malheureusement pas utiliser le resultat d'une passe precedente dans un fragment shader. En multitexturing multipasse, en tout cas, On part toujour de fragment.color.
Mais avec les MRT (Mutliples Render Target), ca va peut-etre changer ?
>Quelques exemples d'applications des gpu
C'est pas que de la recherche, sh et autres gpugpu... Dans les jeux on utilise les GPU aussi pour la simulation de fluide (le sang), les simulations physiques de particules (eclats rebondissant, fumee suivant les conduits, etc..), etc...
>Mais bon, ce n'est qu'un avis personnel et je ne sais pas quelles >ont été les réelles motivations de l'ARB =)
Les constructeurs de GPU voudrait utiliser les memes circuits pour calculs de vertex et de fragment (au lieu de float d'un cote et uchar de l'autre). Apres une suite de calculs la perte d'info est grande si on utilise pas des float (meme des float16), donc l'image est plus "vrai", moins approximative.
Les textures elle-memes en float, c'est (malheureusemnet) pas pour tout de suite :
Le probleme reste pour moi la bande passante et la memoire video dans la carte... Deja qu'avec des textures 8 bits (rgba en DXT5) ca rame a mort pour charger toutes les textures (normal, hauteurs, couleurs, tables) qu'est ce que ca va etre avec des textures float32 (128bits) ou float16 (64bits)?
[^] # Re: details
Posté par Rémi Hérilier . Évalué à 4.
SGI (et surement d'autre) en son temps avait bien compris le problème en partageant la mémoire des stations entre système et gpu (ça devait aussi faire quelques économies:). D'ailleurs, je pense que la gpu faisait plus office de coprocesseur (comme les copro arithmétiques du temps des 386sx) que de processeur à part (comme on l'a sur PC).
Mais bon, il n'y a plus grand monde (chez les fabricant de micro info) pour concevoir une nouvelle architecture et l'imposer :-(
À part attendre les prochaines consoles et y mettre un clavier et un linux =)
[^] # Re: details
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Si tu as 2 plans de mémoire, il faut parfois faire des transferts...
"La première sécurité est la liberté"
[^] # Re: details
Posté par Rémi Hérilier . Évalué à 2.
À ton avis, comment les GPUs font-elles pour optimiser leurs accès mémoire (mémoire embarquée sur la carte graphique bien sûr:) alors qu'elles ont plusieurs unités de texture qui fonctionnent en parallèle ? Elles utilisent tout simplement une architecture qui permet à n processeurs d'accéder à m modules de mémoire et cela en parallèle et de façon non bloquante. Pas mal non ? Ce système porte le joli nom de crossbar =)
Un lien assez intéressant : http://www.interex.org/hpworldnews/hpw806/hpux/02hpux.html(...)
En cherchant sur les moteurs de recherches, tu trouveras pas mal d'exemples d'utilisation du crossbar (en gros, tout ce qui est parallélisme métériel).
Pour info, la Xbox utilise un système de type crossbar. Cela explique partiellement qu'elle est plus rapide qu'un PC de configuration équivalente.
Qu'appelles-tu plans de mémoire ?!
[^] # Re: details
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
hum comment dire...
Pour faire simple et se mettre au niveau (et dans le désordre):
Une puce dispose globalement d'un nombre d'entrée sortie limité, un gros packaging, cela coute chère (BGA vs tqfp). Donc, pour un cout donné, tu es limité en nombre de pin.
Si tu utilises un cross-bar une mémoire même plusieurs banque et 1 CPU + 1 GPU, il te faut : 3 chips, le cross-bar -> 1 entrée GPU, 1 entrée CPU (2*64 bits mini (lien hypertransport 32 bits)), + nentrée par banques si on prend l'archi des GPU, 4 banques de 64 bits soit 4*64+4*25+4*4 (data/adresse/contrôle) =128+372 = 500 pin.
Sachant que vu la conso, il y a 1/3 de pin d'alim, on un cross-bar de 700 pin. Cela fait donc une puce énorme. Soit bien plus que les north bridge actuel.
(Pour rappelle le north bridge PC fait le lien entre le CPU avec le bus FSB, la mémoire avec un bus DDSDRAM, le GPU avec l'AGP et le south bridge avec le pci ou l'hypertransport ou un truc proprio, c'est donc en fait un gros switch...)
Quand l'athlon 64/opteron est arrivé, il utilise un controleur mémoire dans le cpu à la place du northbridge ainsi la latence mémoire passe de 150/180 à 100/120 cycle. C'est la principale raison des performances de ses puces en comparaison des puces précédentes.
L'opteron est connecter par hypertransport à une autre puce qui est elle-même connecté à l'agp connecté au GPU connecté à sa mémoire.
Le GPU utilise 372 pins pour la mémoire (256 bits, 4 banques) et 100 pour l'agp. (472 pin)
Un opteron utilise 180 pins pour la mémoire (128 bits) et 1 ou 3 hypertransports à 2*16 bits. (276 pins)
Le "south bridge" entre les 2 ne fait que de la recopie et n'est même pas un switch.
Pour une version cross bar, il faut le cross-bar au milieu. En plus, avec plus de 700 pins. Plus ? Ben oui, il faut avoir la même bande passante il faut donc rajouter 180 pins... et les pins d'alim associé... et on arrive tranquillement à 1000 pins. Et pour faire quoi ?
Certe on évite les dialogues par bus agp. Mais très peu de donnés sont en faite partagé entre le cpu et le GPU. Et le cross bar rajoute de la latence.
En fait ton archi existe déjà : la plus part des chip graphique intégré, utilise la mémoire central. Les premier n-force utilisait ainsi un bus de 128 bits pour ne pas trop pénalisé le cpu qui se voyait bouffer sa bande passante mémoire. Bref, je ne crois pas que cela soit les solutions les plus rapide...
Il vaut mieux mettre 2 puces ayant chacune leur mémoire, que 2 puces passant par une troisième surtout quand il y a une si grande localité d'acces.
Et puis franchement, tu as vu les perf des stations de travail à comparrer avec un x86 haut de gamme ? A part en calcul flottant, les stations hyper chère se font complètement distancer.
"La première sécurité est la liberté"
[^] # Re: details
Posté par Jimmy . Évalué à 2.
J'aime bien ce genre de détournement d'une technologie pour faire une autre application, ca va bien avec les LL ;-)
[^] # Re: details
Posté par Krunch (site web personnel) . Évalué à 2.
http://developers.slashdot.org/article.pl?sid=03/12/21/169200(...)
http://developers.slashdot.org/article.pl?sid=04/05/09/039204(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: details
Posté par tuan kuranes (site web personnel) . Évalué à 3.
http://libsh.org/download.html(...)
[^] # Re: details
Posté par Rémi Hérilier . Évalué à 10.
Pour info, cette version d'ogl n'est que transitoire. La vrai version 2 d'ogl sera la prochaine (appelée "pure" OpenGL 2) et qui perdra toute compatibilité avec les versions d'ogl existantes.
Au programme (de mémoire car 3dlabs à supprimé les white paper de son site)):
- un refonte de l'API,
- 2 unités programmables supplémentaires (pour l'envoi et la réception de données vers et depuis ogl2),
- une généralisation du concept de buffer (Cf ce que l'on nomme super_buffer ou über_buffer selon les pages oueb),
- des primitives pour de la gestion de mémoire,
- des primitives pour jouer avec le caractère synchrone et asynchrone d'ogl2.
Pour un bref résumé de l'histoire : http://www.romulus2.com/articles/guides/opengl2/ogl1.shtml(...)
[^] # Re: details
Posté par Thierry Van Elsuwé (site web personnel) . Évalué à 2.
[^] # Re: details
Posté par Rémi Hérilier . Évalué à 1.
/me qui croise les doigts ...
[^] # Re: details
Posté par Thierry Van Elsuwé (site web personnel) . Évalué à 2.
Voici un lien qui va dans ce sens:
http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cg(...)
# ET les autres SE ?
Posté par Bruce Le Nain (site web personnel) . Évalué à 4.
[^] # Re: ET les autres SE ?
Posté par gS . Évalué à 6.
Je crois que les drivers ATI faisant la meme chose ne devraient pas tarder (si ils ne sont pas deja sortis).
La version du driver que j'ai installé: 1.0.6111
Pour verifier si vos drivers (et votre carte supporte) le langage de shader:
glxinfo |grep GL_ARB_shading_language_100
Il me semble que les cartes nvidia qui le supportent sont les gammes FX (a partir de la FX5200) et les cartes ultérieures. Chez ATI, je crois aque c'est a partir de la Radeon 9500, mais c'est de mémoire, a verifier...
Les modeles précédents peuvent également etres programmée (fragment & vertex) mais en assembleur ou en utilisant un SDK comme le Cg de NVidia. Je ne parle ici que du langage de haut niveau intégé dans la lib OpenGL (GLSL).
a++
Guillaume.
[^] # Re: ET les autres SE ?
Posté par gS . Évalué à 5.
Ca vas offrir des possibilités fantastiques pour le développement des applis mais ca complique pas mal l'écriture des drivers (qui doivent intégrer a présent un compilateur et un linker, rien que ca...). Mais heureusement, 3DLabs a mis a la disposition du plublic une implémentation de référence des ces deux outils pour simplifier les choses et surtout pour que les compilateur interpretent bien tous le code de la meme façon.
voilivoila,
a++
Guillaume.
[^] # Re: ET les autres SE ?
Posté par Bruce Le Nain (site web personnel) . Évalué à 2.
# Et les brevets Microsoft?
Posté par Patrix (site web personnel) . Évalué à 2.
Rappels:
http://www.zdnet.fr/actualites/technologie/0,39020809,2119029,00.ht(...)
http://linuxfr.org/2002/07/14/8969.html(...)
[^] # Re: Et les brevets Microsoft?
Posté par Krunch (site web personnel) . Évalué à 4.
http://developers.slashdot.org/comments.pl?sid=103472&cid=88163(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.