euh... Moui donc les utilisateurs de soft 3D doivent utiliser Windows. Mauvaise réponse.
Euh, ils peuvent aussi acheter des cartes pro. Et là ça marche très bien. Les cartes graphiques grand public n'ont qu'une seule idée en tête faire plus de fps que la concurrente sous le dernier jeu à la mode. Mes vieilles FireGL font très bien framebuffer + bi écran+switch fullscreen/fenetre+rendu video dans une texture en même temps. Sans plantage.
Suffit pour les maceux, de faire fonctionner un soft OpenGL sous X ( par exemple la version Linux via XWine ) et le même soft nativement sous Quartz pour voir que le problème n'est pas matériel " lié à Windows ".
Tu as déjà vu Quartz accepter un context switch ? Et si oui le reveil a pas fait trop mal à la tête le lendemain ?
Il est impossible de bypasser quartz, tous les rendus de Xquartz/X11.app se font dans des textures avec 0 ou presque accélération. Et malgré tout il y a quand même des carte ATI qui vont te geler ton mac quand tu vas passer l'application X11 en fullscreen. Sous Mac OSX si tu veux faire de l'OpenGL accéléré tu es obligé de faire appel à quartz et d'utiliser le context de quartz tel quel.
Ah, et donc le plantage de X , c'est aussi la perte de toutes les applis ouvertes
Comme sous tous les autres systèmes. Et encore sous X les applis ont une "seconde chance" si elles n'utilisent pas une lib synchrone comme XLib, une appli qui utilise XCB et qui ne voit pas revenir ses tokens peut encore lancer des sauvegardes d'etat en urgence. Sous Windows un context switch qui foire et rend la carte graphique instable c'est ecran bleu direct, sous Mac c'est freeze ad vitam, sous Linux si tu as un autre contexte prêt (par exemple une console qui n'est pas en frame buffer) ton système peut être récupérable.
Et sous Wayland , le problème existera-t-il toujours ou " pas " ?
Oui le problème sera toujours là, ou pour être exact quand il sera résolu sous Wayland, on pourra le résoudre aussi sous X11 et réciproquement. Il ne s'agit pas du tout de l'architecture X11, mais bien de la carte graphique qui sort de l'etat 1 sans parvenir à rentrer dans l'etat 2. Ca peut être un problème de pilote, d'ACPI, de concurrence entre plusieurs contextes etc. Mais la seule façon d'éviter le soucis avec wayland c'est de faire comme quartz : on interdit tout context switch. Si le mec veut passer en plein écran dans une résolution différente on zoom sa texture dans le contexte existant et c'est marre.
Mais rien dans la XLib ne permet une réservation de mémoire divisée par GPU. Rien. Et ça sera jamais fait. ( Et ça, c'est pas moi qui le dit, ce sont les dev Xorg ).
Oui la XLib est une bouse. On est d'accord. XCB est bien mieux, mais aucune des grosses bibliothèque n'a suivi, il y a vaguement pango comme appli en pur XCB, et les EFL. En XCB on a accès à tout le protocole X11 sous-jacent, et donc faire tout ce que tu annonce.
De toute les façons les libs GPGCU ont démontrés que Linux savait parfaitement gérer plusieurs GPU et demander des calculs différents à chacun d'eux avant de mélanger les résultats. Ce qui bloque c'est XLib. Pas la gestion de mémoire, ni X11 ni même l'implémentation xorg.
Euh non, ça fait 100% du parc existant.
Je parlais bien entendu des applis écrites directement en XLib ou en TK ou en XMotif. Ces applis représentent aujourd'hui encore l'écrasante majorité des applis métier.
Mais combien de logiciels " sont à réécrire " , en dehors des libs comme GTK et Qt ?
Mais même les applis codées en GTK ou en QT parfait sont à réécrire. Wayland fait moins de chose que X11, toutes les choses qui ne sont pas faites par Wayland doivent désormais être faites au sein de l'appli. Ca implique nécessairement de revoir tout le code, à moins de vouloir lancer un émulateur X complet avec gestion des inputs + un décorateur de fenêtre qui fait mini-wm avec chaque fenêtre.
de toutes façons ces logiciels n'auraient pas passé sans heurts le passage à XCB.
Oui mais on aurait changé un truc. A savoir le système de messagerie entre les applis et le serveur X. Là on se retrouve à tout changer et à tout devoir recoder. Et quand je vois le mal qu'a eu Rasterman pour migrer les EFL sous XCB. Ca a pris quatre ans ! Pour une lib qui n'était utilisée par quasiment personne, qui pouvait très largement se permettre de tout casser et qui avait l'objectif de passer en XCB dans ses priorités. (Et en plus Rasterman est loin d'être un manchot quand il s'agit de gérer le protocole X11 à la mano, On peut pas en dire autant de tous les devs d'applis graphiques). Ceci étant si les grosses libs avaient vraiment suivi (i.e fait du XCB pur) on aurait pu avoir un système plus faible aujourd'hui, avec pour les applis qui utilisent ces libs des recettes sur "comment faire ci ou ça dans la nouvelle version de la lib." Mais même ça, ça n'a pas marché.
Avec Wayland on fout à la poubelle les libs de haut niveau, les libs de bas niveau, le système de message, le paradigme d'affichage tout entier etc. C'est cent fois plus dur.(Ce qui ne veut pas dire que ça ne se fera pas, tout dépend une fois de plus du degré d'implication des grands acteurs, et aussi de la qualité de la doc)
Mais Wayland ne permet rien que X11R6 ne puisse faire. Il promet de dégraisser le mammouth et de passer sur un paradigme plus adapté aux besoins d'aujourd'hui. Ce n'est pas une mauvaise chose, et ça peut même être très positif. Mais ça demande un effort colossal de l'ensemble de la communauté.
[^] # Re: Fenêtre
Posté par Kaane . En réponse à la dépêche Pourquoi Wayland veut remplacer X. Évalué à 7.
euh... Moui donc les utilisateurs de soft 3D doivent utiliser Windows. Mauvaise réponse.
Euh, ils peuvent aussi acheter des cartes pro. Et là ça marche très bien. Les cartes graphiques grand public n'ont qu'une seule idée en tête faire plus de fps que la concurrente sous le dernier jeu à la mode. Mes vieilles FireGL font très bien framebuffer + bi écran+switch fullscreen/fenetre+rendu video dans une texture en même temps. Sans plantage.
Suffit pour les maceux, de faire fonctionner un soft OpenGL sous X ( par exemple la version Linux via XWine ) et le même soft nativement sous Quartz pour voir que le problème n'est pas matériel " lié à Windows ".
Tu as déjà vu Quartz accepter un context switch ? Et si oui le reveil a pas fait trop mal à la tête le lendemain ?
Il est impossible de bypasser quartz, tous les rendus de Xquartz/X11.app se font dans des textures avec 0 ou presque accélération. Et malgré tout il y a quand même des carte ATI qui vont te geler ton mac quand tu vas passer l'application X11 en fullscreen. Sous Mac OSX si tu veux faire de l'OpenGL accéléré tu es obligé de faire appel à quartz et d'utiliser le context de quartz tel quel.
Ah, et donc le plantage de X , c'est aussi la perte de toutes les applis ouvertes
Comme sous tous les autres systèmes. Et encore sous X les applis ont une "seconde chance" si elles n'utilisent pas une lib synchrone comme XLib, une appli qui utilise XCB et qui ne voit pas revenir ses tokens peut encore lancer des sauvegardes d'etat en urgence. Sous Windows un context switch qui foire et rend la carte graphique instable c'est ecran bleu direct, sous Mac c'est freeze ad vitam, sous Linux si tu as un autre contexte prêt (par exemple une console qui n'est pas en frame buffer) ton système peut être récupérable.
Et sous Wayland , le problème existera-t-il toujours ou " pas " ?
Oui le problème sera toujours là, ou pour être exact quand il sera résolu sous Wayland, on pourra le résoudre aussi sous X11 et réciproquement. Il ne s'agit pas du tout de l'architecture X11, mais bien de la carte graphique qui sort de l'etat 1 sans parvenir à rentrer dans l'etat 2. Ca peut être un problème de pilote, d'ACPI, de concurrence entre plusieurs contextes etc. Mais la seule façon d'éviter le soucis avec wayland c'est de faire comme quartz : on interdit tout context switch. Si le mec veut passer en plein écran dans une résolution différente on zoom sa texture dans le contexte existant et c'est marre.
Mais rien dans la XLib ne permet une réservation de mémoire divisée par GPU. Rien. Et ça sera jamais fait. ( Et ça, c'est pas moi qui le dit, ce sont les dev Xorg ).
Oui la XLib est une bouse. On est d'accord. XCB est bien mieux, mais aucune des grosses bibliothèque n'a suivi, il y a vaguement pango comme appli en pur XCB, et les EFL. En XCB on a accès à tout le protocole X11 sous-jacent, et donc faire tout ce que tu annonce.
De toute les façons les libs GPGCU ont démontrés que Linux savait parfaitement gérer plusieurs GPU et demander des calculs différents à chacun d'eux avant de mélanger les résultats. Ce qui bloque c'est XLib. Pas la gestion de mémoire, ni X11 ni même l'implémentation xorg.
Euh non, ça fait 100% du parc existant.
Je parlais bien entendu des applis écrites directement en XLib ou en TK ou en XMotif. Ces applis représentent aujourd'hui encore l'écrasante majorité des applis métier.
Mais combien de logiciels " sont à réécrire " , en dehors des libs comme GTK et Qt ?
Mais même les applis codées en GTK ou en QT parfait sont à réécrire. Wayland fait moins de chose que X11, toutes les choses qui ne sont pas faites par Wayland doivent désormais être faites au sein de l'appli. Ca implique nécessairement de revoir tout le code, à moins de vouloir lancer un émulateur X complet avec gestion des inputs + un décorateur de fenêtre qui fait mini-wm avec chaque fenêtre.
de toutes façons ces logiciels n'auraient pas passé sans heurts le passage à XCB.
Oui mais on aurait changé un truc. A savoir le système de messagerie entre les applis et le serveur X. Là on se retrouve à tout changer et à tout devoir recoder. Et quand je vois le mal qu'a eu Rasterman pour migrer les EFL sous XCB. Ca a pris quatre ans ! Pour une lib qui n'était utilisée par quasiment personne, qui pouvait très largement se permettre de tout casser et qui avait l'objectif de passer en XCB dans ses priorités. (Et en plus Rasterman est loin d'être un manchot quand il s'agit de gérer le protocole X11 à la mano, On peut pas en dire autant de tous les devs d'applis graphiques). Ceci étant si les grosses libs avaient vraiment suivi (i.e fait du XCB pur) on aurait pu avoir un système plus faible aujourd'hui, avec pour les applis qui utilisent ces libs des recettes sur "comment faire ci ou ça dans la nouvelle version de la lib." Mais même ça, ça n'a pas marché.
Avec Wayland on fout à la poubelle les libs de haut niveau, les libs de bas niveau, le système de message, le paradigme d'affichage tout entier etc. C'est cent fois plus dur.(Ce qui ne veut pas dire que ça ne se fera pas, tout dépend une fois de plus du degré d'implication des grands acteurs, et aussi de la qualité de la doc)
Mais Wayland ne permet rien que X11R6 ne puisse faire. Il promet de dégraisser le mammouth et de passer sur un paradigme plus adapté aux besoins d'aujourd'hui. Ce n'est pas une mauvaise chose, et ça peut même être très positif. Mais ça demande un effort colossal de l'ensemble de la communauté.