El sistema grafico de GNU/Linux - Parte 1

Un sistema informático está compuesto por dos componentes básicos, el hardware que ofrece al usuario unos recursos y el software que permite al usuario controlar ésos recursos. Una de las complicaciones de trabajar con un sistema informático que existía en los albores de la informática, era la complejidad que entrañaba el software. En un principio, los usuarios controlaban los recursos a través de sentencias que escribían en una consola o terminal. Sin embargo, no todo el mundo era capaz de utilizar un equipo informático por ésa complejidad; para solucionarlo, se cambió la forma de comunicación entre el usuario y el software: la era de los entornos gráficos amaneció.

¿Qué es el servidor X?


Hace 26 años en los laboratorios del MIT se creaba un sistema de representación gráfico llamado X. Este sistema se basaba en un protocolo de comunicación que permitía interconectar dos sistemas informáticos diferentes; uno desempeñanda el papel de servidor y el otro el rol de cliente. En este esquema el servidor tiene como misión proveer de los recursos necesarios, manejar las peticiones y gestionar correctamente el dibujado en pantalla de la “imagen” que se quiera. De forma complementaria, el cliente usa los recursos que el servidor le ofrece realizando peticiones que el servidor deberá gestionar correctamente. El servidor gráfico que usamos actualmente tiene el nombre de X.org y fue creado en 2004 a raíz de un problema con la licencia de su predecesor: XFree86. Ahora vamos a explicarlo todo un poco mejor y con más detenimiento.

En el párrafo anterior ya han salido dos palabritas muy importantes y que en todos los artículos estoy bastante seguro que van a salir de nuevo, ya que son los pilares centrales del sistema gráfico de GNU/Linux. La primera es servidor y la segunda cliente.

Suponé que tenes una computadora, y que lo queres usar para dibujar en pantalla las fotos de la playa. Para dibujarlas es de cajón pensar que necesitarás unos recursos que utilizar. Si no necesitases unos recursos podrías dibujar en pantalla una imagen solo con pensarlo ¿no? Por tanto, necesito unos recursos y lo que es más importante: un sistema para gestionarlos.

Es decir, que necesito un sistema que identifique los recursos y que sepa cómo utilizarlos para luego poder dibujar en pantalla las fotos de la playa. Vamos con una metáfora que seguro que la agarras al vuelo. Si quisiera pintar una casa, necesitaría un soporte sobre el que pintar (un folio, pared o lienzo) y un lapicero, pinturas, acuarelas o rotuladores. Además necesito saber usarlos; si rompo el papel y trituro el lápiz es un poco difícil que llegue a pintar algo. El papel y el lapicero son los recursos que la computadora usará para dibujar en pantalla y los conocimientos para identificar un lapicero y usarlo adecuadamente son los métodos de gestión de ésos recursos. Seguimos con el ejemplo anterior, supongamos que soy muy torpe pintando, pero quiero retratar a mi perro. Como soy muy torpe contrato a un pintor profesional. Pues bien, el conjunto de los lapiceros, folios y sistemas de gestión forma el servidor mientras que el dueño del perro representa el cliente, ¿y el pintor? El pintor se estudiará mucho más adelante, cuando se hable de bibliotecas gráficas y manejadores de ventanas.

Ahora ya sabemos que el servidor ofrece unos recursos a los clientes y además implementa un sistema para gestionarlos eficientemente. De forma complementaria el cliente usa ésos recursos y los utiliza para hacer algo con ellos. Sin embargo, ésto no acaba aquí ya que aparte de disponer de recursos para dibujar gráficos en una pantalla, el servidor X.org ofrece otro tipo de recursos: los eventos que ocurren cuando presionas una tecla del teclado o del mouse. Por tanto, vuelvo a repetirlo para que les quede clarísimo, ahora con un ejemplo más ajustado a la realidad. Supongamos que bajo X.org abris gimp y dibujas un cuadrado. Ahora te pregunto, ¿en ése ejemplo quién es el cliente y el servidor? El servidor es X.org y el cliente es Gimp. Por lo tanto, cuando abres Gimp éste le pedirá a X.org unos recursos para poder dibujar en pantalla su interfaz (realiza la petición) y X.org dependiendo de la carga de trabajo atenderá la petición lo antes posible gestionando los recursos para que se pueda dibujar en la pantalla la interfaz de Gimp. Además, cuando clickeas en el espacio de trabajo para dibujar el cuadrado pasan varias cosas, ya que los eventos que emiten el teclado y el ratón hemos quedado en que también son recursos, y que por tanto también los gestiona X.org.

