>Et ? j'ai dis "grosses évolutions", il est donc tout à fait possible de faire des évolutions sans
>toucher aux interfaces, et quand l'interface doit absolument bougée (ce qui normalement ne
>doit pas arriver souvent lorsqu'elle est pensée), ben suffit d'en faire une nouvelle tout en
>gardant l'ancienne, par soucis de compatibilité.
Si tu veux voir ou ca meme ce genre de politique regarde le code d'xorg partie ddx/dri/drm (radeon par exemple) le code est très difficile à lire même pour quelqu'un qui le connais bien. Je pense dc que de ce point de vue le noyau a raison. Néanmoins Xorg n'a pas les même contrainte que le kernel, on peut comprendre leur soucis de rétrocompatibilité.
Merci de donner ses liens, j'avais la flemme de les retrouver :) Juste un petit commentaire sur x-window disaster de nombreux problèmes présentés sont aujourd'hui réglés (ne pas oublier que cela à été écrit aux début des années 90 et 10 ans en informatique c'est une éternité :))
Enfin en ce qui concerne le rendu type postscript, cairo commence à s'imposer, sans pour autant interdire l'existence de programmes qui voudraient controler le rendu au pixel près.
Le deuxième lien est une critique bcp plus constructive de X.
Décidement je n'arrête pas de défendre Xorg (je vais avoir droit à t-shirt non ? ;)). Le protocol X11 me semble vraiment quelques choses de très robuste et bien conçue (avec quelques points noir).
Ce protocole à aujourd'hui une place de choix dans l'industrie. Il me semble donc inutile de vouloir tout changer en abandonnant un protocol qui a plus que fait ses preuves. On passera un jour au protocol X12 (à cause de certaines limites d'X11).
Le problème ici présenté viens plutot de l'architecture x86 et de l'implémentation des drivers dans le server X (implémentation qui fait aujourd'hui l'object de nombreux travaux voir par exemple la présentation d'Egbert Eich au FOSDEM).
Pour toute personne désirant approfondir ses connaissances d'X je conseille de lire l'article de wikipedia ainsi que les liens fournit dans celui-ci.
Toute personne saine (j'ai bon pour l'orthographe ? ;)) d'esprit n'utiliserait pas fbdev quand une acceleration et disponible et encore une fois ici seul linux (a ma connaissance et d'après man fbdev) posséde un module fbdevhw.
Enfin l'interface définit par fbdev me semble trop minimaliste pour tirer profit des cartes graphiques d'aujourd'hui. Mais la solution qui me semble la plus adapter pour régler ce problème est bien celle d'un module noyau pour chaque carte graphique. Ce module s'occupant des tâches sensible et pénalisant le moins possible l'accés à la carte graphique et à ses fonctionalités. Une grande partie du driver de la carte resterait néanmoins en user mode (facilitant la programmation et aussi le portage sur différent OS).
Néanmons cette solution ne me semble pas réalisable dans un avenir proche aux vues de la pluralitées des systèmes supportés par Xorg.
Je suis trop jeune pour connaitre les raisons qui ont poussées à abandonner le projet Utah-GLX. Il me semble néanmoins (j'ai une connaissance très limité d'utah dc pardonnez mes erreurs) que le problème été justement la sécurité.
Le module DRM du noyau est vraiment minimaliste pour chaque carte video. Il "scan" les packets de command qui pourrait être dangereux, grosso modo tous les packets qui concernent le transfert de donnée entre la CG et la ram ou la ram et la CG. Il vérifie donc que le processus qui envoit les commandes à le droit d'accéder à la plage d'addresse spécifier. Pour le reste le DRM se contente de faire un bete copier coller (pas exactement ca) des commandes vers la carte graphiques.
Il me semble, mais je peux me tromper, que le meilleur endroit pour faire ce genre de controle c'est dans le noyau. C'est pourquoi utah présentait un modèle 'moins secure'.
Normalement Xegl devrait résoudre se problème car les parties critiques de la programmation de la carte video auront lieux dans un module du noyau (DRM) qui vérifiera que les opérations qu'on lui demande ne pose pas de problème. Cependant comme l'implémentation d'Xegl est loin d'être terminé, actuellement on ne peut pas évaluer sa robustesse (point de vue sécu).
Cependant comme je le disais dans un poste plus haut 99% des développeurs d'Xorg s'occupent d'autre chose qu'Xegl car pour le moment Xegl ne pourrait fonctionner que sur linux ou freebsd et donc ce n'est pas une solution envisageable à cour terme car Xorg supporte aussi solaris, openbsd, netbsd et d'autres OS.
Donc pas d'accélération du passage à Xegl. De plus des OS comme OpenBSD n'accepteront certainement que des drivers open source pour les cartes graphiques (ca c'est bien :)).
Argh décidement l'orthographe sera toujours mon pire ennemi :)
Sinon petite précision supplémentaire (je viens d'y penser après un petit tour sous gdb ^^) il est bcp plus facile de faire du "reverse engineering" (j'aime pas trop l'expression francaise :d) d'un driver en user mode qu'un driver dans le noyau.
Je pense notament à la lecture des registres (mmio) ou encore au "man in the middle" (bcp plus dure mais tellement plus instructif).
Quand on voit que le seul constructeur à fournir ses spécifications compléte est intel, on ne peut que penser que le reverse engineering est nécessaire. Enfin c'est mon opinion (j'aime pas les blobs binaires dans le noyau >->)
Xorg (XFree86) est vieux, très vieux. Il y a quelques années peux de systèmes d'exploitation offraient une interface intéressante pour accéder aux BUS PCI et aux matériel. A l'époque XFree86 a donc développer ses propres routines d'accés aux bus (PCI, ISA, ...) et ses drivers. Mais pour ne pas reécrire 50 fois la même chose les drivers ont étés réalisés en user mode (pas besoin d'écrire un driver pour chaque OS et X tourne sur bcp d'OS (solaris, bsd, vm, linux, ...)).
Les dévelopeurs d'Xorg ont bien conscience qu'aujourd'hui ce schéma posse problème. Ils réflechissent à comment évoluer vers un système plus sein, et ce bien avant la publication de Loic. Seulement l'impératif pour les développeurs c'est de ne pas tout casser du jour au lendemain mais de progresser petit à petit.
Par exemple actuellement bcp de développement porte sur l'utilisation du librairie générique d'accés aux bus pci (agp, pcie, ...) qui utiliserait le noyau (bsd, solaris, linux, ...).
Par ailleur pour complétement s'affranchir du problème il faudrait un modèle de driver comme celui utiliser par le DRI avec un module noyau (DRM). Mais pour le moment cette solution n'est pas envisageable car trop peux de noyaux ont l'architecture DRM (linux et freebsd seulement).
Cependant sun a commencé à développer un DRM pour le noyau solaris. Il faudrait qu'OpenBSD face de même ainsi que netbsd et les principaux OS aujourd'hui "officielement" supportées aurait l'architecture nécessaire pour un modèle de driver graphique "secure".
Nota bene: DRM c'est pas pour Digital Right Management mais pour Direct Rendering Manager
Voila, il ne faut donc pas cracher sur les développeurs d'Xorg (c'est pas gentil ;)) de plus très peux d'entre eux travaillent activement sur Xgl ou AIGLX, la grande majoritée s'occupe de retravailler Xorg afin de corriger les bugs de conceptions et de repartir sur des bases solides (XCB, Xinput, libpci, ...).
Tu trouveras certainement des benchmarks sur internet (sur des sites comme tomshardware). Néanmoins ces cartes sont plus que suffisante pour faire tourner Xgl (actuellement bcp des développeurs d'Xgl utilisent des cartes intel) et elles possédent d'ailleur le meilleur support.
Elle supporte aussi les pixel shader, je crois pas qu'elle supporte les vertex shader (il me semble qu'elle n'ont pas de tnl mais je peux me tromper je dis ca de mémoire).
Intel dispose du meilleur support opensource (de plus, si je ne m'abuse, c'est intel qui paye des développeurs pour celà). Malheureusement leur carte 3D n'est pas performante comparé à NVidia ou ATI.
ATI driver jusqu'aux X800 (mobility compris). Les X1xxx ne sont pas supportées (même la 2D n'est pas supporté sur ces modèles).
Il existe un benchmark qui permet de se donner une idée de la différence de performance. Il est vrai que fglrx est devant mais de nombreuses optimisations dans le driver libre sont possibles cependant pour le moment l'essentiel du travail porte sur les fonctionnalités.
Je vous conseille de parcourir le thread car l'on y donne des explications sur les raisons de certaines de ces différences.
De plus, est-tu sur d'avoir l'accélération 3D activé (glxinfo doit te dire direct rendering enabled). Si oui alors je te conseil de tester les derniers drivers (depuis le cvs) car il s'est énormement amélioré ces derniers temps. Je serai fortement étonné qu'un bête économiseur d'écran rame alors que quake3 ou encore ut2004 sont parfaitement jouable :)
Il me semble que le reverse engineering s'effectue sur une nv5x Stéphane ne souhaite pas s'intéresser aux vieilles cartes mais aux nouvelles.
OpenGraphics ne pourra pas atteindre le niveau des cartes NVidia ou ATI sans un investissement financier conséquent. Donc meme s'il s'agit d'un projet louable on ne peut se permettre de se restreindre à lui seul. La diversité est nécessaire et souhaitable. Par ailleur le prix des cartes sera certainement bien trop supérieur à celle de nvidia & ati avec des performances inférieur.
Il y a eu un long thread sur la mailing list du noyau linux sur les drivers propriétaire. Je partage l'avis d'un grand nombre de protagonistes de cette discussion, à savoir que l'on ne peut pas se satisfaire de drivers propritaires ! C'est a mon sens un paradoxe d'avoir un noyau libre et des modules propritaires. Comment savoir ce que fait ce module ?
De plus d'un point de vue sécurité l'opacité des cartes graphiques caches de nombreuses failles. Ainsi avec les drivers fglrx (et très probablement avec ceux de nvidia) il est possible en temps que simple utilisateur d'accéder à la mémoire du système (même celle que l'on ne devrait pouvoir accéder).
Cependant le reverse engineering n'est pas la seul voie. De nombreuses personnes tentent de convaincre les constructeurs qu'il serait plus intéressant pour eux d'ouvrir leur driver. De ce point vue Sun Microsystem donne l'example (à mon avis).
Le support DRI (driver 3D open source) pour les cartes ATI va jusqu'aux X850. Le driver n'est pas encore aussi stable que pour les anciennes cartes <9200 mais point de vue fonctionnalitées il n'a pas grand chose à envier.
D'apres ce que j'ai compris de l'architecture d'Xglx ton problème est "normal". Actuellement Xglx est un gros bricolage, mais de jour en jour tout s'améliore et on commence à voir les spécifications se figer. Donc, actuellement, il n'y a pas de synchronisation avec le vertical blank de la carte; ce qui est, me semble t-il, là très probable cause de ce que tu observe.
Il faudra très certainement attendre encore quelques mois (semaines ?) avant que les spécifications actuellement discutées soit accéptées et surtout mises en place.
Xgl est un serveur X qui utilise OpenGL donc toutes applications X qui se connectent à un serveur Xgl utilisera OpenGL (sans le savoir) et pourra donc être accéléré (cairo ou pas cairo dès que celà utilise le protocol X c'est accéléré).
Pour la remarque de David sur cairo->xlib->xgl plus rapide/correct que cairo->glitz l'explication c'est que cairo->xlib utilise l'extension XRender pour le rendu. Hors il me semble que le backend XRender est bcp plus mature que glitz et comme Xgl accelere XRender en OpenGL au final là chaîne cairo->xlib->xgl est mieux que cairo->glitz.
Voilà la manière dont je comprends les choses. Suivre celà c'est un peu techniques et on se perd vite entre les differents niveaux. Un petit schéma peut aider :) http://www.freedesktop.org/wiki/Xegl
De plus EGL ne remplace pas GLX. GLX c'est l'encapsulation de command OpenGL dans le protocol X et EGL c'est une implementation stand-alone d'OpenGL (voir le lien ci-dessus). Donc avec xgl on aura toujours GLX voir même bientôt AIGLX (le truc de redhat qui au final est complémentaire de xgl) et tout sera accéléré.
Reste à se battre pour des drivers libre. Avoir un OS libre avec des drivers propriétaire, personnelement, je considére ca comme un paradoxe. Vous perdez le contrôl de l'OS...
D'après ce que j'ai suivis de son développement, Xgl est loin d'être prêt. Beaucoup de parties du code sont des "bricolages" faits afin de pouvoir faire cette présentation & annonce le plutôt possible. Certaines parties de l'architecture sont encore discutées.
D'ailleur le code réside dans une branch sur freedesktop. Néanmoins on peut espérer que tout ira plus vite désormais que le code est à nouveau ouvert et surtout que les développeurs X ont plus de temps pour se consacrer à ca :)
Il est aussi utile de faire la distinction entre Xglx Xegl. Le premier lance un server X par dessus un serveur X "normale". Le deuxième est un serveur X reposant sur EGL pour la gestion de l'affichage.
L'essentiel c'est que tout le schmilblik avance... Manque plus qu'à lancer une OPA sur NVidia et ATI puis a placer des gens "bien" à leur tête pour libérer les drivers ;)
Le driver DRI pour r300 supporte toutes les cartes RADEON de la 7500 à la X850 (je ne sais plus quoi) en AGP. Il subsiste encore quelques problèmes avec le PCI-E.
Il marche bien pour la platforme PPC. Le site r300.sf.net n'est pas très à jour :) Donc tu peux tester ce driver, mais attention il est encore en développement et il a tendance à "freezer" la machine avec les screensavers.
La 9200 est une evolution de la 8500 donc plus recent que la 7500 :) Par ailleurs il existe aujourd'hui des drivers libres pour les radeon 9500/9800 et X300-X800. Ils sont certes encore en phase de dévelopement mais les spécifications (en grande partie) sont connues grâce au "reverse engenering".
Pour nvidia il me semble que grâce aux travaux effectué sur Haiku l'on connaisse une certaine partie du fonctionnement du chipset, il manque simplement une personne avec assez de temps ou de courage pour ecrire un driver (même minimaliste).
Des patchs rajoutant le support du cell sont deja disponible (voir la mailling list ppc devel). Ils sont realises par IBM et s'ils ne sont pas encore incorpores j'imagine que c'est parcequ'ils estiment que ce support n'est pas encore finis et de plus seul les labos d'ibm et autres fabricant du cell doivent posseder le materiel donc il ne sert a rien de presser son inclusion dans le noyau officiel.
On peut toujours jeter un coup d'oeil au code (personellement je n'en ai pas eu le temps)...
Xgl n'abandonnera pas tout le travail d'Xorg. Au contraire il en profitera. Il faut voir Xgl comme un driver graphic un peu comme EXA, ou XAA, même si il touche plus profondement le serveur X. Mais le server X dans Xorg c'est bien peu de chose comparé à tous le reste (Xlib, XCB, les extentions X, ...)
A terme Xgl sera incorpore a Xorg et au moment de la compilation tu pourras choisir explicitement le serveur Xgl.
Enfin à l'argument Xgl ça sert à rien car il n'y pas de driver libre et bien je dirais simplement qu'aujourd'hui il existe des drivers libre DRI/Mesa acceleration 3D pour toutes les radeons des 7500 au X850XT (9500,9600,9800,X300,X400,X700,X800), pour les derniers chips intel GM900 (i915), et pour qu'elles que autres cartes moins répandues.
Le driver des radeon > 9500 n'est pas encore au niveau des drivers propriétaire mais il s'améliore de jours en jours. Sachant que ce driver est réalisé par une méthode que l'on pourrait qualifier de reverse engineering, il faut comprendre le travail qu'il a nécessité.
[^] # Re: Une nouvelle très importante
Posté par Markov . En réponse au journal Personne n'en a parlé ? Une interface driver intelligente bientôt sous Linux !. Évalué à 1.
>toucher aux interfaces, et quand l'interface doit absolument bougée (ce qui normalement ne
>doit pas arriver souvent lorsqu'elle est pensée), ben suffit d'en faire une nouvelle tout en
>gardant l'ancienne, par soucis de compatibilité.
Si tu veux voir ou ca meme ce genre de politique regarde le code d'xorg partie ddx/dri/drm (radeon par exemple) le code est très difficile à lire même pour quelqu'un qui le connais bien. Je pense dc que de ce point de vue le noyau a raison. Néanmoins Xorg n'a pas les même contrainte que le kernel, on peut comprendre leur soucis de rétrocompatibilité.
[^] # Re: la meilleure solution ? Abandonner X et X.org et créer mieux !
Posté par Markov . En réponse à la dépêche Graves problèmes de sécurité dans x.org. Évalué à 2.
Enfin en ce qui concerne le rendu type postscript, cairo commence à s'imposer, sans pour autant interdire l'existence de programmes qui voudraient controler le rendu au pixel près.
Le deuxième lien est une critique bcp plus constructive de X.
[^] # Re: la meilleure solution ? Abandonner X et X.org et créer mieux !
Posté par Markov . En réponse à la dépêche Graves problèmes de sécurité dans x.org. Évalué à 4.
Ce protocole à aujourd'hui une place de choix dans l'industrie. Il me semble donc inutile de vouloir tout changer en abandonnant un protocol qui a plus que fait ses preuves. On passera un jour au protocol X12 (à cause de certaines limites d'X11).
Le problème ici présenté viens plutot de l'architecture x86 et de l'implémentation des drivers dans le server X (implémentation qui fait aujourd'hui l'object de nombreux travaux voir par exemple la présentation d'Egbert Eich au FOSDEM).
Pour toute personne désirant approfondir ses connaissances d'X je conseille de lire l'article de wikipedia ainsi que les liens fournit dans celui-ci.
http://en.wikipedia.org/wiki/X_Window_System
[^] # Re: petites corrections par rapport au journal
Posté par Markov . En réponse à la dépêche Graves problèmes de sécurité dans x.org. Évalué à 3.
Enfin l'interface définit par fbdev me semble trop minimaliste pour tirer profit des cartes graphiques d'aujourd'hui. Mais la solution qui me semble la plus adapter pour régler ce problème est bien celle d'un module noyau pour chaque carte graphique. Ce module s'occupant des tâches sensible et pénalisant le moins possible l'accés à la carte graphique et à ses fonctionalités. Une grande partie du driver de la carte resterait néanmoins en user mode (facilitant la programmation et aussi le portage sur différent OS).
Néanmons cette solution ne me semble pas réalisable dans un avenir proche aux vues de la pluralitées des systèmes supportés par Xorg.
[^] # Re: petites corrections par rapport au journal
Posté par Markov . En réponse à la dépêche Graves problèmes de sécurité dans x.org. Évalué à 3.
Le module DRM du noyau est vraiment minimaliste pour chaque carte video. Il "scan" les packets de command qui pourrait être dangereux, grosso modo tous les packets qui concernent le transfert de donnée entre la CG et la ram ou la ram et la CG. Il vérifie donc que le processus qui envoit les commandes à le droit d'accéder à la plage d'addresse spécifier. Pour le reste le DRM se contente de faire un bete copier coller (pas exactement ca) des commandes vers la carte graphiques.
Il me semble, mais je peux me tromper, que le meilleur endroit pour faire ce genre de controle c'est dans le noyau. C'est pourquoi utah présentait un modèle 'moins secure'.
Il existe un document qui traite de cela:
http://dri.sourceforge.net/doc/security_low_level.html
De plus un thread viens de réapparaitre sur la mailing list d'xorg:
http://lists.freedesktop.org/archives/xorg/2006-May/015368.h(...)
Voir notamment les interventions de Dave Airlie et d'Alan Cox
http://lists.freedesktop.org/archives/xorg/2006-May/015369.h(...)
http://lists.freedesktop.org/archives/xorg/2006-May/015377.h(...)
[^] # Re: xegl ?
Posté par Markov . En réponse à la dépêche Graves problèmes de sécurité dans x.org. Évalué à 4.
Cependant comme je le disais dans un poste plus haut 99% des développeurs d'Xorg s'occupent d'autre chose qu'Xegl car pour le moment Xegl ne pourrait fonctionner que sur linux ou freebsd et donc ce n'est pas une solution envisageable à cour terme car Xorg supporte aussi solaris, openbsd, netbsd et d'autres OS.
Donc pas d'accélération du passage à Xegl. De plus des OS comme OpenBSD n'accepteront certainement que des drivers open source pour les cartes graphiques (ca c'est bien :)).
[^] # Re: petites corrections par rapport au journal
Posté par Markov . En réponse à la dépêche Graves problèmes de sécurité dans x.org. Évalué à 4.
Sinon petite précision supplémentaire (je viens d'y penser après un petit tour sous gdb ^^) il est bcp plus facile de faire du "reverse engineering" (j'aime pas trop l'expression francaise :d) d'un driver en user mode qu'un driver dans le noyau.
Je pense notament à la lecture des registres (mmio) ou encore au "man in the middle" (bcp plus dure mais tellement plus instructif).
Quand on voit que le seul constructeur à fournir ses spécifications compléte est intel, on ne peut que penser que le reverse engineering est nécessaire. Enfin c'est mon opinion (j'aime pas les blobs binaires dans le noyau >->)
[^] # Re: petites corrections par rapport au journal
Posté par Markov . En réponse à la dépêche Graves problèmes de sécurité dans x.org. Évalué à 10.
Les dévelopeurs d'Xorg ont bien conscience qu'aujourd'hui ce schéma posse problème. Ils réflechissent à comment évoluer vers un système plus sein, et ce bien avant la publication de Loic. Seulement l'impératif pour les développeurs c'est de ne pas tout casser du jour au lendemain mais de progresser petit à petit.
Par exemple actuellement bcp de développement porte sur l'utilisation du librairie générique d'accés aux bus pci (agp, pcie, ...) qui utiliserait le noyau (bsd, solaris, linux, ...).
Par ailleur pour complétement s'affranchir du problème il faudrait un modèle de driver comme celui utiliser par le DRI avec un module noyau (DRM). Mais pour le moment cette solution n'est pas envisageable car trop peux de noyaux ont l'architecture DRM (linux et freebsd seulement).
Cependant sun a commencé à développer un DRM pour le noyau solaris. Il faudrait qu'OpenBSD face de même ainsi que netbsd et les principaux OS aujourd'hui "officielement" supportées aurait l'architecture nécessaire pour un modèle de driver graphique "secure".
Nota bene: DRM c'est pas pour Digital Right Management mais pour Direct Rendering Manager
Voila, il ne faut donc pas cracher sur les développeurs d'Xorg (c'est pas gentil ;)) de plus très peux d'entre eux travaillent activement sur Xgl ou AIGLX, la grande majoritée s'occupe de retravailler Xorg afin de corriger les bugs de conceptions et de repartir sur des bases solides (XCB, Xinput, libpci, ...).
[^] # Re: Quelle carte achetter ? avec des drivers 3D opensource ?
Posté par Markov . En réponse à la dépêche Démarrage d'un projet de développement de pilote libre pour les cartes vidéo NVidia. Évalué à 3.
Elle supporte aussi les pixel shader, je crois pas qu'elle supporte les vertex shader (il me semble qu'elle n'ont pas de tnl mais je peux me tromper je dis ca de mémoire).
[^] # Re: Quelle carte achetter ? avec des drivers 3D opensource ?
Posté par Markov . En réponse à la dépêche Démarrage d'un projet de développement de pilote libre pour les cartes vidéo NVidia. Évalué à 3.
ATI driver jusqu'aux X800 (mobility compris). Les X1xxx ne sont pas supportées (même la 2D n'est pas supporté sur ces modèles).
NVidia en cour...
[^] # Re: Bon courage
Posté par Markov . En réponse à la dépêche Démarrage d'un projet de développement de pilote libre pour les cartes vidéo NVidia. Évalué à 6.
http://www.mail-archive.com/dri-devel%40lists.sourceforge.ne(...)
Je vous conseille de parcourir le thread car l'on y donne des explications sur les raisons de certaines de ces différences.
De plus, est-tu sur d'avoir l'accélération 3D activé (glxinfo doit te dire direct rendering enabled). Si oui alors je te conseil de tester les derniers drivers (depuis le cvs) car il s'est énormement amélioré ces derniers temps. Je serai fortement étonné qu'un bête économiseur d'écran rame alors que quake3 ou encore ut2004 sont parfaitement jouable :)
[^] # Re: Bon courage!
Posté par Markov . En réponse à la dépêche Démarrage d'un projet de développement de pilote libre pour les cartes vidéo NVidia. Évalué à 10.
OpenGraphics ne pourra pas atteindre le niveau des cartes NVidia ou ATI sans un investissement financier conséquent. Donc meme s'il s'agit d'un projet louable on ne peut se permettre de se restreindre à lui seul. La diversité est nécessaire et souhaitable. Par ailleur le prix des cartes sera certainement bien trop supérieur à celle de nvidia & ati avec des performances inférieur.
Il y a eu un long thread sur la mailing list du noyau linux sur les drivers propriétaire. Je partage l'avis d'un grand nombre de protagonistes de cette discussion, à savoir que l'on ne peut pas se satisfaire de drivers propritaires ! C'est a mon sens un paradoxe d'avoir un noyau libre et des modules propritaires. Comment savoir ce que fait ce module ?
De plus d'un point de vue sécurité l'opacité des cartes graphiques caches de nombreuses failles. Ainsi avec les drivers fglrx (et très probablement avec ceux de nvidia) il est possible en temps que simple utilisateur d'accéder à la mémoire du système (même celle que l'on ne devrait pouvoir accéder).
Cependant le reverse engineering n'est pas la seul voie. De nombreuses personnes tentent de convaincre les constructeurs qu'il serait plus intéressant pour eux d'ouvrir leur driver. De ce point vue Sun Microsystem donne l'example (à mon avis).
[^] # Re: Bon courage
Posté par Markov . En réponse à la dépêche Démarrage d'un projet de développement de pilote libre pour les cartes vidéo NVidia. Évalué à 1.
[^] # Re: Le liveCD qui redonne du sens aux liveCD
Posté par Markov . En réponse à la dépêche Un live cd pour tester XGL. Évalué à 10.
Il faudra très certainement attendre encore quelques mois (semaines ?) avant que les spécifications actuellement discutées soit accéptées et surtout mises en place.
# Informations complémentaire
Posté par Markov . En réponse au journal Xgl, la suite. Évalué à 2.
Pour la remarque de David sur cairo->xlib->xgl plus rapide/correct que cairo->glitz l'explication c'est que cairo->xlib utilise l'extension XRender pour le rendu. Hors il me semble que le backend XRender est bcp plus mature que glitz et comme Xgl accelere XRender en OpenGL au final là chaîne cairo->xlib->xgl est mieux que cairo->glitz.
Voilà la manière dont je comprends les choses. Suivre celà c'est un peu techniques et on se perd vite entre les differents niveaux. Un petit schéma peut aider :)
http://www.freedesktop.org/wiki/Xegl
De plus EGL ne remplace pas GLX. GLX c'est l'encapsulation de command OpenGL dans le protocol X et EGL c'est une implementation stand-alone d'OpenGL (voir le lien ci-dessus). Donc avec xgl on aura toujours GLX voir même bientôt AIGLX (le truc de redhat qui au final est complémentaire de xgl) et tout sera accéléré.
Reste à se battre pour des drivers libre. Avoir un OS libre avec des drivers propriétaire, personnelement, je considére ca comme un paradoxe. Vous perdez le contrôl de l'OS...
# Prêt ?
Posté par Markov . En réponse à la dépêche NLD 10 le poste du travail de demain par Novell (avec XGL et Compiz). Évalué à 9.
D'ailleur le code réside dans une branch sur freedesktop. Néanmoins on peut espérer que tout ira plus vite désormais que le code est à nouveau ouvert et surtout que les développeurs X ont plus de temps pour se consacrer à ca :)
Il est aussi utile de faire la distinction entre Xglx Xegl. Le premier lance un server X par dessus un serveur X "normale". Le deuxième est un serveur X reposant sur EGL pour la gestion de l'affichage.
L'essentiel c'est que tout le schmilblik avance... Manque plus qu'à lancer une OPA sur NVidia et ATI puis a placer des gens "bien" à leur tête pour libérer les drivers ;)
[^] # Re: Claviers Powerbooks
Posté par Markov . En réponse à la dépêche Sortie du noyau 2.6.14. Évalué à 2.
Il marche bien pour la platforme PPC. Le site r300.sf.net n'est pas très à jour :) Donc tu peux tester ce driver, mais attention il est encore en développement et il a tendance à "freezer" la machine avec les screensavers.
[^] # Re: 120 euros sans 3D ?
Posté par Markov . En réponse à la dépêche Projet Open Graphic : les premières cartes de test avant la fin de l'année !. Évalué à 2.
Pour nvidia il me semble que grâce aux travaux effectué sur Haiku l'on connaisse une certaine partie du fonctionnement du chipset, il manque simplement une personne avec assez de temps ou de courage pour ecrire un driver (même minimaliste).
[^] # Re: Et le Cell?
Posté par Markov . En réponse à la dépêche Sortie du noyau Linux 2.6.13. Évalué à 6.
On peut toujours jeter un coup d'oeil au code (personellement je n'en ai pas eu le temps)...
[^] # Re: Remplacement ou superposition ?
Posté par Markov . En réponse à la dépêche Exa, une nouvelle architecture accélérée pour les drivers Xorg. Évalué à 5.
A terme Xgl sera incorpore a Xorg et au moment de la compilation tu pourras choisir explicitement le serveur Xgl.
Enfin à l'argument Xgl ça sert à rien car il n'y pas de driver libre et bien je dirais simplement qu'aujourd'hui il existe des drivers libre DRI/Mesa acceleration 3D pour toutes les radeons des 7500 au X850XT (9500,9600,9800,X300,X400,X700,X800), pour les derniers chips intel GM900 (i915), et pour qu'elles que autres cartes moins répandues.
Le driver des radeon > 9500 n'est pas encore au niveau des drivers propriétaire mais il s'améliore de jours en jours. Sachant que ce driver est réalisé par une méthode que l'on pourrait qualifier de reverse engineering, il faut comprendre le travail qu'il a nécessité.