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(...)
Journal Réponse de David Reveman à Nvidia
23
fév.
2006
# Alors, qu'en penser
Posté par gnumdk (site web personnel) . Évalué à 3.
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 Rémi Hérilier . Évalué à 3.
[^] # Re: Alors, qu'en penser
Posté par David . Évalué à 5.
[^] # Re: Alors, qu'en penser
Posté par galatea842 . Évalué à 2.
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 imalip . Évalué à 3.
[^] # Re: Alors, qu'en penser
Posté par Rémi Hérilier . Évalué à 8.
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 ploum (site web personnel, Mastodon) . Évalué à 6.
done."
euh.. j'ai un ordi sans carte 3D. J'aimerais continuer à l'utiliser. Non ?
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: arguments ?
Posté par Sufflope (site web personnel) . Évalué à 5.
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 gnumdk (site web personnel) . Évalué à 8.
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 Sylvain Sauvage . Évalué à 3.
[^] # Re: arguments ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 6.
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.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: arguments ?
Posté par gnumdk (site web personnel) . Évalué à 4.
[^] # Re: arguments ?
Posté par Ontologia (site web personnel) . Évalué à 3.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: arguments ?
Posté par Bruno Ethvignot (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 Ontologia (site web personnel) . Évalué à 4.
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 Jean Roc Morreale . Évalué à 7.
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 Ontologia (site web personnel) . Évalué à 2.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.