X Mesa 9.1 est sorti

Posté par (page perso) . Édité par Nÿco et Xavier Claude. Modéré par Xavier Claude. Licence CC by-sa
Tags :
62
23
fév.
2013
X

Mesa 9.1 vient de sortir ! Pour rappel, Mesa est une implémentation libre de la spécification OpenGL pour plates‐formes de type Unix, comme GNU/Linux.

La précédente version de Mesa permettait d'étendre le support d'OpenGL 3.0 à 3.1 ; cette fois le travail d'implémentation des versions suivantes d'OpenGL, bien qu'en bonne voie, n'a pu être terminé à temps, ce qui explique que le nommage de cette version soit de type 9.x. On peut raisonnablement espérer que la prochaine version de Mesa sera estampillée 10.0, marquant ainsi le support d'une version plus récente d'OpenGL (probablement 3.3).

Cette nouvelle version de Mesa n'est pourtant pas dénuée d'intérêt puisqu'elle apporte le support d'OpenGL ES 3.0 aux puces Intel Gen6 et Gen7 (respectivement Sandy Bridge et Ivy Bridge). L'exploit est à souligner puisqu'on se souvient que la spécification d'OpenGL ES 3.0 ne date que de quelques mois !

Une autre nouveauté intéressera les possesseurs de puces Intel puisque celles-ci bénéficient semble t-il d'un léger gain de performances. Du côté des autres nouveautés, on notera la prise en charge d'OpenGL 3.1 Core pour les puces AMD de la série Radeon HD2000 à HD6000, et l'ajout du du multisample anti-aliasing (MSAA) pour les puces de la série AMD Radeon X1000.

