Informe irregular sobre el desarrollo de Nouveau

Edición del 14 de febrero de 2008

1. Introducción

Han pasado unas dos semanas y ha llegado el momento de otro TiNDC más, el número 35.

Como probablemente ya sabéis, estamos usando el sistema de seguimiento de fallos de FreeDesktop.org. Si os encontráis algún problema que no pueda solucionarse con ayuda en el IRC, por favor, añadid un informe de fallo, para que podamos hacer un seguimiento de los posibles fallos.

Si lo hacéis, también os pedimos:

• Echad un vistazo al canal, ya que las reacciones a vuestras preguntas pueden dilatarse considerablemente.
• Haced un seguimiento del informe de fallo en el sistema, para que podáis reaccionar a las cuestiones que puedan plantear los desarrolladores ante el mismo (tal vez soliciten más datos, realización de pruebas, parches, etc.)
• Realizad pruebas de forma regular (al menos una vez a la semana), para ver si el problema se ha solucionado.

Realizar un informe de fallo sin darle seguimiento no os servirá de mucha ayuda ni a vosotros ni a nosotros. ¡Necesitamos vuestra colaboración continuada!.

Cuando se comenzaron a publicar nuestros TiNDCs antes en Phoronix, nuestra intención era conseguir un poco más de publicidad. El wiki era leído por gente que ya nos conocía, pero el número de los que lo hacían permanecía estancado. Phoronix ya había mostrado interés en el proyecto, publicando algunas noticias sobre los TiNDCs y los cambios en Git.

Así que, de alguna manera, era (y todavía es) una combinación perfecta: conseguimos más proyección pública y Phoronix obtiene información directamente de la fuente. Esperamos que vosotros hayáis seguido informados y entretenidos en todo este tiempo.

Un par de semanas después de iniciar la colaboración, Phoronix se ofreció a ayudarnos, preguntando si nos vendría bien usar equipos que tenían sin uso. Para no quedar como maleducados, o como codiciosos, declinamos el ofrecimiento, ya que teníamos material suficiente para todo el abanico de tarjetas NVidia, con la excepción de las más caras.

En el siguiente intercambio de correos, sin embargo, se vio que algunos de nuestros desarrolladores trabajaban con equipos anticuados, mientras que Phoronix disponía de otros mejores que únicamente acumulaban polvo. Así que accedimos a enviar parte del material, como CPUs, placas base y RAM a Marcheu. Él los entregaría a los desarrolladores durante el FOSDEM, o enviaría el material directamente a los desarrolladores.

Así que, ¡MUCHAS GRACIAS! a Phoronix por su estimable apoyo.

A propósito del FOSDEM: estaremos allí al menos tres personas (Ahuillet, Malc0 y Marcheu). Yo también intentaré estar allí (KoalaBR) para cubrir el acontecimiento, tal como hice el año pasado, pero debido a algunos problemas de salud no creo que pueda ir.

2. Estado actual

Desde hace algún tiempo tenemos problemas con las tarjetas NV4x al intentar usar Nouveau tras eliminar el módulo binario. El problema ha sido diagnosticado por stillunknown: se debía a un registro desconocido, que usa el módulo binario (y nosotros ignorábamos). Tras fijar este registro a un valor por defecto de 0x01, todo se solucionó (cambio en git).

Marcheu publicó un lote de parches para el adaptador de texturas de Xv. Tal como mencionamos en el anterior número, estos:

• añadían filtrado bicúbico a la NV40 (NV30?)
• evitaban el 'rasgado'
• añadían un adaptador de texturas mediante shaders en la NV30

Al compararlas entre si existen algunas diferencias.

Desgracidamente, algunos tests mostraron que el nuevo filtro producía una imagen borrosa respecto a la que se obtenía con el blitter. Marcheu sospecha que se debe a algún error de precisión en su código y lo está investigando. Tuvimos también ahí un problema de ordenación (endianess) en PPC. Parece que siempre había gente azul por ahí. Marcheu solucionó el problema del adaptador de texturas en PPC intercambiando las partes U y V de vídeo.

