Spécifications de OpenGL 4.0

Posté par  . Modéré par baud123.
Étiquettes :
28
3
mai
2010
Technologie
Le Khronos Group (consortium de standards ouverts) a annoncé la sortie de OpenGL 4.0 le 10 mars 2010 sous forme de PDF de 489 pages et 2.8 Mo. Pour mémoire, OpenGL, pour Open Graphics Library, est une spécification qui définit une API d'imagerie 3D et 2D, pour les ordinateurs allant du mobile au super-calculateur, en passant bien évidemment par le jeu vidéo.

Cette version 4.0 apporte son lot de nouveautés :
  • Amélioration de l'interopérabilité avec OpenCL, sans recourir au CPU ;
  • Amélioration du rendu via le passage des opérations en virgule flottante du format simple précision au format double précision ;
  • Et, bien sûr, le très attendu (essentiellement par les programmeurs de jeux) support de la tessellation ! La tessellation est le pavage en français ou encore tiling en anglais. OpenGL la proposait déjà mais seulement via une extension fournie par AMD donc uniquement disponible pour les cartes ATI compatibles. OpenGL rattrape ainsi DirectX 11 qui propose déjà la tessellation. Par exemple, ce journal de début d'année sur DLFP évoquait les différences entre bibliothèques de jeux.


OpenGL 3.3 a été livré à la même occasion, ayant pour but de rétroporter un maximum de nouveautés 4.0 pour les vieux GPU.

NdM : ce sujet n'est plus de toute fraîcheur, mais il nous a paru intéressant de lancer le débat.

