jeudi 24 juillet

Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

Articles précédents : Articles

Liens connexes

Tout sur OpenGL (2046 hits)
L'annonce sur le site de Silicon Graphics (614 hits)
Mesa, une implémentation libre de OpenGL (762 hits)
Le Siggraph 2004 (404 hits)
L'ARB (et résumés de ses conférences: meeting notes) (370 hits)
Les ombres volumétriques par le tampon stencil (872 hits)

Dépêche modérée par

penso

Dépêche éditée par

Yusei

Articles : La spécification de OpenGL 2.0 enfin en version finale

Posté par Patrice Mandin (page perso, ). Modéré le 15 août 2004.

OpenGL est une API créée par Silicon Graphics à partir de l'API IrisGL qui lui était propre. Cela dans le but d'avoir une API unique pour la programmation d'applications graphiques.

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.

Tout sur OpenGL (2046 hits)
L'annonce sur le site de Silicon Graphics (614 hits)
Mesa, une implémentation libre de OpenGL (762 hits)
Le Siggraph 2004 (404 hits)
L'ARB (et résumés de ses conférences: meeting notes) (370 hits)
Les ombres volumétriques par le tampon stencil (872 hits)

> Lire la dépêche (35 commentaires, moyenne: 3,4).

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).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

[+] un peu en retard pour doom3...

Posté par paul brauner () le 15/08/2004 à 12:27. (lien). Évalué à -2.

mais c'est la fête o// \\o \o/

[^]Re: un peu en retard pour doom3...

Posté par Fouki () le 15/08/2004 à 13:59. (lien). Évalué à 4.
C'est plus ou moins faux car Doom 3 utilise la plupart des fonctions de l'Open GL 2.0 mais par les extention "spécifique" de nVidia & ATI :)
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 (page perso, ) le 15/08/2004 à 22:48. (lien). Évalué à 4.
  On peut dire en quelque sorte que les devellopeurs on fait 2 fois plus de boulots...
  
  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(...)
  
  --
  Programmeur Linux, Atari
  Developpement, jeux
  - [^]Re: un peu en retard pour doom3...
    
    Posté par tuan kuranes (page perso, ) le 16/08/2004 à 07:19. (lien). Évalué à 3.
    >permet pas le développement d'un moteur de rendu l'utilisant
    
    ?? 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 () le 16/08/2004 à 21:20. (lien). Évalué à 1.
      A ma connaissance PowerVR est un peu mort, Matrox n'est plus sur les cartes de joueurs et Intel ne le sera probablement jamais. Personnellement, en tant que développeur, je me focaliserais à l'heure actuelle sur le support Ati et nVIDIA sans trop me poser de question au sujet des autres (sauf pê Intel, parce qu'il a une belle part de marché avec ses chips intégrés).
      - [^]Re: un peu en retard pour doom3...
        
        Posté par Krunch (Jabber id, page perso, ) le 17/08/2004 à 00:16. (lien). Évalué à 5.
        Et après je me demande pourquoi les jeux les plus "simples" s'affichent incorrectement sur ma S3...
        
        --
        Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
        pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
      - [^]Re: un peu en retard pour doom3...
        
        Posté par Yusei (page perso, ) le 17/08/2004 à 09:40. (lien). Évalué à 6.
        Ça ressemble étrangement au raisonnement des webmasters qui font leur site pour IE... :-)
      - [^]Re: un peu en retard pour doom3...
        
        Posté par GhZaaark3 () le 17/08/2004 à 14:49. (lien). Évalué à 1.
        je me focaliserais à l'heure actuelle sur le support Ati et nVIDIA sans trop me poser de question au sujet des autres
        
        tu oublies les cartes XGI, une rumeur disait qu'ils allaient filer leur specs.
        
        --
        moué...
        
        [^]Re: un peu en retard pour doom3...
        
        Posté par Rémi Hérilier (page perso, ) le 17/08/2004 à 17:50. (lien). Évalué à 2.
        Mark Havel me semble plutôt développer des applications OpenGL. Focaliser son dev sur les ATI/Nvidia, c'est on ne peut plus normal et cela, pour 2 raisons :
        
        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 () le 18/08/2004 à 15:06. (lien). Évalué à 1.
        XGI, pour sa part, ne fais que suivre les specs énoncés par l'ARB
        
        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...
        
        --
        moué...
        
        [^]Re: un peu en retard pour doom3...
        
        Posté par Rémi Hérilier (page perso, ) le 18/08/2004 à 16:45. (lien). Évalué à 2.
        Oui mais est-ce qu'ils fournissentl vraiment des pilotes ouverts?
        
        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 (page perso, ) le 15/08/2004 à 12:48. (lien). Évalué à 14.