Los eventos funcionan de la siguiente manera. Primero X.org se entera de que hemos presionado una tecla y avisa a todos los clientes que en ése momento estén activos de que el usuario ha presionado una tecla. Si al cliente le interesa (porque en ése momento la aplicación está en primer plano o maximizada), procesa ésa pulsación sobre la tecla y le dice a X.org lo que quiere que haga (realiza una petición), a su vez X.org responderá a la petición gestionando los recursos adecuadamente para complacer al cliente. Ahora seguimos con el ejemplo de antes para explicarlo todo. Cuando abris Gimp, el servidor X.org le dice a Gimp que alguien a pulsado en su icono, Gimp identifica ésa señal con la acción de abrir una nueva instancia del programa y crear un dibujo en blanco y le pide a X.org que le reserve los recursos suficientes para poder dibujar su interfaz, X.org atiende la petición y le dice a Gimp que acaba de reservar los recursos, Gimp manda al “pintor” que dibuje la interfaz, luego dibujas un rectángulo y el mismo proceso se repite: X.org capta los eventos que producis al pulsar cualquier tecla, se lo envía a Gimp, éste lo procesa y se comunica con X.org para decirle que reserve recursos para poder dibujar el rectángulo, X.org le da luz verde y Gimp lo dibuja. Hasta aquí todo claro ¿no?

Todo el rollo que he metido en los cuatro párrafos anteriores lo he escrito para que comprendas qué funciones detenta el cliente y el servidor. Si lo comprendiste todo podrás responder sin ningún tipo de problema a éstas preguntas. ¿Qué hace X.org? Pues identifica y gestiona ciertos recursos y lo más importante: no dibuja nada. Simplemente gestiona los recursos, lo vuelvo a repetir y si no lo tienes claro vuelve atrás: no dibuja nada. ¿Qué hace el cliente? Pues usa los recursos de los que X.org dispone pidiéndole que le asigne un número determinado según la operación que tenga que realizar. Así de fácil, éstas funciones realizan el servidor gráfico y cualquier cliente (Gimp, Amarok, Scribus, Gedit, Kate, Thunar, Metacity o gtk). A partir de ahora voy a empezar a especificar un poco y a explicar cosillas un poco más características.

¿Qué son las X?


Ya hemos dicho que el sistema de representación gráfico de GNU/Linux se basa en dos entes separados: el servidor X y un cliente. Sin embargo, ambos trabajan codo con codo para poder dibujar en pantalla un gráfico; pero si están separados ¿cómo demonios se entienden? A través de un protocolo de comunicación, a través de X.

X es el lenguaje que utilizan el servidor y el cliente para entenderse (aunque también nos referimos a él como al sistema gráfico en términos globales). Una cosa muy curiosa de X y que en gran parte se ha convertido en un lastre bestial que está amenazando con matarlo (ya lo veremos en Wayland) es que el canal de comunicación puede ser cualquier cosa, desde un bus interno de la computadoraor hasta un cable par trenzado. Es decir, que a través del protocolo X puedo comunicar un servidor X ucraniano con un cliente subsahariano a través de internet. Y aquí viene cuando te vas a sorprender por primera vez. Imagínate que estoy sentado en una ciudad africana, y que quiero arrancar el programa de modelado tridimensional Blender. La computadora que tengo apenas puede arrancar, como para pedirle que modele tridimensionalmente. Entonces te acordas de que tenes un amigo en Ucrania que se acaba de comprar una bestia de computadora, lo llamas y le decis si te puede prestar la computadora para ejecutar Blender. Encantado, tu amigo acepta y confugura la computadora para funcionar como servidor africano. Vos configuras tu computadora para que utilice la computadora Ucraniana como servidor gráfico. Lo que ocurrirá es que al arrancar tu computadora el servidor X estará a miles de kilómetros de distancia, en una ciudad ucraniana mientras el cliente se estará ejecutando en mi computadora. Es decir, que los recursos que Blender está utilizando son los de la computadora ucraniana y Blender irá como la seda. Ambos ordenadores se comunican bajo X, aunque estén a miles de kilómetros de distancia. ¿Se puede hacer ésto de verdad? Teóricamente sí, y de hecho se hace, ahora bien, no te creas que es tan fácil ya que aparte de configurar el entorno gráfico tendrás que configurar a mano todos los protocolos de enrutamiento y transmisión de datos aparte de tener una banda ancha bastante grande, pero se puede hacer.

