Markov a écrit 95 commentaires

A ma connaissance seul les drivers 2D etait libre, si tu as un pointeur vers les sources du driver 3D (si c'est libre on doit avoir les sources non ? :))

Sans vouloir etre pessimiste, s'ils ont choisis E17 c'est certainement parceque celui-ci ne demande pas d'accéleration hardware pour donner de bonne performances. Ce qui indique donc a mon avis qu'il n'y aura aucun support de la partie graphique de la machine.

Intel non seulement fournis les specifications aux developpeurs mais en plus elle les paye. Apres intel n'est pas tout rose, notament sur ses chipset wifi.

Pour la performance des drivers sous linux j'y vois plusieurs explications. Ces derniers temps les developpeurs s'occupe du 'gestionnaire de memoire" car aussi etonnant que cela puissa paraitre actuellement la memoire video est gere de maniere ad-hoc et ca ressemble a un bricolage. Donc 90% des commits sur les drivers 3d et pour intel s'effectuent sur cette branch.

Autre explications possible, il me semble que sous linux une des fonctionnalitee de la carte n'est pas utilise (impossible de me souvenir du nom mais ca a rapport avec la memoire et la possibilite de faire des trucs "intelligent" avec, seulement ca semble pas exploitable avec sans le gestionnaire dont je parle plus haut).

Dernier point, la configuration par defaut sous linux est tres conservative et aura surement tendance a brider les performances. Je te conseil donc d'augmenter la taille de memoire allouer a ta carte graphique, notament la memoire agp. Regarde aussi ce que propose driconf comme option pour ta carte.

Au passage le chipset intel X3000 (dans les chipset 965) a l'air d'avoir des performances plus qu'honorable et semble capable de rivaliser avec les derniers chipset moyen de gamme de la concurence.

http://www.oakcourt.dyndns.org/~andrew/x3000_benchmark.html

GLX_EXT_texture_from_pixmap permet d'utiliser les pixmap du serveur X comme texture. Donc cette extention ne permet pas d'acceler tout le rendu mais simplement d'utiliser le rendu du server X (qui peut utiliser l'acceleration render ou exa ou autre en fonction de la carte du driver...) comme texture. Le compositeur peut alors faire tout plein de truc en opengl (transparence des fenetres, effet wobbly, ...).

Quand NVidia ne proposait pas cette extention aucun rendu ne passer par mesa en software tout simplement parcequ'avec les drivers proprios vient la libGL de nvidia. Il est par contre possible de trafficer un serveur X pour utiliser mesa en software pour faire le compositing en opengl mais alors ca risque de ramer.

Bref cette extention n'accelere rien mais permet d'utiliser des pixmap X comme texture en opengl et ainsi d'avoir un "compositeur" (existe-t-il une traduction francaise meilleur ?) en opengl comme compiz. Les autres compositeurs n'utilise pas opengl (metacity ou autre), du moins pas encore.

Pourrait tu donner un lien vers cette declaration de Theo. Dans mes cours d'infos le modele driver in userland semblait etre presenter comme aussi bien point de vue securite que les drivers in kernel. En realite avoir les drivers en userland peut aider a bien penser comment decoupler la partie vraiment critique du driver, des parties fonctionnelles.

AIGLX veut effectivement dire accelerated indirect GLX mais cela n'a rien a voir avec le rendu offscreen. Au paravant quand tu utilisais GLX en mode indirect tu envoyais tes commandes GL au serveur X, seulement celui-ci etait incapable d'utiliser le driver 3d pour faire le rendu et donc utiliser mesa en software. Au premier abord cela semble simple de faire appel au driver 3d depuis le serveur mais en realite cela posait de nombreux problemes, notament en ce qui concerne la synchronisation. De plus le code GLX du serveur X etait assez "degeu" et difficilement modifiable, c'est pour cela qu'AIGLX a demande du temps.

L'extension GLX_EXT_texture_from_pixmap permet d'utiliser les pixmaps du serveur X comme texture, ainsi le serveur X fait le rendu des fenetres dans des pixmap en utilisant l'acceleration habituel (render|exa|...) puis le compositeur utilise ces pixmap comme texture opengl et hop on a tous les effets qui sont zolies :)

L'avantage Xgl c'est que le rendu des fenetres utilise OpenGL et non render ou exa ou autre, ainsi pour dev de driver il n'y aurait plus besoin que d'ecrire un driver opengl. Cependant cette solution n'est pas rellement prete pour s'imposer. Probablement que glucose permettra de s'en approcher.

Tu devrais soumettre des bugs ou alors demander pourquoi le driver r300 ne marche pas pour toi sur dri-users@lists.sourceforge.net. Car il marche pour beaucoup de personnes. C'est très probablement un problème de configuration de ta part. Il reste vrai que beaucoup de functions ne sont pas encore implémenté (smooth line, fragment program incomplet, ..).

