C'est vrai que maintenant, quasiment n'importe quel GPU a une puissance à peine exploitée par les applications graphiques. L'idée est de "passer le cap" en n'hésitant plus à écrire des applications graphiques qui en tirent partie. La seule API permettant de vraiment le faire est OpenGL... mais il faut savoir à quelle sauce le manger: GLX,EGL,AGL...
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!
C'est OpenGL ES/EGL qui devrait nous permettre de se débarraser de ce serveur X11 "en tâche de fond"... et là on parle de Xegl. Cela veut dire que OpenGL ES/EGL n'a pas besoin de X11. C'est indépendant. La séparation entre la couche X11 et la couche OpenGL est nette et précise, et ça c'est bon.
De ce que j'ai compris, les modifications de David Reveman sur Mesa apportent un début de support EGL pour les drivers du radeon. Mais bon, il faut avouer que je n'ai pas encore lu les specifications OpenGL ES/EGL pour voir de quoi il en retourne vraiment.
Je n'ai jamais mis en doute les performances des GPUs modernes. Ce que je mets en doute c'est leur capacité à gérer en même temps toutes les façons d'accéder à cette puissance.
Admettons que tu as un serveur Xegl qui tourne. Sur ce serveur X11 tu as des applications X11 qui utilise aussi de la 3D, via OpenGL/GLX. Donc tu as le window manager qui bosse avec OpenGL EGL et des applications qui utilisent les xlibs implémentés en OpenGL/EGL(xegl!) mais qui utilisent spécifiquement de OpenGL/GLX pour accélérer des effets "à la 3D" que ne peuvent lui fournir les xlibs ou encore des couples cairo/glitz/OpenGL GLX ou EGL. Le GPU doit gérer l'ensemble de ces contextes (EGL/GLX) non indépendants de manière cohérente et performante: la difficulté est là.
Bon... si on veut conserver la transparence réseau: le serveur X11 pourra être implémenter sur OpenGL EGL, mais toutes les applications (y compris le window manager) devront rester en OpenGL GLX.
[^] # Re: Joli mais dangereux...
Posté par sylware . En réponse au journal Xgl, la suite. Évalué à 3.
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!
C'est OpenGL ES/EGL qui devrait nous permettre de se débarraser de ce serveur X11 "en tâche de fond"... et là on parle de Xegl. Cela veut dire que OpenGL ES/EGL n'a pas besoin de X11. C'est indépendant. La séparation entre la couche X11 et la couche OpenGL est nette et précise, et ça c'est bon.
De ce que j'ai compris, les modifications de David Reveman sur Mesa apportent un début de support EGL pour les drivers du radeon. Mais bon, il faut avouer que je n'ai pas encore lu les specifications OpenGL ES/EGL pour voir de quoi il en retourne vraiment.
Je n'ai jamais mis en doute les performances des GPUs modernes. Ce que je mets en doute c'est leur capacité à gérer en même temps toutes les façons d'accéder à cette puissance.
Admettons que tu as un serveur Xegl qui tourne. Sur ce serveur X11 tu as des applications X11 qui utilise aussi de la 3D, via OpenGL/GLX. Donc tu as le window manager qui bosse avec OpenGL EGL et des applications qui utilisent les xlibs implémentés en OpenGL/EGL(xegl!) mais qui utilisent spécifiquement de OpenGL/GLX pour accélérer des effets "à la 3D" que ne peuvent lui fournir les xlibs ou encore des couples cairo/glitz/OpenGL GLX ou EGL. Le GPU doit gérer l'ensemble de ces contextes (EGL/GLX) non indépendants de manière cohérente et performante: la difficulté est là.
Bon... si on veut conserver la transparence réseau: le serveur X11 pourra être implémenter sur OpenGL EGL, mais toutes les applications (y compris le window manager) devront rester en OpenGL GLX.