Peux-tu expliquer en quoi XLib pose un problème vis à vis de gérer plusieurs GPU?
Même si le protocole X11R6 est assynchrone à 99%, la XLib ne fonctionne quasiment qu'en mode synchrone. Donc pour tout un tas d'opérations elle ne peut gérer qu'une seule carte à la fois et bloque tout le reste tant qu'elle n'a pas reçu de réponse. Donc forcément en cas de plantage d'un des pilotes avant que XLib n'ait eu sa réponse, tout le monde est gelé.
Si c'était vraiment le cas alors avec XCB on n'aurait pas ce problème non
Avec XCB il n'y a pas le problème en effet. De façon générale on peut parfaitement gérer plusieurs rendus/GPU/surfaces/écrans en mélangeant allègrement en X11.
Je croyais que c'était un problème d'implémentation de X.Org..
Je n'ai jamais dit que c'était un problème d'implémentation X.Org. Mon seul message est que tout ce qui est possible avec Wayland est possible avec X11R6. Si on était en langage de programmation on dirait que X11R6 et Wayland sont tous les deux turing-complet mais ne relèvent pas du même paradigme.
Je suis d'accord avec nud et Kaane
Le problème est que Kaane n'était pas complètement d'accord avec nud et que je suis Kaane. Donc soit j'ai encore réussit à faire comprendre exactement l'inverse du message que je ne voulais pas donner, soit il y a un soucis.
je pense que les décorations clients seront gérées par les toolkits
CF mon post, ça pose de nombreux problèmes. Le premier et que l'on peut cascader les compositor et donc créer un compsitor pour les décorations (un wm quoi). Le second est que certaines applis ont déjà de décorations gérées par le client (les applis compiz et les applis Gnome3 au moins), charge donc au toolkit de reconnaitre ces applis pour ne pas recoller une couche de déco par dessus. Charge ensuite au wm si il y en a un de reconnaitre tout ça pour ne pas faire de même. Sinon une appli gtk/compiz sous un wayland avec un compositor wm va se retrouver avec 3 décos...
Se pose ensuite le problème de la gestion des évènements sur ces décos. C'est pas insoluble du tout, mais comme je l'ai dit précédemment il y aura des lignes de code à corriger dans quasiment toutes les applis.
Pas 100% vrai ça: avec Wayland une application peut passer une adresse de buffer mémoire du GPU au serveur d'affichage (Weston) pour qu'il l'utilise, ce qui doit être très efficace en local (si le GPU a une mémoire séparée), X11R6 ne permet pas ça.
Sous X11R6 il y a des tonnes d'équivalents. Je dis d'équivalents parce que comme X11R6 ne fait pas de composing, il n'y a aucun intérêt à lui retransmettre les buffers directs. On lui signale juste qu'on les prend et on dessine dedans. Pour les plus courant on peut citer les extensions overlay(un peu morte),DBE(pas toutes les implémentations), XAA, EXA, DRM, DRI (et dans une certaine mesure XRender même si c'est une surcouche). Toutes ces extensions vont faire mumuse directement avec la mémoire de la carte graphique, et sont donc très rapide en local.
[^] # Re: Fenêtre
Posté par Kaane . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 0.
Qt5 devrait aussi supporter XCB.
Ca serait une excellente chose.
Peux-tu expliquer en quoi XLib pose un problème vis à vis de gérer plusieurs GPU?
Même si le protocole X11R6 est assynchrone à 99%, la XLib ne fonctionne quasiment qu'en mode synchrone. Donc pour tout un tas d'opérations elle ne peut gérer qu'une seule carte à la fois et bloque tout le reste tant qu'elle n'a pas reçu de réponse. Donc forcément en cas de plantage d'un des pilotes avant que XLib n'ait eu sa réponse, tout le monde est gelé.
Si c'était vraiment le cas alors avec XCB on n'aurait pas ce problème non
Avec XCB il n'y a pas le problème en effet. De façon générale on peut parfaitement gérer plusieurs rendus/GPU/surfaces/écrans en mélangeant allègrement en X11.
Je croyais que c'était un problème d'implémentation de X.Org..
Je n'ai jamais dit que c'était un problème d'implémentation X.Org. Mon seul message est que tout ce qui est possible avec Wayland est possible avec X11R6. Si on était en langage de programmation on dirait que X11R6 et Wayland sont tous les deux turing-complet mais ne relèvent pas du même paradigme.
Je suis d'accord avec nud et Kaane
Le problème est que Kaane n'était pas complètement d'accord avec nud et que je suis Kaane. Donc soit j'ai encore réussit à faire comprendre exactement l'inverse du message que je ne voulais pas donner, soit il y a un soucis.
je pense que les décorations clients seront gérées par les toolkits
CF mon post, ça pose de nombreux problèmes. Le premier et que l'on peut cascader les compositor et donc créer un compsitor pour les décorations (un wm quoi). Le second est que certaines applis ont déjà de décorations gérées par le client (les applis compiz et les applis Gnome3 au moins), charge donc au toolkit de reconnaitre ces applis pour ne pas recoller une couche de déco par dessus. Charge ensuite au wm si il y en a un de reconnaitre tout ça pour ne pas faire de même. Sinon une appli gtk/compiz sous un wayland avec un compositor wm va se retrouver avec 3 décos...
Se pose ensuite le problème de la gestion des évènements sur ces décos. C'est pas insoluble du tout, mais comme je l'ai dit précédemment il y aura des lignes de code à corriger dans quasiment toutes les applis.
Pas 100% vrai ça: avec Wayland une application peut passer une adresse de buffer mémoire du GPU au serveur d'affichage (Weston) pour qu'il l'utilise, ce qui doit être très efficace en local (si le GPU a une mémoire séparée), X11R6 ne permet pas ça.
Sous X11R6 il y a des tonnes d'équivalents. Je dis d'équivalents parce que comme X11R6 ne fait pas de composing, il n'y a aucun intérêt à lui retransmettre les buffers directs. On lui signale juste qu'on les prend et on dessine dedans. Pour les plus courant on peut citer les extensions overlay(un peu morte),DBE(pas toutes les implémentations), XAA, EXA, DRM, DRI (et dans une certaine mesure XRender même si c'est une surcouche). Toutes ces extensions vont faire mumuse directement avec la mémoire de la carte graphique, et sont donc très rapide en local.