Il ne faut pas oublier qu'un processeur graphique est décomposé en (en gros) 3 sous systèmes :
- une unité 2D (exploitée pour le dessin des interfaces anté MacOSX, Xgl, Vista)
- une unité 3D (exploitée par OpenGL ou Direct3D)
- une unité de traitement vidéo (overlay, (dé)compression, etc.)
Si les 2 dernières sont améliorées au fil du temps, la première en revanche ne l'est plus du tout. Il suffit de voir le battage que font Nvidia & consort sur les nouvelles GPU qu'ils sortent tous les 6 mois/1 an, ça ne parle que de vidéo et de 3D. On aura donc beau dire mais les GPU "modernes" savent afficher plus rapidement une simple ligne avec l'unité 3D qu'avec la 2D (et il en est de même pour toutes les primitives 2D).
L'extension que tu décris pour normaliser les "accès bas niveau" existe déjà, c'est le couple OpenGL/GLX. Je ne pense pas d'ailleurs qu'une extension soit le plus efficace (c'est une extension, donc un comportement rajouté). Permettre le choix entre un rendu 2D et un rendu 3D (au sens utilisation de l'unité 2D ou 3D) serait, selon moi, plus pertinent (et j'y vois aussi une facilité lors de la configuration de X:)
Pour pour le backend 2D, on aurait par exemple :
toolkit <-> API de X <-> backend X 2D <-> pilote <-> matériel
et pour le backend 3D :
toolkit <-> API de X <-> backend X 3D <-> OpenGL/GLX <-> pilote <-> matériel
On peut d'ailleurs faire le rapprochement avec le
toolkit <-> API vectoriel <-> backend 3D <-> OpenGL/GLX <-> pilote <-> matériel
qu'ont Gtk+2.8 et Qt4.
Après, j'suis pas dev chez Xorg/Novell/autre, alors mon avis me pèse pas lourd =)
Il est d'ailleurs intéressant de voir que Xgl utilise glitz, on retombe sur le
toolkit <-> API de X <-> "backend 3D" <-> OpenGL/GLX <-> pilote <-> matériel
Peut-être qu'à terme, on verra glitz intégré à X =)
On parle des effets de compositions que permettent la transparence et les textures mais d'autres mécanismes tels que les VBO (Vertex Buffer Object) peuvent apporter d'autres avantages comme réduire l'empreinte d'un programme en mémoire centrale en stockant des informations dans la mémoire graphique. Cela permet ainsi de minimiser l'envoi d'information sur le bus graphique.
Après, on peut se permettre de rêver. Pour la simple page de rédaction que j'utilise actuellement, les éléments statiques tel le bouton "Vérifier" n'auraient plus besoin d'être redessiné entièrement mais juste à donner un ordre comme "desssine le widget XXyyZZ_0324 à telle position". Comparé à "dessine le rectangle plein P1 P2 P3 P4 - dessine le rectangle vide P1 P2 P3 P3 - écrit 'Vérifier' avec tels paramètres", le gain serait énorme.
Pour revenir sur la surcharge de la GPU à cause de l'abus d'effets (que tu évoques dans un post précédent), le problème est autre. Si tu veux jouer à Doom3, tu as une grosse machine, si c'est pour faire du bureautique/web/mp3^Wvorbis, une configuration plus modeste est plus que suffisante. Après, si ça laggue car il y a trop d'effets, c'est le problème de l'utilisateur pas celui des développeurs (enfin si, l'optimisation est de leur ressort mais c'est encore un autre problème;)
D'ailleurs, à ce que j'en ai compris, Xgl n'utilise que :
- des textures pour stocker le contenu des fenêtres (widgets ?)
- des polygones pour faire un support aux textures
- du rendu dans une texture pour manipuler 2D, 3D et vidéo dans un tout cohérent
- la transparence pour aider à l'appréhension du bureau
- des effets de couleur comme la désaturation
- un peu de physique empirique pour les effets sur les fenêtres
Somme toute des trucs implémentés dans les GPU depuis belle lurette (je ne sais plus quelle démo a été faite sur un celeron avec un proc graphique genre i810).
Toutefois, une utilisation des shaders pour améliorer le filtrage d'image (comme les summed area) serait une utilisation saine comparé à afficher tout le texte visible à l'écran avec un effet de bumpmapping /o\
Je ne pense pas que l'utilisation directe d'OpenGL dans une application pour faire des effets soit maline. D'ailleurs, les travaux actuels portent plus sur la vectorisation (et donc aussi la simplification) de l'affichage (Cf Cairo et Arthur pour ne pas les citer). Le but est de ressortir des cartons un concept assez vieux : avoir la même API d'affichage quelque soit le support (écran, imprimante, pdf, image ou que sais-je encore). Un fois ces mécanismes stables et éprouvés, ils pourront se pencher sur la suite (utilisation de shader et de toutes autres joyeusetés futures). Mais pour l'instant, Qt4 n'est pas encore majoritairement utilisé et les backends de Cairo sont en cours de finalisation. Donc attendons de voir avant de prendre peur ;)
[^] # Re: Joli mais dangereux...
Posté par Rémi Hérilier . En réponse au journal Xgl, la suite. Évalué à 3.
- une unité 2D (exploitée pour le dessin des interfaces anté MacOSX, Xgl, Vista)
- une unité 3D (exploitée par OpenGL ou Direct3D)
- une unité de traitement vidéo (overlay, (dé)compression, etc.)
Si les 2 dernières sont améliorées au fil du temps, la première en revanche ne l'est plus du tout. Il suffit de voir le battage que font Nvidia & consort sur les nouvelles GPU qu'ils sortent tous les 6 mois/1 an, ça ne parle que de vidéo et de 3D. On aura donc beau dire mais les GPU "modernes" savent afficher plus rapidement une simple ligne avec l'unité 3D qu'avec la 2D (et il en est de même pour toutes les primitives 2D).
L'extension que tu décris pour normaliser les "accès bas niveau" existe déjà, c'est le couple OpenGL/GLX. Je ne pense pas d'ailleurs qu'une extension soit le plus efficace (c'est une extension, donc un comportement rajouté). Permettre le choix entre un rendu 2D et un rendu 3D (au sens utilisation de l'unité 2D ou 3D) serait, selon moi, plus pertinent (et j'y vois aussi une facilité lors de la configuration de X:)
Pour pour le backend 2D, on aurait par exemple :
toolkit <-> API de X <-> backend X 2D <-> pilote <-> matériel
et pour le backend 3D :
toolkit <-> API de X <-> backend X 3D <-> OpenGL/GLX <-> pilote <-> matériel
On peut d'ailleurs faire le rapprochement avec le
toolkit <-> API vectoriel <-> backend 3D <-> OpenGL/GLX <-> pilote <-> matériel
qu'ont Gtk+2.8 et Qt4.
Après, j'suis pas dev chez Xorg/Novell/autre, alors mon avis me pèse pas lourd =)
Il est d'ailleurs intéressant de voir que Xgl utilise glitz, on retombe sur le
toolkit <-> API de X <-> "backend 3D" <-> OpenGL/GLX <-> pilote <-> matériel
Peut-être qu'à terme, on verra glitz intégré à X =)
On parle des effets de compositions que permettent la transparence et les textures mais d'autres mécanismes tels que les VBO (Vertex Buffer Object) peuvent apporter d'autres avantages comme réduire l'empreinte d'un programme en mémoire centrale en stockant des informations dans la mémoire graphique. Cela permet ainsi de minimiser l'envoi d'information sur le bus graphique.
Après, on peut se permettre de rêver. Pour la simple page de rédaction que j'utilise actuellement, les éléments statiques tel le bouton "Vérifier" n'auraient plus besoin d'être redessiné entièrement mais juste à donner un ordre comme "desssine le widget XXyyZZ_0324 à telle position". Comparé à "dessine le rectangle plein P1 P2 P3 P4 - dessine le rectangle vide P1 P2 P3 P3 - écrit 'Vérifier' avec tels paramètres", le gain serait énorme.
Pour revenir sur la surcharge de la GPU à cause de l'abus d'effets (que tu évoques dans un post précédent), le problème est autre. Si tu veux jouer à Doom3, tu as une grosse machine, si c'est pour faire du bureautique/web/mp3^Wvorbis, une configuration plus modeste est plus que suffisante. Après, si ça laggue car il y a trop d'effets, c'est le problème de l'utilisateur pas celui des développeurs (enfin si, l'optimisation est de leur ressort mais c'est encore un autre problème;)
D'ailleurs, à ce que j'en ai compris, Xgl n'utilise que :
- des textures pour stocker le contenu des fenêtres (widgets ?)
- des polygones pour faire un support aux textures
- du rendu dans une texture pour manipuler 2D, 3D et vidéo dans un tout cohérent
- la transparence pour aider à l'appréhension du bureau
- des effets de couleur comme la désaturation
- un peu de physique empirique pour les effets sur les fenêtres
Somme toute des trucs implémentés dans les GPU depuis belle lurette (je ne sais plus quelle démo a été faite sur un celeron avec un proc graphique genre i810).
Toutefois, une utilisation des shaders pour améliorer le filtrage d'image (comme les summed area) serait une utilisation saine comparé à afficher tout le texte visible à l'écran avec un effet de bumpmapping /o\
Je ne pense pas que l'utilisation directe d'OpenGL dans une application pour faire des effets soit maline. D'ailleurs, les travaux actuels portent plus sur la vectorisation (et donc aussi la simplification) de l'affichage (Cf Cairo et Arthur pour ne pas les citer). Le but est de ressortir des cartons un concept assez vieux : avoir la même API d'affichage quelque soit le support (écran, imprimante, pdf, image ou que sais-je encore). Un fois ces mécanismes stables et éprouvés, ils pourront se pencher sur la suite (utilisation de shader et de toutes autres joyeusetés futures). Mais pour l'instant, Qt4 n'est pas encore majoritairement utilisé et les backends de Cairo sont en cours de finalisation. Donc attendons de voir avant de prendre peur ;)
les 2¢ d'un réinventeur de roue chevronné /o\