• # Bof

    Posté par  . Évalué à 4.

    Le truc dommage, c'est qu'ils vont devoir refaire plein de développement après, pour pouvoir passer sur gallium (enfin, d'après ce que j'ai compris).
    Mais sinon c'est un joli coup, en effet.

    • [^] # Re: Bof

      Posté par  . Évalué à 2.

      > passer sur gallium

      C'est Nouveau qui passe à Gallium. De ce que je sais, ATI ne passe pas à Gallium.

      • [^] # Re: Bof

        Posté par  . Évalué à 10.

        ATI ? AMD, tu veux dire ? Ca, je n'en sais rien... j'évite fglrx comme la peste.



        ... par contre, pour ce qui est des drivers libres, ils vont tous passer à la casserole, à un moment ou à un autre, en ce qui concerne Gallium3D...

        Phoronix [1] fait d'ailleurs état de travaux sur un driver libre "Radeon MS" qui devrait utiliser Gallium3D ; apparemment, il implémente surtout une initialisation propre des cartes pour l'instant, et devrait fusionner avec le driver libre Radeon actuel...



        Driver Radeon qui se tire la bourre (façon de parler) avec RadeonHD (celui dont les progrès sont relatés dans le journal), en ce moment, sur l'utilisation ou non des AtomBIOS (BIOS proprios des cartes, servant de couche d'abstraction pour éviter de taper directement dans les registres du GPU... pour info, AMD vient de lâcher les dernières versions, apparemment librement redistribuables, à la communauté... reste que l'entièreté des AtomBIOS ne sera sans doute pas documentée, notamment les parties aidant au décodage matériel des codecs "type HD", puisqu'apparemment matériellement trop liés à la gestion des drm)...

        - Radeon veut utiliser AtomBIOS (et le fait) ;
        - RadeonHD veut utiliser les registres et (presque) pas AtomBIOS (et le fait) ;
        - AMD veut que le driver libre utilise AtomBIOS (et semble faire pression sur les gars de RadeonHD pour qu'ils l'utilisent) ;

        ... du coup, c'est un peu le bordel... il semble que RadeonHD ait un support plus propre des R500/R600, pour l'heure, mais l'implémentation est plus lente, puisqu'ils n'utilisent pas trop AtomBIOS en guise de framework, mais tapent plutôt dans les registres à l'ancienne...

        Radeon se met cela dit à supporter les R500 et R600 (a priori à partir des versions 6.8.x du driver), et pourrait, grâce à AtomBIOS, implémenter le support de nouvelles cartes plus rapidement que RadeonHD...

        De toute façon, pour l'heure, l'essentiel des efforts semblent se concentrer sur le support de toute la gamme en 2D/3D via l'actuel DRI, afin de ne pas laisser des possesseurs de GPU ATI/AMD sur le carreau (enfin, avec fglrx ou vesa, mais pour ce que ça change)... et Gallium3D de partout est encore lointain...



        Perso, ce qui m'intéresserait le plus serait de voir revenir le support du multi-GPU avec randr1.3 dans xserver 1.5 (soit X.org 7.4)... avec mes X800XL en tri-écran, le plus simple est encore de se limiter à X.org 7.2 et le vieux driver radeon sans randr 1.2 (et pas d'accélération... mais au moins, ça marche bien en 2D et avec Xv)... et ça risque d'arriver plus tôt que Gallium3D (que ses propres développeurs qualifiaient il y a moins d'un mois de "plus ou moins au stade alpha" [1, cf première page])...



        Bref, ça bouge, dans le clickodrome... il y a plein de bonnes choses à venir (notamment, l'implémentation de nouveaux codecs dans XvMC par Intel, et même le futur remplaçant de XvMC, toujours par Intel, à savoir VA-API), on a presque la doc des 2/3 des fabricants (AMD en lâche beaucoup, ces temps-ci), ... il ne reste plus qu'à attendre (pour les pauvres mortels comme moi, qui ne peuvent que baver devant l'évolution, voire tout au plus bugreporter) ou à contribuer (pour les fous furieux à qui l'on doit toutes ces jolies couleurs)...

        ... après la longue période de modularisation, qui dut suivre l'enracinement chronique pre-X.org, chez XFree86, qui s'en plaindra ?



        [1] http://www.phoronix.com/scan.php?page=article&item=galli(...)

        • [^] # Re: Bof

          Posté par  . Évalué à 5.

          c'est tellement le bousin entre radeonhd et radeon que même toi tu les confonds ! c'est pourtant simple :

          Alex Deucher commence à faire tourner glx_gears sur le driver ati libre (ou radeon) pendant que de l'autre côté, Alex Deucher libère des docs sur la programmation 3D des cartes AMD/ATI (vu qu'il travaille chez AMD/ATI depuis quelques mois) utilisables par l'équipe radeonhd hébergée chez opensuse...

          • [^] # Re: Bof

            Posté par  . Évalué à 1.

            Tout à fait ! Mea culpa pour ce couper/coller malencontreux (je l'avais écrit plus loin, ai voulu le remonter, et me suis pris les pieds en plein dedans)...

    • [^] # Re: Bof

      Posté par  . Évalué à 3.

      Ben gallium est encore en développement et aucune carte ne marche de manière stable dessus.

      Même intel ne sait pas s'ils resteront sur mesa-dri ou passeront sur gallium [1].

      Et puis mesa-dri n'est pas prêt de disparaître vu le nombre de carte qu'ils supporte (et le boulot que ca serait de tous les porter).

      Ca me rappel les drivers ralink qui utilisait la stack wifi dernier cri (qui n'était pas dans le noyau) alors que d'autre continuait à développer sur l'ancienne : les drivers ralink était très compliquer à utiliser.

      [1]
      http://article.gmane.org/gmane.comp.video.mesa3d.devel/10087
      If existing DRI drivers
      get to continue living side-by-side with gallium stuff, then until
      gallium proves to be a significant win for our chipsets we can go ahead
      and ignore it, it sounds like.

      • [^] # Re: Bof

        Posté par  . Évalué à 10.

        La tendance c'est que nouveau, radeon (à partir des r300) et intel (à partir des i915) passeront à gallium3d et le reste restera avec les drivers actuel. La raison en est un simple il n'y pas assez de développeurs seul nouveau à une équipe assez grosse. Pour intel il attende d'avoir un driver gallium3d plus ou au moins aussi performant que leur driver actuel.

        Sur radeon il y a cet guerre entre radeon & radeonhd qui est catastrophique car les deux équipes non pas la même vision de ce qui doit être fait. Chacun travail donc dans le sens qui lui semble être le bon. Je ne dis pas que je sais ce qui est mieux à faire, seulement qu'au final ca détruit la productivité. Chez nouveau Stéphane c'est le despote qui dit on fait modesetting randr 1.2, EXA, puis 3D gallium et tout le monde travail dans le même sens.

        Comme quoi des despotes comme Linus ca a du bon. Je rapelle au passage que la dictature, d'un point de vu mathématique, est l'un des systèmes les plus démocratique :)

        • [^] # Re: Bof

          Posté par  . Évalué à 4.

          D'après le site de Tungsten Graphics : http://www.tungstengraphics.com/wiki/index.php/Gallium3D ils vont développer un drivers pour intel i965 qui aura les même fonctionnalités que l'actuel. C'est d'ailleurs avec un driver cell, les seuls qu'ils développent si on regarde le git : http://gitweb.freedesktop.org/?p=mesa/mesa.git;a=tree;h=1173(...)
          (les gars de TG sont des dev majeurs niveau Xorg/Mesa si on regarde leur équipe : http://tungstengraphics.com/about.htm ).

          Après ils peuvent dire que c'est du alpha, je trouve que c'est un code qui marche bien : sans cracher sur le super boulot d'Alex Deucher & Dave Airlie, sur nouveau avec une NV40, on a openarena qui tourne plus que correctement (un ptit howto pour les têtes brulées. ATTENTION : pas de support de la part des dev pour l'instant : si ça marche pour vous tant mieux, sinon tant pis : donc pas de rapport de bug, ni de plainte sur IRC, évidemment sauf si vous avez un patch qui règle le soucis :-) http://nouveau.freedesktop.org/wiki/GalliumHowto ), après le support commence pour les autres cartes, mais le projet est très ambitieux : support des cartes depuis les RIVA TNT jusqu'au dernières GeForces.

        • [^] # brainstorming

          Posté par  . Évalué à 4.

          La cible est le modesetting/TTM dans Linux.
          Le reste en user space avec Gallium3D.

          Les interfaces pour le modesetting dans le kernel sont toujours en brainstorming intense (c'est pour ça que marcheu sur nouveau pousse sur randr1.2 en user space). Le TTM semble assez stable mais je n'y mettrais pas ma main à couper. Pour ce qui est de Gallium3D, on en est vraiment au début, il va certainement y avoir pas mal de modifications.

          Pour OpenGL3, rien en vue. Carmak a fait une conférence comme quoi un des moyens les plus sûrs dans le design d'APIs est de faire du code avec mise en condition réèlle... c'est ce qui se passe actuellement autour de la nouvelle pile graphique pour Linux. Je ne serais pas étonné si les designers d'opengl3 suivent de près la conception de cette pile.
          Le pb principal est qu'opengl2 n'est plus du tout adapté aux GPUs modernes ce qui rend la conception d'un driver un vrai cauchemard. La nouvelle pile graphique pour Linux veut des interfaces modernes et donc fait un break avec l'esprit d'opengl2 (il y aura la compatibilité avec opengl2 via mesa).

          Une chose, les GPUs deviennent épouvantablement complexes, ce qui va rendre leur reverse engineering presque déraisonnable. En gros, c'est maintenant qu'il faut agir.

          • [^] # Re: brainstorming

            Posté par  . Évalué à 4.

            Non le reverse engineering ne devient pas déraisonnable ; effectivement les GPU deviennent de plus en plus des CPU et faire le reverse engineering d'un CPU c'est facile :). Naturellement il y a des choses difficiles a bien saisir avec le RE je pense par exemple à la synchronisation des textures unit sur R500. Mais l'un dans l'autre au final c'est en plus facile qu'avant mais ca demande plus de temps ou une bonne organisation.

        • [^] # Re: Bof

          Posté par  . Évalué à 4.

          Chez nouveau Stéphane c'est le despote qui dit on fait modesetting randr 1.2, EXA, puis 3D gallium et tout le monde travail dans le même sens.

          Je pense surtout que pour Nouveau, chaque développeur bosse sur une partie différente des autres. C'est rare que l'on se marche sur les pieds. Si on regarde http://nouveau.freedesktop.org/wiki/FeatureMatrix et que l'on imagine chaque case du tableau comme une tâche à réaliser, on pourrait presque mettre un développeur de Nouveau par case.

          Bon, évidemment, on n'a pas assez de développeurs pour remplir tout le tableau :). En ce qui me concerne, seule la 3D m'intéresse, je laisse les autres s'occuper du reste. Gallium3D est un gros morceau à digérer quand même (sans parler des shaders programs que je connais pas trop encore), mais sûrement plus simple au final que les drivers DRI actuels dans Mesa, qui ont beaucoup de code dupliqués entre eux.

Suivre le flux des commentaires

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