En ce qui concerne le reverse engineering d'une carte 3D, ce n'est pas impossible mais la difficultée peut être très grande s'il n'y a absolument aucune information sur les cartes (particuliérement en ce qui concerne les registres pour configurer la carte (mode video, couleur, DMA buffer, ...)) après comprendre les packets 3D c'est beaucoup plus "facile".

Il reste vrai que les développeurs qui travaillent au reverse engineering manquent de temps. Cela principalement parcequ'ils le font en hobbie. De plus il me semble que la raison pour laquelle aucun développeurs n'est embauchés pour travailler sur le reverse enginering c'est principalement à cause de pression de la part de NVidia et ATI sur les éventuels employeurs (je pense par exemple à NVidia qui n'a pas apprécié le travail d'un employé de trolltech à propos du reverse enginering de leur carte).

Non cela ne corrige pas la faille a laquel tu fais reference. Cependant, je crois utile de rappeler que cette faille est loin d'etre facilement exploitable et surtout qu'il existe des moyens plus simple pour compromettre une machine faisant tourner un serveur X.

Cela etant, les developpeurs X travaillent dans "l'ombre" a regler tous ca en decouplant petit a petit le serveur X des drivers afin d'arriver a avoir l'ensemble des drivers carte graphique de X a utiliser l'architecture DRM/DRI ou une architecture type framebuffer. Ainsi X n'aura plus besoin d'avoir les privileges qu'il a aujourd'hui. Il faudra encore certainement attendre quelques annees pour voir cela arriver...

Peut être simplement que ces kernel dev ne supportent pas les blobs binaire et donc qu'il n'achéte pas de matériel ne fonctionnant qu'avec des drivers proprio...

Le problème vient d'une update du kernel et ne pourrait pas impacter les drivers libre OSS car dans le noyau quand tu changes un truc qui affecte les autres c'est à toi d'aller modifier ce qu'il faut, enfin souvent tu es aidé :)

Donc non c'est très, mais alors vraiment très improbable que cela arrive avec les drivers libre. Ensuite les dev ubuntu qui s'occupe du noyau doivent probablement pas aimer les blobs binaire comme tous les dev du noyau et dc il n'en n'ont pas sur leur machine.

Cela étant si ubuntu veut supporter officielement les drivers proprio alors elle doit effectivement s'assurer de ne pas les rendre inopérationnel à chaque update. Mais il me semble qu'il les propose simplement pour faciliter la vie de ceux qui veulent les installer. D'ailleur par defaut quand on install une ubuntu on pas que les drivers libre ?

Je pense que tu devrais orienter ton choix vers intel et son chipset GMA X3000. Il dispose(ra) du meilleur support opengl, exa, glucose, xgl, aiglx dont tu puisse rever car bcp des developpeurs des drivers intel developpe aussi aiglx, exa, ... Bref leur materiel de reference me semble etre intel.

ATI jusqu'au X850 peut etre supporte mais attention le driver est loin d'etre finis et malheureusement les devs qui s'en occupent manque de temps.

Non j'en doute. D'après les informations qui circule la partie 3D des derniers chips (X1000) est similaire en grande partie au r300 et r400 (don't un driver libre existe). Seulement la partie 2D est complétement différentes (l'engine VIVO si je me souviens bien du nom). Or avant d'attaquer la 3D il faut configurer la 2D (changement de mode video, DMA access...).

Dave Airlie a ecrit un driver 2D (pour X1300) grâce aux informations dont-il dispose par son travail (sous NDA) et il a demandé à ATI l'authorisation de publier ce driver mais ATI n'a pas donné de réponse et ceux depuis 5 mois.

Sinon ce kit peut effectivement facilter le reverse engineering de la partie 3D si des différences importantes existe avec les familles r300 (radeon 9500 a 9800) et r400 (X300 a X800). Mais ce kit n'est pas libre d'accés et il faut probablement signer un NDA avec ATI.

Selon les derniers bench des developpeurs du driver libre pour radeon r2xx le driver libre est plus rapide en 3D que le driver proprietaire. Je te conseil de verifier ton installation du driver et pourquoi pas d'essayer le cvs de mesa :)

Justement je tentais de demontrer que ces raisons ne sont pas les vrais raisons. S'il y avait un probleme de brevet alors les informations deja fournis par le reverse engineering permettrait de les attaquer. Le bridage logiciel je n'y croit pas sachant que ATi et Nvidia aident les developpeurs des outils d'overclocking (en leur disant quoi faire et en leur donnant des informations sur les cartes). Le marche linux n'ai pas ridiculement petit pour eux sinon ati n'embaucherait pas 15 personnes pour bosser sur ses drivers linux (nvidia aussi y consacre des resources mais je n'en connais pas l'ampleur).

