Articles : Interface graphique fonctionnelle : encore un effort pour l'open source
Posté par didier granjon. Modéré le 07 juillet 2008.
C'est au cours de l'année que je réussis à démarrer une Slackware 3.0 (fournie par mon copain Christophe, salut Christophe !) qui m'amenait à un shell en mode texte. Ici, pas de graphique, juste du texte.
Ce n'est que 6 mois plus tard que je fis connaissance de mon mentor Linuxien (salut Baptiste !). Non content d'installer mon Linux en dual-boot avec Windows - à l'époque, ça restait quand même indispensable pour mes études - je configurais également mon serveur X sur une RedHat 5.2. J'avais d'ailleurs tellement bien oeuvré pour faire fonctionner tout ceci que j'avais fait une démonstration dans un amphi lors d'une install party avec configuration d'une Matrox G200 en mode 2D 16 millions de couleurs en lieu et place du mode 16 couleurs.
Avec le recul, on prend mieux la mesure des progrès qui ont été fait. Aujourd'hui, toute distribution est au moins en mesure de démarrer le serveur X et de proposer une interface graphique fonctionnelle. Néanmoins, cette situation n'est pas encore parfaite et certains points sont toujours en cours d'amélioration.
![[en]](../images/en.png)
x.org (542 hits)-
Le projet 'nouveau' (1542 hits)
> Lire la dépêche (145 commentaires, moyenne: 3,2).
Vous avez demandé le commentaire #948455.
Run by 
Cette page a été générée par Templeet en 0.0855s (dont 0.0071 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Merci pour cette dépêche, je rebondis...
Idée excellente que cette dépêche car je vais enfin pouvoir poser la question qui me taraude depuis que j'uilise Linux (3 ans).
Est ce que vraiment faire une image de ce qui doit être affiché et l'envoyer via un socket sur un serveur qui lui va l'envoyer à la CG n'est pas un peu obsolète aujourd'hui ?
Il me semble, merci de me corriger si je me trompe, que cela a été pensé il y a bien longtemps du temps des terminaux déportés.
Ne gagnerait on pas énormément en performances et en ressources en faisant ce que font Windows et Mac : une couche graphique au plus près du matériel ?
J'ai osé poster cette idée sur le "brainstorm" Ubuntu, autant dire que je me suis fait pourrir par les intégristes Unixiens de tout poils. Mais je persiste, sans compter tous les aspects où Linux est en retard (gestion à chaud des changements de paramètres, gestion des profils couleurs...).
http://www.romuphoto.fr
[^]Re: Merci pour cette dépêche, je rebondis...
Tu a calculé la bande passante des sockets locales ?
De toute façon ce truc "obsolete" te permet plus de chose et plus facilement que les système "plus près du matériel" donc ce serait stupide de s'en séparer. Surtout que les terminaux X et l'affichage
déporté d'applications, n'en déplaise a certains c'est toujours très utilisé.
Ensuite quand on voit les perfs que sont capables de tirer enlightenment sur le système 2D, ou les jeux natif 3D je ne vois pas de raison de changer.
Les plus gros soucis de perfs et de resources des applications X11 sont plus souvent lié à l'utilisation de N couches de toolkits et autres abstractions qu'au dispositif X11 en lui même
Il [e2fsck] a bien démarré, mais il m'a rendu la main aussitot en me disant "houlala, c'est pas beau à voir votre truc, je préfèrerai que vous teniez vous même la tronçonneuse" (traduction libre)
[^]Re: Merci pour cette dépêche, je rebondis...
Non je n'ai rien calculé.
Bien évidemment ma remarque ne compte que dans une optique "Linux sur le poste de travail de tout un chacun", et dans cette optique, ça me fait un peu l'impression d'utiliser un bazooka pour écraser une mouche le serveur X.
http://www.romuphoto.fr
[^]Re: Merci pour cette dépêche, je rebondis...
Surtout que les terminaux X et l'affichage
déporté d'applications, n'en déplaise a certains c'est toujours très utilisé.
Je plussoie vigoureusement. Ici chez moi: deux machines ont un écran et font aussi TX, et derrière j'ai huit autres machines qui servent à des trucs variés. Et quand aux performances, même sur un réseau un peu chargé, ça reste dans la plupart des cas très utilisable. Il faut dire que pour les games, j'ai un SMS, une SNES, une GB et une GC, donc pas de jeux sur les ordinateurs en gros. casser l'architecture client-serveur du X11 serait à la fois un troll bien glauque et une énorme erreur stratégique.
( Kriiikzz )
[^]Re: Merci pour cette dépêche, je rebondis...
D'autant que certains trucs sont prévus pour fonctionner avec un export de l'affichage...
... parce que bon... configurer mon Mythbackend sans exporter le clickodrome, soit ça me force à avoir un X.org complet dans un des conteneurs de l'un de mes serveurs (beurrrk), soit à mettre les mains dans une base mysql (beurrrk)...
[^]Re: Merci pour cette dépêche, je rebondis...
Un avantage de ne pas faire comme Apple et Microsoft, c'est de ne pas être obligé d'installer et d'utiliser un environnement graphique.
Pour ce qui est des perfs, a moins de de passer son temps a mesurer les FPS, Xorg ne se caractérise pas par une lenteur extravagante.
Quant à l'architecture client/serveur, même s'il elle date, en quoi est-elle si mauvaise que cela ?
[^]Re: Merci pour cette dépêche, je rebondis...
J'ajoute que la gestion des profils couleur existe => dispwin
[^]Re: Merci pour cette dépêche, je rebondis...
Moi aussi j'utilise un truc dans le genre "xcalib" :
- faut récupérer les sources,
- faut recompiler,
- faut que le driver graphique supporte la chose
- dès qu'on modifie un truc dans le Xorg.conf, faut le redémarrer.
Bref c'est l'âge de pierre des interfaces, désolé.
Mais ta remarque "c'est de ne pas être obligé d'installer et d'utiliser un environnement graphique" est très juste et je ne serais pas vraiment surpris que le problème vienne de là : on veut tout faire faire à Linux, du serveur sans interface au poste de travail et fatalement, on se retrouve donc sur le plus petit dénominateur commun à toutes ces utilisations.
http://www.romuphoto.fr
[^]Re: Merci pour cette dépêche, je rebondis...
Moi aussi j'utilise un truc dans le genre "xcalib" :
- faut récupérer les sources,
- faut recompiler,
Effectivement, si c'est pas dans les dépôts de ta distrib... mais bon tu ne doit pas être obligé de le recompiler tout les jours non plus.
- dès qu'on modifie un truc dans le Xorg.conf, faut le redémarrer.
J'imagine que cela va changer a moyen terme. Il me semble avoir lu quelques part que l'un des objectif de Xorg était de ne plus dépendre d'un fichier de config et de pourvoir déteminer la config dynamiquement.
Pour le moment, on payes encore les errances du projet Xfree, mais il y a eu beaucoup d'avancées.
Bref c'est l'âge de pierre des interfaces, désolé.
Certes, certaine parti de l'architecture ne sont pas vraiment au top. Mais je le redis : Le projets Xfree a laissé quelques séquelles.
[^]Re: Merci pour cette dépêche, je rebondis...
Ce n'est pas xrandr qui devrait gérer ça par hasard ?
La Roue du Temps
[^]Re: Merci pour cette dépêche, je rebondis...
Est ce que vraiment faire une image de ce qui doit être affiché et l'envoyer via un socket sur un serveur qui lui va l'envoyer à la CG n'est pas un peu obsolète aujourd'hui ?
Naaaannn !
Ca permet de faire des chouettes export display pour faire tourner des applis distantes, éventuellement dans un tunnel ssh, sur ton serveur X local, et ça, c'est bien =)
[^]Re: Merci pour cette dépêche, je rebondis...
Et je crois que les tunnels compressés tel que NX (http://www.nomachine.com/) s'appuient également sur ces mécanismes.
[^]Re: Merci pour cette dépêche, je rebondis...
Des gens plus compétents que moi et très impliqués sur le sujet (au hasard, Keith Packard) ont conclu que le problème des sockets était un non-problème avec très peu d'overhead. L'overhead est ailleurs (apparemment, la nature de la XLib, ses appels bloquants et son caching inapproprié seraient davantage problématiques, d'où l'apparition de XCL/XCB). j'ajoute que sur une machine locale, il s'agit de sockets UNIX et que l'extension XSHM permet d'utiliser de la mémoire partagée (donc d'éviter les transfert que tu décris). Même les projets destinés à l'embarqué (comme feu PicoGUI ou les plus actuels Xynth/XFast) utilisent une architecture client/serveur comparable.
Par contre, j'ai tendance à être pas mal de l'avis de John Smirl (qui critiquait les efforts placés dans EXA dans la mesure où tous les chips actuels ont des capacités 3D, et qui préconisait +/- une couche d'abstraction 100% EGL/OpenGL à la place, surtout que les avancées d'OpenGL (shaders...) permettent d'imaginer des applications inconcevables par le passé, au hasard http://alice.loria.fr/publications/papers/2005/VTM/vtm.pdf ).
L'architecture de DirectFB 2.0 semble aussi s'orienter vers l'utilisation de backends (comme OpenVG) exploitant davantage l'accélération matérielle http://directfb.org/wiki/index.php/DirectFB_2.0:_Efficient_2(...)
[^]Re: Merci pour cette dépêche, je rebondis...
La plupart des implémentations d'EXA (Radeon et Nouveau au moins, je sais pas pour Intel) sont faites en programmant directement le moteur 3D de la carte. Et si j'ai bien tout compris, ça permet d'éviter d'avoir à lancer toute la machinerie OpenGL pour faire de la 2D.
[^]Re: Merci pour cette dépêche, je rebondis...
Est ce que vraiment faire une image de ce qui doit être affiché et l'envoyer via un socket sur un serveur qui lui va l'envoyer à la CG n'est pas un peu obsolète aujourd'hui ?
Ca n'est plus fait comme ça depuis longtemps : xorg utilise la mémoire partagée unix (shm, etc...) pour transmettre les grosses données lorsque c'est possible (Utilisation en local, activation des modules kivonbien, etc).
[^]Re: Merci pour cette dépêche, je rebondis...
Dans un debat sur OSNews sur le même sujet, un lecteur m'a dit que shm était incompatible avec l'accélération matérielle, ce qui est un probleme..
J'avoue avoir un peu de mal a comprendre comment ça marcherait un bureau avec une acceleration materielle si le client fait le rendu de l'image..
J'ai lu que de plus en plus une grosse partie du rendu est faite par le client X (le programme), mais il faudrait que le programme client puisse faire le rendu en utilisant l'acceleration materielle (et idealement directement dans la mémoire de la carte graphique si l'affichage est local) et ensuite passe une reference vers l'image au serveur X qui idéalement utiliserait aussi l'acceleration materielle pour composer ces image dans le rendu final mais
1) tous les clients et le serveur partageant la carte graphique: ça ne pose pas un probleme? Au départ, les cartes graphique avaient 'un seul maitre' pour l'acceleration 3D il me semble.
2) j'ai l'impression que si le serveur X compose des 'images' fourni par le client, au niveau rendu des fontes ça risque d'être l'horreur: pas de possibilité de faire de l'anti-aliasing propre tant que tu ne connais pas ton positionement par rapport aux pixels (tant que le DPI des écrans reste assez faible :-( ).
Ce n'est pas clair tout ça pour moi..
Je ne comprends pas bien pourquoi on parle d'image fourni par le client: si le client fournissait des vecteur et du texte a la place d'image (ce que fait Cairo il me semble non?), le rendu et la composition étant fait par le serveur, ces problemes la disparaitraient non?
[^]Re: Merci pour cette dépêche, je rebondis...
[...] il faudrait que le programme client puisse faire le rendu en utilisant l'acceleration materielle (et idealement directement dans la mémoire de la carte graphique si l'affichage est local)
Si l'affichage est déporté, il n'y a aucun moyen que l'application utilise la carte graphique !
Maintenant, lorsqu'une application (ou un toolkit graphique) veut utiliser l'accélération matérielle, elle utilise l'api OpenGL en court-circuitant le serveur X. Donc il est impossible d'utiliser openGL en affichage déporté (sauf bidouille, mais cela n'aurait aucun intéret de tt façon).
et ensuite passe une reference vers l'image au serveur X qui idéalement utiliserait aussi l'acceleration materielle pour composer ces image dans le rendu final
C'est à peu de choses près ce qu'il se passe actuellement. Lorsque le serveur X est en mode RenderAccel (EXA, XAA,...), il utilse des optimisations implémentées par le pilotes de la CG. On peut aussi utiliser un composeur (?) style compiz qui utilise le contexte OpenGL de la cg.
1) tous les clients et le serveur partageant la carte graphique: ça ne pose pas un probleme? Au départ, les cartes graphique avaient 'un seul maitre' pour l'acceleration 3D il me semble.
C'est toujours le cas et ce n'est pas près de changer. C'est la même chose que faire du multi-tâche alors qu'on a qu'un seul CPU: il faut le partager entre les applications en sauvegardant/restaurant leur contexte respectif.
j'ai l'impression que si le serveur X compose des 'images' fourni par le client, au niveau rendu des fontes ça risque d'être l'horreur: pas de possibilité de faire de l'anti-aliasing propre tant que tu ne connais pas ton positionement par rapport aux pixels (tant que le DPI des écrans reste assez faible :-( ).
Étant donné que l'on n'a pas encore inventé les pixels quantiques, l'image envoyée par le client sera toujours alignée sur un pixel (logique, non ?). L'AA est fait par le client, s'il veut que sont image puisse être composée, il n'a qu'à y avoir des pixels (semi-)transparents...
Je ne comprends pas bien pourquoi on parle d'image fourni par le client: si le client fournissait des vecteur et du texte a la place d'image
Le protocol X permet cela mais ces instructions restent basiques.
(ce que fait Cairo il me semble non?),
Non, justement c'est à cairo que l'on demande de dessiner des formes vectorielles dans un pixmap, que l'on envoit ensuite au serveur X. Imagine le temps qu'il faudrait pour redessiner ton écran si à chaque refresh X devait se taper le rendu d'une description vectorielle au lieu d'une faire une bête copie binaire. Ce serait aussi la voie vers une explosion de la complexité du protocol X (il faudra une nouvelle version du protocole à chaque fois que tu voudrais utiliser un nouveau type de flou ?!).
le rendu et la composition étant fait par le serveur, ces problemes la disparaitraient non?
À quels problèmes fait tu références ?
L'avantage de cette architecture c'est que le rendu et la composition sont effectués par ceux qui sont le mieux disposés à le faire. Et avec un compositeur style compiz, on arrive même à masquer la latence engendrée lorque le serveur X demande à une fenêtre de se redessiner.
[^]Re: Merci pour cette dépêche, je rebondis...
>>Si l'affichage est déporté, il n'y a aucun moyen que l'application utilise la carte graphique !<<
Aucun moyen dans l'implementation actuelle, pas dans l'absolu:
-le client pourrait utiliser sa carte graphique pour accelerer un rendu sans l'afficher, recopier l'image en mémoire principale (raisonnable depuis PCI Express pour des rendus complexes) puis l'envoyer au serveur
-si le client envoyait des vecteurs ou des commandes OpenGL au serveur, le rendu serait fait par le serveur: j'ai bien compris que ce n'est pas le cas a l'heure actuelle, mais 'aucun moyen' n'est pas correcte.
>>mais cela n'aurait aucun intéret de tt façon<<
Bin la bande passante utilisée pour envoyer des vecteur ou des commandes OpenGL est tres inferieure a celle utilisée pour envoyer des images donc dans certaines conditions (assez limitée d'accord), cela pourrait être interressant.
>>Étant donné que l'on n'a pas encore inventé les pixels quantiques, l'image envoyée par le client sera toujours alignée sur un pixel (logique, non ?).<<
Certes mais si la composition decale l'image d'une quantité non-entiere, le mapping des pixels n'est plus valable non?
>>Non, justement c'est à cairo que l'on demande de dessiner des formes vectorielles dans un pixmap, que l'on envoit ensuite au serveur X.<<
Oui j'avais oublié ça, mais ça veut dire que cairo ne peut pas utiliser l'acceleration materielle alors???
>>Imagine le temps qu'il faudrait pour redessiner ton écran si à chaque refresh X devait se taper le rendu d'une description vectorielle au lieu d'une faire une bête copie binaire.<<
Bof, le serveur pourrait cacher le rendu je ne vois pas ou est le probleme.
>>Ce serait aussi la voie vers une explosion de la complexité du protocol X (il faudra une nouvelle version du protocole à chaque fois que tu voudrais utiliser un nouveau type de flou ?!).<<
C'est effectivement le gros probleme..
[^]Re: Merci pour cette dépêche, je rebondis...
Aucun moyen dans l'implementation actuelle, pas dans l'absolu:
-le client pourrait utiliser sa carte graphique pour accelerer un rendu sans l'afficher, recopier l'image en mémoire principale (raisonnable depuis PCI Express pour des rendus complexes) puis l'envoyer au serveur
-si le client envoyait des vecteurs ou des commandes OpenGL au serveur, le rendu serait fait par le serveur: j'ai bien compris que ce n'est pas le cas a l'heure actuelle, mais 'aucun moyen' n'est pas correcte.
Merci de me lire correctement, tout est toujours possible mais cela vaut -il réellement la peine ? ;)
Je te ferais remarquer aussi que la BP des cartes graphiques ne fait qu'augmenter. On ne fait pas qu'envoyer des "commandes vectorielles" à un CG, on y copie aussi des structures et des textures. Si tu parcours les liens donnés dans cet articles, tu te rendras compte que le problème de copier des données dans la cg de manière efficace est primordial. Ajoute y l'over-overheard d'un réseau et c'est à peine si tu peux encore jouer à pong.
Dans ton idée (rappel, opengl permet de faire du rendu temps-réel, ie affichier le plus d'images possibles par secondes), ce qu'il te faut c'est pas le protocole X mais un protocole de streaming vidéo + un mesa qui permet au client d'utilise une carte graphique.
Note: le fait d'utiliser un client déporté n'empêche pas le serveur X de faire du composing accéléré (cf. compiz).
Certes mais si la composition decale l'image d'une quantité non-entiere, le mapping des pixels n'est plus valable non?
gni !? Comment fais-tu pour décaller une image d'un demi-pixel ? (hint: dépose un brevet, ça a l'air intéressant... (o: )
mais ça veut dire que cairo ne peut pas utiliser l'acceleration materielle alors???
Il peut faire comme tout le monde et utiliser OpenGL (comme QT le peut, je pense).
Bof, le serveur pourrait cacher le rendu je ne vois pas ou est le probleme.
Oui mais pour des raisons qui me sont inconnues, il ne le fait pas; Compiz le fait. Par contre, X peut cacher des pixmaps à la demande de l'application.
[^]Re: Merci pour cette dépêche, je rebondis...
Je crois que tu te mélanges un peu les pinceaux quand même : Cairo peut utiliser l'accél matérielle parce que justement il ne fait pas le composting avant de l'envoyer à X ....
[^]Re: Merci pour cette dépêche, je rebondis...
Si j'ai bien compris Cairo est utilisé par le client donc s'il peut utiliser l'accél matérielle et que le compositeur qui lui est coté X serveur utilise l'accel materielle aussi alors ça veut dire que plusieurs processus utilisent tous les deux l'accel materielle, c'est possible?
[^]Re: Merci pour cette dépêche, je rebondis...
Je ne vois pas de problème à ce que deux applis différentes utilisent "en même temps" l'accel matérielle : en OpenGL on a des contextes, il me semble qu'il y a un équivalent pour EXA/XAA.
[^]Re: Merci pour cette dépêche, je rebondis...
Donc il est impossible d'utiliser openGL en affichage déporté (sauf bidouille, mais cela n'aurait aucun intéret de tt façon).
Heuu ... si justement, GLX a été fait pour ça et il est possible d'utiliser de l'OpenGL "déporté".
Imagine le temps qu'il faudrait pour redessiner ton écran si à chaque refresh X devait se taper le rendu d'une description vectorielle au lieu d'une faire une bête copie binaire.
Bahh, c'est ce que fait justement OpenGL, et c'est bien plus rapide qu'une "copie binaire" puisque c'est la carte graphique qui s'en occupe ...
Faire passer de l'OpenGL par le réseau, ce n'est pas "aberrant", car au lieu de faire passer des pixmaps complets, tu fais passer en quelques octets un paquet disant "trace moi telle triangle à telles coordonnées", etc. Plus la scène est compliquée, plus le traffic augmente par contre, donc pour des images "compliquées" il doit y avoir un seuil où passer par des bitmaps est plus avantageux.
[^]Re: Merci pour cette dépêche, je rebondis...
Ahh merci ! j'avais l'impression d'avoir rêvé !
J'ai fait le test il y a 3 mois entre deux bécanes : d'un coté un thinkpad X22 : pauvre pentium3 et vieille radeon 8mo (huhu), sur lequel j'avais lancé tremulous avec comme DISPLAY une autre bécane, en l'occurence un pc de bureau avec une nvidia gefore6600 : ça marchait !
Juste un soucis : des ralentissement sensibles lors de changement de scène (typiquement l'arrivée depuis un couloir vide vers une salle de carnage avec du monde et des bâtiments dans tout les sens) qui sont certainement du au fait d'envoi d'infos lourdes commes des textures et autres. Sachant que dans mon test j'étais limité par la carte ethernet 10mb/s du thinkpad, il faudrait refaire le test entre deux bécanes en gigabit !
Donc oui il y a des trucs où c'est normal que ça ralentisse (transfert de textures et autres) mais la 3D en elle-même est bien accélérée en déporté !
† In te confirmátus sum ex útero : de ventre matris meæ tu es protéctor meus.
[^]Re: Merci pour cette dépêche, je rebondis...
Heuu ... si justement, GLX a été fait pour ça et il est possible d'utiliser de l'OpenGL "déporté".
Ah c'est sympa ça ! merci pour l'info, cela m'apprendra à raconter n'importe quoi.
Sinon je trouvais cela aberrant dans le cadre d'une utilisation "temps-réel" (jeux) où la latence du réseau doit quand même se faire sentir. Plus les problèmes de chargement de textures évoqués par Thomas D.
Concercant cairo, celui-ci utilise l'extension Xrender mais rien ne l'empêcherait d'utiliser opengl (evas et qt possèdent ce genre de backend).