(58 commentaires).

  • # Présence dans Debian

    Posté par (page perso) . Évalué à 3.

    Sur Debian (wheezy/sid), on est encore sur du Mesa 8 et j'aimerais bien profiter des dernières nouveautés de Mesa 9. Est-ce que quelqu'un a une idée de quand est-ce que Mesa 9 (ou 9.1) sera empaqueté pour Debian ?

    Merci.

    • [^] # Re: Présence dans Debian

      Posté par . Évalué à 2.

      Il faudra attendre la sortie de Wheezy pour voir entrer les nouveautés dans Sid qui est pour l'instant en mode correction de bugs.

    • [^] # Re: Présence dans Debian

      Posté par . Évalué à 0. Dernière modification : le 24/02/13 à 14:24

      pacman -Qii mesa
      Nom : mesa
      Version : 9.0.2-1
      URL : http://mesa3d.sourceforge.net
      Licences : custom
      Groupes : --
      Fournit : --
      Dépend de : libgl libx11>=1.5.0 libxext>=1.3.1 libxdamage
      libxfixes libxcb libxxf86vm
      Dépendances opt. : opengl-man-pages: for the OpenGL API man pages
      Requis par : clutter lib32-mesa xf86-video-vmware
      Est en conflit avec : --
      Remplace : --
      Taille installé : 17376,00 KiB
      Paqueteur : Andreas Radke
      Architecture : x86_64
      Compilé le : mer. 23 janv. 2013 16:48:28 GMT
      Installé le : dim. 27 janv. 2013 09:56:32 GMT
      Motif d'installation : Installé comme dépendance d'un autre paquet
      Script d'installation : Non
      Description : Mesa 3-D graphics libraries and include files
      Fichiers de sauvegarde :

      Quand y'en a assez d'attendre, y'a les Rolling Release. :)

      • [^] # Re: Présence dans Debian

        Posté par . Évalué à 5. Dernière modification : le 24/02/13 à 14:28

        Vous êtes en retard :o

         [I] media-libs/mesa
     Available versions:  7.10.3 7.11.2 8.0.4-r1 9.0.1 (~)9.0.2 (~)9.0.3 (~)9.1 {bindist +classic debug +egl g3dvl +gallium gbm gles gles1 gles2 hardened (+)llvm motif +nptl openvg osmesa pax_kernel pic r600-llvm-compiler selinux shared-dricore +shared-glapi vdpau wayland xa xorg xvmc KERNEL="FreeBSD" VIDEO_CARDS="i915 i965 intel mach64 mga nouveau r100 r128 r200 r300 r600 radeon radeonsi savage sis tdfx via vmware"}
     Installed versions:  9.1(00:13:04 24/02/2013)(egl gallium gbm gles1 gles2 llvm nptl openvg osmesa shared-glapi xa xorg xvmc -bindist -classic -debug -pax_kernel -pic -r600-llvm-compiler -selinux -vdpau -wayland KERNEL="-FreeBSD" VIDEO_CARDS="nouveau -i915 -i965 -intel -r100 -r200 -r300 -r600 -radeon -radeonsi -vmware")
     Homepage:            http://mesa3d.sourceforge.net/
     Description:         OpenGL-like graphic library for Linux

        • [^] # Re: Présence dans Debian

          Posté par (page perso) . Évalué à 4.

          Vous êtes en retard :o

          Si je me souviens bien, le ~ indique que le paquet est pour l'instant masqué, c'est ça? Si c'est le cas, l'équivalent dans Arch, ce sont les repos [testing] et [community-testing]. Mesa 9.1 est dans [testing] depuis hier.

      • [^] # Re: Présence dans Debian

        Posté par (page perso) . Évalué à 6.

        Quand y'en a assez d'attendre, y'a les Rolling Release. :)

        Ah mais non, tu comprends, c'est "instable" ;)

        Franchement, je comprend l'intérêt de debian dans le monde des serveurs ou en entreprise mais pour le desktop personnel, si on a assez de connaissance pour maintenir une debian, on en a assez pour maintenir une Arch. Et Arch, c'est bien assez stable par défaut et c'est surtout à jour.

        /me sent qu'il va se faire moinsser par ceux qui ont jamais testé Arch et qui font que répéter la doctrine des distros non-rolling-release.

        • [^] # Re: Présence dans Debian

          Posté par (page perso) . Évalué à 7.

          J'ai testé Arch et je n'aime pas forcément. Le gros problème des rolling-release pour moi, c'est qu'un changement de version majeure peut arriver à chaque mise à jour, et un changement de version majeure, ça veut potentiellement dire une configuration à refaire. Et je n'ai pas forcément le temps au milieu de la semaine de refaire une mise à jour, je me prévois des jours où j'ai le temps pour refaire éventuellement ma conf quand je change de version de distribution.

          « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

          • [^] # Re: Présence dans Debian

            Posté par (page perso) . Évalué à 8.

            Personnellement, ça doit m'arriver une ou deux fois par semestre de devoir changer la configuration d'un programme à cause d'un changement de version majeure. Et c'est souvent uniquement à cause de Arch.

            D'ailleurs, en 2012, y'a eu de gros changements dans Arch et j'ai été étonné de la stabilité! (Grub2, merging de /(bin|lib) et /usr/(bin|lib) et systemd. C'est d'ailleurs la seule année où j'ai dû prévoir des mises à jour sur mes systèmes car elles pouvaient potentiellement mal se passer.

            Si un projet est bien fait, il est rétro-compatible avec ses anciens fichiers (ça me semble le minimum). Parfois, on a des petits messages qui nous conseille de mettre à jour telle ou telle chose mais ça s'arrête généralement là et tu peux te permettre de repousser ça au week end.

            Cela dit, j'ai un contre exemple, le projet PostgreSQL qui est une usine à gaz pour faire le changement de version. La solution est d'empêcher ses mises à jour (en le marquant dans la liste des paquets à ne pas mettre à jour). Quand une nouvelle version sortira, pacman affichera un joli warning et tu peux attendre le week end pour faire ta mise à jour.

            • [^] # Re: Présence dans Debian

              Posté par (page perso) . Évalué à 10.

              Personnellement, ça doit m'arriver une ou deux fois par semestre de devoir changer la configuration d'un programme à cause d'un changement de version majeure.

              Je suis d'accord que ça arrive rarement, mais ça arrive toujours au mauvais moment.

              La solution est d'empêcher ses mises à jour (en le marquant dans la liste des paquets à ne pas mettre à jour). Quand une nouvelle version sortira, pacman affichera un joli warning et tu peux attendre le week end pour faire ta mise à jour.

              Ce n'est pas terrible si la mise à jour corrige des failles de sécurité (surtout si on est pas disponible le weekend suivant).

              « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

              • [^] # Re: Présence dans Debian

                Posté par (page perso) . Évalué à 4.

                Ce n'est pas terrible si la mise à jour corrige des failles de sécurité (surtout si on est pas disponible le weekend suivant).

                Qui a besoin d'un serveur SQL aussi complexe de Postgre sur un desktop user ;) Et puis, si c'est le cas, ça veut probablement dire que le service est pas accessible de l'extérieur alors bon… Je trouve que passer à un système "stable" a bien plus d'inconvénients que ce petit problème surtout que c'est pas tout rose niveau sécu chez eux (tout le monde a les mêmes versions de tous les logiciels).

                Bon cela dit, faut qu'on arrête de dériver là, on est loin de mesa ;)

              • [^] # Re: Présence dans Debian

                Posté par . Évalué à 2.

                Sérieusement, sur un desktop, vous faites des mises à jours toutes les min ? vous ne pouvez pas attendre le WE ?

                Je charie un peu mais quand je fais une mise à jour en semaine (Pacman -Sy puis Pacman -Su) et que je vois un paquet "critique" dans la liste des fichiers à updater:
                - driver graphique
                - kernel
                - dernièrement grub2/systemd
                - …

                bah j'arrête. Et je fais ça le WE tranquillement … suis pas à 5 jours près … (et d'ailleurs je fais mes updates bien moins souvent).

                Si vous avez besoin d'un certains paquet à jour, absolument pendant la semaine, bah forcément besoin de faire un màj totale. Suffit de faire un pacman -S softàinstaller.

                A mon sens, aujourd'hui, il n'y a pas d'inconvénient à utiliser une rolling release telle que Arch.

                Les autres, il faut de toutes façon les réinstaller tous les 6 mois, et c'est bcp bcp plus fastidieux …

    • [^] # Re: Présence dans Debian

      Posté par . Évalué à 8. Dernière modification : le 24/02/13 à 14:30

      C'est à mon avis un des plus gros problèmes de Debian.
      En période de freeze plus aucun nouveaux paquets ne rentre, maintenant ça fait 6 peut être même 7 mois que le freeze à commencé, ce qui est long pour le monde du logiciel.
      J'aimerais beaucoup avoir un package de ffmpeg 1.1 alors que la version courante des dépots est la 0.8.5 qui date de plus d'un an, ou alors avidemux 2.6.1 alors que la version packagée est la 2.5.6 qui elle aussi a plus d'un an.

      Le top serait d'avoir une version de Debian qui soit indépendante des périodes de freeze et qui intègre les nouveaux paquets une sorte de testing/unstable constamment mise à jour, une "vrai" rolling release en somme.
      Il me semblait que Debian Cut faisait ça, mais apparemment elle freeze aussi en même temps que les autres.
      Donc il ne reste plus qu'a faire une autre branche de Debian qu'on pourrait appeler "Debian Rolling" qui serait toujours à jour mais pas forcément ultra stable et qui servirait au même titre que testing et unstable à tester/débugger/éprouver les paquets pour stable.
      Mais v'la le travail, ça doit être tellement immense que je ne vois même pas à quoi ça correspond :-D.
      Par contre si ça existait je l'utiliserais sans hésiter ;-).

      Le but est il de trouver des solutions, ou bien des bonnes questions ?

      • [^] # Re: Présence dans Debian

        Posté par (page perso) . Évalué à 1.

        J'ai pas lu de belles choses sur avidemux 2.6.0/2.6.1

      • [^] # Re: Présence dans Debian

        Posté par . Évalué à 0.

        Cette version "rolling unstable" de Debian existe depuis quelques années ; elle commence par "ubu" et finit par "ntu".

        • [^] # Re: Présence dans Debian

          Posté par . Évalué à 2. Dernière modification : le 24/02/13 à 15:48

          Heu cette solution n'est pas satisfaisante :-D.
          Et puis si le truc qui commence par "ubu" et finit par "ntu" était réellement une rolling, pourquoi y aurait il 2 versions à sortir par an ? ça n'a pas de sens ;-)

          Un exemple plus concret serait LMDE (Linux Mint Debian Edition) mais pourquoi pas un pur Debian en vrai rolling ?

          Le but est il de trouver des solutions, ou bien des bonnes questions ?

        • [^] # Re: Présence dans Debian

          Posté par . Évalué à 3.

          Aptosid?

      • [^] # Re: Présence dans Debian

        Posté par . Évalué à 10.

        La période de freeze est longue pour tout le monde, utilisateurs ou packageurs. La bonne nouvelle est qu'il y a un moyen de réduire cette période : être plus nombreux à corriger les bugs bloquants… Pareil pour les paquets, si ça va pas assez vite, ben faut investir un peu de temps et soutenir les gens qui les font… C'est ouvert à tous, il faut juste avoir un peu de temps à y consacrer.

        Après je comprend tout à fait que ça soit plus marrant de troller sur linuxfr sur l'air de « yakafauxcon » que de participer à une tâche assez ingrate.

        • [^] # Re: Présence dans Debian

          Posté par . Évalué à 9.

          C'est vrai, pluzin !
          ça fait déjà pas mal de temps que je me dis que je devrais contribuer à Debian, mais je ne sais pas par quel bout commencer, et puis c'est comme beaucoup de domaines c'est le premier pas le plus difficile.
          Peut être que si j'avais un mentor il pourrait m'aider à faire ce premier pas, mais du coup il faut trouver quelqu'un (francophone de préférence) qui consente à m'accorder un peut de son temps et ça c'est pas gagné.

          Le but est il de trouver des solutions, ou bien des bonnes questions ?

          • [^] # Re: Présence dans Debian

            Posté par (page perso) . Évalué à 3.

            Tout dépend du domaine dans lequel tu veux contribuer: traduction, doc, tri de bugs, site web, packaging, résolution de bugs ..

            Je doute que tu trouves 1 unique mentor, mais tu peux poser tes questions sur les différentes listes de diffusion / IRC.

            • [^] # Re: Présence dans Debian

              Posté par (page perso) . Évalué à -2.

              Le packaging est quand même très compliqué chez debian. Le fait qu'il faille un mentor en dit long…

              Rejoignez nous sur l'incubateur d'excellence de linuxfr: https://linuxfr.org/board

              • [^] # Re: Présence dans Debian

                Posté par . Évalué à 9.

                Dès que tu fais quelque chose qui doit marcher dans tous les cas, ou au minimum pas mettre le bazar, ça ne s’improvise pas. Je trouve au contraire ça plutôt rassurant.

              • [^] # Re: Présence dans Debian

                Posté par (page perso) . Évalué à 6.

                Il n'y pas besoin d'un mentor.

                Si quelqu'un veut envoyer un paquet alors qu'il ne dispose pas encore des droits pour, bah c'est comme tout dans le logiciel libre, si quelqu'un avec les droits qui vont estime le travail à la hauteur pour être inclus, bah c'est inclus.

                Si quelqu'un veut disposer de ses propres droits d'upload, le projet, via un AM (Application Manager) vérifie que le candidat a les compétences et le sérieux requis.

                Le processus pour devenir membre a d'ailleurs simplifié ajd, pour examiner les précédentes contributions du candidat à Debian.

                Enfin, il n'y pas besoin d'être "DD" pour (commencer à) contribuer à Debian.

          • [^] # Re: Présence dans Debian

            Posté par . Évalué à 10.

            Quelques pistes que je connais pour contribuer à Debian :
            – les traductions manquent de bras, notamment les traductions des descriptions de paquets. C'est une chose très importante pour les non-anglophone…
            Ça se fait par une interface web : http://ddtp.debian.net/ddtss/index.cgi/fr
            Le mieux est de se présenter sur la liste de traduction en Français avant.

            – si tu utilises KDE, il y a un gros travail de triage de bugs (2300 ouverts…). Le plus simple est de commencer avec les vieux bugs qui n'ont plus de raison d'être, les demandes de fonctionnalités à rapporter aux développeurs amont, etc. Techniquement ce n'est pas très difficile, mais ça aide pas mal.
            Le mieux est de se présenter sur le chan IRC de l'équipe.

            Il y a bien entendu d'autres tâches à faire dans Debian, à toi de voir ce que tu veux faire. Un bon départ est le coin du développeur :
            http://www.debian.org/devel/

            • [^] # Re: Présence dans Debian

              Posté par . Évalué à 2.

              Merci pour ces liens et conseils.
              Je vais les garder dans un coin pour les étudier, et qui sait peut être faire le premier pas et entrer dans la grande famille de ceux qui font vivre Debian ;-)

              Le but est il de trouver des solutions, ou bien des bonnes questions ?

      • [^] # Re: Présence dans Debian

        Posté par . Évalué à 2.

        Testes sid/experimental alors.

        /etc/apt/preferences.list:

        Package: *
