Journal OpenGL 6.5.3 is out

Posté par  (site web personnel) .
Étiquettes : aucune
0
4
mai
2007
La grande nouveauté est...
... roulement de batteries ...


\o/ \o/ OpenGL 2.0 et 2.1 est supporté \o/ \o/


Allez, histoire de ne pas faire un journal de première page trop court, j'ajoute ces infos :


New features

* OpenGL 2.0 and 2.1 API support.
* Entirely new Shading Language code generator. See the Shading Language page for more information.
* Much faster software execution of vertex, fragment shaders.
* New vertex buffer object (vbo) infrastructure
* Updated glext.h file (version 39)
* Updated glxext.h file (version 19)
* GL_MAX_DRAWBUFFERS is now 4 (software rendering) so "multiple render targets" are really supported.

Bug fixes

* Fog was errantly applied when a fragment shader was enabled (bug 9346)
* glPush/PopClientAttrib didn't handle VBO bindings correctly (bug 9445)
* With 32-bit Z buffer, the fragment Z of lines and points was sometimes wrong.
* GL_POST_CONVOLUTION_ALPHA_BIAS/SCALE was broken.
* 1D convolution state could effect 2D image transfers
* Overlapping glCopyPixels with negative Y zoom didn't work (bug 10521)
* Fixed a number of framebuffer/renderbuffer reference counting bugs
* Fixed a few bugs in software-emulated alpha planes
* Assorted minor bug fixes in glCopy/DrawPixels, glPixelZoom, etc.
* Assorted DRI driver bug fixes.
* Fixed a number of bugs that prevented "depth-peeling" rendering from working.

Internal code changes

* Old array_cache module replaced by new vbo module. All geometry rendering is now cast in the form of vertex buffer objects.
* Massive changes to the Shading Language compiler and related state.
* Vertex/fragment shaders are compiled into GPU instructions and programs very similar to GL_ARB_vertex/fragment_program.
* Vertex and fragment programs are executed with the same code now.
* The SSE-optimized vertex program path has been removed since it didn't support more than 12 temp registers, didn't support branching/looping, etc.

To Do (someday) items

* Switch to freeglut
* Fix linux-glide target/driver.
* Improved lambda and derivative calculation for frag progs.


