9 de enero de 2009

Modesetting

Si en Linux 2.6.28 vio la luz GEM, el gestor de memoria para GPUs, en 2.6.29 ve la luz "modesetting", es decir, el código encargado de configurar el "modo" (resolución, profundidad del color) de funcionamiento de la tarjeta gráfica.

Aunque a los que no tenemos mucha idea de gráficos nos parece que eso tiene pinta de ser sencillo (especialmente con varias salidas de video y hotplugging de monitores), los que lo han hecho aseguran que es algo tremendamente complicado -era imprescindible, para empezar, que estuviera basado en un gestor de memoria, lo cual obligó a esperar la inclusion de GEM-, razón por la cual se han tardado tantos años en llegar a este punto.

En Linux la situación actual ya era de por si aun más complicada, pues el catastrófico diseño de los gráficos obliga a compartir el mismo hardware entre varios drivers. Eso implica que cuando se pasa de las X a una VT (Control + Alt + F1), las X guardan el estado de la tarjeta, se resetea la tarjeta, y se deja que el driver de la VT (radeonfb, por ejemplo) configure de nuevo la tarjeta de cero. Para volver a las X, el proceso inverso. Por eso hay esa pequeña y molesta pausa, y dependiendo del driver que uses, directamente puede colgarse el sistema si el driver se olvidó de reiniciar alguna cosa. Y al recuperar un sistema suspendido o hibernado, es necesario a veces un programa en espacio de usuario que restablezca el estado de la gráfica. Si ese programa falla, la pantalla se queda en negro...

Con modesetting, todo se centraliza en un solo driver dentro del kernel, y parte de ese código se comparte entre varios drivers. De entrada, eso significa que una barbaridad de código en varias partes del sistema pasa a mejor vida, lo cual implica mayor robustez. La suspensión e hibernación es más sólida. Las X ya no necesitan saber configurar esa parte de la tarjeta gráfica, su labor se centra en dibujar cosas y mandárselas al hardware. Cambiar de las X a las VT y viceversa es prácticamente instantáneo. Pero no acaba la cosa ahí:

[ 12.601149] allocated 1280x1024 fb: 0x007df000, bo ffff88003c4086c0
[ 12.601270] fb0: inteldrmfb frame buffer device
[ 12.601272] registered panic notifier
[ 12.601277] [drm] Initialized i915 1.6.0 20080730 on minor 0

Es decir, el driver -el driver drm, nada que ver con el de fb- te crea un dispositivo framebuffer tradicional pero basado en modesetting y GEM. Y además, te añade un "panic notifier": Es decir, si el kernel se cuelga, te mostrará el panic en la pantalla....aunque estés en las X.

Lo único malo es que la opción del kernel "activar modesetting por defecto" -que es la que activa el fb basado en modesetting- no puede activarse si no tienes unas X con drivers que soporten modesetting para tu gráfica....

4 comentarios:

  1. Anónimo10:19 p. m.

    > Lo único malo es que la opción del kernel "activar modesetting por defecto" -que es la que activa el fb basado en modesetting- no puede activarse si no tienes unas X con drivers que soporten modesetting para tu gráfica...

    ¿Sabes qué drivers soportan y qué drivers no soportan esta característica?

    Un saludo

    ResponderEliminar
  2. Anónimo10:41 p. m.

    las tarjetas gráficas Intel... aún se esperan que ATI y Nvidia publiquen nuevas versiones basadas en GEM.

    la razon es porque gran parte de la tecnología GEM fué desarrollada por programadores de Intel, pero las especificaciones son abiertas, y los fabricantes de tarjetas gráficas pueden emplear este módulo

    ResponderEliminar
  3. Anónimo11:46 p. m.

    Esperemos como siempre a que nuestros amigos de nvidia saquen de nuevo la versión propietaria del driver... si estubiera abierto probablemente ya estaría echo pero que le vamos a hacer...

    ResponderEliminar
  4. Creo que el driver Noveau lo implementaba, pero por supuesto, nadie usa eso aún.

    ResponderEliminar