Release: a=experimental
Pin-Priority: 900

Package: *
Release: a=unstable
Pin-Priority: 950

        Par contre, avec ça, faut pas s'étonner si le comportement du PC change sans trop prévenir ou si des problèmes apparaissent.

        Concernant ArchLinux, j'ai essayé, pendant 2 jours d'affilée il n'y a pas plus de quelques mois (3-4), et Xorg avait un problème de dépendance cassée avec DBus (si je me souviens bien, c'était peut-être un autre paquet) donc bon, qu'on vienne pas me dire que les rolling release ça marche tout seul.

        Enfin, je pense que mon prochain test de distro sera quand j'aurais réussi à installer une gentoo, au moins il existe des snapshot stables pour commencer. C'est juste dommage qu'a chacun de mes essais j'aie eu des problème avec le noyau, en fait.
        Mais au moins cette distro semble permettre de réduire les dépendances, du coup je pense que ça dois réduire le risque d'emmerdement d'une distro binaire en rolling.

        • [^] # Re: Présence dans Debian

          Posté par . Évalué à -7.

          Concernant ArchLinux, j'ai essayé, pendant 2 jours d'affilée il n'y a pas plus de quelques mois (3-4), et Xorg avait un problème de dépendance cassée avec DBus (si je me souviens bien, c'était peut-être un autre paquet) donc bon, qu'on vienne pas me dire que les rolling release ça marche tout seul.

          Jamais eu ce problème. Et si, ça marche tout seul.

          Ce genre de problème est inexistant. J'pense que t'as dû faire un truc pas clair. Les paquets sont testés avant d'être intégrés aux dépôts principaux. Une Archlinux à jour ne devrait jamais avoir ce genre de problèmes !

          • [^] # Re: Présence dans Debian

            Posté par . Évalué à 6.

            Bah… j'ai juste installé à partir de l'image fournie, lu les instructions de l'installateur, abouti sur une ligne de commande, tenté d'installer Xorg, et échoué pour cause de dépendance foireuse, dans l'ordre.

            Maintenant, si tu me dis que c'est impossible, que ce genre de problème est inexistant, alors, si tu veux, moi j'ai eu mon expérience, je verrai dans n mois/années si ça a changé, ou quand quelque chose me fera penser que ça pourrait être intéressant de retenter.
            Clairement, ce n'est pas de lire "Ce genre de problème est inexistant. J'pense que t'as dû faire un truc pas clair." qui me fera changer d'avis. Encore, j'aurai été bidouiller des trucs un peu obscurs de moi-même, ok.

            Là, je savais que j'attaquais une distro qui me semble tout de même plus délicate que celle à laquelle je suis accoutumé, alors j'ai d'abord visé un système utilisable, avant de viser un système efficace.
            Je procède toujours de cette façon quand j'aborde un système que je ne connais pas, et a l'heure actuelle, les systèmes avec lesquels ça n'a pas marché sont au nombre de 3: Debian woody/potato (mon 1er contact avec linux, qui a été un échec vu que par défaut, aucun bureau n'était installé. Donc, sans internet et une machine valide à côté, le système était inutilisable sans connaître l'existence d'aptitude), gentoo et archlinux (courant 2012 pour ces deux la, qui ont le même problème qu'avait debian woody/potato, sauf que maintenant, j'utilise quasi-exclusivement la ligne de commande et que je n'ai donc plus aucune difficulté avec elle).

            Si je dois comparer Debian et arch linux, je ne dirais pas que l'une est meilleure parce que je n'ai pas réussi à installer la seconde, juste que la seconde nécessite sûrement plus de travail/compétences pour aboutir à un système stable. Debian stable ne nécessitant que des mises à jour que l'on peut faire "à l'aveugle" en sachant que le comportement du système ne changera pas.
            Arch introduisant des versions majeures régulièrement, il est plus complexe de contrôler ce flux de fonctionnalités nouvelles. Et certains utilisateurs, y compris d'utilisateurs avancés, n'ont "pas de temps à perdre avec ça", tout simplement.

            Cette notion de temps à investir plus régulièrement est à mon sens la principale différence entre les distributions "permanentes" et les distributions "temporelles" (pour essayer de traduire rolling release et son contraire).
            Rien que le fait qu'il faille vérifier qu'un des paquets sensible n'a pas changé de version majeure/mineure régulièrement est une "perte de temps" (en fait, on déplace une tâche régulière à une date fixe future) comparativement aux distro "temporelles" ou ça n'arrive que tous les N mois (mais du coup, il faut rattraper tout le retard. L'avantage, c'est que certaines modifications peuvent être sautées, parce qu'elles ont pu être supprimée dans le logiciel en question. Ca dépend du modèle de release de celui-ci après…)

            • [^] # Re: Présence dans Debian

              Posté par . Évalué à -2. Dernière modification : le 25/02/13 à 14:09

              Si je dois comparer Debian et arch linux, je ne dirais pas que l'une est meilleure parce que je n'ai pas réussi à installer la seconde, juste que la seconde nécessite sûrement plus de travail/compétences pour aboutir à un système stable.

              C'est l'inverse. Pour avoir un système ArchLinux instable, il faut soit:
              -installer n'importe quoi depuis l'AUR
              - attendre 2 ans entre chaque mise à jour et tomber sur un os, ne pas suivre les indications sur archlinux.org, et tenter pacman --force. Et là, l'utilisateur a tout cassé…
              - avoir activé les dépôts testing (et dans ce cas là faut pas venir se plaindre…)

              Le système est stable dès le départ.

              Arch introduisant des versions majeures régulièrement

              C'est assez rare, en fait. Et s'il y a besoin, il suffit de suivre les indications fournies sur archlinux.org

          • [^] # Re: Présence dans Debian

            Posté par . Évalué à 3. Dernière modification : le 26/02/13 à 08:55

            J'ai essayé d'installer Arch il y a 3 ans et demi environ car j'en avais un peut marre d'Ubuntu, mais impossible d'installer le serveur X, pourtant j'y ai passé du temps à lire le (très bon) wiki de Arch Linux.
            Donc bon, la console c'est bien, mais la sourie aussi.
            Et du coup je suis passé sur Debian et j'y suis toujours et j'y suis bien (sauf en période de freeze)

            Testes sid/experimental alors.
            Par contre, avec ça, faut pas s'étonner si le comportement du PC change sans trop prévenir ou si des problèmes apparaissent.

            Je sais que j'en demande beaucoup mais les côtés "le comportement du PC change sans trop prévenir" ou "des problèmes apparaissent" me dérangent un peut.

            Le but est il de trouver des solutions, ou bien des bonnes questions ?

            • [^] # Re: Présence dans Debian

              Posté par . Évalué à 1.

              Je sais que j'en demande beaucoup mais les côtés "le comportement du PC change sans trop prévenir" ou "des problèmes apparaissent" me dérangent un peut.

              Pour être franc, cette phrase est plus de l'ordre du "disclaimer". Genre, si un utilisateur de gnome était en sid au moment ou gnome 3 est passé dans experimental/sid, bah les gens qui font des mises à jour sans regarder les numéros de version ont dû avoir un choc.
              Le but d'experimental et de sid sont bien portés par leur nom: c'est pas de tout faire pour pourrir les bécanes des utilisateurs, mais ces dépôts servent de tampon, avant la testing, qui est la future stable.

              Mais perso, je n'ai rien noté de tel depuis 1 an que je suis en sid. Après, c'est vrai aussi que le DE que j'ai utilisé l'an dernier, c'était XFCE4, et puis je suis passé à juste un gestionnaire de fenêtre en tuile, donc les changements majeurs qui bouleversent mes habitudes… bah… j'en ai pas vus.
              Et pourtant, j'utilise même la version de dev de plusieurs logiciels: code::blocks et i3, notamment.

            • [^] # Re: Présence dans Debian

              Posté par . Évalué à 5.

              Donc bon, la console c'est bien, mais la sourie aussi.

              Aucun souci, pas besoin de Xorg : pacman -S gpm,, suivi de systemctl enable gpm et te voila apte à utiliser ta souris à loisir !
              (Et tu peux même cliquer sur les menus dans links, quand tu va sur le web !)

              Enfin, moi mon installation de Xorg s'est bien passée, résultat je suis resté sous ArchLinux. Peut-être que si un jour tu ré-essaie, tu aura plus de chance ? Note, le wiki d'Arch, c'est bien, mais ce n'est pas mal non plus d'être abonné au flux rss des news ArchLinux.org, qui indiquent quand il y a des mises à jour avec des détails à savoir, ou qui nécessitent une intervention manuelle. Peut-être qu'à l'époque, c'était un problème temporaire et tu aurai pu trouver la réponse à cette endroit ?

      • [^] # Re: Présence dans Debian

        Posté par (page perso) . Évalué à 4.

        ça tombe bien, c'est un sujet de discussion récurrent et tu as la liste des propositions :
        http://wiki.debian.org/ReleaseProposals

        • [^] # Re: Présence dans Debian

          Posté par . Évalué à 1.

          Effectivement on dirait que c'est un sujet très en vogue !
          Merci pour le lien.

          Le but est il de trouver des solutions, ou bien des bonnes questions ?

  • # Support d'OpenGL 3.0 pour la famille nv50

    Posté par (page perso) . Évalué à 6.

    Un autre point qui n'a pas été documenté est le support d'OpenGL 3.0 pour la famille nv50 des cartes nvidia. Cela met le driver mesa nv50 à parité avec le driver nvc0.

    Je n'ai pas d'infos sur ce qu'il manque à faire pour supporter OpenGL 3.1 sur Nouveau.

    • [^] # Re: Support d'OpenGL 3.0 pour la famille nv50

      Posté par (page perso) . Évalué à 2.

      Ici la correspondance pilote/carte pour ceux intéressés
      Martin : dommage que ça n'ait pas été documenté !

      • [^] # Re: Support d'OpenGL 3.0 pour la famille nv50

        Posté par (page perso) . Évalué à 2.

        Martin : dommage que ça n'ait pas été documenté !

        Je sais… Mais comme presque tout mesa/nouveau est développé par une seule personne, je vais pas trop lui en vouloir si en plus il documente pas tout ce qu'il fait…

        Faudrait vraiment que quelqu'un vienne l'aider!

        • [^] # Re: Support d'OpenGL 3.0 pour la famille nv50

          Posté par (page perso) . Évalué à 4.

          le pauvre, c'est pas marrant le développement solo :-/

        • [^] # Re: Support d'OpenGL 3.0 pour la famille nv50

          Posté par . Évalué à 3.

          Faudrait vraiment que quelqu'un vienne l'aider!

          Il n'y a pas de ponts entre les équipes des pilotes Intel, Radeon et nOUVEAU?

          C'est assez drôle de noter que pour un domaine qui sert de support essentiel au "visuel" à savoir serveurs graphiques, pilotes gfx, c'est assez obscure.
          Il a fallu attendre tes récentes initiatives et le coup de balais Wayland pour y voir quelque chose.

          • [^] # Re: Support d'OpenGL 3.0 pour la famille nv50

            Posté par (page perso) . Évalué à 6.

            Il n'y a pas de ponts entre les équipes des pilotes Intel, Radeon et nOUVEAU?

            Si si, le code est partagé au maximum. Enfin, à part Intel qui refuse de bosser sur Gallium, mais c'est une autre histoire.

            Mais quand je dis qu'il n'y a qu'un seul développeur à travailler sur mesa/nouveau, je veux dire qu'il n'y a qu'une personne qui bosse sur le support de la 3D pour les cartes nvidia (et il est étudiant en physique). Il écrit le code des compilateurs qui transforment la représentation intermédiaire gallium en code machine pour les cartes et gère le runtime ((sous-)allocation de buffers, fences, etc…).

            Il a fallu attendre tes récentes initiatives et le coup de balais Wayland pour y voir quelque chose.

            Je dirai plutôt que c'est la modularisation du serveur X qui a rendu tout ça possible. Ça reste un énorme sac de noeud mais on avance! Quant à mes interventions, elles ne me permettent juste que de voir à quel point j'ai encore rien compris… Pour info, si ça t'intéresse, les présentations faites par les "X-men" à LCA cette année sont vraiment excellentes!

  • # Aider les développeurs

    Posté par . Évalué à 4.

    Je me demandais, les glitchs graphiques dans un jeu, c'est dû à un bug/quelque chose de non implémenté dans mesa, ou dans les drivers de mon chipset graphique (une ATI Radeon Xpress 1150, avec ati-dri et xf86-video-ati) ?

    Par exemple sous Darwinia, certaines surfaces perdent leur texture, quand elles n'essayent pas de se relier entre elles :
    Darwinia

    Est-ce que je peux aider d'une façon ou d'une autre à corriger ça ?

    • [^] # Re: Aider les développeurs

      Posté par (page perso) . Évalué à 2.

      Je me demandais, les glitchs graphiques dans un jeu, c'est dû à un bug/quelque chose de non implémenté dans mesa, ou dans les drivers de mon chipset graphique (une ATI Radeon Xpress 1150, avec ati-dri et xf86-video-ati) ?

      C'est un bug, oui. Met à jour pour utiliser les dernières versions de tout et si le problème persiste, contacte les devs (bug report ou IRC).

      • [^] # Re: Aider les développeurs

        Posté par . Évalué à 2.

        D'accord, mais qui est concerné ?
        Pour les versions, je suis sous Arch et ce problème existe depuis que je l'ai essayé (je n'y ai jamais vraiment joué vu que je ne dépasse pas les 20FPS sous Linux).

        • [^] # Re: Aider les développeurs

          Posté par (page perso) . Évalué à 2.

          D'accord, mais qui est concerné ?

          Dur à dire, mais je te conseille d'envoyer cette capture d'écran sur #dri-devel et de demander si ils connaissent le bug. Cela dit, j'en doute car j'ai rien sur la mailing list dri-devel. Ensuite, faudra remplir un bug report.

          Pour les versions, je suis sous Arch et ce problème existe depuis que je l'ai essayé (je n'y ai jamais vraiment joué vu que je ne dépasse pas les 20FPS sous Linux).

          Très bien, déjà t'es à jour.

    • [^] # Re: Aider les développeurs

      Posté par . Évalué à 1.

      J'ai le même genre de chose avec une ATI RC410 et les mêmes pilotes, en tout cas. Si je peux aider en quoi que ce soit pour le rapport de bug, contacte-moi !

Envoyer un commentaire

Suivre le flux des commentaires

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