Journal Petit point sur le serveur X

Posté par yannig (site web personnel) le 27 avril 2009 à 16:19.

Étiquettes : aucune

avr.

2009

Keith Packard fait un petit point sur son blog sur l'état du serveur X sous Linux :

http://keithp.com/blogs/Sharpening_the_Intel_Driver_Focus/

Pour ceux qui ne connaîtrait pas Keith, sachez qu'il s'agit de Monsieur Serveur X chez Intel (il est plus ou moins à l'origine du fork Xorg et c'est lui qui a plus ou moins défini les grands changements qui ont eu lieu dans Xorg). Keith ne fait bien sûr référence qu'au matériel Intel mais l'article reste intéressant puisque faisant un point sur les différentes technologies présentes dans le Kernel et le serveur X.

Il y parle notamment de l'accélération 2D (XAA, EXA, UXA), 3D (none, DRI1/2), la gestion de l'état du chipset graphique depuis le kernel (Kernel mode setting) ainsi que l'allocation de la mémoire graphique via un gestionnaire dédié à ce travail (GEM).

L'article explique que les travaux de changements sont terminés, l'étape suivante va donc consister à supprimer les vieilleries du serveur X (ce qui en soit est une excellente nouvelle). Nous ne devrions plus avoir les mêmes changements incessant de ces derniers temps (kernel mode setting, UXA, GEM etc) mais plutôt des travaux menés pour se séparer des branches mortes de code (ou considérer obsolète et devant donc être supprimer comme XAA, DRI1 etc) et stabiliser les drivers sur la nouvelle architecture et ainsi réduire la complexité et en principe augmenter la fiabilité.

# Arrgg

Posté par bubar🦥 (Mastodon) le 27 avril 2009 à 17:06. Évalué à 3.

Argg Enorme :))

