de support correct pour l'ATI Mach64, qui est antidéluvienne,
La prochaine version di DRI devrai te combler, quelques développeurs (2-3) se sont mis au travail en passant par la difficile phase d'apprentissage de l'architecture et des sources de XFree/DRI et ca a fini par porter ses fruits.
En conséquence, certains matériels restent de manière totalement absurde de coté pour certaines fonctionnalités (typiquement XVideo, XRender), alors qu'une implémentation par défaut le leur donnerait au prix certes de performances médiocres.
C'est le cas pour XRender, cela a d'ailleur des effets pervers: beaucoup de cartes n'ont pas nécéssairement le support adéquat révé pour l'implémenter, d'où la difficulté, d'où le fait que l'on reste sur plus de 90% des drivers sur l'implémentation soft par manque de codeurs qualifiés sur XFree.
La disparité des interfaces et sous systèmes a prendre en compte participe à la difficulté d'écriture des drivers XFree. Prenez par exemple le problème de switch vers une VC Linux: pas de support noyau, pas de moyen de com entre les deux, pas d'interaction possible entre les deux d'où une aproche empirique de XFree pour sauvegarder et restaurer les bons registres avant et après le switch.
Avantage: system independant.
Inconvénient: un truc bouge dans la gestion console du noyaux; ca casse. Un truc bouge dans le code accéléré de XFree sans prendre garde à cet obscur cas particulier; ca explose. Le drivers n'en est pas pour autant de mauvaise qualité.
Les cartes graphiques actuelles deviennent des monstres de complexités. A coté, la complexité de nos UC et CPU fait presque palle figure. La tandance vers laquelle je crois il faudrais se tourner c'est de considerer nos cartes comme de vrai machines leur drivers devenant aujoud'hui de propres OS.
Alors, un support OS host devient une évidence (merge fb/drm/...) et une base commune de code peut émerger, simplifiant l'écriture de driver.
Un driver carte ethernet Linux est facile a écrire aujourd'hui, même avec une plétore d'accélérations (zerocopy/checksum, bientot crypto ...) même un portage du système complet sur un nouveau CPU/Architecture se fait de plus en plus facilement. Pourquoi ?
- Base système commune (c'est le plus important)
- 10 ans d'expérience et de maturation pour construire cette infrastructure système (Kernel arch independent).
- Beaucoup de développeurs et un bon arbitre.
L'architecture de XFree a fait un bout du chemin (le DDX pour la 2D) mais necessite aujourd'hui une infrastrucure noyaux qui se cherche pour tirer parti de nos rolls du pixel.
Pour répondre à la problématique "partie réseau qui me sert peu et ralentit tout":
C'est faux: X11 utilise en local les socket Unix et pas TCP/IP. De plus une étude a été mené par Keith Packard il y a quelques années déjà pour savoir si un mode mémoire partagé pour la transmission des messages entre le client et le serveur ne serait pas plus avantageux. Le résulat est éloquent: le mode message est bien plus léger et plus rapide, la gestion des ordres X11 en mode block au travers d'un segment de mémoire partagé faisant écrouler les perfs.
Par contre, pour la manipulation des Bitmaps, l'extention XShm est bien entendu indispenssable.
Néanmois, pour parler de celle ci, même en l'utilisant, de part la très faible interaction entre le noyaux et le serveur, plusieurs copies mémoire sont réalisés avant que vous obteniez votre image à l'écran. Ici pas de zérocopy! (dito pour XVideo). Quand on sait ce que coute une copie mémoire sur du graphique ....
Comment définitivement régler le pblm et obtenir les perfs des interfaces graphiques client side (directfb/gtkfb) tout en gardant l'ensemble des fonctionnalités X11 ? (séparation conceptuelle client / serveur d'ailleur respectée même avec le DRI pour OpenGL/GLX) ?
- remonter la gestion de la mémoire graphique/texture/video... au niveau d'un nouveau gestionnaire kernel (la VM graphique en quelque sorte).
- réviser la XShm pour éliminer les incohérences rendant difficile l'implémentation d'un fonctionnement ZeroCopy. (histoire de travailler non plus avec des segment de mémoire partagé IPC Unix, mais avec un segment partagé entre la VM graphique, le serveur X et le client X si celui ci est local. Du coup, l'extention deviendrait presque transparente vu du programmeur).
On obtiendrais alors les avantages du client side sans avoir plus tard a inventer des truc a la metaframe and co pour palier au pblm.
Boouuuhhh, faut que je me calme, j'ai pas l'habitude d'écrire de tels romans!! ;-)
[^] # Re: XFree86 est-il assez rapide ?
Posté par efuste . En réponse à la dépêche XFree86 est-il assez rapide ?. Évalué à 1.
La prochaine version di DRI devrai te combler, quelques développeurs (2-3) se sont mis au travail en passant par la difficile phase d'apprentissage de l'architecture et des sources de XFree/DRI et ca a fini par porter ses fruits.
C'est le cas pour XRender, cela a d'ailleur des effets pervers: beaucoup de cartes n'ont pas nécéssairement le support adéquat révé pour l'implémenter, d'où la difficulté, d'où le fait que l'on reste sur plus de 90% des drivers sur l'implémentation soft par manque de codeurs qualifiés sur XFree.
La disparité des interfaces et sous systèmes a prendre en compte participe à la difficulté d'écriture des drivers XFree. Prenez par exemple le problème de switch vers une VC Linux: pas de support noyau, pas de moyen de com entre les deux, pas d'interaction possible entre les deux d'où une aproche empirique de XFree pour sauvegarder et restaurer les bons registres avant et après le switch.
Avantage: system independant.
Inconvénient: un truc bouge dans la gestion console du noyaux; ca casse. Un truc bouge dans le code accéléré de XFree sans prendre garde à cet obscur cas particulier; ca explose. Le drivers n'en est pas pour autant de mauvaise qualité.
Les cartes graphiques actuelles deviennent des monstres de complexités. A coté, la complexité de nos UC et CPU fait presque palle figure. La tandance vers laquelle je crois il faudrais se tourner c'est de considerer nos cartes comme de vrai machines leur drivers devenant aujoud'hui de propres OS.
Alors, un support OS host devient une évidence (merge fb/drm/...) et une base commune de code peut émerger, simplifiant l'écriture de driver.
Un driver carte ethernet Linux est facile a écrire aujourd'hui, même avec une plétore d'accélérations (zerocopy/checksum, bientot crypto ...) même un portage du système complet sur un nouveau CPU/Architecture se fait de plus en plus facilement. Pourquoi ?
- Base système commune (c'est le plus important)
- 10 ans d'expérience et de maturation pour construire cette infrastructure système (Kernel arch independent).
- Beaucoup de développeurs et un bon arbitre.
L'architecture de XFree a fait un bout du chemin (le DDX pour la 2D) mais necessite aujourd'hui une infrastrucure noyaux qui se cherche pour tirer parti de nos rolls du pixel.
Pour répondre à la problématique "partie réseau qui me sert peu et ralentit tout":
C'est faux: X11 utilise en local les socket Unix et pas TCP/IP. De plus une étude a été mené par Keith Packard il y a quelques années déjà pour savoir si un mode mémoire partagé pour la transmission des messages entre le client et le serveur ne serait pas plus avantageux. Le résulat est éloquent: le mode message est bien plus léger et plus rapide, la gestion des ordres X11 en mode block au travers d'un segment de mémoire partagé faisant écrouler les perfs.
Par contre, pour la manipulation des Bitmaps, l'extention XShm est bien entendu indispenssable.
Néanmois, pour parler de celle ci, même en l'utilisant, de part la très faible interaction entre le noyaux et le serveur, plusieurs copies mémoire sont réalisés avant que vous obteniez votre image à l'écran. Ici pas de zérocopy! (dito pour XVideo). Quand on sait ce que coute une copie mémoire sur du graphique ....
Comment définitivement régler le pblm et obtenir les perfs des interfaces graphiques client side (directfb/gtkfb) tout en gardant l'ensemble des fonctionnalités X11 ? (séparation conceptuelle client / serveur d'ailleur respectée même avec le DRI pour OpenGL/GLX) ?
- remonter la gestion de la mémoire graphique/texture/video... au niveau d'un nouveau gestionnaire kernel (la VM graphique en quelque sorte).
- réviser la XShm pour éliminer les incohérences rendant difficile l'implémentation d'un fonctionnement ZeroCopy. (histoire de travailler non plus avec des segment de mémoire partagé IPC Unix, mais avec un segment partagé entre la VM graphique, le serveur X et le client X si celui ci est local. Du coup, l'extention deviendrait presque transparente vu du programmeur).
On obtiendrais alors les avantages du client side sans avoir plus tard a inventer des truc a la metaframe and co pour palier au pblm.
Boouuuhhh, faut que je me calme, j'ai pas l'habitude d'écrire de tels romans!! ;-)