Finalmente, las tarjetas NV34 parecen demasiado lentas para hacer uso de este adaptador. Por favor, usad en su lugar el blitter/overlay. Después de todo esto, él trabajará en Gallium3D para las tarjetas NV3x hasta que esté listo para pasarlo a otras manos capaces.

Malc0 y Stillunknown están preparándose para hacer que Randr1.2 sea el camino de código predeterminado en Nouveau. Para logarlo, crearon un 'Meta-informe de error' que hace un seguimiento de todos los informes de error relacionados con Randr1.2 que impiden el cambio (informe de error).

También ha habido algo de actividad en el frente de los PPC. Lo primero es que moondrake encontró una forma de evitar los problemas de bloqueo total que se producían en PPC. Se necesitaba sincronizar las FIFOs más a menudo al subir grandes cantidades de datos a la tarjeta. Kelnos verificó el parche de moondrake y comprobó que sus bloqueos también se habían esfumado.

Sin embargo, el parche resultó ser simplemente una forma de evitar el fallo real, que era la corrupción de la memoria. Esta se producía a causa del malfuncionamiento de AGP en el Powerbook para las escrituras. Benh y Marcheu se sumaron, aportando parches, aunque todavía no se ha logrado una solución definitiva. La última versión del parche de moondrake está aquí. Al investigar los problemas de PPC marcheu se percató de que el código de DDX para AGP en PPC era totalmente de locos.

Durante las pruebas, surgió la idea de comparar el valor de ciertos registros en Linux y OSX para ver en qué podían diferir. kelnos ofreció reducir su partición de Linux para instalar OSX. Apareció sbriblie, que ya tenía OSX funcionando en el mismo hardware y se ofreció a realizar las pruebas usando la herramienta radeontool de Airlied, para OSX, pero no logró hacerla funcionar.

Moondrake no se rindió e intentó diversos modos, desactivó el SBA (Direccionamiento de banda lateral) y finalmente evitó que se cargase uninorth-agp (un controlador para el northbridge usado por Apple). Esa fue la clave, haciendo desaparecer sus problemas de bloqueo y corrupción.

Además, Malc0 arregló el problema "la NV34 solamente funciona a la segunda", al encontrar el mismo problema en x86 (cambio en git).

Bien, y ahora la lista habitual de asuntos breves:

• jb17some sigue trabajando en la aceleración de XvMC. Resumió la situación actual en el Wiki

• Airlied hizo una presentación en la LCA, en donde charló sobre el estado actual de los controladores gráficos. Se rumorea que hizo una demostración de nuestro controlador Gallium3D. Pero, echád un vistazo aquí... (¡y cuidado con los gatitos!).
• pq está trabajando en la inclusión de MMioTrace en el kernel. Aunque está recibiendo ayuda de hackers del kernel como Ingo Molnar la tarea es mucho mayor de lo que se estimó inicialmente, así que, por ahora, apunta a su inclusión en la versión 2.6.26.
• Darktama está intentando averiguar algo más sobre la causa de que las visualizaciones 3D fallen completamente en NV5x.
• Y Darktama está barajando la posibilidad de crear un "generador de voodoo" (las secuencias de incialización), que podría permitir la creación de las secuencias de inicialización para los cambios de contexto de forma programática.

3. Ayuda necesaria

As always:

Como siempre:

• Echad un vistazo a nuestra página TestersWanted

• Comprobad la ausencia de regresiones en el código de randr1.2

Por favor, comprobad el arreglo del "uso tras el módulo binario" de Stillunknown en las NV4x. Y si encontráis bloqueos en NV4x (incluso mejor en NV40), contactad, por favor, con stillunknown.

Y, sí, los probadores con PPC son bienvenidos (también desarrolladores :)), así como los parches para BSD, ya que nadie se ha ofrecido tras nuestra petición y oferta de apoyo para esos usuarios en uno de nuestros últimos números.