Juste quelques commentaires sur XFree86 et les perfs:
XFree86 fait pas mal de concessions sur les perfs au nom de la sacro sainte portabilitée et passe souvent son temps a réinventer la roue. On peut citer par exemple la gestion complète en userspace de tous les devices d'entrés (en train de changer pour Linux en branche HEAD et kernel 2.5 qui utilise l'events API), la réimplémentation complète de toute la gestion PCI (qui quand y a des bugs et interfere mal avec le noyau crashe la machine), réimplémentation de l'I2C, des drivers tuner et de beaucoup de choses dans la Xvidéo extention étant du ressort de V4L(2) sous Linux (attention, je n'ai pas dit que la XVideoEntention n'était pas nécessaire, cetaines choses sont de sont ressort et pas de celui de V4L).
Du fait de son extrème portabilité et de son mode full userspace, et bien exit les transferts DMA pour les pixmaps, exit la synchro verticale avec les interrupts et j'en passe...
L'arrivée du DRI commence a bouleverser les choses et certains drivers commences a profiter de cette petite incursion kernel (DRM) pour détourner sa raison originelle (la 3D client side) pour par exemple tranferrer les images YUV (Xvideo) en DMA (ATI), dans le CVS du DRI/DRM on commence a voir apparaitre la gestion du vertical retrace sous interruption pour décharger le CPU et la carte GFX (pourquoi calculer 2000 frame secondes quand votre écran en affiche au mieux ~100 sans parler des effets de fliker). D'ici que le serveur X puisse utiliser cette fonctionnalité, y a q'un pas. (driver ATI et MGA).
(enfin pas tout a fait, faudrai que le serveur X ait enfin un client DRI intégré ou que les gens de XFree décident de définir un DRM like pour autre chose que la 3D et le DRI).
Si on essay d'avoir une vision plus globale, un XFree "optimisé" tirerais au mieux parti de l'infrastructure fournie par le kernel:
- utilisation de l'interface FrameBuffer pour acceder à la carte au lieu de réinventer la gestion PCI, SBUS etc...
- utilisation de l'API native pour la gestion des claviers/pointeurs.
- avec un raprochement du DRM et de l'interface FB, l'utilisation systématique des DMA pour les transferts de données supéreurs à une certaine taille.
- utilisation des interruptions pour la gestion de la synchro verticale.
- utilisation systématique de V4L pour le partie input de la XVideoExtention.
- gestion mémoire de la carte plus évoluée et unifié au niveau kernel entre le DRI/DRM, XFree, FB, V4L (très important pour les carte type Matrox Marvel, ou ATI All In Wonder). Les problématiques de gestion de la mémoire de ces cartes, sans être aussi complexe que la VM du noyau, sont de moins en moins triviales. Un premier travail est effectué dans ce sens dans une branche particulière du DRI, visant à ramener a terme la gestion de la mémoire des textures dans le noyau pour la partager entre tous les clients 3D.
Bref, beaucoup de chemin reste a parcourir, mais le train est en marche même si c'est loin d'être un TGV. Rien en tout cas ne necessite une remise en cause globale de ce qui existe en terme d'architecture haut niveau. Ce n'est qu'un pblm d'implémentation.
Par contre messieurs les codeurs de toolkits graphiques et d'application, s'il vous plais, validez votre design, profilez vos aplications et vos librairies, en 6 ans d'évolution, c'est devenu une catastrophe sur ma machine alors que les applis sont juste un peut plus jolie et ne font strictement rien de plus... Bien codé, l'ensemble devrais être aussi sinon plus rapide que l'équivalent de l'époque.
Un dernier mot en ce qui concerne XFree: Un grand merci au personnes de XFree et du DRI et que la force soit avec vous.
Pour les currieux, estimez a combien se monte le nombre total de personnes directement impliqués dans le dev de XFree et du DRI, vous serez étonnés. Comme quoi les choses tiennes à pas grand choses.
Alors si vous voulez que XFree soit plus perfomant, plus fonctionnel etc... engagez vous ! ;-))
# Re: XFree86 est-il assez rapide ?
Posté par efuste . En réponse à la dépêche XFree86 est-il assez rapide ?. Évalué à 1.
XFree86 fait pas mal de concessions sur les perfs au nom de la sacro sainte portabilitée et passe souvent son temps a réinventer la roue. On peut citer par exemple la gestion complète en userspace de tous les devices d'entrés (en train de changer pour Linux en branche HEAD et kernel 2.5 qui utilise l'events API), la réimplémentation complète de toute la gestion PCI (qui quand y a des bugs et interfere mal avec le noyau crashe la machine), réimplémentation de l'I2C, des drivers tuner et de beaucoup de choses dans la Xvidéo extention étant du ressort de V4L(2) sous Linux (attention, je n'ai pas dit que la XVideoEntention n'était pas nécessaire, cetaines choses sont de sont ressort et pas de celui de V4L).
Du fait de son extrème portabilité et de son mode full userspace, et bien exit les transferts DMA pour les pixmaps, exit la synchro verticale avec les interrupts et j'en passe...
L'arrivée du DRI commence a bouleverser les choses et certains drivers commences a profiter de cette petite incursion kernel (DRM) pour détourner sa raison originelle (la 3D client side) pour par exemple tranferrer les images YUV (Xvideo) en DMA (ATI), dans le CVS du DRI/DRM on commence a voir apparaitre la gestion du vertical retrace sous interruption pour décharger le CPU et la carte GFX (pourquoi calculer 2000 frame secondes quand votre écran en affiche au mieux ~100 sans parler des effets de fliker). D'ici que le serveur X puisse utiliser cette fonctionnalité, y a q'un pas. (driver ATI et MGA).
(enfin pas tout a fait, faudrai que le serveur X ait enfin un client DRI intégré ou que les gens de XFree décident de définir un DRM like pour autre chose que la 3D et le DRI).
Si on essay d'avoir une vision plus globale, un XFree "optimisé" tirerais au mieux parti de l'infrastructure fournie par le kernel:
- utilisation de l'interface FrameBuffer pour acceder à la carte au lieu de réinventer la gestion PCI, SBUS etc...
- utilisation de l'API native pour la gestion des claviers/pointeurs.
- avec un raprochement du DRM et de l'interface FB, l'utilisation systématique des DMA pour les transferts de données supéreurs à une certaine taille.
- utilisation des interruptions pour la gestion de la synchro verticale.
- utilisation systématique de V4L pour le partie input de la XVideoExtention.
- gestion mémoire de la carte plus évoluée et unifié au niveau kernel entre le DRI/DRM, XFree, FB, V4L (très important pour les carte type Matrox Marvel, ou ATI All In Wonder). Les problématiques de gestion de la mémoire de ces cartes, sans être aussi complexe que la VM du noyau, sont de moins en moins triviales. Un premier travail est effectué dans ce sens dans une branche particulière du DRI, visant à ramener a terme la gestion de la mémoire des textures dans le noyau pour la partager entre tous les clients 3D.
Bref, beaucoup de chemin reste a parcourir, mais le train est en marche même si c'est loin d'être un TGV. Rien en tout cas ne necessite une remise en cause globale de ce qui existe en terme d'architecture haut niveau. Ce n'est qu'un pblm d'implémentation.
Par contre messieurs les codeurs de toolkits graphiques et d'application, s'il vous plais, validez votre design, profilez vos aplications et vos librairies, en 6 ans d'évolution, c'est devenu une catastrophe sur ma machine alors que les applis sont juste un peut plus jolie et ne font strictement rien de plus... Bien codé, l'ensemble devrais être aussi sinon plus rapide que l'équivalent de l'époque.
Un dernier mot en ce qui concerne XFree: Un grand merci au personnes de XFree et du DRI et que la force soit avec vous.
Pour les currieux, estimez a combien se monte le nombre total de personnes directement impliqués dans le dev de XFree et du DRI, vous serez étonnés. Comme quoi les choses tiennes à pas grand choses.
Alors si vous voulez que XFree soit plus perfomant, plus fonctionnel etc... engagez vous ! ;-))