Je vais essayer de me préter à cet exercise. Tout d'abord une observation générale, qui a sont importance, les progrés des cartes graphiques ont principalement été poussé par l'industrie du jeux vidéo (je ne pense pas soulever polémique ici :)). C'est donc une parties "limités" des fonctionalités des cartes qui a été privilégié, à savoir la 3D (là encore je pense rallier la majorité :)).
Au début les cartes 3D avaient peux de mémoire (2, 4, 8, ...Mo) aussi la premiére version du DRM (direct rendering manager) ainsi que de DRI (Direct rendering infrastructure) ne ceux sont pas soucier de gérer dynamiquement cet mémoire et on a préférer une solution simple de découpage de celle-ci en différentes zones à la discrétion du driver. Pour les jeux avec peux de texture ou avec des texture pas très grosse, cela ne pose aucun (ou peu) de problème et cela ne pénalise pas les performances (aux contraire un gestionnaire dynamique de mémoire peut se révéle couteux en performance). Donc premier point absence de gestionnaire de mémoire.
DRI est une extension qui permet a un programme opengl de "parler" directement avec le driver de la carte via mesa(opengl) sans passer par le serveur X ce qui évite d'être dans les "bouchons" du protocole X. DRI posséde des limitations issues de son design original à savoir l'accélération d'un programme opengl en plein écran (il s'agit ici d'une hypothese de ma part baser sur le protocole et son implémentation tant celui-ci semble bien adapter à cet situation et mal à d'autres, il faudrait demander aux auteurs originaux qu'elles étaient leur intention à l'époque).
En ce sens le DRI ne concoit que le rendu 3D s'opére forcement dans le scan out buffer (le buffer qui est afficher à l'écran). C'est pourquoi sous compiz avec une application 3D utilisant DRI vous ne voyez pas l'application se déplacer avec le cube, celle-ci envoit ses commandes à mesa qui dessine directement dans le scan out buffer. Cela explique aussi pourquoi le support de certaines extension comme les pbuffer ou les framebuffer object d'opengl n'ont vu le jour que récemment, tant leur implémentation été problématique dans ce cadre.
Enfin l'ensemble de cet infrastructure se retrouve éparpillé. Nous avons le DRM dans le noyau, nous avons le driver 2D (DDX) du serveur X qui est en charge d'initialiser la carte et le DRM ainsi que d'activer le DRI dans le serveur X et enfin le driver 3D à proprement parler dans mesa. Un grave problème se pose alors, si vous voulez changer radicalement l'interface (comme ce qui se passe aujourd'hui) vous devez assurer une compatibilité arriére ou alors vous préparer à de sérieux problèmes.
Effectivement souvent les distributions ou les utilisateurs ne mette à jour qu'une partie du systéme: quand vous recompilez un nouveau noyau vous ne recompiler pas un nouveau serveur X, ni un nouveau DDX ni un nouveau mesa. Or la régle c'est qu'un nouveau noyau doit marcher avec un vieux server X et un vieux DDX et un vieux mesa. Donc tout changer, ou faire des modifications radicales n'est pas chose aisée.
Pour résumer les grands problèmes sont: absence de gestionnaire de mémoire, protocole DRI peut adapter à l'usage de l'accélération 3D qu'on aimerait avoir (accélération de l'interface en utilisant la 3D et donc plusieurs clients 3D ne dessinant pas forcement directement à l'écran mais ailleur en mémoire), fragmentation du code gérant la carte graphique (outre le problème de compatibilité descendante on peut aussi évoquer suspend/resume qui est souvent aléatoire). Keith Packard dresse une liste plus compléte des problèmes qui doivent être résolue dans son talk du LCA ou du FOSDEM de cet année.
Les solutions c'est simple avoir un gestionaire de mémoire c'est chose faite grâce a Tungsten graphic. Réunir le code d'initialisation de la carte dans le noyau (comme pour les autres drivers). Un nouveau protocole pour la communication entre le server X, les applications et le driver 3D de la carte graphique: DRI2.
Le gestionaire mémoire permettra de tirer partie de la mémoire des cartes graphique. En exagérant on peut dire aujourd'hui qu'a chaque frame rendu on recharge toute les textures dans la carte graphique et qu'on les estimes perdu pour la prochaine frame (donc qu'on renvoit tout). Aujourd'hui les textures des jeux videos c'est des centaines de Mo et renvoyer 100Mo à la carte pour chaque frame c'est couteux même avec les gros busses qu'on a :). Avec le gestionaire de mémoire les textures, vertex, ... sont soit dans la ram principale soit dans la ram de la carte graphique et on ne déplace les données que quand le besoin se présente.
Avoir le modesetting et l'initialisation de la carte dans le noyau permettra d'avoir un seul acteur en charge de la carte, cela s'implifira le suspend/resume, cela permettra aussi de ne pas avoir à changer plusieurs de mode video pendant le boot (flicker problem), un démarrage bcp plus rapide du serveur X car celui-ci n'aura plus à faire plein de chose que le noyau faisait déjà lors du boot...
DRI2 pour l'utilisateur principalement c'est avoir glxgears qui s'intégre enfin à compiz ;). Mais cela apportera aussi d'autre avancées comme permettre de supporter plus simplement et efficacement les buffer object d'opengl et autre pbuffer.
Pamplemouse sur la pelle à tarte Tungsten graphique termine le développement d'un nouvelle infrastructure de driver qui rend non seulement l'écriture de ceux-ci plus simple mais également devrait permettre de bien mieux exploiter les cartes graphiques récentes.
Malheureusement tout ceux-ci est en chantier et le temps semble long, je n'ai pas encore vu de bench pour comparer les performances mais je doute que tant que tout ne se stabilise pas cela soit bien significatif.
Pour le nombre d'actif si il n'y a que peut de personnes à travailler sur tout ca c'est simplement une question de moyen. Comme je le disais seul Intel, Redhat, Tungsten Graphics, Suse, AMD paient des gens (certaines plus que d'autre) or face à l'empleur de la tache c'est bien peu. Je dois dire que je suis particuliérement choqué que des gens de canonical se pleignent sur la mailing list que les choses n'avance pas vite, s'ils veulent les faire avancer vite ils n'ont qu'a payer des gens pour travailler dessus.
(Vous m'excuserez pour l'orthographe mais l'heure et la taille du message on raisont de tout motivation pour le corrigé...).
[^] # Re: DRI/Mesa etc.
Posté par Markov . En réponse au journal Pour un driver NVIDIA libre .... Évalué à 10.
Au début les cartes 3D avaient peux de mémoire (2, 4, 8, ...Mo) aussi la premiére version du DRM (direct rendering manager) ainsi que de DRI (Direct rendering infrastructure) ne ceux sont pas soucier de gérer dynamiquement cet mémoire et on a préférer une solution simple de découpage de celle-ci en différentes zones à la discrétion du driver. Pour les jeux avec peux de texture ou avec des texture pas très grosse, cela ne pose aucun (ou peu) de problème et cela ne pénalise pas les performances (aux contraire un gestionnaire dynamique de mémoire peut se révéle couteux en performance). Donc premier point absence de gestionnaire de mémoire.
DRI est une extension qui permet a un programme opengl de "parler" directement avec le driver de la carte via mesa(opengl) sans passer par le serveur X ce qui évite d'être dans les "bouchons" du protocole X. DRI posséde des limitations issues de son design original à savoir l'accélération d'un programme opengl en plein écran (il s'agit ici d'une hypothese de ma part baser sur le protocole et son implémentation tant celui-ci semble bien adapter à cet situation et mal à d'autres, il faudrait demander aux auteurs originaux qu'elles étaient leur intention à l'époque).
En ce sens le DRI ne concoit que le rendu 3D s'opére forcement dans le scan out buffer (le buffer qui est afficher à l'écran). C'est pourquoi sous compiz avec une application 3D utilisant DRI vous ne voyez pas l'application se déplacer avec le cube, celle-ci envoit ses commandes à mesa qui dessine directement dans le scan out buffer. Cela explique aussi pourquoi le support de certaines extension comme les pbuffer ou les framebuffer object d'opengl n'ont vu le jour que récemment, tant leur implémentation été problématique dans ce cadre.
Enfin l'ensemble de cet infrastructure se retrouve éparpillé. Nous avons le DRM dans le noyau, nous avons le driver 2D (DDX) du serveur X qui est en charge d'initialiser la carte et le DRM ainsi que d'activer le DRI dans le serveur X et enfin le driver 3D à proprement parler dans mesa. Un grave problème se pose alors, si vous voulez changer radicalement l'interface (comme ce qui se passe aujourd'hui) vous devez assurer une compatibilité arriére ou alors vous préparer à de sérieux problèmes.
Effectivement souvent les distributions ou les utilisateurs ne mette à jour qu'une partie du systéme: quand vous recompilez un nouveau noyau vous ne recompiler pas un nouveau serveur X, ni un nouveau DDX ni un nouveau mesa. Or la régle c'est qu'un nouveau noyau doit marcher avec un vieux server X et un vieux DDX et un vieux mesa. Donc tout changer, ou faire des modifications radicales n'est pas chose aisée.
Pour résumer les grands problèmes sont: absence de gestionnaire de mémoire, protocole DRI peut adapter à l'usage de l'accélération 3D qu'on aimerait avoir (accélération de l'interface en utilisant la 3D et donc plusieurs clients 3D ne dessinant pas forcement directement à l'écran mais ailleur en mémoire), fragmentation du code gérant la carte graphique (outre le problème de compatibilité descendante on peut aussi évoquer suspend/resume qui est souvent aléatoire). Keith Packard dresse une liste plus compléte des problèmes qui doivent être résolue dans son talk du LCA ou du FOSDEM de cet année.
Les solutions c'est simple avoir un gestionaire de mémoire c'est chose faite grâce a Tungsten graphic. Réunir le code d'initialisation de la carte dans le noyau (comme pour les autres drivers). Un nouveau protocole pour la communication entre le server X, les applications et le driver 3D de la carte graphique: DRI2.
Le gestionaire mémoire permettra de tirer partie de la mémoire des cartes graphique. En exagérant on peut dire aujourd'hui qu'a chaque frame rendu on recharge toute les textures dans la carte graphique et qu'on les estimes perdu pour la prochaine frame (donc qu'on renvoit tout). Aujourd'hui les textures des jeux videos c'est des centaines de Mo et renvoyer 100Mo à la carte pour chaque frame c'est couteux même avec les gros busses qu'on a :). Avec le gestionaire de mémoire les textures, vertex, ... sont soit dans la ram principale soit dans la ram de la carte graphique et on ne déplace les données que quand le besoin se présente.
Avoir le modesetting et l'initialisation de la carte dans le noyau permettra d'avoir un seul acteur en charge de la carte, cela s'implifira le suspend/resume, cela permettra aussi de ne pas avoir à changer plusieurs de mode video pendant le boot (flicker problem), un démarrage bcp plus rapide du serveur X car celui-ci n'aura plus à faire plein de chose que le noyau faisait déjà lors du boot...
DRI2 pour l'utilisateur principalement c'est avoir glxgears qui s'intégre enfin à compiz ;). Mais cela apportera aussi d'autre avancées comme permettre de supporter plus simplement et efficacement les buffer object d'opengl et autre pbuffer.
Pamplemouse sur la pelle à tarte Tungsten graphique termine le développement d'un nouvelle infrastructure de driver qui rend non seulement l'écriture de ceux-ci plus simple mais également devrait permettre de bien mieux exploiter les cartes graphiques récentes.
Malheureusement tout ceux-ci est en chantier et le temps semble long, je n'ai pas encore vu de bench pour comparer les performances mais je doute que tant que tout ne se stabilise pas cela soit bien significatif.
Pour le nombre d'actif si il n'y a que peut de personnes à travailler sur tout ca c'est simplement une question de moyen. Comme je le disais seul Intel, Redhat, Tungsten Graphics, Suse, AMD paient des gens (certaines plus que d'autre) or face à l'empleur de la tache c'est bien peu. Je dois dire que je suis particuliérement choqué que des gens de canonical se pleignent sur la mailing list que les choses n'avance pas vite, s'ils veulent les faire avancer vite ils n'ont qu'a payer des gens pour travailler dessus.
(Vous m'excuserez pour l'orthographe mais l'heure et la taille du message on raisont de tout motivation pour le corrigé...).