Journal Réponse de David Reveman à Nvidia

Posté par  (site Web personnel) .
Étiquettes : aucune
0
23
fév.
2006
Voila, j'ai envoyé un mail à David pour lui demander de répondre aux arguments de Nvidia comme quoi Xgl serait un mauvais choix, apparement je ne suis pas le seul à avoir fait cette demande, il a donc posté sur la mailing list xorg une réponse complete dans laquelle il explique ca vision des choses: En gros, Xgl n'arrange pas trop Nvidia.

http://lists.freedesktop.org/archives/xorg/2006-February/013(...)

Le papier de Nvidia:
http://download.nvidia.com/developer/presentations/2006/xdev(...)
  • # Alors, qu'en penser

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

    La chose la plus importante que je note est quand meme que les prochains driver nvidia vont faire fonctionner compiz avec Xorg comme il fonctionne actuellement avec Xglx. Déjà ca va faire beaucoup de tord au projet :(

    Mais j'espere que David va pas se décourager, c'est quand meme le seul à vouloir vraiment tenter une grosse évolution de X et il a peut être raison en pensant que la meilleur solution est de toute basé sur OpenGL.

    Les arguments de Nvidia sont en gros: On veut pas Xgl, ca va tout casser ce qu'on a dans nos drivers, y'a pas moyen...
    • [^] # Re: Alors, qu'en penser

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

      SGI utilise bien OpenGL pour l'affichage de son serveur X, ça a donc déjà été testé/éprouvé. Par contre il est clair que l'archi d'un PC n'a rien à avoir avec celle d'une station SGI ...
      • [^] # Re: Alors, qu'en penser

        Posté par  . Évalué à 5.

        Il me semble pourtant que les dernieres stations SGI en date sont basées sur des processeurs Intel.
        • [^] # Re: Alors, qu'en penser

          Posté par  . Évalué à 2.

          Oui certaines, mais pas toutes...

          Pour les stations de travail, un modèle (Prism) tourne sous Linux (avec processeur Intel) et deux (Fuel et Tezro) sous Irix (processeur MIPS).

          http://www.sgi.com/products/workstations/

          Pour les serveurs, la proportion s'inverse...

          http://www.sgi.com/products/servers/
          • [^] # Re: Alors, qu'en penser

            Posté par  . Évalué à 3.

            En prime, les processeurs intel chez SGI, ca a plutot tendance a etre de l'Itanium, qui n'a rien a voir avec l'architecture PC.
        • [^] # Re: Alors, qu'en penser

          Posté par  (site Web personnel) . Évalué à 8.

          Le processeur ne fait malheureusement pas tout. Les architectures à mémoire unifiée que SGI a développé pour ses stations ne sont pas comparable avec celle de nos PC. À la rigueur, les portables qui utilisent une partie de la mémoire centrale pour le framebuffer, les textures & cie s'en rapproche mais ne tiennent pas longtemps la comparaison.

          En effet, sur ces portables, le processeur, le chipset et la mémoire sont sur le même bus et le système graphique passe par l'AGP/PCIe (et donc le chipset) pour accéder à la mémoire centrale. il en est de même pour toutes les E/S.

          Sur les SGI Visual Workstation (la gamme à base de proc Intel), le proc, la proc graphique, le proc sonore ainsi que le chipset sont en attaque directe sur le controleur mémoire et seules les E/S genre clavier/souris/ddur/carte fille sur PCI doivent passer par le chipset. De plus les accès mémoire sont fait via un crossbar, système qui permet à chaque composant d'accéder en même temps à la mémoire (avec bien sûr des cas particuliers de conflit qui sont gérés en hard).

          Je n'ai malheureusement pas d'exemples concrets à te donner car il n'existe pas beaucoup de doc sur ces stations (trop chères comparées à une gros PC). Mais je peux t'en donner un sur les SGI O2 qui ont une architecture dont s'inspire celle des SGI Visual Workstation.

          Comme la mémoire est partagée, une application qui passe un buffer à OpenGL pour définir une texture ne fait que donner l'adresse mémoire (il n'y a donc pas de recopie dans la mémoire graphique, d'où un certain gain). De plus, la mémoire étant partagée, une modification du buffer par l'application se répercute immédiatement à l'écran puisqu'il n'y a pas de transfert à effectuer. Utiliser une vidéo comme texture est de facto très facile à réaliser et n'est pas gourmand pour un sous (à part le décodage bien sûr;)

          Ressortir une telle architecture avec les possibilités actuelles (HyperTransport & cie) permettrait sans doute de redonner un sérieux souffle au PC mais serait-ce encore un PC ?
  • # arguments ?

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

    "So far I haven't heard a single argument for why X on OpenGL is a a bad idea other than that it's a big step and a lot of work will have to be
    done."

    euh.. j'ai un ordi sans carte 3D. J'aimerais continuer à l'utiliser. Non ?
    • [^] # Re: arguments ?

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

      "Voulez-vous activer le support OpenGL pour le serveur d'affichage ?
      Attention : fonctionnalité non supportée par les anciennes cartes graphiques - si vous ne savez pas répondez non"

      T'as entendu parler de la section Modules de xorg.conf ? :)
      • [^] # Re: arguments ?

        Posté par  (site Web personnel) . Évalué à 8.

        On parle de Xgl la, un serveur X uniquement basé sur OpenGL.

        Mais bon, David parle du long terme la, d'ici que Xegl soit pret, y'aura plus une carte sans processeur 3d de vivante... Et puis cela n'empechera pas d'utiliser Xorg si il te reste une vieille carte 2D.
        • [^] # Re: arguments ?

          Posté par  . Évalué à 3.

          Le problème n'est pas seulement d'avoir un matériel 3D mais le pilote qui va avec (libre le pilote, il va de soi).
      • [^] # Re: arguments ?

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

        Il s'agit de deux serveurs X différents non ? (quoique je comprenne rien à la technique)

        Si c'est le cas, je vois bien les distros n'en proposer qu'un seul sur le CD-rom, par manque de place... Et tu vois peut-être ce qui m'inquiète.

        En même temps, c'est juste une question hein.
        • [^] # Re: arguments ?

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

          Mwai, enfin Xegl il reutilise 80% du code de Xorg, c'est juste le serveur qui est différent. Il va pas faire 50Mo le serveur X.
          • [^] # Re: arguments ?

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

            Bah si ! Pourquoi changer les bonnes habitudes ?

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

    • [^] # Re: arguments ?

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


      Un argument qui est avancé encore et encore est que nous ne devrions pas utiliser OpenGL en raison de tout l'ancien matériel en service dans les pays en voie de développement. Il y a deux solutions à ce problème. D'abord, OpenGL est une API extensible. Par l'intermédiaire de solutions de rechange logicielle (fallbacks) elle est capable de fonctionner sur le plus petit matériel. OpenGL ES fournit également des profils d'API. Les profils sont des sous-ensembles bien définis de l'API OpenGL. Si nécessaire nous pourrions définir un profil minimum couvrant la plus petite API OpenGL possible. La taille du code ne devrait pas être un problème, une implémentation propriétaire d'OpenGL ES de 100 Ko est disponible. Un profil OpenGL supplémentaire ne nécessite pas un support de la virgule flottante. Rien n'empêche de réaliser des équivalents en open source si nous choisissons d'y consacrer les ressources.

      L'autre argument est simplement d'exécuter du logiciel qui a été conçu pour fonctionner sur le matériel en service. Personne ne s'attend à ce qu'un IBM PC fasse fonctionner Windows Longhorn mais le même PC continue à faire fonctionner DOS sans problème.

      Le point essentiel ici est qu'OpenGL est plus extensible qu'EXA. L'extensibilité d'EXA est incomplète au plus haut point, elle ne couvre pas des fonctionnalités avancées du GPU comme la 3D et la programmabilité. Avec OpenGL il est possible d'avoir une seule API pour tout : du téléphone cellulaire au superordinateur.


      http://linux.tlk.fr/traitement-graphique/
      Jon Smirl - 30 août 2005 - Ancien développeur Xegl
  • # On pourrait pas simplifier ce bordel ?

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

    Je vais encore me moinsser mais là la moutarde me monte au nez.

    Ca fait pas mal de temps que je suis ça de loin, car j'aimerai bien avoir un bôô desktop 3d, joli, apaisant comme Aqua (Oui m'dame, je trouve que MacOS X c'est beau et apaisant) et je suis les pérégrinations quasi politiques des interminable débats sur le design du serveur X.

    Heureusement, on possède cet excellente document (merci à son auteur) qui nous permet d'y voir clair, à condition d'avoir le courage de tout lire jusqu'au bout (ça n'enlève rien à l'excellence du contenu de cet article et de sa présentation)
    http://linux.tlk.fr/traitement-graphique/

    On y apprend que le projet X fait 16 millions de lignes de code, et qu'on est en train de le modulariser. Fort bien, il était temps.

    Je veux bien que les pauvres dev (franchement, je les admire) s'amusent avec leur quasi assembleur (le C(oui je sais, je suis lourd avec ça)) à gérer les différends Unix dans lesquels les services offerts par l'OS est pas le même et etc.. , mais j'ai vraiment l'impression que X devient une usine à gaz immensément bordélique.

    Il faudrait

    - Un pilote en mode noyau, s'occupant de la vidéo, du pci/agp, du calvier, de la souris, etc... Sur *BSD on ferait un système autonome, sous Linux on utilise l'existant.
    - Un framebuffer collectant toutes les demandes de dessins des API de fenêtrages avec plusieurs implémentation d'API. Un fb en 3D serait l'idéal avec la possibilité d'utiliser une norme (comme OpenGL, DirectX) en tant que driver comme le préconise justement Jon Smirl.

    Puisqu'il s'agit de politique, a quand les entreprises du secteurs (au hasard RedHat, Mandriva, Novell, ?) se mettront-elles d'accord pour développer un et un seul ensemble de projets cohérants entre eux et pas la friture entre Novelle qui veut Xgl et Mandriva quie veut Xegl ?

    Moi je parie que quand des langages haut niveau iront aussi vite que le C, on risque de voir des projets alternatifs...

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

    • [^] # Re: On pourrait pas simplifier ce bordel ?

      Posté par  . Évalué à 7.

      Il y a aucune friture entre XGL/XeGL/AIGLX, puisque XeGL découle de XGL, que du code est commun à AIGLX et XGL et qu'au final ce qui est fait pour l'un marchera pour l'autre. Ces projets permettent de répondre à des besoins de manière différente, une enjambée pour l'un et un pas pour l'autre.

      Comme d'hab c'est surtout les fanboï de tout bord qui compliquent inutilement l'histoire...

      Ah pis tu as oublié de mentionner lisaac ça fait tout drôle :)
      • [^] # Re: On pourrait pas simplifier ce bordel ?

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

        Ah pis tu as oublié de mentionner lisaac ça fait tout drôle :)
        Oui, maiiiiis tu vooiiiis, vu que le compilateur est pas encore liiiiiiibre, je peux pas trop le défendre.
        On attend toujours ces messieurs de l'INRIA (étude en cours).

        C'est dommage car dans quelques temps on aura un compilateur tout frais entièrement réécrit, et là je pense que pour ce genre d'application, il sera parfait.
        Et ça sera même possible tiens parce que la librairie fenêtre est entièrement écrite en Lisaac, en se basant sur le putpixel ou le put_bitmap_line. Et le code est libre.

        Rest à faire les binding pour gtk, qt, etc... Simuler la xlib aussi.

        Ce serait un bôôô projet ! ;-)

        « 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 à ceux qui les ont postés. Nous n’en sommes pas responsables.