Apres il est vrai que leur drivers utilisent souvent des astuces afin d'augmenter le framerate de certains jeux. Mais en donnant leur specs ils ne donnent pas les astuces qu'ils utilisent. Les specifications d'une carte graphique c'est grosso modo une liste de registre (des addresses memoire) avec leur fonctions (ce qu'on peut y lire ou y ecrire et ce que cela realise).

Je ne connais pas bien les informations fournis pas microsoft mais je connais celle fournit par apple. Dc d'apres mon experience et aussi des echos que j'en ai eu il est bcp plus facile de developper un driver sous windows ou sous os x. Par exemple apple fournis des tonnes d'exemples de squelette de drivers, il y a presque plus qu'a completer les blancs. Je pense que microsoft et msdn doit fournir des informations et exemples semblable.

Cependant cela ne me semble pas etre le probleme le plus important. Pour moi avoir un noyau linux avec module binaire c'est renoncer a tout ce qui fait l'interet du libre a savoir connaitre ce qu'il se passe ou du moins en avoir la possibilite.

Comment savoir ce que font les modules binaire des cartes graphiques ? N'introduisent t'ils pas des bugs, des failles ? Comment verifier la qualite de leur code ? De plus qd le constructeur decide de ne plus supporter une gamme de produit je dois jeter mon materiel si je veux passer a un noyau plus recent ?

Bref pour moi l'important c'est d'avoir des drivers libre qui est important. Et les constructeurs ont a cet egard des comportement intriguant. Par exemple pour les cartes graphiques ati r200, r300, r400 ou les cartes nvidia, par reverse engineering l'on connait suffisament precisement le fonctionnement de ces cartes. Mais les constructeurs ne veulent pas donner les specifications manquantes (certains registre ne sont pas compris et les drivers libre y ecrivent des valeurs dites magiques ;)) Bref ils n'ont pas de gros secret a cacher alors pourquoi ne pas donner la liste des registres et leur fonctions ?

Nota bene: DSL pour l'ortho j'ecris cela entre deux trains :)

DRM est l'acronyme de Direct Rendering Manager (http://dri.sourceforge.net/doc/drm_low_level.html) est ca existait bien avant que les DRM (Digital Right Management) deviennent a la mode.

C'est deux choses n'ont donc rien a voir. Pour comprendre l'architecture DRI/DRM(): http://dri.sourceforge.net/doc/design_low_level.html.

Justement le mise en place de l'architecture DRM permettra d'ameliorer la securite de ce cote et petit a petit (avec les autres changement majeurs libpci, ...) Xorg n'aura plus besoin de disposer des droits root.

En faite je pense que le mot de passe que j'ai utiliser est une alteration d'un autre mot de passe... enfin je vais pas trop en dire sur comment je fais mes mots de passe mais disons que j'ai seulement un bon milliers de truc a tester...

Le truc c'est que j'ai fait cette partition avant de partir en vacance et naturellement durant celle-ci j'ai oublie la passphrase :P Morale de l'histoire faut pas partir en vacance... ;)

Je ne crois pas que KGI soit une alternative fiable. Le projet a voulu faire table rase du passe et tout changer du jour au lendemain. Or dans tout l'univers du libre si tu observe tu verra qu'aucun projet ne procede comme cela. Le noyau linux avance par "petit a petit", de meme pour xorg, gcc, ... il y a parfois des grands changement mais ils sont anticipes et reste compatible avec ce qui se faisait avant.

De plus la situation des drivers graphiques ne fait que s'ameliorer sur linux, bsd, solaris. D'ici peu tous ces OS auront un module noyau type DRM ce que voulait faire KGI plus ou moins. Ils partagerons dc la meme architecture pour mettre en place l'acceleration graphique.

Figure que toi que les meilleurs developeurs de drivers 3D n'aspire qu'a faire du libre... Bcp des developpeurs d'xorg, mesa, dri travaille pour intel ou ati ... De plus la preuve que les developpeurs de drivers libre sont tres bon c'est le driver open source pour r200 qui est plus rapide que fglrx sur ces cartes.

Donc l'excuse qu'il n'y pas les competences dans la communaute est completement fausse. Soulignons au passage l'engagement exemplaire d'intel qui continura a fournir des drivers libre pour ces prochaines cartes graphiques (c'est deja le cas pour les actuels).

Merci cela devrait pouvoir m'aider.

Oui pour un benchmark un peu mieux fait (r200 dri configure au top):
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/(...)

Grosso modo le driver libre est aussi voir plus performant sauf pour ut2k mais il y a une raison à cela. Je ne me souviens plus des détails mais cela avait un rapport avec les vertex buffer et le gestionnaire de mémoire encore inexistant à l'époque des tests (aujourd'hui encore c'est en travail).

Dans tout les cas le support des radeon R100, R200, R300, R400 ne fait que s'améliorer dans les drivers open source.

