Informe irregular sobre el desarrollo de Nouveau

Edición del 30 de mayo

1. Introducción

Aquí estamos de nuevo. El número 34 vuelve para vuestro placer. Muchas gracias por vuestro interés continuado en nuestro controlador y el TiNDC.

Como demostración de lo importantes que son para nosotros las pruebas de funcionamiento, tanto rindolf como AndrewR informaron sobre algunas regresiones en los últimos 14 días. Rindolf encontró problemas con los jitter tras largos periodos en las X, mientras que AndrewR tuvo un kernel panic. Ambos problemas se introdujeron alrededor de una semana antes de que se informase sobre elllos, lo que permitió localizar el parche problemático con bastante facilidad.

Así, incluso cuando no se hayan anunciado correcciones o mejoras para vuestra tarjeta, por favor haced alguna prueba de funcionamiento al menos una vez a la semana para asegurarnos de que todo sigue funcionando correctamente.

En las últimas semanas se debatió sobre si deberíamos trabajar en sacar una versión sólo de 2D. Hubo partidarios y detractores de la medida, se intercambiarion opiniones, y se pospuso la decisión :).

Argumentos a favor:

• Las distribuciones podrían iniciar la distribución sin muchos problemas
• Conseguiríamos más probadores y usarios.
• Haría patente el hecho de que estamos avanzando a buen ritmo y que logramos cierto éxito (respecto a los resultados apreciables por los usuarios finales).
• Mejor hacer una versión previa al ofrecimiento de 3D. Las funcionalidades 3D nos traerán una gran cantidad de probadores y usuarios y, en combinación con el 2D, puede sobrepasarnos.
• release early, release often

Contra-argumentos:

• El soporte de NV5x no es lo suficientemente bueno
• Todavía no queremos dar soporte a una interfaz estable del DRM (que sería necesario para la integración en las distribuciones), ya que serán al menos necesarios dos cambios más (para el establecimiento de modo y el TTM)

• RandR1.2 todavía no está suficientemente rematado.

• No necesitamos una gran cantidad adicional de probadores y usuarios en estos momentos, sino probadores dedicados que estén interesados en resolver problemas específicos, que es lo que tenemos ahora.

Ya que cada posición tiene puntos válidos, no se llegó a una decisión final. Por lo que decidimos esperar un par de semanas más y discutir nuestras opciones en el FOSDEM, el próximo mes.

Y para que quede constancia: No, no se nos ha aproximado NVidia ofreciendo especificaciones (y, para ser honestos, tampoco lo esperamos).

2. Estado actual

Parece que MMioTrace seguirá sin funcionar en el kernel 2.6.24 ya que el hacker del kernel implicado no pretende recuperar los enlaces necesarios. Las buenas noticias vienen del hecho de que pq está empezando a trabajar en la integración de MMioTrace en el kernel estándar y está siendo ayudado por ese hacker del kernel para localizar las funcionalidades equivalentes a las que fueron eliminadas. Hay consenso sobre la utilidad de una herramienta como MMioTrace en el kernel estándar.

Si todo sale bien, veremos MMioTrace en marcha en la versión 2.6.25 o 2.6.26 en adelante.

Stillunknown añadió un sistema experimental de restauración del modo de vídeo que se puede activar usando el valor "true" en la opción "NewRestore". AndrewR no dudó en probarlo, aportando información inmediatamente a stillunknown. Los resultados fueron variados, ya que para algunos funcionaba, mientras que para otros no. Stillunknown reaccionó añadiendo al menos dos correcciones a su código.

• 

• Perturbaciones del adaptador de texturas

