Informe irregular sobre el desarrollo de Nouveau
Edición del 21 de marzo
1. Introducción
Hola. Vas a leer el número 37 del TiNDC. Si esperas que este número tenga la extensión del anterior prepárate para una pequeña decepción. Volveremos a la extensión habitual.
En resumen, no hay demasiados avances de los que informar, ya que la gente está intentando familiarizarse con Gallium o están trabajando en hacer funcionar Gallium en sus tarjetas.
Si te sientes con valor, puedes probarlo siguiendo las instrucciones del blog de Hanno Böck (http://www.hboeck.de/archives/599-A-try-on-current-nouveau.html) o echando un vistazo a nuestro wiki: http://nouveau.freedesktop.org/wiki/GalliumHowto
Por favor, tened en cuenta que no vamos ni podemos dar soporte en este tema todavía. Si funciona, tienes suerte, y si no, no os quejéis. Existen fallos conocidos tanto en Nouveau como Gallium y estamos trabajando en ellos. Pero acabamos de empezar...
Salió la pregunta de si Nouveau manejaría cosas como la velocidad del ventilador. La respuesta es: no, por favor, usad NVClock, de Thunderbird, para ese tipo de cosas.
Y un último tema para esta introducción: tenemos una tarjeta 8400 donada por kho. Esta tarjeta no abandonará las golosas manos de Marcheu, que se unirá a los esfuerzos de Darktama para hacer funcionar el 3d en las tarjetas NV50. Mil gracias a kho por su generosa donación!.
Xorg ha sido aceptada como organización mentora en el GSoC2008. En función de los resultados de los años anteriores, no somos muy optimistas respecto a la obtención de un puesto en Xorg para nuestros proyectos. Si sale, querríamos trabajar en NV5x, por lo que si tienes una tarjeta libre 8x00 que quieras donar, hazte oir. Y no, no esperamos que dones una 8800TGS o una 9x00. Otra tarjeta 8400 o 8500 sería suficiente.
Ya que se preguntó por el tema un par de veces en el IRC: Consideramos las últimas tarjetas G92 como parte de la familia NV50 y les daremos soporte en el futuro. Sin embargo, advertid que en estos momentos existen algunas limitaciones (más sobre esto en el siguiente capítulo).
2. Estado actual
Como señalamos en el anterior número, el establecimiento de modo va a ser integrado en el núcleo oficial muy pronto. Fedora 9 va a hacerlo primero, atando antes todos los cabos (http://people.freedesktop.org/~ahuillet/irclogs/nouveau-2008-03-06.htm#1251)
Stillunknown y Malc0 continaron puliendo y arreglando Randr1.2. Se limpió el código para NV50 ya que se habían acumulado muchos restos. La nueva edición está más en línea con el código del resto de tarjetas. Sin embargo, no se añadido nueva funcionalidad, y solamente se han incorporado arreglo obvios (advertid que ni Malc0 ni Stillunknown tienen una tarjeta NV5x disponible). Así que el código funciona tanbien o tan mal como antes.
Sin embargo, todavía hay esperanza: Xorg-NV ha incorporado código para interpretar las tablas de la BIOS de las tarjetas NV50. Tal vez malc0 sea capaz de adaptarla a nuestro código. Lo que salga de todo esto está por verse todavía.
Aparte de eso, el plazo para tener Randr1.2 fue confirmado para el caso de que no aparezcan problemas imprevistos. Y además, Nouveau ya no falla al salir de las X. Simplemente intenta resturar el modo texto y falla horriblemente, dejando una consola de texto inutilizable.
Airlied probó (http://people.freedesktop.org/~ahuillet/irclogs/nouveau-2008-03-12.htm#0053) Gallium en PPC y encontró algunos problemas con el buffer de profundidades. Una inspección posterior de Darktama y Marcheu apuntó a un posible problema en Mesa para PPC. Parece haber un problema con los buffer de profundidad. Fijaos en la rueda verde para ver el problema:
Darktama trabajó algo en NV30, ayudando a pmdata a poner en marcha la tarjeta. "Simplemente inserté la NV30GL para divertirme y arreglé los principales problemas. El resto queda para pmdata :)"
Benkai está todavía trabajando en recopilar las opciones, problemas y posibles soluciones para conseguir el soporte de suspensión en Nouveau. Tras ello comenzó a probar la funcionalidad de suspensión/restauración en una NV04 insertando el código de suspensión en EnterVT (cambio a la consola de texto) y el de restauración en LeaveVT. De forma que al acceder a la consola de texto, el estado se guarda y se recupera al regresar a las X.
Para dicha funcionalidad, se añadió un ioctl() en el DRM y PGRAPH resultó trivial en NV04: Nouveau simplemente acomoda un canal y llama a engine->graph.save_context() antes de inicializar PGRAPH. Para restaurar, llegó con una llamada a engine->graph.restore_context(). Tras ello, nouveau funcionaba todavía tras un ciclo de LeaveVT/EnterVT (con inicialización de PMC/PTIMER/PFB/GPRAPH).
Tras este éxito, benkai añadió el guardado y recuperación de todos los registros PFIFO al ioctl(). Nouveau ahora genera una interrupción de cambio de contexto PGRATH tras la cual X vuelve a enviar instrucciones a la FIFO de nuevo. Desgraciadamente, la tarjeta emite errores extraños después de esto.
Como ya comentamos en otro número, el estado actual se puede consultar aquí: http://nouveau.freedesktop.org/wiki/Suspend_support
Tras consultar su factura eléctrica, Ahuillet también se expresó.
Y ahora alguna información sobre la NV50. Incialmente esperábamos que la NV50 tendría un modo de compatiblidad NV40, pero esas esperanzas se desvanecieron enseguida. Estando la ingeniería inversa un poco atrasada, y pendiente de buscar el camino a través de Gallium, Darktama decidió trabajar en las NV4x, donde la mayoría de las cosas necesarias y a eran conocidas.
Concentrarse en NV4x ayudó a que se pudiesen hacer las impresionantes demostraciones de LCA y FOSDEM, pero dejaron aparcada la NV50. Cuando Darktama cambió su NV40 por una NV30 para ayudar a pmdata con sus problemas de incialización, tuvo la mala suerte de estropear su NV40. Así que, ante la opción de trabajar en la NV30 o la NV50, eligió la NV50 y abordó el motor 3D. Tras un duro trabajo detectó que el motor 3D rehusa dibujar en superficies lineales y la única manera de hacerlas de forma teselada es usando algunas banderas de las páginas de paginación de la GPU.
Lo primero que logró hacer funcionar es el limpiado del buffer. Lo siguiente que adaptó fue el DRM. Un cambió en él impide que los canales de la GPU accedan directamente la VRAM. Ahora lo hacen a través del sistema de memoria virtual de la tarjeta. Este es un paso necesario a la hora de soportar superficies teseladas, que son necesarios por 3D.
El siguiente objetivo es intentar la representación de triángulos. Esto, sin embargo, necesita de cambios complejos en el DRM de Nouveau. Se espera que el soporte inicial de Gallium venga antes de la composición en EXA, ya que necesitaremos forzar que todos los pixmaps sean teselados, y tratar con los respaldos de software podría resultar realmente complicado. Gallium es más sencillo ya que debería haber muchos menos casos de respaldo de software. El dibujado siempre se hace en un buffer privado (incluso al dibujar en el buffer frontal) y copiado al buffer frontal real. Esperamos que el motor 2D de la NV50 sea capaz de realizar la copia de una superficie teselada a una no teselada. Esto todavía lo desconocemos.
Y, finalmente, un grupo de temas cortos:
- Marcheu ha terminado su prototipo de Gallium para NV10 y lo ha integrado en el repositorio. Ahora depende de otros el avanzar desde ahí.
- pq ha enviado su parche de MMioTrace para su inclusión en el kernel y su revisión (en estos momentos: 2.6.25 rc). Por favor, ayudadle a probar MMioTrace en vuestras máquinas, si podéis.
- Algunas causas más de bloqueos en PPC pudieron detectarse y solucionarse.
Desde hace un tiempo pq tiene problemas con las transferencias AGP (principalmente ImageFromCpu), que ahora han sido identificados y esperamos que también solucionados.
- Tras solucionar los problemas de inicialización en NV30, pmdata ha comenzado a trabajar en Gallium3D para NV30 y se asustó un poco con el asunto de las funciones de sombreado. Está pensando cambiarse a NV10.
- Además, p0g está de vuelta, trabajando en Galliumm para Novueau
3. Ayuda necesaria
Como siempre: consultad nuestra páginaTestersWanted .
pq necesita vuestra ayuda para probar MMioTrace. Por favor, ofreceos voluntarios solamente si estáis usando un kernel más reciente o igual a 2.6.25 rc. ¡También se agradecen las pruebas con SMP!
Stillunknown busca probadores de NV5x para verificar que su limpieza del código no ha estropeado nada. También ayudaría si probáis a cambiar desde y hacia la consola de texto usando el driver binario y MMioTrace. Preguntad a pq, Stillunknown o Malc0 por la ayuda que preciséis.
Creo que no lo mencionamos en los últimos números, pero agradeceríamos gustosamente más desarrolladores. Por favor, ofreceos si el estado actual de alguna tarjeta o funcionalidad os molesta
Y por último, pero no menos importante: por favor, probad Randr1.2 con nouveau. Cambiaremos a este código por defecto en cuanto no aparezcan nuevos problemas. Por favor, ¡recordad que si no se hacen pruebas los gatitos morirán!.