Informe irregular sobre el desarrollo de Nouveau

Edición del 23 de diciembre

1. Introducción

Un poco más tarde de lo habitual ya está aquí el, probablemente, último número de este año: ¡damos la bienvenida al número 32 del TiNDC! :). Y, debido a las vacaciones, incluso más tarde que en Phoronix (¡lo sentimos!). El próximo número saldrá en unas 3 semanas.

En las últimas semanas el canal ha estado mucho más tranquilo de lo habitual. Algunos estamos muy ocupadon con la Vida Real (TM) y lo que se está desarrollando no se puede mostrar directamente, ya que nuestros desarrolladores bucean en una nueva zona llamada Gallium3D.

Por cierto: FOSDEM 2008 tendrá de nuevo una sala para desarrollo de XORG. Probablemente haremos un informe de cómo van las cosas desde allí, así como algo de desarrollo y ayuda a quienes quieran introducirse en el mundo del desarrollo de nouveau.

En cualquier caso, hasta 3 miembros del proyecto planean en estos momentos acudir al FOSDEM, y nos gustaría mucho que viniesen más. Así que, si puedes acercarte, no lo dudes.

Finalmente, IronPeter anunció que existe un driver acelerado de X11 para la PS3 (escrito por Glaurung), basándose en algo de código y en información de nuestro proyecto. Ahora están centrados en integrar funcionalidad 3D. Se puede consultar este hilo para mayor información (y el wiki mencionado en él): http://forums.ps2dev.org/viewtopic.php?t=8364&postdays=0&postorder=asc&start=150

Aunque parece que con el Firmware 2.10 ha dejado de funcionar correctamente. http://ps2dev.org/News/Is_Sony_blocking_3D_access%3F

2. Estado actual

Todavía tenemos informes de que PPC no funciona bien. Un ejemplo es la PictOpt A8+A8 en NV1x del que ya hablamos en números anteriores. Cuando jma volvió al canal, ahuillet se ofreció con algunos parches para probar. Los resultados no fueron sustancialmente mejores que los obtenidos hasta el momento. En resumen, la visualización de las fuentes está totalmente rota.

Tras debatirlo con marcheu, parece como si A8 en PPC esperase una palabra de 32bits (4 bytes) en el orden 03040102 en lugar de 04030201, que es lo que estamos usando en estos momentos. La opción de alterar el orden de los bytes así no gustó a ahuillet, que se quejó de que el código de los combinadores de registros se haría todavía más complicado de lo que ya es. Veremos que resulta de todo esto. El uso de un respaldo por software sería factible, pero tendría un impacto grande en el rendimiento de la visualización de fuentes con AA.

La mayor del trabajo realizado en las últimas semanas ha sido en el código de establecimiento de modo y de randr1.2. El código evoluciona rápidamente y a menudo funciona la doble salida (dual head) en tarjetas NV4x y, en menor medida, en NV3x. Sin embargo, no se ha realizado progreso alguno en fastidioso problema: "NV5x no regresa al modo texto".

Con todo, stillunknown afirma comprender ya cómo funciona el establecimiento de modo en las tarjetas NV3x y NV4x y espera dejar randr1.2 para DVI y VGA en buena forma. Se han hecho avances y cometido errores, pero, a pesar de algunos casos problemáticos, cada vez llegan más informes de éxito.

Malc0 mejoró su intérprete de la BIOS añadiendo algunos códigos de operación que faltaban y soporte para la interpretación de la tabla de inicialización de Bios que faltaba (llamada BIT, o Bios Init Table, que es el nuevo tipo de BIOS de NVidia). Todo este trabajo reveló más información sobre el código que hace uso de él, lo que ayudó bastante a stillunknown.

Con realimentación de AndrewR, MighMoS y muchos más, stillunknown ha ido mejorando, lento pero seguro, el código de randr1.2. Finalmente obtuvo informes de gente con NV3x, NV4x, de que casi todo lo referente al modo de clonado de dual head funcionaba, incluso cuando las resoluciones en las dos pantallas no coinciden. Es así tanto en salidas VGA como DVI, incluso con conexión en caliente. Dual link puede funcionar en tarjetas 7x00. Debido a que solamente han llegado un par de informes de éxito, no podemos todavía afirmar ¡Funciona!.

Stillunkown querría disponer de algunos probadores más para tarjetas 7x00, ya que parecen un poco más problemáticas.

No satisfecho con el alterior resultado, stillunknown decidió tantear la aceleración de la rotación. Parece que funciona en los casos de tarjetas NV10 a NV4E en los que ya funciona randr-1.2. Así que nos hacen falta más voluntarios para hacer pruebas de todos los aspectos de RandR1.2.

De acuerdo con Stillunknown, tus posibilidades son:

<stillunknown> El estado de las distintas tarjetas es: 6xxx muy bien 7xxx y 5xxx decente
<stillunknown> para geforce3/4, merece la pena probar, pero hay que tener suerte
<stillunknown> geforce1/2/4mx no han sido probadas, hasta donde sé(**)