¿Qué es hal, udev y D-Bus?


Hasta ahora he dicho que el servidor X se encarga de gestionar los recursos; también he dicho que hay dos tipos de recursos, los que se utilizan para dibujar en pantalla una imagen y los que proceden de los eventos que provoco al presionar una tecla del teclado o del mouse.

Una parte importantísima de X (me refiero al sistema gráfico en términos globales, a partir de ahora siempre que diga X tene en cuenta la doble acepción) es configurar los dispositivos de entrada para que funcionen a la perfección. Ahora quiero explicar cómo es posible que cuando conecte un dispositivo al ordenador éste lo reconozca automáticamente. Esto vale para monitores, teclados, altavoces, mouses, pendrives, discos rigidos extraíbles, tabletas digitalizadoras o cualquier periférico.

Si navegás hasta la carpeta /dev te encontraras con un montón de archivos. Cada archivo representa virtualmente un dispositivo conectado a la computadora y se denominan archivos de dispositivo (bueno, cada uno no, pero es hilar muy fino, si te interesa investiga vos mismo ). Esos archivos sirven para que las aplicaciones puedan identificarlos. Si por ejemplo InkScape quiere escanear una imagen acudirá a /dev/scan para mandarle las órdenes, luego ya será otro programa el que traduzca ésas órdenes al escáner. Ahora bien, ¿quién crea ésos archivos? Udev, éste sistema crea archivos de directorio de forma dinámica. Es decir, que cuando advierte que se ha añadido un dispositivo a la computadora lo identifica mediante los metadatos y crea un archivo de dispositivo para que otros programas puedan referirse a él. Udev tan solo crea los archivos de directorio cuando el kernel avisa de que algo se ha conectado a algún puerto. Sin embargo, no todo es tan fácil, ya que las aplicaciones no pueden acceder directamente a un dispositivo; la variedad de dispositivos y la peculiaridad de cada uno de ellos lo hace imposible, y me explico.

Suponé que vas a conectar un teclado de la marca LB (Life is Bad) y que por el motivo que sea tenes que cambiarlo a otro modelo de la misma marca (o de otra marca, me es indiferente). Estarás de acuerdo en que los dos teclados no son iguales, cada uno tiene unas teclas de función diferentes y puede que estén utilizando puertos diferentes. Sin embargo InkScape no debería ver ninguna diferencia, para él los dos son un teclado y le importa tres hu$#os (hablando mal y pronto) si es un modelo u otro. Pero no son iguales y se producirá un error si InkScape no aplica una diferenciación. Aquí aparece hal (Hardware Abstraction Layer). Si hago que InkScape vea a los dos dispositivos iguales no tendrá que saber las características de cada uno; luego ya me encargaré yo de aplicar las diferenciaciones oportunas a las órdenes genéricas que mande InkScape. Eso es exactamente lo que hace hal, proporciona una capa de abstracción de hardware a la que todas las aplicaciones se dirijan cuando quieran manejar un dispositivo, después, cuando la aplicación mande las órdenes y dependiendo del modelo del dispositivo aplica la configuración específica.

