Mucho se ha hablado sobre Xgl este ultimo tiempo, y pareciera que todos quieren instalarlo en sus escritorios, pero también veo que hay mucha confusión acerca de que se pretende con Xgl, incluso algunos creen que es una suerte de 3ddesktop pero más espectacular. Hace tiempo que quería escribir sobre el tema, y podría haber escrito varios artículos, pero como la próxima semana no voy a tener mucho tiempo, decidí escribirlo todo en uno solo. Sé que esto llegará a Planeta GNOME Hispano en donde hay gente que sabe mucho más del tema, agradezco si me envían correcciones al artículo por mail privado.
X-Server
El sistema gráfico utilizado en Linux es X-Window, este sistema asume que las aplicaciones actúan como un cliente (x-client) de un servidor X-Window (x-server). El x-server se encarga de lograr la interacción entre el usuario y la aplicación, el rol del servidor es desplegar la imagen en pantalla, y recibir los eventos de teclado, mouse y otros dispositivos. Hay distintas implementaciones de x-servers, los hay para Linux, MacOSX y también para Windows.
Mientras mejor sea el x-server, mejor es la representación de la aplicación. Para ir mejorando un servidor x-server se van proponiendo extensiones (x extensions) y con el tiempo estas extensiones se van implementando en los distintos x-server y drivers. Ejemplos de x-server son XFree86 y Xorg.
Aunque normalmente tanto los x-client y el x-server se ejecutan en un mismo computador, la separación entre x-client y x-server también permite que una aplicación que se ejecuta en un computador, pueda utilizarse desde otro computador en forma remota con un x-server corriendo en el computador local al usuario en forma independiente del sistema operativo.
Modelo de composición
El dibujado de las aplicaciones en pantalla se llama composición. En los sistemas tradicionales, cada ventana es un rectángulo en donde se dibuja la aplicación. Cuando una ventana cubre a otra, no es necesario dibujar el contenido de la ventana no visible. Cuando una ventana que cubre a otra se mueve, la nueva superficie visible de la ventana debe ser redibujada por la aplicación. Si ustedes mueven una ventana en el escritorio rápidamente, verán como las aplicaciones intentan redibujar las ventanas. Este es el modelo de composición utilizado tanto en Windows como en Linux
Una de las desventajas es que las aplicaciones constantemente tienen que estar redibujando las ventanas aunque no hayan sufrido cambios. Si la aplicación no responde, lo único que veremos sera un rectángulo vacío, o si la aplicación se demora en redibujar, se verá un retraso en el despliegue. Otra desventaja es que una ventana que quiera utilizar áreas no rectangulares o áreas semitransparentes, tienen «conciencia» limitada de lo que esta dibujado detrás de ellas, por lo tanto cualquier ventana que no sea 100% opaca y rectangular, no se dibujará correctamente. Si han visto como funcionan gDesklets o SuperKaramba, entenderán de lo que estoy hablando.
Composite Managers : xcompmgr, luminocity, looking glass
Un modelo de composición mas evolucionado consiste en dibujar las ventanas completamente fuera de pantalla (off-screen). Cada aplicación dibuja solamente cuando necesita cambiar algo de su ventana, y el contenido completo de cada ventana siempre está disponible, aunque no sea visible. Una aplicación especializada se encarga de transferir la imagen de cada ventana al área visible de video, es decir al escritorio que vemos en pantalla. En esta transferencia puede aplicar cualquier transformación, por ejemplo cambiar el tamaño, rotar, mezclar con el fondo, etc. Esta aplicación especializada es lo que se conoce como Composite Manager. Mientras que un Window Manager debe posicionar y manipular (move/resize) las ventanas en el escritorio, un Composite Manager se encarga de renderizar las ventanas en el escritorio.
Un Composite Manager radical podría por ejemplo dibujar las ventanas como una textura sobre un polígono a través de OpenGL, y pedirle a la tarjeta de video que dibuje el polígono en pantalla, considerando que hoy en dia las tarjetas de video son hábiles en renderizar polígonos en un entorno 3D, se podría delegar gran parte del trabajo a una tarjeta con aceleración 3D. Si por ejemplo se quisiera obtener una vista minituarizada o ampliada de la ventana, bastaría simplemente con cambiar el tamaño del polígono y la tarjeta de video se encargaría de hacer el render, y Uds. saben: «sí, son rápidas». Al mover una ventana sobre otra, son simplemente dos polígonos que se superponen, y se pueden mover «como si nada».
Keith Packard trabajó en una nueva x-extension llamada Composite. Esta extensión permite cambiar el modelo de composición tradicional en donde cada ventana dibuja solo las áreas visibles, y redibuja las que se van «descubriendo», por el descrito en el párrafo anterior en donde las ventanas se dibujan siempre off-screen. El trabajo se inicio en el x-server experimental kdrive, también conocido como el x-server de freedesktop.org, y posteriormente se implementó en el servidor Xorg, que es el que viene con la mayoría de las distribuciones de Linux. Hay un paper sobre los cambios necesarios para cambiar al nuevo modelo de composición.
El primer Composite Manager conocido se llama xcompmgr, y era un Composite Manager de ejemplo que implementaba cosas simples como agregar sombras y transparencias a las ventanas. Para realizar estas sombras y transparencias se utilizaron funciones de la extensión XRender (también de K.P.), un obstáculo es que prácticamente ningún driver de Xorg acelera(ba) correctamente la extensión XRender, a excepción del driver propietario de nvidia. El problema es que la arquitectura de aceleración de Xorg (XAA) no es muy adecuada para tener XRender acelerado por hardware, mientras que la arquitectura de kdrive (KAA) si permite una buena implementación de XRender pero no hay muchos drivers compatibles con kdrive. Por lo tanto, xcompmgr solo era usable si eras propietario de una nvidia, o bien utilizabas kdrive pero sin aceleración por hardware.
Para solucionar este problema, surgió la iniciativa de EXA, que vendría siendo algo así como KAA aplicado a Xorg. La idea era que lentamente los drivers XAA se fueran convirtiendo en EXA, y el usuario puede escoger si usar EXA o el modelo tradicional XAA. Mientras tanto, en RedHat se comenzó a experimentar modificando Metacity, que es el Window Manager de GNOME, para que incluyera funciones de un Composite Manager. Este desarrollo tomo el nombre de Luminocity. Este Composite Manager era mas ambicioso que xcompmgr e incluía funciones de transformación de ventanas, uso inteligente de transparencias para destacar ventanas en transición, y un selector de escritorios en donde se podia ver cada ventana minituarizada en tiempo real.
Si buscamos otra aplicación de Composite conocida, tenemos el famoso proyecto Looking Glass de Sun. Ellos aprovecharon la extensión composite para poder hacer un Window Manager/Composite Manager que pudiera manipular las ventanas en un entorno 3D.
Xgl y Compiz
Otro camino posible para obtener buenos resultados era olvidarse de Xorg y crear un nuevo x-server que facilitara el trabajo considerando el nuevo modelo de composición, y aprovechando las características de las tarjetas de video modernas que han sido diseñadas para utilizar operaciones gráficas 3D aceleradas por hardware. Es ahi donde aparece el x-server Xgl, publicado recientemente por Dave Reveman de Novell. Este x-server realiza sus operaciones de render no utilizando un driver propio, sino que utilizando un driver OpenGL. El x-server Xgl mas común es el Xglx, y lo que hace es conectarse a otro servidor X que tenga soporte de OpenGL a través de la extensión GLX (OpenGL/X). Entonces si levantamos Xorg + Xglx tendremos un x-server con operaciones OpenGL aprovechándose de la infraestructura de otro x-server con drivers OpenGL a través de GLX. Es esta combinación la que hemos tenido oportunidad de ver últimamente en los alucinantes videos.
El Composite Manager creado para aprovechar las características de Xgl se llama Compiz, además de ser un Composite Manager también es un Window Manager. Una de las cosas interesantes de Compiz es que funciona en base a plugins, entonces cada plugin agrega un nuevo efecto especial a Compiz. Los plugins que existen a la fecha permiten hacer fade de las ventanas al aparecer/desaparecer, rotar los escritorios virtuales como un cubo, visualizar las ventanas como Exposé de MacOSX, mover las ventanas como si fueran de papel. etc.
Aiglx y Xair
No todos eran partidarios de construir un nuevo x-server como se hizo con Xgl, porque era harto trabajo. Entonces surgió un proyecto alternativo llamado Aiglx, publicado por RedHat. Aiglx permite utilizar aceleración OpenGL para realizar la composición, pero modificando suavemente Xorg. Aiglx se apoya en un Composite Manager llamado Xair, que al parecer es una evolución de Luminocity.
Soporte de Hardware
Para utilizar el nuevo modelo de composición en nuestros computadores, necesitamos hardware que sea compatible con las distintas combinaciones de x-servers y composite managers. Hoy en día la mejor alternativa es utilizar alguna tarjeta de video que utilice un chip de nvidia. El soporte va a ir mejorando a medida que se implementen las funciones necesarias por cada x-server y composite manager, específicamente el soporte de EXA, y la nueva extensión GLX_EXT_texture_from_pixmap son claves para la expansión de estas nuevas tecnologías.
El cambio en la forma en que se perciben las ventanas, y el hecho de que las aplicaciones ya no tienen que redibujar, hacen que el cambio realmente valga la pena, inclusive si solamente se utiliza xcompmgr en su forma mas básica.
Las esperanzas son altas, por ejemplo tengo una tarjeta de video integrada Intel i855 de 64MB, xcompmgr funciona perfectamente con Xorg, es suficientemente usable como para tenerlo diariamente en mi escritorio. Compiz+Xgl funcionan bien, pero con algunos «glitches», y hay cosas que funcionan lentas debido a la falta de soporte de GLX_EXT_texture_from_pixmap en la versión actual de mi driver.
¿Como estan los otros sistemas?
MacOSX cambió el modelo de composición hace bastante tiempo, a través de Quartz Extreme . Windows cambiará el modelo de composición en Windows Vista, pero requerirán un hardware mucho mas potente para poder aprovechar estas características.
octubre 12th, 2006 at 12:49
He conseguido que funcione Xgl bajo Suse 10.1 de 32 Bits, pero no se porque diablos no me corre bajo un Suse de 64 bits, he seguido los mismos pasos en ambos lados y estoy con la misma version de Suse la 10.1. Alguien tiene idea estoy con Kde 3.5 y ATI. 9200
Aproposito me entere que Mandriva va a traer Xgl como soporte nativo , no seria malo que los muchachos de suse hicieran lo mismo.
octubre 7th, 2006 at 22:47
Estoy corriendo XGL+Beryl sobre Ubuntu 6.06 y funciona todo a la perfección sobre una ATi 9600 PRO 256MB. En la actualidad no creo que Windows Vista ni MacOS puedan superar la calidad y efectos que ofrece XGL.
octubre 6th, 2006 at 14:55
Aiglx con Intel funciona sin problemas utilizando los drivers open source. Asi lo tengo funcionando actualmente con Ubuntu 6.06 + repositorios de xgl.compiz.info
octubre 6th, 2006 at 13:28
Varias distros prometen incluir XGL y/o Aiglx, aunque no esta muy claro como van a hacer con eso de los drivers propietarios… en fin, para los que se mueren de ganas de ver xgl+compiz y saber si sus pcs tienen lo minimo necesario para eso, bájense el live cd de KORORAA, ya no se consigue en la pagina oficial porque segun violaron la GPL al incluir drivers propietarios, busquenlo por torrents
Tambien pueden probar el liveCD de DreamLinux 2.0 XGL edition, aunque este supuestamente se porta bien unicamente con las placas nvidia.
En SuSE, ubuntu y gentoo, se instala sin mucho inconvenientes, la red está plagada de howtos
Saludos
octubre 4th, 2006 at 17:46
Excelente post 😀
octubre 3rd, 2006 at 18:21
Algun sistema linux, que instala xgl por defecto…
porfa…
septiembre 25th, 2006 at 23:39
xgl es excelente, el mejor entorno grafico qe me ha tocado ver, el detalle es que todavia es muy inestable y tiene bastantes problemas con algunas librerias OpenGL.
Pero a pesar de todo es muy bueno el entorno.
septiembre 1st, 2006 at 00:06
Soy nuevo en este S.O, me gustaria que me expliquen cual es el programa o la aplicacion para poner el cubo y como instalarlo en el escritorio, y bueno no entendi que es el xgl, ni el looking glass, ni que es el luminucity
agosto 29th, 2006 at 14:33
123
123
agosto 28th, 2006 at 00:49
Mag, en teoria si puedes instalarlo en RH4, pero seguramnte será tanto trabajo que no vale la pena.
Aiglx ya esta usable. Para los que tenemos tarjetas intel por ejemplo es mejor usar aiglx en vez de xgl
agosto 24th, 2006 at 13:02
Sobre el desempeño, no puedes comparar los juegos con las aplicaciones. Los juegos estan diseñados para ocupar una determinada API, que tambien esta diseñada para ocupar una determinada arquitectura de hardware. Las aplicaciones simplemente piensan en un framebuffer lineal.
Por ejemplo, el tema de reproduccion de video. Con el hardware 2D simplemente pintas un rectangulo de un color determinado (azul en xvideo) y descomprimes el video en otro contexto, la tarjeta de video se encarga de reemplazar los pixeles azules para que se vea el video al momento de convertir la señal de digital a analogo. Y te hace automaticamente el escalado e interpolación. Que haces entonces cuando tienes render directo? en un composite manager como aplicas una sombra sobre el rectangulo azul que te recortara el video?…. que hace Xgl? en vez de hacer eso utiliza pixel buffers para renderizar en una textura, pero si el hardware+driver no lo soporta, sonaste.
En cuanto a tu pregunta del uso de la RAM, en realidad no es relevante. La pregunta es en que contexto se realizan las cosas. Recuerda que X es cliente servidor, entonces las cosas se deberian hacer en el cliente o en el servidor? donde opera el composite manager? que transferencia de pixels hay que hacer entre un contexto y otro?.
En el caso de mi tarjeta de video por ejemplo (intel), con aiglx tengo xvideo igual que en xorg, pero con xgl no funciona bien, ya que en el segundo caso xvideo debe ser implementado con opengl, y no hay soporte del driver para pixels buffers/frame buffer objects.
El documento de Jon Smirl es bastante bueno, aunque hubieron varias replicas sobre algunas cosas en que no todos estaban de acuerdo.
agosto 24th, 2006 at 12:48
Interesante comentario Eleazar. La arquitecura tiene su impacto en el desempeño. Por ejemplo XAA que es la arquitectura de aceleracion de los drivers de xorg esta diseñada con una arquitectura de hardware antigua. EXA es un paso adelante, pero aun tiene los inconvenientes de que hay que migrar los drivers hacia EXA. Al utilizar una arquitectura de bajo nivel unificada (OpenGL), los fabricante de drivers solo se preocupan de implementar solamente OpenGL y no XAA/EXA. Al utilizar OpenGL se supone que se puede sacar mucho mayor provecho del hardware, ya que el hardware actual esta diseñado con OpenGL y Direct3D en mente.
El clasico ejemplo de lo que ocurria antes que xorg + xaa + aceleracion por hardware era mas lento que usar kdrive + exa + escasa o nula aceleracion cuando se ocupaba la extension RENDER (xcompmgr la ocupa po rejemplo). Los drivers propietarios de nvidia son diferentes porque ocupan su propia arquitectura de aceleracion, diseñada con esos chips en mente, y a eso es lo que apunta tener opengl como base.
(sigo en el siguiente comentario.. no recuerdo cuanto era el largo maximo)
agosto 24th, 2006 at 12:15
Oops, el link:
http://jonsmirl.googlepages.com/graphics.html
agosto 24th, 2006 at 12:13
Ese tipo de impactos como el xv con xgl y muchos otros (leer diapos de nVidia en la parte de «Why not xgl?») son de esperarse si lo que se quiere es desarrollar un xserver nuevo
«So far I haven’t heard a single argument for why X on OpenGL is a a bad idea other than that it’s a big step and a lot of work will have to be done»
Entonces… ¿Es Dave Reveman solo un sin oficio que se dedico a llevarle la contraria a los desarrolladores de xorg conservadores?, ¿eso es todo? vamos! tienen que haber diferencias en el desemeño, no puede ser solo cuestion de una arquitectura de software distinta, algun otro beneficio estan persiguiendo los partidarios de construir un x-server desde cero sobre las api de OpenGL (reutilizando cuanto codigo les sea posible de xorg claro esta)
Y no me refiero al desempeño de por ejemplo, los efectos de compiz corriendo en xgl o en aiglx, las tarjetas de video modernas tienen años haciendo cosas mucho mas complejas, las diferencias serian imperceptibles, hablo mas bien de aplicaciones como juegos, o juegos.. y este… tambien juegos (alguien ayudeme para citar alguna otra cosa xD)
Con respecto a la pregunta que hice anteriormente del rendimiento, voy a ponerme algo mas especifico, criollo y puntual, ¿Cuánta ram ocupa xorg+xgl? ¿Mas que aiglx?… ¿Alguien que lea este blog tiene aiglx funcionando que me pueda responder?
PD: Aca les dejo otro link, Jon Smirl que fue desarrolador del proyecto Xegl comenta sobre el estado de los gráficos en Linux, la intro y la conclusion son bastante puntuales, el resto…. ehmmm, digamos que es en gran parte un esfuerzo de él para que los entusiastas esten mas concientes de como trabaja la parte grafica en linux.
Saludos
agosto 22nd, 2006 at 15:31
Se supone que exgl no requiere xorg, pero no se en que estado se encontrara.
El tema de xgl o aiglx tiene que ver mas que nada por un tema de arquitectura que de performance. El mismo Dave Reveman dice en ese correo que ademas del tema de esfuerzo, no ve otros «contras» hacia xgl.
Aunque igual hay impacto en algunas areas, por ejemplo si usas extensiones com xv es distinto si el server esta corriendo sobre opengl o en forma indirecta como aiglx. En el caso de Xgl por ejemplo, xv requiere que tengas buen soporte de frame buffer objects o pixel buffers en tu driver, o bien hacer alguna truculencia como utilizar el xorg subyacente. En el caso de aixgl se utiliza el mismo xv del xserver.
agosto 22nd, 2006 at 01:48
Tengo una duda, hasta el momento xglx corre como una sesion sobre xorg no?, eso va a quedarse asi? o algun dia aparecera porfin ese «X server completely on top of the OpenGL API»?
Que tan eficiente es la solución actual xorg+xgl en comparacion con la solucion de red hat de desarrollar un par de extensiones y quien sabe cuantos parches mas para el xorg actual?
Jeje despues de todo detras de ese cubo mistico, todavia esta aquel tradicional y polvoriento xorg de toda la vida
Me consegui este reply del mismo David Reveman (El «mesias» de esta revolución gráfica xD), bastante interesante, entre otras cosas, da su opinion sobre aiglx y la posición que ha tomado nvidia en todo esto, tambien responde a un comentario en particular que hizo la gente de red hat con respecto a la forma en que se llevo a cabo el desarrollo del xgl en sus ultimas etapas
http://lists.freedesktop.org/archives/xorg/2006-February/013306.html
Por cierto, el post anterior…radeon 7000? hmmm, la mejor de las suertes amigo…
agosto 18th, 2006 at 21:14
La verdad estaba leyendo tu informacion y espero puedan ayudarme con mi problema tengo instalado Fedora Core 5 en mi maquina pero solo funciona en modo texto ya q en modo grafico al momento de trabajar luego de pocos minutos o aveces casi segundos se cuelga no se cual sea mi problema la targeta q uso es ati radeon 7000. Agradezco su gran ayuda
agosto 8th, 2006 at 16:59
Según tengo entendido la máquina virtual usa unos drivers genéricos.
Salu2
agosto 8th, 2006 at 16:42
Hola Franco saludos:
Con respecto al artiulo buenisimo, pero me queda un duda.
por ejemplo : si estoy corriendo por ej SUSE linux (con Xgl corriendo) en un servidor virtual machine con Xen y me conecto a este, la extención Xgl ¿en que tarjeta corre?, en la del pc de donde me estoy conectando o en el servidor virtual machine.
Quizas es una pregunta de Xen y no de Xgl pero, no sabia donde ponerla.
De antemano Gracias.
agosto 3rd, 2006 at 14:35
fome