Todavía no cansado de añadir funcionalidades a Nouveau, stillunknown hizo algunas pruebas con el adaptador de texturas y vio que se producian algunas perturbaciones y roturas de la imagen en su tarjeta. Tras comentarlo con Marcheu y Ahuillet, además de algunas pruebas más, descubrió que el driver binario muestra los cuadriláteros 2D grandes (mayores a 512x512 píxeles, aproximadamente) mostrando un triángulo mayor y realizando el recorte para hacer la visualización ajustada al cuadrilátero necesario. Esto tiene el efecto de realizar la visualización de arriba-hacia-abajo (en lugar de la teselación en dos triángulos que tiene lugar cuando se solicita directamente a la tarjeta la visualización de un cuadrilátero), lo que suprime los recortes (tearing). Implementó dicha estrategia para el adaptador de texturas de las NV40 y la visualización resultó correcta. (http://gitweb.freedesktop.org/?p=nouveau/xf86-video-nouveau.git;a=commit;h=d9149bddc758cc0644630b26fe10fc563ba38ce9)

• 

Visualización correcta

Pensando algo más sobre este asunto, llegó a la idea de aplicar este método también EXA para NV40. Funcionó de maravilla y debería eliminar también los recortes (tearing) en eXA, aunque nadie se había quejado por ello hasta el momento. http://gitweb.freedesktop.org/?p=nouveau/xf86-video-nouveau.git;a=commit;h=71435dde5b2fd1c197ef5dc31b22ba40abcbca7e

Tras el parón de las vacaciones, algunos de nuestros anteriores probadores volvieron y anunciaron cómo les iban las cosas. chownmeined anunció que el código normal y el RandR1.2 funcionaba perfectamente. seventhguardian anunció una regresión al iniciar las X: la pantalla permanecía negra. Stillunknown localizó el fallo y subió una corrección que arregló el problema para seventhguardian. Darktama todavía tiene problemas con su portátil y Nouveau. La pantalla se queda negra. Algunas correcciones aportadas por Malc0 lograron al menos que funcionase la retroiluminación, pero la pantalla seguía negra. Así que se hizo necesaria una sesión de depuración, lo que proporcionó a malc0 algunos datos más sobre los que reflexionar. Todavía falta encontrar una solución.

Además, Malc0 mejoró el intérprete de la BIOS para las tarjetasNV4x, ya que éstas pueden mostrar algunos códigos de operación que todavía no son manejados por nuestro intérprete.

SeventhGuardian trabajó algo más en la detección de la salida de TV tras charlar con Thunderbird, malc0 y stillunknown. Los primeros intentos resultron en la detección aleatoria, pero tras pelearse un poco más con el asunto, al final localizó los registros que deben activarse y qué información devuelve la tarjeta. Así que ahora tenemos funcionando la detección de carga. La "carga" en esto caso se refiere a una línea conectada, bien sea VGA, TV-OUT, DVI, etc. Resumió sus hallazgos en nuestro wiki: http://nouveau.freedesktop.org/wiki/Load_Detection

SeventhGuardian pretende comenzar a trabajar en la salida de TV ahora.

Y ahora, nuestra retahila habitual de temas cortos:

• Marcheu ha implementado el filtrado bicúbico para el adaptador de texturas de las NV40, eliminando todas las distorsiones existentes. El código todavía no se ha integrado, pero debería estarlo pronto.
• Marcheu traducirá seguidamente este código a la NV30. Esta experiencia es necesaria para terminar la plataforma Gallium 3D para tarjetas antiguas. Y luego ya se puede empezar con el trabajo de acelerar el 3D para las tarjetas más antiguas.
• Tras un par de días de trastear, pq consiguió hacer funcionar MMioTrace en un kernel 2.6.24.rc7. Así que está en el buen camino para conseguir enviar su módulo para la inclusión a la LKLM (lista del kernel). Aunque todavía queda trabajo por hacer, es necesario recoger los comentarios de la lista, etc...

• Darktama ha adoptado una nueva estrategia en el IRC: quedarse quieto, sin moverse. Y en caso de que alguien tenga un problema con el driver, simplemente hacer un comentario de una línea de cómo resolverlo (incluso si no se trata de una NV5x o NV4x) y luego regresar al modo inmóvil (ocurrió al menos dos veces )

• Darktama advirtió algunos problemas en las NV4x respecto a cómo manejamos los contextos. Tiene sospechas de cómo solucionarlo, pero necesita más registros de MMioTrace de NV4x.

• Pmdata empezó solucionando los problemas que teníamos con la incialización de la vista (viewport) en las tarjetas NV30, pero su solución hizo que fallasen las otras tarjetas NV3x. Parece que Stillunknown localizó el culpable y lo arregló: http://gitweb.freedesktop.org/?p=nouveau/xf86-video-nouveau.git;a=commit;h=9f932eb684814e2a04c83d5aee172b9e020d82a3

Tuvimos algunas quejas de que el difuminado en las pantallas planas era incorrecto (hughsie, egn and tango_). Malc0 dijo que Nouveau usa los mismos valores que NV en los registros de difuminado, pero no los mismos que el driver privativo. Sospecha que NV usa valores por defecto (seguros) mientras que el driver binario usa valores que se ajustan al tipo de tarjeta. Algunas pruebas rápidas hechas por hughsie y tango con radeontool (rama nvidia) y los valores del driver binario confirmaron estas sospechas. La solución, mientras que funcionó para hughsie no lo hizo para tango.

Radeontool es otra herramienta para la lectura de los registros MMIO. Se desarrolló originalmente para radeon, pero también tiene una rama de desarrollo para tarjetas NVidia.

Tuvimos algunos informes sobre la lentitud del 2D de las NV1x. Parece que es una regresión y estamos intentando localizar qué la produjo exactamente.

Y, finalmente, un poco más de información sobre el estado de nuestro código Gallium. Como ya mencionamos, darktama está trabajando en ello para NV4x. Básicamente funciona, aunque tiene algún código ah-hoc que impide que funcione bien en todas las situaciones. Solucionarlo llevará algún tiempo. La buena noticia es que Nouveau 3D es mucho más rápido que la versión software (softpipe).

3. Ayuda necesaria

Como siempre:

• Echad un vistazo en la página TestersWanted .

• Comprobad la existencia de regresiones en el código RandR1.2

Además:

• Enviad trazas MMio de tarjetas NV4x (que deberían ser las tarjetas 6x00 y 7x00). Y si lo hacéis, por favor haced funcionar una aplicación 3D que os guste (decid cuál en el correo), por lo menos glxgears.

• Estamos buscando gente que puebe el código RandR1.2, especialmente en NV04. Por favor, probad e informad de los resultados a Malc0.

Ya que el código RandR1.2 cambia a menudo, haced las pruebas a menudo. Indicad las regresiones también a malc0 y stillunknown, si os encontráis con ellas.