http://www.mesa3d.org/

  • # Qui relèvera le défi

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

    de traduire ces notes de version en mettant plus de mots français que de mots techniques anglais ?

  • # bug ?

    Posté par  (site web personnel, Mastodon) . Évalué à 10.

    >opengl 6.5.3 is out

    et aprés

    > OpenGL 2.0 et 2.1 est supporté

    Y a comme un bug... Faut se relire avant de publier...

    Bref, il s'agit de mesa3d 6.5.3.

    • [^] # Re: bug ?

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

      par ailleurs c'est plutôt OpenGL 6.5.3 is Mai
      il ne faut pas s'arrêter à la chaleur estivale actuelle et encore attendre 3 mois quand même pour Août.

  • # Mesa

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

    C'est Mesa 6.5.3 qui est sorti et pas OpenGL 6.5.3.

    • [^] # Re: Mesa

      Posté par  . Évalué à 4.

      Il me semble aussi qu'il manque un nouveau glx pour vraiment en tirer parti (voir tableau 6.1 page 49 dans le document suivant):

      http://www.opengl.org/documentation/specs/glx/glx1.4.pdf

      Donc pour le moment on doit avoir l'interface opengl 2.0 disponible uniquement si on link directement avec mesa dc sans acceleration ou affichage sous X.

      Bienvenue dans le subtile monde des protocoles graphiques :)

      • [^] # Re: Mesa

        Posté par  . Évalué à 2.

        Heuu, t'es sûr ? Je fait du dev OpenGL 2.0 et j'ai aucun problème d'accélération...

        • [^] # Re: Mesa

          Posté par  . Évalué à 1.

          Sur quel plate forme as tu fait de l'opengl 2.0 ? Attention GL 2.0 est compatible avec 1.5 ou avant donc tu peux très bien faire plein de truc sans vraiment utiliser une fonction particulière/propre a GL 2.0/2.1.

          Si tu fais un glxinfo tu verra la version du protocole GLX (ca doit etre 1.2 pour tout les linux d'aujourd'hui sauf peut être avec les drivers nvidia). Le protocole GLX fait le liens entre OpenGL et le protocole X donc GLX n'est utile et n'a de sens que sous un système X window, et ce protocole définis qu'elle version d'opengl est supporte(voir le lien que j'ai donné).

          Enfin je serais pas étonné que les fonctions GL 2.0 soient tout de même exposées sous le protocole GLX 1.2 ou 1.3. Ce qui ne serait pas conforme au protocole mais par exemple l'extension EXT_TFP nécessaire a compiz sous AIGLX est expose avec glx 1.2 alors qu'elle requiert au moins le 1.3 ou 1.4 (enfin c'est un micmac du genre).

    • [^] # Re: Mesa 6.5.3

      Posté par  . Évalué à 4.

      A propos du numéro de version, c'est toujours une version 'instable/de développement' comme on dit (deuxième numéro impair).

      Brian Paul, le chef du projet Mesa, a annoncé Mesa 7.0 (la version stable) pour bientôt sur la liste de diffusion, le temps de faire quelques corrections dans la 6.5.x. Cette version 7.0 sera officiellement celle à partir duquel OpenGL 2.0 sera supporté.

  • # Pendant ce temps...

    Posté par  . Évalué à 4.

    Les premiers logiciel/jeux utilisant DirectX 10 vont commencer à sortir.
    DirectX10 qui est une technologie "plus mieux bien" que OpenGL2, car tout le monde sait bien que, plus le numéro de version est élevé, plus le produit est aboutit.

    Un décideur pressé.

    • [^] # Re: Pendant ce temps...

      Posté par  . Évalué à 4.

      En même temps, je te rappel que DirectX est un framework et non une API 3D... Direct3D oui.
      De plus, Direct3D et un fork de OpenGL à la base.

      • [^] # Re: Pendant ce temps...

        Posté par  . Évalué à 4.

        De plus, Direct3D et un fork de OpenGL à la base.

        Un fork ? T'es sur de toi la ? Rien de tout ça sur wikipedia en tout cas...

        • [^] # Re: Pendant ce temps...

          Posté par  . Évalué à 2.

          Fork le mot est peut etre excessif mais si tu regarde la premiere version ca ressemble beaucoup a opengl avec des classes et l'horrible notation polonaise en plus.

          • [^] # Re: Pendant ce temps...

            Posté par  . Évalué à 2.

            C'est meme plus qu'excessif comme mot., ca n'a rien a voir. Au mieux c'est pompé sur Open GL.

            • [^] # Re: Pendant ce temps...

              Posté par  . Évalué à 4.

              Oui, c'est un peu excessif, je reconnais ^^.
              L'histoire c'est que, à la base, un consortium comprenant les plus grand (IBM, Microsoft, ect...) on commencé à développé un API commune pour la 3D, car il n'existait rien.
              Quelques années après que les bases soient bien posé et que ça fonctionnait, Microsoft à décidé de se retirer du projet pour développer son petit truc dans son coin. Évidement, le plus gros du travail avait déjà été fait, il suffisait juste de récrire le code.

            • [^] # Re: Pendant ce temps...

              Posté par  . Évalué à 2.

              Je t'invite a consulter les premières version de direct3d et a compare avec le protocole opengl, les similarités sont nombreuse, directx a depuis évolué et suivi une voie un peu différentes mais il reste encore de tres nombreuses similarités même s'il reste vrai que techniquement parlant les deux api n'ont rien de similaire mais il s'agit plus de la facon de présenter que des fondements. C'est d'ailleurs pourquoi wine arrive a convertir les appels direct3d en appel opengl assez facilement.

  • # Le rôle de Mesa

    Posté par  . Évalué à 3.

    Si je ne me trompe pas, Mesa est une implémentation logiciel d'OpenGL, ce qui permet de faire tourner des applications OpenGL même si l'accélération 3D de la carte n'est pas supportée.
    Après, vu que ce n'est pas la carte qui fait le travail, celui-ci est relayé au CPU.
    Ma question est donc, au vu de la puissance actuelle des CPU, que permet au juste de faire tourner Mesa.
    Peut-on espérer pouvoir faire tournée « prochainement » des bureaux en 3D, à défaut de jouer à des FPS avec par exemple une « carte mesa » ?
    Voilà, j'aimerai donc connaître le but de ce projet, et où est-il utile et utilisé.

    • [^] # Re: Le rôle de Mesa

      Posté par  . Évalué à 6.

      Mesa ne peut etre competitif avec une acceleration materiel meme avec les cpus actuelle. Seul, peut être, les processeurs cell peuvent rendre utilisable cette approche logiciel. Il y a plusieurs raison a cela :

      - Les cartes graphiques sont capables de traiter plusieurs pixels en même temps avec des opérations complexes et particulière (typiquement des groupes de 64 ou 128 pixels, nvidia allez jusqu'a 1024 me semble t-il mais ce n'étaient pas un bon choix) un CPU lui ne pourra pas traiter autant de pixel aussi efficacement même avec les instructions "multimedia". En effet l'agencement mémoire sur la carte graphique et l'architecture autour permet d'optimiser les access sur ces groupes de pixels alors que pour le cpu le plus souvent on a des cache miss et on ne peut avoir une organisation aussi sioux que pour le gpu.

      - Les cpu ne sont pas tres efficaces pour des opérations comme le blending de pixel a moins de faire des routines tres optimisées.

      - Mesa ne cherche pas a optimiser aux maximums son rendue software principalement car c'est irréaliste. En effet il faudrait écrire en asm chaque combinaison possible de rendu et il y en a plusieurs milliers voir une infinité si l'on considère les vertex et pixel shader. Donc mesa s'intéresse plus a avoir une pipeline software la plus proche des spécifications opengl (je crois que certains professionnel se sert du rendu de mesa comme référence).

      - Enfin le rendu dans les résolutions actuelle demande de deplace des dizaines de mega octect de mémoire a chaque frame et l'architecture de nos machines n'est pas la plus optimise pour ca.


      Voila pourquoi mesa ne représente pas une solution fonctionnel pour le rendu en software de bureau 3d. Mais mesa est utilisées par tout les pilotes 3d graphiques libre sous linux; effectivement rare sont les cartes qui implémentent l'ensemble d'opengl aussi beaucoup de fonction de l'opengl sont laisse a la charge de mesa.

      Mesa est aussi utilise pour tester des idées en software de protocole ou extension opengl qui pourrait être utile. Il est aussi probablement utilise dans plusieurs application professionnel qui ne peuvent se contenter du rendu des cartes graphiques. Bref je ne pense pas que l'on puisse facilement dresser une liste exhaustive de ses utilisations. Mais il reste un composant clef de l'accélération matériel sous linux ou netbsd, il s'agit tout simplement du centre névralgique par ou tout passe pour l'opengl. C'est pourquoi chaque amélioration qu'il subit a de grande chance d'améliorer les drivers libres de manière indirect.

      Et le but de ce projet c'est simplement de proposer une implémentation d'opengl en software la plus conforme possible ainsi que de fournir une infrastructure pour l'accélération matériel d'opengl. A ma connaissance c'est la seul implémentation aussi complète d'opengl en software, il s'agit vraiment d'un travail énorme.

Suivre le flux des commentaires

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