Ya sabemos más o menos lo que pasa cuando conecto un periférico a la computadora. Primero, el kernel advierte de que se ha conectado, udev crea un archivo de dispositivo, hal lo estudia y crea un dispositivo genérico en su capa de abstracción de hardware, para que las aplicaciones puedan usarlo. Sin embargo, ¿cómo se comunican entre ellos? A través de D-Bus. Técnicamente D-Bus es un framework de comunicación entre procesos o IPC, pero para que nos entendamos todos es el bus del trabajo. Lo utilizan todos aquellos que se quieran comunicar entre sí. Es decir, cuando una aplicación se quiere comunicar con otra lo usa, cuando Hal se quiere comunicar con udev lo usa, cuando el kernel se comunica con un módulo lo usa, cuando udev se comunica con hal lo usa. Es indispensable y tremendamente eficiente, no solo se utiliza en la generación de gráficos sino que lo utilizan casi todos los programas para comunicarse con otros.

Gestores de Sesiones y gestores de Acceso


Empecemos por el principio. Cuando pulsas en el botón de encendido de tu computadora ésta arranca; lo hace en dos fases, en la primera se realiza una comprobación básica de integridad del hardware; cuando se ha completado con éxito se lee el MBR (Master Boot Record), se carga el stage 1 del gestor de arranque y éste redirige el flujo de control al stage 2 donde se cargará Grub (o sucedáneos), una vez en este punto eligis el SO que desees y comienza la segunda fase en la que será el SO el que se cargue. En ésta segunda fase lo primero que se carga en memoria es el kernel, cuando éste ha finalizado empieza a reconocer el equipo informático, a aplicar configuraciones y a ir activando servicios secundarios. Este punto es el que nos interesa (todo lo anterior tan solo lo he escrito para hacer una composición de lugar), ya que un servicio secundario que el kernel activará es el entorno gráfico.

Espero que a estas alturas todo el mundo diferencie el kernel del sistema gráfico. El primero crea herramientas para acceder a los recursos y el segundo utiliza ésas herramientas para gestionar las peticiones que le llegan de los clientes gráficos y poder mostrar en pantalla una imagen (por ejemplo). Por tanto, el sistema gráfico puede o no ser arrancado, todo dependerá de si el kernel desde un inicio lo levanta por defecto o lo tendremos que arrancar a mano. Para arrancar el sistema gráfico además tendremos que realizar dos cosas, la primera es levantar el servidor gráfico para luego empezar a levantar una por una todos los clientes gráficos. Es decir, que lo primero que hace el kernel para levantar el entorno gráfico es cargar el X.org y luego ya empieza a levantar el manejador de ventanas, bibliotecas gráficas o aplicaciones como heybuddy o gimp. En el arranque del servidor gráfico se cargarán todos los componentes que lo forman, tales como módulos, manejadores de dispositivo o protocolos de comunicación. Por lo tanto, levantar X.org significa levantar todos los componentes que lo forman. Esto es la teoría, ahora pasemos a la realidad.

Como es evidente, sería terriblemente farragoso arrancar uno a uno todos los módulos que forman el servidor gráfico, para ello lo que se hace es teclear una orden que arranque todas las dependencias de X.org y una cosa más: se crea una instancia de un gestor de acceso o Display Manager.

Para explicar la función que cumple el Display Manager es necesario acudir a dos características del sistema gráfico X. La primera es la capacidad que tiene X de ofrecer entornos personalizados para diversos usuarios, es decir, que X proporciona un entorno multiusuario. La segunda es la capacidad de separar el servidor gráfico y las aplicaciones; es decir, que puedo tener un sistema informático potente en Tierra de Fuego y utilizar una aplicación en Reikiavik que utilice los recursos del equipo informático argentino.

Para sacar el máximo beneficio a ambas características tengo que implementar un sistema que permita al usuario elegir el tipo de sesión que quiere utilizar, es decir, si quiere usar ése u otra computadora como servidor gráfico y qué cuenta quiere utilizar. Ése sistema lo forman los Display Managers o gestores de Acceso.