(**) Editor: AVISO, AVISO, AVISO

Consulta Randr12 para ver las últimas novedades.

Thunderbird utilizó los datos aportados por los diligentes probadores del canal para crear un generador/calculadora de frecuencias de reloj. Crea pares válidos de memoria y GPU dentro de los límites permitidos por la BIOS. Tal vez más tarde podamos usarlo para hacer overclocking de las tarjetas NVidia con nouveau, sin miedo de dañarlas (hacer underclocking no es problemático). Overclocking todavía es problemático para las tarjetas que se inician con voltajes más bajos. Todavía no sabemos cómo programar eso, y, según dice Thunderbird, está muy ligado al caso particular de cada tarjeta.

Una comparación entre los valores de reloj generados por el driver binario y la versión de Thunderbird mostró algunas diferencias para casos extremos, pero, en la mayoría de los casos, los resultados calculados eran exactamente los mismos. Pero, puesto que Thunderbird no quiere poner en riesgo el hardware con valores incorrectamente calculados, todavía está mejorando su código y, por tanto, todavía no ha sido publicado.

En los últimos números nos hemos estado refiriendo a menudo al trabajo de Darktama en Gallium3D para las NV4x y NV5x, aunque avisamos que su trabajo no estaba publicado. Bien, ya lo está, pero, antes de que te desmayes porque ya existe un driver 3d libre para NVidia... ¡tranquilízate! :). Aunque funcionan muchas cosas, todavía muchas más no lo hacen (tanto en nuestra parte como en la de Gallium), no están implementadas, o contienen errores. Y no es rápido (comparado con el driver cerrado) pero, aún así, es más rápido que la visualización por software. En estos momentos no tenemos ninguna documentación para la instalación, por lo que estás a tu riesgo y ventura. Bien, parece que Darktama ha encontrado un culpable en nuestro código y está convencido de poder aumentar el rendimiento, pero todavía no ha acabado de implementar y probar el arreglo.

Solamente un par de ejmplos de lo que se puede esperar:

Google Earth:

Quake:

Este es un pantallazo imposible de la demo de quake 3 Arena. Darktama dice que el código debería haberse encontrado con una aserción (lo intentó en su sistema de desarrollo), con una salida inmediata del programa como resultado, pero el sistema de AndrewR de alguna manera parece saltársela...

El repositorio oficial de nouveau se encuentra aquí: http://gitweb.freedesktop.org/?p=nouveau/mesa.git;a=shortlog;h=gallium-0.1 Darktama tiene su propio repositorio de git, que usa como campo de pruebas y hace un seguimiento casi inmediato del oficial de "Gallium". Dado que Gallium está en continua evolución, eso significa que el código puede no funcionar. Las razones para ello pueden ser fallos en el propio Gallium, o funcionalidades defectuosas o sin implementar por nuestra parte. En algunas ocasiones Darktama está incluso arreglando fallos en el propio Gallium...

Algunas cuestiones breves:

• ahuillet ha echado un vistazo al establecimiento de modo para NV2x. Hizo algunas pruebas y trazados para Malc0 y stillunknown. Todavía no se ha decidido sobre sí hacer algo en ese tema o esperar a Marcheu y su plataforma Gallium3D.
• pmdata finalmente logró hacer funcionar las NV30 con EXA. Una extraña instrucción de nv30tcl 0x2b8 contiene valores x,y de viewport x,y y era necesario para el funcionamiento de nv30exa con nv30gl pero faltaba hasta que pmdata lo añadió.
• Nos acabamos de dar cuenta de que el script de JussiP busca los volcados en el directorio incorrecto, con lo que no se detecta las novedades y aparece totalmente desactualizado. Intentaremos modificar el script e informar sobre el estado del directorio de descargas correcto. De todos modos, ¡no se ha perdido ninguno de los volcados enviados!
• stillunknown está considerando implementar el video texturado usando shaders en NV4x. Eso mejoraría además nuestra implementación de XV, que no es para tirar cohetes.
• jb17some todavía trabaja en XvMC y realiza progresos lentamente. Tiene algo más de información sobre cómo se almacenan los datos de Luma (datos de blanco y negro) y Chroma (datos de color).
• Marcheu todavía trabaja en la separación del código de Xv en una parte genérica y otra para cada tarjeta.
• p0g informó sobre problemas con EXA en una NV1x, pero éxito con randr1.2 al usar un monitor. Los problemas se debían al trabajo de stillunknown en la rotación, que entraba en conflicto con el parche de ahuillet para A8+A8 (en cuanto a funcionalidades, no a nivel de código). Ya están solucionados.

3. Ayuda necesaria

Stillunknown y malc0 buscan voluntarios para hacer pruebas de su código para randr1.2 y sus herramientas (para obtener y comparar datos).

Y, como siempre, echad, por favor, un vistazo a la página de "Se busca ayuda" del wiki para las peticiones que surgan entre número y número del TiNDC. http://nouveau.freedesktop.org/wiki/TestersWanted