" 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)"

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 (page perso, ) le 15/08/2004 à 13:03. (lien). Évalué à 8.
Ca, c'est juste unes des utilisations des shaders, plus precisement ici, des vertex shaders. C'est la technique dite du "displacement mapping".

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 (page perso, ) le 15/08/2004 à 13:41. (lien). Évalué à 5.
  "Faux, le displacement mapping"
  
  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 (page perso, ) le 15/08/2004 à 16:12. (lien). Évalué à 3.
```
fragment shader est beaucoup moins parlant que pixel shader. 

(puisqu'un fragment shader ne peut modifier que des pixels...)
```
    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 (page perso, ) le 15/08/2004 à 16:39. (lien). Évalué à 2.
      Les deux appellations se defendent, utiliser le terme fragment ne fait que compliquer a mon avis...
      
      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 (page perso, ) le 15/08/2004 à 22:11. (lien). Évalué à 5.
        Je trouve justement que le terme de fragment convient très bien. Au delà de l'idée qu'une carte graphique ne sert qu'à faire du graphisme, elle est surtout une unité de calcul d'une puissance inégalable par un cpu.
        
        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 (page perso, ) le 16/08/2004 à 04:57. (lien). Évalué à 2.
        >Même en restant que dans le graphisme, les algorithmes à >plusieurs passes sont de plus en plus utilisé
        
        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 (page perso, ) le 16/08/2004 à 13:18. (lien). Évalué à 4.
        La bande passante est en effet un énorme problème mais ce n'est pas le système graphique qui est en cause mais l'architecture du PC (je ne suis jamais allé voir dans les Macs) : ce "fichu" bus intermédiaire (agp, pci-x) entre le système central et le système graphique.
        
        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 () le 18/08/2004 à 11:42. (lien). Évalué à 1.
        si tu utilises la même mémoire pour le cpu et le gpu globalement tu divise la bande passante mémoire par 2.
        
        Si tu as 2 plans de mémoire, il faut parfois faire des transferts...
        
        [^]Re: details
        
        Posté par Rémi Hérilier (page perso, ) le 18/08/2004 à 16:36. (lien). Évalué à 2.
        Diviser la bande passante ? C'est en effet ce qui arrive si on utilise un simple bus comme celui du PC.
        
        À 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 () le 27/08/2004 à 15:48. (lien). É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.
        
        [^]Re: details
        
        Posté par Jimmy (page perso, ) le 16/08/2004 à 19:23. (lien). Évalué à 2.
        Est-ce que tu as des exemples d'applications pratiques du GPU comme coprocesseur pour des calculs autres que graphiques ? Ca pourrait effectivement être d'une grande efficacité pour certaines formes de calcul vectoriel (Matlab/Scilab). A quand un plug-in pour POV, pour Scilab ou bien pour un logiciel de CAO ?
        
        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 (Jabber id, page perso, ) le 17/08/2004 à 00:26. (lien). Évalué à 2.
        L'utilisation des GPU pour autre chose que du graphisme a déjà été discuté plusieurs fois sur Slashdot, voici les deux premiers articles que j'ai retrouvé:
        http://developers.slashdot.org/article.pl?sid=03/12/21/169200(...)
        http://developers.slashdot.org/article.pl?sid=04/05/09/039204(...)
        
        --
        Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
        pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
        
        [^]Re: details
        
        Posté par tuan kuranes (page perso, ) le 17/08/2004 à 07:16. (lien). Évalué à 3.
        http://www.gpgpu.org/(...)
        http://libsh.org/download.html(...)

[^]Re: details