Si estás habituado a utilizar una distribución de GNU/Linux habrás oído hablar casi seguro de GDM, KDM, XDM, Slim o LXDM. Todos ellos son Display Managers, funcionan como un cliente gráfico y sirven para definir la sesión que el usuario ha escogido, además, hacen una cosa muy importante ya que se autentican con el servidor gráfico a través de un protocolo denominado XDMCP. No quiero entrar en detalles sobre el protocolo porque no creo que lo vayás a utilizar nunca, lo que quiero que quede claro es que los Display Managers sirven para que el usuario defina la sesión que quiere utilizar y además se autentican con el servidor gráfico si éste se encuentra en un equipo informático diferente.

En los párrafos anteriores he mencionado la palabra sesión varias veces. Ahora bien, ¿qué es una sesión? Para explicarlo voy a poner un ejemplo. Suponé que has creado una nueva cuenta para tu periquito, que le ha dado por aprender informática. Creas la cuenta Rufo y le asignas una contraseña fácil para que se acuerde. El periquito comienza a personalizar el escritorio. Le añade un fondo de pantalla, define las aplicaciones por defecto, añade al inicio de sesión unos programas determinados y cambia la contraseña porque no se fía de ti. Además se pone a navegar y consulta PillateUnLinux para ver lo que han publicado en los últimos días, sin embargo no le da tiempo a acabar de leer las noticias y apaga la computadora. Al día siguiente y acuciado por un deseo infinito,enciende la computadora y llega hasta el Display Manager. Con el pico teclea su nombre y desplegando las alas para que nadie le espíe introduce la contraseña. Cuál es su sorpresa al ver que el escritorio que se le presenta se encuentra en el mismo estado que cuando presionó el botón de apagar (o si es un periquito aplicado cuando tecleó shutdown -h now en la consola) la noche anterior. El estado del escritorio es una sesión, y un gestor de sesiones es el encargado de almacenar, modificar y cargar la información que define ése estado.

Hemos visto que para arrancar el entorno gráfico hay que arrancar primero el servidor gráfico; esta operación la llevará a cabo el kernel en el momento del inicio o nosotros a posteriori. Una vez que se ha cargado el servidor X hay que empezar a abrir los clientes que hagan uso de las funcionalidades que ofrece el servidor gráfico. Para arrancar los clientes gráficos antes es necesario arrancar un display manager, que me permitirá introducir el nombre de usuario que quiero utilizar y así definir la sesión. Una vez que he metido el usuario, el gestor de sesiones cargará el estado del escritorio asociado a mi cuenta de usuario y empezará a monitorear todas las acciones que vaya haciendo para ir modificando el archivo que define mi sesión y así poder retomarla cuando quiera. Si has entendido hasta aquí, habrás entendido cómo se levanta el entorno gráfico, es decir, primero el servidor y luego los clientes a través de un gestor de acceso y de sesión. Por último, hablemos un poco del Linux FrameBuffer.

Linux FrameBuffer


Hasta ahora hemos hablado del entorno gráfico como un servicio independiente del kernel. Sin embargo, también es posible representar gráficos en pantalla sin usar las X a través del Linux FrameBuffer. Un framebuffer es la representación del estado de la pantalla en un “archivo”. Para pintar en pantalla un gráfico lo que se hace primero es pintarla en un espacio aparte denominado framebuffer que luego se copiará a pantalla. Lo que por ahora quiero que comprendas es que para dibujar algo en pantalla, primero lo tenemos que dibujar en un espacio aparte denominado FrameBuffer. Por tanto, si construyo un sistema que pinte gráficos en ésos framebuffers y que luego los copie en pantalla, habré diseñado un sistema gráfico. De forma muy resumida éso representa el Linux FrameBuffer: un sistema alternativo que permite gestionar framebuffers.