Aller plus loin

  • # Gneu?

    Posté par  (site web personnel) . Évalué à 6.

    mais il nous a paru intéressant de lancer le débat.

    Le débat sur quoi? Il n'y a à ma connaissance aucune alternative à OpenGL.

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Gneu?

      Posté par  . Évalué à 10.

      Cherche un peu... Au choix:
      · C'est mieux que Direct3D ?
      · Pourquoi sortir la version 4 à peine un an après la version 3, qui n'a même pas eu le temps d'être implémenté ?
      · Quand est-ce que ce sera réellement utilisable sous Linux ?
      · Est ce que ce sera plus puissant en Java ?
      · Vim où Emacs ?

      • [^] # Re: Gneu?

        Posté par  . Évalué à 0.

        « · Vim ou Emacs ? »
        Vim.
        Pour mon OS j'utilise déjà Archlinux.

      • [^] # Re: Gneu?

        Posté par  . Évalué à 4.

        Tu oublies aussi :

        . pourquoi est-ce que Windows est paradoxalement la meilleure plateforme pour faire du développement OpenGL moderne ?

        (Rappel : ces grouillots d'Apple ne supportent toujours pas OpenGL post 2.1)

        • [^] # Re: Gneu?

          Posté par  (site web personnel) . Évalué à 1.

          pourquoi est-ce que Windows est paradoxalement la meilleure plateforme pour faire du développement OpenGL moderne ?

          Parce que Intel fait des cartes moisies, ATI des drivers pourris et NVIDIA ne fait que des cartes Windows.

          Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

      • [^] # Re: Gneu?

        Posté par  (site web personnel) . Évalué à 1.

        « Vim où Emacs ? »

        DTC

    • [^] # Re: Gneu?

      Posté par  . Évalué à 6.

      Ils veulent peut-être lancer un débat sur le lancer de débat?

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Gneu?

        Posté par  (site web personnel) . Évalué à 3.

        Le lancer de débat, un nouveau sport olympique après le lancer de nains ?

        • [^] # Re: Gneu?

          Posté par  . Évalué à 10.

          Pourquoi ne pas prendre le meilleur des 2 ?
          Le lancer de nains qui se débattent.

    • [^] # Re: Gneu?

      Posté par  . Évalué à 2.

      Je pense qu'il voulait parler du mode de développement différent d'un truc similaire qu'on ne trouve que sur une seule plateforme non libre dont le nom m'échappe...

      Il me semble avoir lu jadis qu'opengl ne peut être qu'à la traine. Contrairement à l'autre, il ne fait que standardiser ce qui existe déjà ou est déjà faisable sur les différents processeurs graphiques.

      A l'opposé, l'autre impose sa vision des choses que les constructeurs doivent suivre...

      • [^] # Re: Gneu?

        Posté par  . Évalué à 1.

        sur une seule plateforme non libre

        Selon une rumeur, il parait qu'il y aurait plusieurs plateformes pour ce truc similaire, toute du même éditeur qui ferait aussi des consoles de jeu.

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # débat

    Posté par  (site web personnel) . Évalué à 6.

    Amélioration du rendu via le passage des opérations en virgule flottante du format simple précision au format double précision ;

    Dans quel genre de situation est-ce que la double precision est utile ?

    • [^] # Re: débat

      Posté par  . Évalué à 5.

      Les vertex/pixels shaders peuvent effectuer des calculs en plusieurs passes qui peuvent s'avérer très complexes. On peut arriver à générer des erreurs de calculs visibles à l'écran dans certains cas... la double précision permet de générer une erreur qui ne sera pas visible à l'écran.
      De manière générale, ce sont les multiplications successives de matrices ou de vecteurs qui génèrent les plus grosses erreurs de calculs sur les nombres flottants.

      • [^] # Re: débat

        Posté par  . Évalué à 3.

        Mouais, j'avoue avoir plutôt pensé à de la programmation généraliste sur GPU (et plus spécifiquement au calcul scientifique).

        • [^] # Re: débat

          Posté par  . Évalué à 3.

          Pour le calcul sur GPU il y a déjà OpenCL. Je ne pense pas que le groupe Chronos conçoive l'API d'OpenGL pour en faire autre chose que ce qu'il est censé faire : Du rendu 3D.

          • [^] # Re: débat

            Posté par  . Évalué à 4.

            Oui, mais en attendant pour faire du double précision sur la CG il faut que ce soit implémenté dans le matériel, sinon ça risque d'être difficile.

            Donc si c'est dans la norme, il y a des chances que ça atterrisse dans les cartes, et c'est bien pour le GPGPU.

            • [^] # Re: débat

              Posté par  . Évalué à 2.

              CGs double précision :
              - nVidia GTX 200 serie (GTX 260, GTX 280, GTX 285, GTX 295)
              - nVidia GTX 400 serie (GTX 470, GTX480)

              Cf. http://developer.download.nvidia.com/compute/cuda/3_0/toolki(...) - Appendix A. CUDA-Enabled GPUs :
              Toutes les cartes marquées 'Compute Capability' 1.3 ont la double précision.

              • [^] # Re: débat

                Posté par  . Évalué à 4.

                Hum, rappelons que les performances en double précision des GTX 4XX sont castrées à un huitième des performances en simple précision pour préserver l'intérêt commercial des cartes nvidia dédiées au calcul scientifique. Même sans cela, la précision accrue n'est pas gratuite et les performances s'en ressentent automatiquement, ce qui explique que virtuellement aucun jeu actuel n'utilise autre chose que des flottants simple précision sur le GPU.

                L'article [http://home.comcast.net/~tom_forsyth/blog.wiki.html#%5B%5BA%(...)], même s'il est un peu vieillissant, reste une critique pertinente des velléités d'utiliser des double dans les jeux vidéos.

                • [^] # Re: débat

                  Posté par  . Évalué à 0.

                  ce qui explique que virtuellement aucun jeu actuel
                  j'en ai mal aux yeux

                  • [^] # Re: débat

                    Posté par  . Évalué à 2.

                    Tu trouves que je fais une ampoulite ?

  • # lancer le débat :)

    Posté par  (site web personnel) . Évalué à 6.

    La dépêche était un peu courte mais évoquant la force d'OpenGL pour la portabilité des jeux, il a semblé opportun de rajouter le lien vers le journal de début d'année montrant la pérennité de ce standard multiplateforme. Le débat peut porter :
    - sur le dynamisme d'OpenGL (montré par ses publications régulières o_O) et n'hésitant pas à rétroporter en version antérieure pour ceux ne pouvant pas (encore) monter de version
    - sur l'avenir de la déclinaison pour téléphone mobiles aka ordiphone, OpenGL_ES
    - le fait que wikipedia anglais met les pieds dans le plat http://en.wikipedia.org/wiki/Comparison_of_OpenGL_and_Direct(...) qui n'est pas encore disponible en français :/
    - vous pouvez étendre le débat à OpenAL remplaçant efficacement la bibliothèque son propriétaire fmod qui était souvent reprise dans des bibliothèques haut-niveau de jeux, http://en.wikipedia.org/wiki/Panda3D par exemple a fait le choix d'en proposer 3 : OpenAL en libre, fmod en proprio et en:Miles_Sound_System en open-source (que je ne connaissais pas)
    - éventuellement, tenter de vérifier "la loi de jiba" aka "une nouvelle bibliothèque ou moteur de jeu par mois" (réinventant bien-sûr la roue ou choisissant un n-ième langage)
    - certains n'éviteront pas le débat Intel + ATI^W AMD chevaliers du libres vs nVidia le méchant blob
    Toute ressemblance avec une confusion sur le terme débat et le mot troll serait purement fortuite, le débat qui me paraît intéressant concerne la réelle plus-value dans les jeux (voire dans la réalité virtuelle pour ceux qui auraient des liens) et j'en oublie.

    • [^] # Re: lancer le débat :)

      Posté par  . Évalué à 3.

      Je me lance : pourquoi en 2010 on n'a pas une API orienté objet alors que c'est pourtant le meilleur paradigme?

      • [^] # Re: lancer le débat :)

        Posté par  (site web personnel) . Évalué à -2.

        Pour que tu puisses la créer sous la forme d'une librairie, ta version, ma version, la version du voisin....

        Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

      • [^] # Re: lancer le débat :)

        Posté par  . Évalué à 3.

        ...c'est pourtant le meilleur paradigme?
        Ce n'est pas ce que pense les plus grands:
        http://www.codersatwork.com/

        • [^] # Re: lancer le débat :)

          Posté par  (site web personnel) . Évalué à 5.

          Le paradigme objet n'est pas universel à tous les langages... Le moteur objet n'est pas le même (compatible) dans tous les langages...

          Parfois aussi, une structure d'arbre de classe trop imbriquée avec l'héritage multiple donne une rigidité donc une difficulté à faire évolué l'arbre de classe au cours du temps plus grande que ce que l'on espérait : la souplesse de ré-utilisation ! Je trouve par exemple qu'Eiffel est tombé dans ce travers.

      • [^] # Re: lancer le débat :)

        Posté par  (site web personnel) . Évalué à 2.

        Parce qu'on sait pas faire de la perf avec de l'objet à cause de la liaison dynamique qui oblige d'utiliser des VFT, ce qui est lent (pointeur sur fonction -> impossible d'inliner, très dur pour le processeur d'optimiser, risque de vidage du cache, de la queue d'instructions à exécuter, etc...)

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

        • [^] # Re: lancer le débat :)

          Posté par  . Évalué à 2.

          Une fonction liée dynamiquement ne peut pas être inlinée, VFT ou pas.

          • [^] # Re: lancer le débat :)

            Posté par  (site web personnel) . Évalué à 3.

            T'as pas compris. Il s'agit de supprimer l'aspect dynamique de l'appel de la fonction.
            ie. On remplace l'appelle à un pointeur sur fonction par un appel statique en utilisant un switch dichotomique (en log2(n) donc) sur l'id de l'objet.

            Ajoute qu'avec une bonne analyse de flot, on transforme 98% des appels en monomorphique.

            De cette manière on peut inliner très agressivement tout en gardant les possibilités de dynamisme dans l'écriture du code.

            « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: lancer le débat :)

      Posté par  (site web personnel) . Évalué à 3.

      -quand est-ce qu'Apple aura un bon support d'OpenGL (j'ai un collègue qui râle très fort là dessus) ?

      Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

      • [^] # Re: lancer le débat :)

        Posté par  . Évalué à 2.

        Depuis qu'ils ont les IPhones et autres IPad chez Apple, ils ne semblent s'intéresser de moins en moins à l'évolution d'OSX.

        Cela dis un désintéré d'Apple pour OSX motiverait peut être du monde sur des projets comme GNUStep et Etoilé. Histoire que d'avoir un digne successeur de NeXT qui ne soit pas propriétaire.

        • [^] # Re: lancer le débat :)

          Posté par  . Évalué à 2.

          Parceque tu penses que Apple prefererait mettre un truc qu'ils ne controle pas sur leur portable?
          Tu reves!

    • [^] # Re: lancer le débat :)

      Posté par  (site web personnel) . Évalué à 4.

      On y apprend un truc très intéressant sur les différences entre D3D et OpenGL : D3D oblige le programmeur à gérer manuellement ses resources hardware, ce qui est plus difficile, mais plus flexible et plus simple pour l'auteur du driver.

      OpenGL gère les ressources lui même, ce qui est plus facile à programmer, mais permet moins de tuner finement. De plus ça facilite pas la tâche du driver (enfin surtout celui qui l'écrit...)

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Suivre le flux des commentaires

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