Oups, c''est vrai que tout mon raisonnement se basait sur le client X générique et non sur un client plus spécifique comme Xgl =)
Conceptuellement parlant OpenGL/GLX est dans X11. Cela signifie qu'il faut déjà un serveur X11 qui tournent pour pouvoir utiliser OpenGL/GLX (Il te faut un display etc...). Donc Xgl doit avoir un serveur X11 derrière!
il n'y a que GLX qui est dans X, OpenGL est indépendant de tous "système de fenêtrage" (après, qu'ATI ou Nvidia fasse des gros hacks qui lient OpenGL à X, c'est leur problèmes, on verra leur rapidité à s'adapter à EGL).
Ceci étant, en parcourant les specs d'EGL, j'ai eu l'impression de lire les specs de GLX, surtout dans la manière de découper une contexte en un état client et un état serveur (ce que fait GLX pour permettre d'encapsuler OpenGL dans le protocole X). Au final, EGL m'apparait comme une API unifiant GLX/WGL/AGL et pouvant reposer sur un système de fenêtrage. Avoir un EGL marchant sur X ou sur le framebuffer de Linux ne changera rien pour le toolkit utilisé (graphiquement parlant).
Le contexte de l'unité 3D (en supposant qu'il n'y a pas une contexte unique pour toute la GPU) n'est pas énorme au point d'atteindre plusieurs Mo : Il y a les piles de matrices de transformations (la plus grande pile doit faire 32 éléments), les états comme le mode de remplissage des polygones (quelques champs de bits) , les sources de lumières (8 grand max), etc. Les textures, shaders et autre VBO sont déjà en VRAM. De plus, des infos sont stockées côté pilotes, pas côté GPU. Comparé à une map de TuxRacer, un contexte doit être insignifiant.
Il faut aussi garder en tête qu'OpenGL est un flux de données et c'est le pilotes qui se charge de le gèrer (pour t'en convaincre regarde l'utilité de glFinish). Si glXMakeCurrent (et son équivalent eglMakeCurrent) doit attendre la fin du traitement d'une autre application 3D, il attendra avant de prendre la main. Le fait que Xgl soit fonctionnel sur un Celeron et un proc graphique i810 montre qu'il n'y a pas trop de soucis à se faire de ce côté là (je garde une réserve car on n'a pas vu de vidéos de Xgl/Compiz avec des oo.org et autres grosses applications, ça se trouve, c'est catastrophique):
Avant on trouvait que le WM/DM se trainait le bit avec un petit proc, il faudra être conscient que la GPU peut en faire de même ...
[^] # Re: Joli mais dangereux...
Posté par Rémi Hérilier . En réponse au journal Xgl, la suite. Évalué à 2.
Conceptuellement parlant OpenGL/GLX est dans X11. Cela signifie qu'il faut déjà un serveur X11 qui tournent pour pouvoir utiliser OpenGL/GLX (Il te faut un display etc...). Donc Xgl doit avoir un serveur X11 derrière!
il n'y a que GLX qui est dans X, OpenGL est indépendant de tous "système de fenêtrage" (après, qu'ATI ou Nvidia fasse des gros hacks qui lient OpenGL à X, c'est leur problèmes, on verra leur rapidité à s'adapter à EGL).
Ceci étant, en parcourant les specs d'EGL, j'ai eu l'impression de lire les specs de GLX, surtout dans la manière de découper une contexte en un état client et un état serveur (ce que fait GLX pour permettre d'encapsuler OpenGL dans le protocole X). Au final, EGL m'apparait comme une API unifiant GLX/WGL/AGL et pouvant reposer sur un système de fenêtrage. Avoir un EGL marchant sur X ou sur le framebuffer de Linux ne changera rien pour le toolkit utilisé (graphiquement parlant).
Le contexte de l'unité 3D (en supposant qu'il n'y a pas une contexte unique pour toute la GPU) n'est pas énorme au point d'atteindre plusieurs Mo : Il y a les piles de matrices de transformations (la plus grande pile doit faire 32 éléments), les états comme le mode de remplissage des polygones (quelques champs de bits) , les sources de lumières (8 grand max), etc. Les textures, shaders et autre VBO sont déjà en VRAM. De plus, des infos sont stockées côté pilotes, pas côté GPU. Comparé à une map de TuxRacer, un contexte doit être insignifiant.
Il faut aussi garder en tête qu'OpenGL est un flux de données et c'est le pilotes qui se charge de le gèrer (pour t'en convaincre regarde l'utilité de glFinish). Si glXMakeCurrent (et son équivalent eglMakeCurrent) doit attendre la fin du traitement d'une autre application 3D, il attendra avant de prendre la main. Le fait que Xgl soit fonctionnel sur un Celeron et un proc graphique i810 montre qu'il n'y a pas trop de soucis à se faire de ce côté là (je garde une réserve car on n'a pas vu de vidéos de Xgl/Compiz avec des oo.org et autres grosses applications, ça se trouve, c'est catastrophique):
Avant on trouvait que le WM/DM se trainait le bit avec un petit proc, il faudra être conscient que la GPU peut en faire de même ...
Rem