Voy a explicarlo un poco mejor. Hasta ahora he estado hablando de recursos gráficos. Gestionando adecuadamente ésos recursos gráficos la computadora es capaz de mostrar en pantalla una imagen. Para GNU/Linux el gestor por excelencia de ésos recursos gráficos es el sistema de ventanas X. A través de él se gestionan los recursos y permite la representación gráfica en sistema derivados de GNU/Linux. Sin embargo, también existen otros gestores de recursos, el Linux FrameBuffer es uno de ellos. Este sistema gráfico lo único que hace es utilizar los recursos que me ofrece la computadora para pintar en pantalla unos gráficos. Sin más, no se complica la vida con servidores, sesiones, Display Managers o protocolos de comunicación. Simplemente pinta, primero lo hace en un archivo aparte denominado framebuffer y luego lo copia a la pantalla. La pega es que tiene muy pocas funcionalidades: es tremendamente ineficiente. No soporta grandes cargas de trabajo, no aprovecha las cualidades de las tarjetas gráficas y tan solo puede dibujar algunos gráficos.
Sin embargo, es muy ligero. ¿Dónde puedo utilizar un sistema gráfico muy torpe pero muy ligero? En el arranque. Si alguna vez utilizaste alguna distribución como Arch, BackTrack, SLAX o Knoppix habrás observado que mientras está abierta la terminal y se está cargando el SO en la parte superior aparece tux u otro gráfico. Las Xs no están cargadas, entonces ¿cómo es posible? Exacto, gracias al Linux FrameBuffer.

En un inicio, X fue diseñado para ser extremadamente modular y simple. Una de sus máximas reza lo siguiente “Proporciona mecanismos en lugar de políticas”, eslógan que enfatiza el objetivo que persigue X: ofrecer la base para que se construya un sistema gráfico. Pero solo ofrece la base, lo restante se debe diseñar con herramientas adicionales. Las extensiones son parte de ésas herramientas, bienvenidos al verdadero problemón de X.

Extensiones de X


Como ya he dicho en el primer párrafo, en el diseño de X lo que se pretendía era dotar de un entorno que fuese capaz de gestionar correctamente los recursos gráficos, que controlase los eventos y que ofreciese un protocolo de comunicación. Lo restante no entra dentro del sistema X y para solucionar la escalabilidad, se hizo de X un sistema muy modular. Así pues, si quisiéramos dotar de una funcionalidad especial a X, tan solo tendríamos que escribir una porción de código y enchufarlo al sistema X, ésa porción de código se llama extensión X.

DRI (Direct Rendering Infrastructure)


Una computadora no es más que una calculadora potentísima. Está compuesta por diferentes unidades de proceso que hacen cálculos complejos a una velocidad endiablada. Hacen sumas, integrales, logaritmos, límites, resuelven ecuaciones y calculan ángulos con leyes trigonométricas (por poner unos ejemplos). En base a ésos cálculos podemos presentar en pantalla una imagen, reproducir una canción o enviar un correo electrónico. Toda la capacidad de cálculo de un ordenador se basa en dos componentes base, la Unidad Central de Proceso o CPU y la Unidad de Procesamiento Gráfico o GPU. Ambas son muy diferentes entre sí y están optimizadas para realizar cálculos diferentes; la CPU es la encargada de realizar los cálculos más habituales mientras que la GPU ha sido diseñada para realizar los cálculos correspondientes al procesamiento gráfico. Como es evidente, no sería muy lógico utilizar indistintamente una u otra unidad de proceso, lo mejor sería utilizar la CPU con carácter general y cuando se vaya a hacer algún procesamiento gráfico utilizar la GPU. Sin embargo, nos encontramos con un problema y es que la CPU controla toda la computadora, todas las peticiones pasan por ella ¿en serio? Pues no, para éso se inventó el DRI, para proporcionar acceso inmediato a la GPU a todo aquel que quiera realizar cálculos de procesamiento gráfico. Eso sí, si no habilitamos DRI en el servidor X (¿ves por qué es una extensión?) tene por seguro que te desesperarás cuando hagas cálculos gráficos complejos porque todas las peticiones pasarán por la CPU y el rendimiento bajará dramáticamente.

