Informe irregular sobre el Desarrollo de Nouveau
Edición del 8 de agosto
Introducción
Han pasado poco más de dos semanas y los desarrolladores principales me han chantajeado para que escriba un nuevo TiNDC (si no escribes, nosotros tampoco escribimos código). Así que, por el bien de la comunidad, aquí vamos: TiNDC 25.
Ah, antes de empezar, quiero dar las gracias a ahuillet quien de nuevo se tomó el tiempo necesario para editar mi tosco borrador referido a los temas de Xv. Pero ahora...
Estado Actual
Se mantuvieron numerosos debates sobre cómo deshacerse de la espera bloqueante del notificador de DMA. Tras obtener algo de realimentación por parte de darktama, ajax, pq y marcheu, cristalizó una tendencia: evitar el TTM por el momento e implementar un sistema con 2 ioctl()s.
1. Disponer un nuevo número de marca (fence) (uint64_t siempre creciente) 2. Esperar al número de marca (fence) #,
asumiendo que las transferencias se hacen en-orden, y ya que el número de marca sería por FIFO, esto podría funcionar.
Debido a que el TTM no se adapta exactamente a nuestras necesidades (por ejemplo, a la gestión de FIFOs desde el espacio de usuario), parece cada vez más probable que nouveau use únicamente algunas funcionalidades concretas, mientras que se implementan otras partes privadamente.
Puesto que el TTM necesita funcionar en un gran número de tarjetas, incluso funciona con las más 'tontas'. Debido a que las tarjetas de NVidia ya han implementado la mayor parte de la funcionalidad a través del hardware, gran parte del código del TTM es en realidad una sobrecarga para nosotros.
Esta decisión no tuvo buena acogida por parte de airlied (el mantenedor del DRM), que quiere únicamente un gestor de memoria (un TTM revisado, si es preciso) en el árbol. La discusión continuó en #dri-devel (http://dri.egore911.de/index.php?date=2007-07-26) con opiniones válidas desde ambas posturas. La decisión final es que migraremos al TTM pero, ya que este no es estable, no está siendo usado por los drivers actuales (como mucho hay dos drivers que usen el TTM o que trabajen con él: Radeon e Intel), y le falta funcionalidad para nouveau, trabajaremos con la gente del TTM para que éste se adapte a nuestras necesidades mientras añadiremos soluciones provisionales por el momento, de forma que nouveau funcione.
Para evitar este campo minado de debate "político", ahuillet cambió sus prioridades al vuelo e intentó implementar el doble buffer. Antes de que pasasen 24 horas solicitó gente que hiciese pruebas.
Para complicarlo todo un poco más, darktama trabajó en la integración del TTM en nouveau. Preparó un parche y lo envió a dri-devel para su supervisión, ya que modificaba algunas partes del TTM para adaptarlo mejor a nuestras necesidades. Mientras esperaba los comentarios se comenzó la discusión antes mencionada.
También se continuó el trabajo en Xv, al escribir p0g algunos tests para averiguar algo más sobre cómo manejan las tarjetas los datos de imagen YV12.
Tras echar un vistazo durante un tiempo a los resutados de p0g, él, pq, ahuillet y marcheu llegaron a la conclusión de que el formato nativo era nv12 (ese es un formato de codificación/visualización, no una tarjeta de NVidia. Véase el enlace "VUY Formats en www.fourcc.org/). Además, los datos que se iban a mostrar se cargaban en la tarjeta a través de la FIFO, y no a través de una transferencia DMA. Por lo que se hicieron algunos tests más para averiguar porqué y qué tipo de ventaja de rendimiento nos podría proporcionar. Todavía estamos pendientes de los resultados.
Otro tema interesante en Xv es el objeto de superposición (overlay). Tras un trabajo inicial en Xv que lo hacía funcionar pero que no proporcionaba una mejora del rendimiento tan sustancial como se esperaba, p0g y ahuillet intentaron realizar ingeniería inversa sobre cómo la tarjeta usa la superposición (overlay). Usaron trazas de valgrind-mmt y averiguaron de qué objeto se trataba y cómo controlar la mayor parte de sus atributos.
El objeto de superposición (overlay) no es un objeto normal, como los objetos NV30_TCL_PRIMITIVE_3D o los objetos PCI / AGP mencionados en números anteriores. Es un objeto software, lo que significa que si se escribe un valor en un desplazamiento concreto del objeto, la tarjeta generará una interrupción que será gestionada por el módulo del kernel. El módulo del kernel debe mirar el valor escrito y ejecutar una función asignada a dicho valor. Entonces, la función escribirá/gestionará los registros MMIO que llevarán a cabo la funcionalidad deseada a la pantalla. Dado que ese no era el tema que ahuillet estaba indagando / esperando, el esfuerzo se trasladó a otros asuntos.
Pero, a partir del trabajo en la superposición (que implicaba trazas de MMIO) marcheu y ahuillet llegaron a la conclusión de que podríamos dar soporte nativo a YV12 (de hecho, NV12, pero la conversión es sencilla...) simplemente estableciendo los mismos valores de los registros que en el caso de la superposición. Al final no resultó ser tan sencillo. Fijar los dos bits obtuvo resultados, e hizo creer a ahuillet que habíamos dado en el clavo, pero la depuración de imágenes mal mostradas no es tan fácil, con lo que llevó varias horas estar un 80% seguros de que el bit no era una señal de "NV12 nativo", sino algún parámetro de conversión YUV->RGB.
Por lo que, en estos momentos, podemos decir: para todas las tarjetas <NV50, tenemos en funcionamiento una versión de Xv con un rendimiento ligeramente mejor que la anterior. Marcheu y ahuillet realizaron algunas mediciones y lo interesante es: Xv es bastante rápido para un frame concreto, pero cuando mplayer muestra los frames, muestra también algunos contadores en pantalla, que disparan algunas operaciones 2D que, a su vez, hacen que se produzca la sincronización de todo ello, incluída la transferencia de Xv.
En relación a renouveau: pmdata está todavía intentando partir renouveau en un volcador y un intérprete. Ha tenido éxito en la creación de volcados que únicamente contienen valores de la memoria comprobada y que se pueden pasar por un intérprete que obtiene un volcado tal como lo conocemos en estos momentos. Todavía falta por conseguir la plataforma xml.
pq biseccionó otro problema importante y que no era nada fácil: al ver 2 vídeos con Xv en nouveau, la cola DMA se colgaría tarde o temprano (tras, como mucho, 10 minutos). Ya que nv no presentaba este problem, localizó el problema en un cambio combinado al DDX y el DRM ( https://bugs.freedesktop.org/show_bug.cgi?id=11820)
Durante el fin de semana airlied trabajo algo sobre PPC. Tras algunos problemas debidos a un nouveau_drm.h desactualizado, logró hacer funcionar de nuevo glxgears en su G5. Sin embargo, el color todavía es incorrecto (negro), aunque eso es mucho mejor que la falta de funcionamiento.
Además, airlied hizo funcionar renouveau en MacOS X, para poder obtener información sobre el manejo de las tarjetas de NVidia también en PPC.
"Probablemente necesito simplificar partes significativas de renouveau con un hacha..." Airlied sobrecogido por un diseño brillante que facilita el portado
Además del trabajo de ahuillet con Xv, jb17some trabajó algo en el XvMC. Está bastante seguro de que ha encontrado cómo se transfieren los datos a la tarjeta y cómo se modifican antes de la transferencia final. Un resumen más actualizado de sus averiguaciones están disponibles en el wiki, aquí http://nouveau.freedesktop.org/wiki/jb17bsome .
Marcheu y Darktama también solucionaron algunos asuntos: Actualizaron la versión del DRM a la 0.0.10, que eliminó la carga de la escritura de la gestión de subcanales del driver al DRM. El DRM obtuvo también su propio subcanal que en estos momentos está inutilizado. Sin embargo, es necesario para los próximos cambios para hacer funcionar el TTM con nouveau. Y eso concluye la historia anterior sobre si usar o no el TTM.
"Un canal es simplemente una cola FIFO con su contexto gráfico. Cada una de las FIFOs tiene 8 subcanales, elementos que contienen una instrucción para que sea ejecutada por la tarjeta y que se ejecutan consecutivamente."
Ahora, ¿por qué necesita el DRM su propio FIFO? Bien, en el futuro el TTM gestionará la memoria de la tarjeta. La filosofía del TTM es que el DRM posee los bloques de memoria y los coloca como quiere, por lo que debe ser capaz de mover las cosas para, por ejemplo, evitar la fragmentación dela memoria. Así, necesitas ser capaz de realizar DMA, y para ello se necesita el objeto DMA del que hablamos en los números anteriores. Y para ello necesitamos una FIFO.
El próximo asunto en la lista de tareas pendientes de Marcheu es arreglar la funcionalidad "cargar en pantalla" de las tarjetas NV3x y luego extender la funcionalidad EXA de nv40 a las NV3x. Tras eso, es probable que venga el trabajo en dual head (doble salida de video). El orden en el que se implementan las funcionalidades se debe en parte al interés que suscitan y en parte al progreso del TTM (véase antes). Actualmente, el estado del TTM hace árduo el trabajo en 3D. Por lo que cosas "más fáciles" como el rendimiento en 2D se ejecutan antes.
Sin embargo, el uso de subcanales precisa de cambios de contexto funcionales, y algunas tarjetas (NV1x and NV2x) tienen problemas, como cuelgues de la cola de DMA al iniciar las X. Es necesario trabajar más en ello (¡bienvenida la ayuda haciendo pruebas!), pero parece que el trabajo en el cambio de contexto en esas tarjetas no está funcionando del todo.
Y como suele ser habitual cuando todo está roto, matc viene al rescate. Esta vez se dió cuenta de que no inicializábamos correctamente las interrupciones en las tarjetas NV3x (bien, lo hacemos al principio, pero los siguientes procedimientos de inicialización necesitan desactivarlas de nuevo y no las volvemos a activar más adelante.
Help needed
Ahuillet solicita pruebas de su código para Xv. Aparte de compilar e instalar nouveau, esto únicamente implica el visionado de vídeos e informar del resultado 
Querríamos que quienes tengan tarjetas 8800 prueben nuestro driver actual e informen de cómo funciona. Ya que "únicamente" tenemos dos tarjetas G84 para hacer el desarrollo y las pruebas, se agradece mucho la información que se pueda dar del funcionamiento de estas tarjetas. Advertencia: usa la rama randr-1.2 e informa a Darktama.
Como se mencionó más arriga, necesitamos trazas de MMio para NV41, NV42, NV44,NV45, NV47,NV48 y NV4C. Por favor, hazte notar en el canal.
Finalmente, una corrección al número de accesos publicado la semana pasada. Estaba equivocado, ya que mis estadísticas muestran accesos totales, y no referencias. Por lo que el número de accesos era tres veces más grande!. En estos momentos estamos en torno a los 2200 accesos para el número #23.