Autre précision c'est nvidia qui a changé l'ABI. Pas les dev d'ATI même si certains on participait.

Et même mieux, intel pait la compagnie Tungsten Graphics pour faire les drivers libre et au dernière nouvelle les gars de Tungsten devrait faire le driver des futurs cartes. Pour mémoire Tungsten Graphics c'est la boite qui dévelope Mesa. Enfin derniérement intel a embauché des membres majeurs de Xorg afin qu'ils puissent travailler dessus et aussi sur le support open source des technologies intel.

Sinon, les cartes radeon jusqu'au X850 sont supportées par les drivers libre DRI. Les carte NVidia sont en train de subir du reverse engineering http://renouveau.sf.net. Et des personnes attendent le feu vert d'ATI pour publier le driver 2D libre des X1XXX, sachant que la partie 3D ressemble au R3XX et R4XX il devrait alors être possible de faire le reverse engineering de ces cartes assez rapidement donc l'horizon n'est pas si sombre. Même si on préférerait tous des spécifications libre et accésibles.

il y a incompatibilité quand il y a changement d'API. Donc il n'y a pas forcément besoin de nouveaux drivers à chaque nouvelle version de Xorg. Mais quand ça arrive, il ne suffit pas de recompiler le driver, il faut le modifier.

Un changement d'API demande effectivement une modification du driver mais souvent cette modification est minime et ne nécessite pas de reécriture. Il y a aussi les changements d'ABI et la une simple recompilation suffit.

Dans tous les cas des drivers libres (open source) sont bien meilleur car quand il y a un tel changement c'est la personne qui introduit le changement qui doit s'assurer que l'ensemble compile, donc de mettre à jour tous les drivers inclus. On voit d'ailleur cette situation dans tous les drivers inclus dans les noyaux BSD ou linux. Il arrive aussi qu'on abandonne des drivers, mais cette abandon à lieu bien plus tard que dans le cas d'un driver propriétaire (regarde les anciennes cartes ATI ou NVidia). Tu l'aura compris je suis ferment pour des drivers open source.

Il peut très bien y avoir un jour une personne développant un driver, qui se trouve limité par les performances de DRI, et qui décide de créer sont propre système qui lui convient.

Il faut voir l'architecture DRI un peu comme une pile de protocole réseau dans le noyau. On peut toujours développer une alternative mais cela demande énormément d'effort et risque de ne pas être utilisé. Il est a mon avis préférable de partir de ce qui existe et de l'améliorer petit à petit.

Le driver nv est arrivé avec XFree 3.3.6. A cette époque il n'y avait pas de drivers proprios c'est vrai. Mais aujourd'hui on a des drivers propriétaires qui fonctionnent (certains disent qu'ils sont de mauvaise qualité, personnellement je n'ai jamais eu de problème et je n'ai jamais entendu d'arguments qui appuient cette affirmation) et pour autant le driver nv est toujours maintenu. Et ne t'inquiète pas, il y a suffisament "d'intégristes" du libre pour qu'il y ai toujours des gens à tester les drivers libres.

Je suis probablement un intégriste (c'est grave docteur ?) mais accépter des drivers propriétaires enlève tous les avantages d'avoir un système libre. Comme dirait Theo comment savoir ce que fait le constructeur ? De plus il s'agit de fabricant de matériel, il ne tire pas de profit des drivers (c'est discutable...).

Enfin je peux t'assurer que seul les optimisations et les "cheats" pour améliorer les performances de tel ou tel jeux ont une valeur industriel. Le reste, savoir comment programmer la carte, ne révèle que peut de chose si ce n'est que les architectures des cartes n'ont pas bcp changées, donc on te vends du vieux pour du neuf...

Par exemple les changement entre les r3xx et r4xx sont minimes. Il semble de plus que la famille r5xx soit au final très proche des r3xx et r4xx (seul la partie 2D aurait changé et il y aurait eu ajout d'un controller de mémoire digne de ce nom). De même chez nvidia...

Voila j'espére t'avoir convaincu de l'importance de driver open source :)

Et pourtant à mon avis adapter un pilote de XAA -> EXA est surement plus facil que de développer un pilote from scratch pour une carte graphique ( surtout avec le support 3D ).

Pas forcément, par exemple pour les radeon r3xx & r4xx (ATI 9500 à X850) faire l'accélération EXA est plus compliqué car ces cartes n'ont pas la pipeline OpenGL fixe mais utilise les vertex & pixel shader pour l'émuler. Donc pour l'accélération EXA sur ces cartes il faut faire les vertex & pixel shader programmes qui vont bien ainsi que l'infrastructure pour "charger" les programmes sur la carte.

Ce travail est dc excessivement redondant avec le driver 3D c'est d'ailleur pour cela que personne ne travaille sur un support EXA pour ces cartes.