Ya sabemos lo que es DRI, ahora quiero explicar qué es DMA (Direct Memory Access). Para conseguir renderizado directo tendré que disponer de un transporte para llevar mis peticiones directamente a la GPU. Éso es DMA, un bypass permitido que se salta la exigencia de visitar la CPU cada vez que quiera hacer un cálculo. Si observas la definición anterior digo cálculo, y no le he puesto el apellido gráfico, ¿a qué se debe? Pues a que el DMA es un transporte global, que se coge para bypassear la CPU y acceder directamente a un dispositivo. Por ejemplo, también se hace con determinadas direcciones de memoria RAM o en entornos de producción discográfica, donde la latencia es importantísima.

Básicamente éso es DRI, un sistema para renderizar por hardware (o renderizado directo). Lo puede usar cualquier aplicación que quiera utilizar directamente la GPU, bueno, cualquiera no ya que existen unas políticas de uso que registran a todos los procesos para detectar a posibles impostores, pero esto es hilar muy fino. DRI está formado por tres componentes, el primero es el DRM (Direct Rendering Manager), que se encarga de gestionar los recursos y las políticas de uso; el segundo es un driver OpenGL; y el tercero es una interfaz que usan los drivers gráficos llamada normalmente libdri.so. Lo he resumido muchísimo, y ni tan siquiera he entrado en el funcionamiento del DRI o el DMA, pero para que os hagáis una idea conceptual sobra, si estáis interesados en saber más, internet os espera.

GLX (OpenGL Extension to the X Window System)


Agarrate porque vienen curvas. Hasta ahora la vida parecía sencilla, ya que disponíamos de DRI para habilitar el renderizado directo y nada más. Sin embargo, DRI es un proyecto bastante nuevo, lo que había antes se llamaba GLX. Pero ¿y qué me importa a mí? Pues importa y mucho porque GLX se diseñó para ser un enchufe especial entre X y OpenGL y aún se sigue usando. Es especial porque GLX provee renderizado directo, pero solo para OpenGL. Soy consciente de que todavía no he dado OpenGL, pero creo oportuno empezar a hablar de GLX en éste artículo para que empecés a esbozar una visión general. OpenGL no es más que un conjunto de primitivas que dibujan cualquier cosa. Es decir, le das a OpenGL lo que quieres dibujar y él te lo dibuja (renderiza).

Es decir, que todas las aplicaciones que usen OpenGL (por ejemplo compiz, que es muy conocido) usarán GLX para realizar peticiones al sistema X que además serán directas porque irán a la GPU sin pasar por la CPU. Se diferencia de DRI porque éste último aparte de soportar OpenGL, se puede utilizar en otros entornos; si una aplicación no quiere utilizar OpenGL, pues tan contenta se queda ya que DRI también le proporcionará renderizado directo; si ésta aplicación hipotética no dispusiera de DRI no podría renderizar por hardware y tendría que pasar por la CPU, reduciendo el rendimiento. Con que a éstas alturas sepas que el DRI proporciona un entorno global para renderizado directo y que GLX se limita a usarse con una cosa sin forma denominada OpenGL, sobra material. Lo que tenés que comprender es la importancia del DRI.

GEM (Graphics Execution Manager) y TTM (Translations Table Maps)


Aparte del volumen de cálculo que nos proporcionan las unidades de procesamiento, otro componente indispensable en cualquier equipo informático es la RAM (Random Access Memory). Su uso principal es servir de soporte para almacenar datos en ejecución. Al igual que muchas aplicaciones, el sistema gráfico hace uso de la RAM, pero al contrario que otros programas, su uso es prolongado y muy frecuente. Es decir, que la gestión de la RAM definirá en gran medida el rendimiento con el que funcione el sistema gráfico. Si hay una mala gestión, el sistema gráfico será muy torpe, las latencias se disparan y los nervios de los usuarios se crisparán. Por el contrario, con una buena gestión la fluidez del sistema se hace patente y el usuario podrá disfrutar de un buen SO. Como todas las decisiones que se hacen en un ordenador, las peticiones de RAM pasan por la CPU. Pero estamos en las mismas que con el DRI, si quiero que el equipo sea rápido, tendré que bypassear la CPU para hacer que las decisiones sean más rápidas. Este bypass lo realizan TTM o GEM, un módulo que permite la gestión de RAM involucrada con el entorno gráfico.