Posté par Rémi Hérilier (page perso, ) le 15/08/2004 à 16:28. (lien). Évalué à 10.
OpenGL 2.0 est un peu decevant car juste c'est juste une compilation des differentes extensions... Pas de nouveautes revolutionnaires, donc.

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é (page perso, ) le 15/08/2004 à 21:56. (lien). Évalué à 2.
  A ce que je sache, c'est parce que cela a été abandonné que les white paper ont été supprimés du site. Ceci dit, certaines idées venant des ces white paper sont déjà reprises dans cette nouvelle version (+/- VBO, GLSL) et d'autres sont en cours (+/- PBO).
  - [^]Re: details
    
    Posté par Rémi Hérilier (page perso, ) le 15/08/2004 à 22:48. (lien). Évalué à 1.
    Te souviens-tu de où tu avais lu ça ? Je ne trouve rien de plus récent que juillet 2003 (des posts sur le forum de gamedev.net):
    
    /me qui croise les doigts ...
    - [^]Re: details
      
      Posté par Thierry Van Elsuwé (page perso, ) le 16/08/2004 à 08:57. (lien). Évalué à 2.
      Malheureusement non. Je ne me rappelle pas avoir lu une déclaration ferme. Mon impression vient de faits cumulés (rapport des meeting ARB, lecture de news/forum sur opengl.org, de conversations avec d'autres développeurs OpenGL et le fait que la page ait justement disparue).
      
      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 (Jabber id, page perso, ) le 16/08/2004 à 08:17. (lien). Évalué à 4.

Linux, BSD et les autres ? Ça va aider au développement des applis 3D ? Est-ce que ça permettra de développer plus facilement des pilotes de cartes video ?

--
Hôdo
Livingstone

[^]Re: ET les autres SE ?

Posté par gS () le 16/08/2004 à 11:16. (lien). Évalué à 6.
Certainement, en tout cas, les derniers drivers nvidia (proprios, ok, ok,...) permettent de programmer les shaders. Ils sont compatibles OpenGL 1.5 mais ca le fait deja. J'ai testé, ca fonctionne, le driver integre le compilateur et le linker.
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 () le 16/08/2004 à 11:23. (lien). Évalué à 5.
  Une petite précision sur mon message précédent:
  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 (Jabber id, page perso, ) le 17/08/2004 à 13:50. (lien). Évalué à 2.
    merci pour cette réponse claire et complete ;)
    
    --
    Hôdo
    Livingstone

Et les brevets Microsoft?

Posté par Patrix (page perso, ) le 16/08/2004 à 09:13. (lien). Évalué à 2.

Quelqu'un sait-il où on en est avec les droits revendiqués par Crimosoft sur OpenGL?
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 (Jabber id, page perso, ) le 17/08/2004 à 00:40. (lien). Évalué à 4.
Je crois qu'ils ont un peu abandonné l'idée: http://www.theregister.co.uk/2003/03/03/microsoft_quits_opengl_boar(...)
http://developers.slashdot.org/comments.pl?sid=103472&cid=88163(...)

--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.

Revenir en haut de page

Articles précédents : Articles

Liens connexes

Dépêche modérée par

Dépêche éditée par

Articles : La spécification de OpenGL 2.0 enfin en version finale

[+] un peu en retard pour doom3...

[^]Re: un peu en retard pour doom3...

[^]Re: un peu en retard pour doom3...

[^]Re: un peu en retard pour doom3...

[^]Re: un peu en retard pour doom3...

[^]Re: un peu en retard pour doom3...

[^]Re: un peu en retard pour doom3...

[^]Re: un peu en retard pour doom3...

[^]Re: un peu en retard pour doom3...

[^]Re: un peu en retard pour doom3...

[^]Re: un peu en retard pour doom3...

details

[^]Re: details

[^]Re: details

[^]Re: details

[^]Re: details

[^]Re: details

[^]Re: details

[^]Re: details

[^]Re: details

[^]Re: details

[^]Re: details

[^]Re: details

[^]Re: details

[^]Re: details

[^]Re: details

[^]Re: details

[^]Re: details

[^]Re: details

ET les autres SE ?

[^]Re: ET les autres SE ?

[^]Re: ET les autres SE ?

[^]Re: ET les autres SE ?

Et les brevets Microsoft?

[^]Re: Et les brevets Microsoft?