/*mode_user_abuse
Cher Phil, si vous passiez dans les parages si vous avez du temps et si vous encore l' envie, pourriez vous s' il vous plait traduire ce billet afin de le rendre accessible au plus grand nombre de francophones ?
(Le dernier point (public et vulgarisé) fait par Keith Packard avait été traduit par Phil_Free).
/*mode

Blague à part, si quelqu' un pouvait en faire la traduction (exacte, pas un truc fait par un pied comme moi), ça ferait à n' en pas douter une très belle dépêche !!!

Et merci Yannig pour ton journal!
- [^] # Re: Arrgg
  
  Posté par Thomas Douillard le 27 avril 2009 à 17:43. Évalué à 3.
  
  Question vulgarisation je trouve que l'article est déja plutot (très) bon et accessible à l'informaticien moyen.
  
  L'anglais ne m'a pas paru très compliqué non plus, c'est plutôt technique donc pas de raison, donc faut pas hésiter à foncer :)
# Et aussi

Posté par med le 27 avril 2009 à 17:24. Évalué à 6.

Il y a aussi Gallium3D qui est en train d'arriver et qui devrait énormément simplifier l'écriture des pilotes 3D (http://www.phoronix.com/scan.php?page=news_item&px=NzE2O(...) ).

Pour le reste il est temps que les choses cessent de bouger. Ces derniers temps le pilote intel n'a pas été reluisant entre les nouveaux bugs et les régressions niveau performance. À ce sujet je recommande la lecture de http://www.phoronix.com/ qui fait régulièrement des tests pour voir l'évolution des performances.

Bref nous sommes encore dans une période un peu douloureuse mais une fois ces briques définitivement en place et fonctionnelles, l'avenir s'annonce radieux (enfin, j'espère).
- [^] # Re: Et aussi
  
  Posté par Adrien le 27 avril 2009 à 17:55. Évalué à 4.
  
  Bref nous sommes encore dans une période un peu douloureuse
  
  C'est clair que le pilote intel est en ce moment à la ramasse question 3D :-(
- [^] # Re: Et aussi
  
  Posté par Anonyme le 27 avril 2009 à 19:53. Évalué à 3.
  
  c'est pareil avec le pilote ati/radeon (libre) il se vautre comme une loutre bourré (ou pire il freeze) lorsque tu actives les effets sous KDE. Cela se passe pour certaines version du kernel et il semblerait que ce soit donc aussi lié au kernel et à ACPI (cette grosse bouse infame continue à nous emmerder). Le problème est présent pour toutes les versions récentes des distributions que ce soit ubuntu 9.04, Fedora10 et Mandriva 2009 et spécifique aux cartes vidéos ati utilisant le driver libre pour le moment en tout cas.
  
  Je ne sais pas trop pourquoi mais il semblerait que les effets KDE sont une bonne source pour découvrir des bugs dans Xorg et les drivers...
  - [^] # Re: Et aussi
    
    Posté par med le 27 avril 2009 à 20:11. Évalué à 10.
    
    Je ne sais pas trop pourquoi mais il semblerait que les effets KDE sont une bonne source pour découvrir des bugs dans Xorg et les drivers...
    
    La raison est assez simple : les développeurs KDE (contrairement à ceux d'autres projets) ont refusé de contourner les bugs de fonctionnalités qui marchaient sur le papier. Avant on était dans un cercle vicieux : certaines fonctionnalités ne fonctionnaient pas en pratique mais comme personne ne les utilisaient (parce qu'elles ne marchaient pas donc), les développeurs des pilotes ne corrigeaient pas les bugs, et ainsi de suite. Comme KDE est un poids lourd c'est plus incitatif pour corriger les problèmes que lorsque c'est un petit projet qui les exhibe. Donc KDE s'en prend plein la tête concernant certaines lenteurs (dont une bonne partie, pas toutes évidemment, sont simplement des problèmes de pilotes) mais au final c'est bénéfique pour tout le monde.
    - [^] # Re: Et aussi
      
      Posté par Sytoka Modon (site web personnel) le 28 avril 2009 à 18:49. Évalué à 4.
      
      Et c'est très bien ainsi. Il fallait faire cela lors de la transition vers KDE4, c'était le bon moment.
      
      Je me rappelle qu'il y a eu la même chose entre le noyau Linux et la glibc il y a quelques années. Les mecs du noyau refusait de contourner les bogues de la glibc. Cela avait été chaud. Au final, on a une glibc bien plus propre.
# Vous devez entrer un sujet et un commentaire

Posté par Troy McClure (site web personnel) le 27 avril 2009 à 17:33. Évalué à 10.

J'ai l'impression que ça fait dix ans qu'on lit des papiers de keith packard bossant sur des trucs géniaux qui vont sortir xfree86 xorg de la préhistoire et qui nous annonce qu'on est au bout du tunnel, y'a plus qu'à réécrire ça et ça et on y est, faudra juste optimiser un peu ça mais ça sera facile on va utiliser opengl et ça va depoter, pour l'instant ça rame mais avec openfgl ça va voler.

xrender, xrandr, dri, dri2, xserver, uxa, exa, xaa, gem, dtc, dkm et j'en passe et j'y comprends rien.

En attendant j'ai une carte ati et c'est pas la joie.
- [^] # Re: Vous devez entrer un sujet et un commentaire
  
  Posté par Infernal Quack (site web personnel) le 27 avril 2009 à 17:46. Évalué à -2.
  
  Pourrais-tu m'indiquer où je peux activer l'option dtc sur mon serveur X ?
  
  Merci.
  L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
  - [^] # Re: Vous devez entrer un sujet et un commentaire
    
    Posté par godzom le 27 avril 2009 à 18:03. Évalué à -2.
    
    L'option dtc?
    
    Ben DTC bien sûr.
    
    Désolé je n'ai pas pu me retenir.....
    Je sors...
- [^] # Re: Vous devez entrer un sujet et un commentaire
  
  Posté par med le 27 avril 2009 à 17:46. Évalué à 10.
  
  * xrender c'est une méthode de composition, le truc le plus basique qui existe mais comme c'est souvent pas très bien implémenté dans les pilotes au final en faisant ça en logiciels c'est souvent plus rapide.
  
  * xrandr c'est pour changer la résolution à la volée, changer l'orientation de l'écran, etc.
  
  * dri et dri2 c'est pour permettre aux applications de taper dans la carte graphique sans passer par X (par exemple pour les jeux 3D). Malheureusement dri n'aime pas beaucoup la composition, du coup dri2 a été fait pour pallier ce défaut
  
  * xaa, exa et uxa, dans l'ordre, c'est pour permettre de l'accélération 2D, chaque génération étant supposément top moumoute (mais en pratique exhibe aussi un certain nombre de régressions)
  
  * gem c'est un gestionnaire de mémoire vidéo dans le noyau
  
  * dtc est assez claire je pense :)
  
  * kms (j'imagine) permet au noyau de régler le mode video. Ça évite à l'écran de flasher entre les modes texte et graphique et surtout ça évite à X de devoir le faire ce qui permet d'éviter de le lancer en root.
  
  Voilà, s'il y a des erreurs n'hésitez pas à corriger.
  - [^] # Re: Vous devez entrer un sujet et un commentaire
    
    Posté par Ph Husson (site web personnel) le 27 avril 2009 à 22:55. Évalué à 2.
    
    Il me semble que Xrender n'est pas qu'une méthode de composition, bien loin de là, c'est juste une API pour faire de la 2D accélérée, après, récemment on a eu droit à pas mal de compositing manger qui se mettent à Xrender mais c'est que très récent.
    Il me semble que la plupart des toolkits utilisent Xrender comme moyen d'accélération, même si un certain nombre de driver peinent à l'exploiter correctement.
    - [^] # Re: Vous devez entrer un sujet et un commentaire
      
      Posté par Troy McClure (site web personnel) le 27 avril 2009 à 23:13. Évalué à 3.
      
      acceleration ou deceleration ? Il me semble que pendant très longtemps ça a été une vraie merde. Je crois que rasterman avait publié quelques benchs assassins là dessus.
- [^] # Re: Vous devez entrer un sujet et un commentaire
  
  Posté par yannig (site web personnel) le 27 avril 2009 à 17:48. Évalué à 5.
  
  Je comprends ton point de vue puisque je suis moi même un utilisateur de cette couche graphique depuis maintenant quelques années. Je tiens néanmoins à dire que cette fois-ci, les choses changent vraiment :
  - plus de hack border line (voir pas du tout border line) pour initialiser la carte graphique (le kernel mode setting est là pour ça)
  - plus de gestion mémoire graphique à la main avec une gestion différente pour chaque driver (GEM fait ce travail de manière générique)
  - disponibilité d'un framework générique de gestion de la 3D (gallium3D)
  
  Cerise sur le gâteau, deux grands acteurs des cartes graphiques (Intel et AMD) ont libérés leurs spécifications. D'autant que pour ne rien gâter, l'équipe des développeurs de nouveau a fait un travail remarquable de reverse engineering sur le matériel Nvidia.
  
  Effectivement, ça ne fonctionne pas de manière parfaite, mais tout me porte à croire que bientôt, on ne pourra plus reprocher à Linux de disposer d'une couche graphique bancale et que nous sommes effectivement en train de voir le bout du tunnel.
  - [^] # Re: Vous devez entrer un sujet et un commentaire
    
    Posté par Ph Husson (site web personnel) le 27 avril 2009 à 23:00. Évalué à 4.
    
    - plus de gestion mémoire graphique à la main avec une gestion différente pour chaque driver (GEM fait ce travail de manière générique)
    
    Oh ca laisse encore la place pour changer encore en cours de route. Genre changer d'allocateur, d'ordonnanceur, d'organisation complète de la mémoire. Entre autre ATI & NVIDIA font un peu la gueule parce que aux dernières nouvelles, GEM ca marche bien pour des IGP, mais pour des GPU externes, pas trop.
    
    - disponibilité d'un framework générique de gestion de la 3D (gallium3D)
    En fait gallium3D c'est un framework pour faire un driver en implémentant que des routines 3D....
    Jusqu'à ce qu'on se rende compte que 90% des cartes graphiques actuelles ont de meilleures performances 2D en mode 2D qu'en mode 3D, et faudra tout revoir de 0 avec un autre copain de XAA.
    Gallium3D c'est bien pour les NVIDIA > G80, et les ATI de la même espèce qui sont des GPGPU (ie chaque morceau du GPU peut faire tout et n'importe quoi), mais pour le reste des cartes, bof bof quoi.
    
    Donc comme vous l'aurez peut être constaté, je suis plutôt pessimiste, et je pense qu'on a pas fini d'entendre parler de "révolutions" dans Xorg.
    - [^] # Re: Vous devez entrer un sujet et un commentaire
      
      Posté par Anonyme le 28 avril 2009 à 05:25. Évalué à 10.
      
      Entre autre ATI & NVIDIA font un peu la gueule parce que aux dernières nouvelles, GEM ca marche bien pour des IGP, mais pour des GPU externes, pas trop.
      
      Ouhais enfin ATI et Nvidia se serait impliqué un peu plus dans xorg ils n'y auraient pas eu de problème. Donc à force de trainer les pieds ils se les sont pris dans le tapis.
- [^] # Re: Vous devez entrer un sujet et un commentaire
  
  Posté par Thomas Douillard le 27 avril 2009 à 17:54. Évalué à 4.
  
  xrender, xrandr, dri, dri2, xserver, uxa, exa, xaa, gem, dtc, dkm et j'en passe
  
  Si tu lis l'article, il dit un peu la même chose que toi, pendant un moment ils ont développé pleins de trucs alternatifs, tous combinables les uns avec les autres, donc trop de combinaison à tester, donc trop de bugs, donc ... Et que l'heure est un peu à la rationalisation de tout ça.
  
  J'imagine que ça facilite pas forcément le développement de driver quand ça bouge beaucoup du point de vue de l'architecture de rendu, etc. Donc rationaliser, dans ce cas, c'est faciliter ?
  
  Il faut quand même reconnaître que le serveur X à bien bougé ces dernières années, entre la composition, la configuration automatique, et j'en passe.
  
  Après, pour le driver ATI, si X à l'architecture qui permet d'exploiter pleinement la carte, ça ne veut pas non plus dire que ça règle toute la problématique de l'écriture de drivers. C'est juste que sans ça, c'est même pas la peine d'y penser ...
- [^] # Re: Vous devez entrer un sujet et un commentaire
  
  Posté par IsNotGood le 28 avril 2009 à 01:37. Évalué à 4.
  
  J'ai l'impression que ça fait dix ans qu'on lit des papiers de keith packard bossant sur des trucs géniaux qui vont sortir xfree86 xorg de la préhistoire et qui nous annonce qu'on est au bout du tunnel
  ...
  En attendant j'ai une carte ati et c'est pas la joie.
  
  Keith Parckard a au début été connu sur des travaux innovants. Il faisait un boulot de "laboratoire". Maintenant on passe à la production. Je crois que F11 a kms et dri2 pour certains chipsets par défaut.
  Il n'a pas promis au début de ses travaux que tout serait réglé dans la semaine. Ici encore, il dit que ça va prendre du temps et que cette période est délicate.
- [^] # Re: Vous devez entrer un sujet et un commentaire
  
  Posté par Serge Julien le 28 avril 2009 à 14:59. Évalué à 1.
  
  xrender, xrandr, dri, dri2, xserver, uxa, exa, xaa, gem, dtc, dkm et j'en passe et j'y comprends rien.
  
  Et moi non plus... parce que souvent, quand j'essaie de lire des articles sur le sujet, ça devient trop technique pour moi, et surtout, je n'arrive pas à avoir de vue d'ensemble. Ce que j'aimerais *vraiment* trouver à propos de tous ces trucs qui gèrent l'affichage, c'est une représentation graphique, avec des beaux blocs les uns au-dessus / à côté des autres, qui montrent un peu comment les différents modules s'agencent et quelle est la responsabilité de chacun.
  
  Je dis bien une représentation graphique, car un petit dessin vaut mieux qu'un long discours...
  - [^] # Re: Vous devez entrer un sujet et un commentaire
    
    Posté par zebra3 le 28 avril 2009 à 17:59. Évalué à 3.
    
    Le problème, c'est que comme leur serveur X est planté, ils vont avoir du mal à te sortir une représentation graphique... C'est pour ça qu'ils se lancent dans un travail de fiabilisation...
    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# X et intel

Posté par Axioplase ıɥs∀ (site web personnel) le 28 avril 2009 à 06:09. Évalué à 4.

Oui, bien si quelqu'un arrive à utiliser ma carte graphique normalement, je le prie de me le faire savoir.

Mon xorg dit
Driver "intel"
VendorName "Intel Corporation"
BoardName "82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device"

Point de vue rapidité, ça met jusqu'à une seconde pour m'afficher une autre tab dans firefox (et à peu près une demi seconde pour effacer un caractère dans la barre d'url d'opera…)

Bref, un une vieille carte avec un support de merde (j'ai en gros du tout mettre à "Off" dans xorg, sinon quoi X refuse de se lancer tout simplement…)
Et google dit que tout le monde avec cette carte a ce problème…

(Oui, ce commentaire a sa place dans les forums, mais il répond à un journal)
- [^] # Re: X et intel
  
  Posté par benoar le 28 avril 2009 à 21:22. Évalué à 2.
  
  Ton problème ne me semble pas venir des pilotes graphiques, mais plutôt du reste du système (Firefox qui met du temps à changer de tab, ça existe même sur du matos super haut de gamme, hein).
  - [^] # Re: X et intel
    
    Posté par Axioplase ıɥs∀ (site web personnel) le 29 avril 2009 à 08:22. Évalué à 2.
    
    J'ai mis firefox comme exemple, mais *tout* rame monstrueusement sous X. Pourtant la machine n'est pas spécialement lente. Là, c'est simplement *inutilisable* (et j'ai testé avec FreeBSD, NetBSD, PC-BSD et Ubuntu. Soit X refusait de se lancer avec diverses insultes, soit l'ordinateur était si lent qu'il en devenait inutilisable).
    Le problème ne se pose que sous X. En console, tout tourne très bien, c'est pas un problème d'ordinateur lent (2.6 Ghz, 1Go de ram). 4 secondes pour afficher un terminal quand c'est instantané avec un 1Ghz et 512Mo de ram (même OS, même WM, etc), il y a anguille sous roche… Et je parle pas de changer de desktop virtuel où il doit rafraichir tout l'écran…
    
    Mon problème semble venir de la carte graphique.
# n'oublions pas MESA

Posté par Anonyme le 28 avril 2009 à 18:18. Évalué à 1.

et oui ce dernier a pas mal de manques et pause donc des problèmes par exemple avec les jeux. J'ai essayé récemment de faire fonctionner un jeu avec wine et j'ai un message d'erreur comme quoi mon matos est trop vieux et qu'il faut un support des shaders 2.0 minimum (c'est un peu du chinois pour moi tout ca). Ce qui est dommage c'est que le même jeux fonctionne sans problèmes avec les vieux drivers fglrx... (vieux car j'ai une ati X300).
- [^] # Re: n'oublions pas MESA
  
  Posté par med le 28 avril 2009 à 18:30. Évalué à 4.
  
  Gallium devrait aider. Pour l'instant chaque pilote doit implémenter une pile opengl. Multiplie ça par n pilotes, ça donne 1) une duplication de code énorme 2) une duplication de bugs énorme 3) une charge de travail énorme. Avec gallium, chaque pilote n'auura qu'une seule pile qui tapera dans gallium. Ce sera gallium qui s'occupera de faire de l'opengl, openvg ou quoi que ce soit d'autre. Concrètement ça veut dire qu'il n'y aura une seule pile opengl pour tous les pilotes, donc pas de duplication, moins de bugs et plus facile à faire évoluer. Et théoriquement il serait aussi possible de faire une pile direct3d par exemple et tous les pilotes supporteraient automatiquement direct3d.
# Le grand nettoyage de code a commencé

Posté par Meku (site web personnel) le 28 avril 2009 à 22:46. Évalué à 2.

Bon ça y est, il semble que XAA, EXA et DRI1 aient été retirés du pilote intel dans la branche de développement :
http://lists.freedesktop.org/archives/xorg-commit/2009-April(...)
- [^] # Re: Le grand nettoyage de code a commencé
  
  Posté par Maclag le 29 avril 2009 à 09:07. Évalué à 3.
  
  C'est formidable de réduire comme ça le code, mais moi ce que je voudrais vraiment, c'est avoir une configuration un peu optimisée qui marche bien sans devoir comprendre le fonctionnement complet de l'architecture de xorg et ses 200 acronymes...
  
  A l'heure où on parle de plus en plus de Linux dans le grand public, j'imagine la tête des gens qui vont l'essayer: ah ben ma super carte que j'ai payée la peau du ... et ben sous Linux elle rame à mort.
  Et la réponse sur le forum:
  «C'est parce que t'as pas activé l'EXA à la place de XAA, mais bientôt tu pourras tout remplacer par UXA et ça marchera avec KMS et GEM!»
  «- ...»
  «Ben édite ton xorg.conf avec les bonnes options, quoi! Ca marchera pas encore très bien, mais d'ici un petit moment ça déchirera!»
  «- Édition... hmm... CD Win, install, suivant, suivant, suivant!»
  [4 ou 5 reboot plus tard]
  «- C'est bon, ma carte a retrouvé sa vélocité d'avant, merci! Je vais suivre tes conseils et je réessaierai Linux... plus tard!!»
  - [^] # Re: Le grand nettoyage de code a commencé
    
    Posté par Meku (site web personnel) le 29 avril 2009 à 23:12. Évalué à 9.
    
    Et bien justement, en retirant XAA, EXA, DRI1, etc., il n'y aura plus à bidouiller la configuration profonde de Xorg, ni besoin de comprendre des rouages de Xorg, puisqu'il n'y aura plus qu'une configuration possible sur laquelle les développeurs vont pouvoir se concentrer pour l'optimiser et la stabiliser.
    
    Comme dit dans le billet de Keith Packard, avec 48 combinaisons possibles, à la moindre modif que tu fais il faut vérifier qu'il n'y a pas de régression ailleurs... du coup le développement avance encore moins vite, et donc les utilisateurs subissent une période plus longue d'instabilité, de pauvres performances, et de bidouilles de configuration...
  - [^] # Re: Le grand nettoyage de code a commencé
    
    Posté par thedude le 29 avril 2009 à 23:22. Évalué à 6.
    
    ou encore:
    
    Jean Rene vient de s'acheter une carte graphique de la mort a 300$
    - J'ai pas le [biecran-resolution machin-3d lente-ce que tu veux ici]
    - Ah mais ca c'est parce que NVidia c'est des pourris. Les pilotes sont pas bon. T'aurais du prendre ATI
    - ah bon.
    - Mais en fait, ATI a des bugs aussi, les pilotes est mal gaule. c'est pas la faute al inux, c'est ATI qui implemente pas tout le pilote, du coup kde4 rame a mort.
    - Ah. Mais faut prendre quoi alors?
    - Intel. Mais le chipset est pourri, il fait juste de la 3d de base. Mais le pilote est libre, tu comprends bien, c'est achement mieux.
    - Ah bon. Mais je croyais que linux supportait plus de matos que windows?
    - Mais c'est le cas. Ma S3 trio sur port ISA est toujours supportee, plus sous windows. Tu peux aussi continuer a faire marcher une Savage 3d si tu veux. Une ATI Rage 128. Mais faudra faire une croix sur la 3d pour celle la.
    - Ah. Bon, ben faut que j'y aille la, tu m'excuses, hein.

Suivre le flux des commentaires

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