No los voy a aburrir, simplemente voy a decir que TTM se desarrolló primero, pero tras la ilusión inicial y debido a su complejidad técnica, ciertos programadores demandaron un sistema más sencillo, que pesase menos y que se acoplase mejor con los drivers. Para solucionar ésos problemas se desarrolló de cero GEM, con éste nuevo gestor de memoria se reduce la complejidad y se aumentan las características técnicas, sin embargo, hay un problema bastante gordo. GEM no proporciona un gestor de memoria completo. Tan solo provee las partes de un sistema gráfico que son comunes a cualquier tarjeta gráfica, las partes dependientes de la tarjeta gráfica tendrán que ser incluidas en los drivers. Esto es (hablando rápido y mal) un putadón, ya que en los drivers libres no pasa nada, pero ¿y los privativos? Pues que la gestión de memoria será cerrada en parte, con lo que se está reduciendo la complejidad técnica pero se está aumentando la contribución a la privatización del código. El debate está servido.

XRender


Todos los habituados a compiz, KWin, Mutter o Enlightment (por poner unos ejemplos) disfrutaran de efectos de composición off-screen. Aunque cada vez se usa menos, la primera extensión que permitía hacer ésto era XRender. Este módulo provee las primitivas necesarias para manipular un framebuffer y aplicar los efectos deseados.

XVideo


He aquí un ejemplo bastante sencillito que usa DRI sin usar OpenGL. XVideo es una extensión que permite la modificación de reproducciones en curso a través de renderizado directo. Es decir, que suponé que estás utilizando MPlayer y decides darle a la f para ponerlo en pantalla completa. Lo que acabas de hacer es escalar el clip de vídeo. Has pasado de una ventana de 500×350 pixels (por ejemplo) a una de 1680×1050. Como estarás pensando, escalar un clip de vídeo debe ser costoso en recursos, y hacerlo sin que se pierda calidad de imagen justo en el momento del escalado tiene que se complicado. Pues éso es lo que hace XVideo. Técnicamente hablando, XVideo es una salida de vídeo lógica que se puede configurar en algunos reproductores (MPlayer, Xine o MythTV) para habilitar el uso de DRI al hacer operaciones especiales con la reproducción en curso. Como podes observar no utiliza en ningún momento OpenGL, por lo que si DRI no existiese no podría usar directamente la GPU, ¿queda clara la diferencia entre GLX y DRI?

KMS (Kernel Mode Setting)


He dejado KMS para el final porque no es una extensión de X, pero es bastante importante. Cuando arranca la computadora, lo hace en modo texto (casi siempre, aunque veamos colores en la consola, ¿te suena el Linux FrameBuffer?) y en un momento determinado cambia a modo gráfico. Lejos de ser fácil, el cambio era bastante complicado ya que dependía de la información recogida en la BIOS (que almacena algunos modos gráficos, normalmente los óptimos), los procedimientos del servidor gráfico y los del kernel. Es decir, que entre todos se hacían un lío lo que provocaba gran consumo de recursos y un continuo “pestañeo” al inicio del SO. Todo ésto se solucionó otorgando al kernel todas las competencias para el cambio gráfico. Se hizo así porque teóricamente el kernel dispone de la información necesaria para levantar el modo gráfico óptimo en el arranque, ya que atiende a la información de la BIOS y de las aplicaciones interesadas (como el servidor X). Así pues, cuando elegimos en el gestor de arranque el SO que quieras, se carga el kernel en memoria y acto después se elige el modo gráfico y se levanta el entorno gráfico. Además, ésto posibilita que cuando una aplicación quiera modificar el modo gráfico por cualquier motivo o cambie a modo texto al pulsar Alt+Ctrl+Fn, el cambio se hará más rápido ya que el kernel sabrá si el modo gráfico requerido es igual o distinto del actual, minimizando al máximo los cambios de contexto innecesarios. Un vídeo donde se puede ver KMS en acción.




Extraido y adaptado de pillateunlinux
Parte 1
Parte 2
Parte 3