La Infraestructura de Representación Directa ( DRI ) es el marco que comprende la pila de gráficos moderna de Linux que permite a los programas de espacio de usuario sin privilegios emitir comandos al hardware de gráficos sin entrar en conflicto con otros programas. [6] El uso principal de DRI es proporcionar aceleración de hardware para la implementación de Mesa de OpenGL . DRI también se ha adaptado para proporcionar aceleración de OpenGL en una consola de búfer de cuadros sin un servidor de pantalla en ejecución. [7]
La implementación de DRI está distribuida a través del servidor X y sus bibliotecas de cliente asociadas, Mesa 3D y el subsistema de kernel Direct Rendering Manager . [6] Todo su código fuente es software libre .
En la arquitectura clásica del sistema X Window, el servidor X es el único proceso con acceso exclusivo al hardware gráfico y, por lo tanto, el que realiza la renderización real en el framebuffer . Todo lo que hacen los clientes X es comunicarse con el servidor X para enviar comandos de renderización. Esos comandos son independientes del hardware, lo que significa que el protocolo X11 proporciona una API que abstrae el dispositivo gráfico, de modo que los clientes X no necesitan saber ni preocuparse por los detalles específicos del hardware subyacente. Cualquier código específico del hardware se encuentra dentro del Device Dependent X , la parte del servidor X que administra cada tipo de tarjeta de video o adaptador gráfico y que también suele denominarse controlador de video o gráfico .
El auge de la renderización 3D ha mostrado los límites de esta arquitectura. Las aplicaciones de gráficos 3D tienden a producir grandes cantidades de comandos y datos, todos los cuales deben enviarse al servidor X para su renderización. A medida que aumentaba la cantidad de comunicación entre procesos (IPC) entre el cliente X y el servidor X, el rendimiento de la renderización 3D se vio afectado hasta el punto de que los desarrolladores del controlador X concluyeron que, para aprovechar las capacidades del hardware 3D de las últimas tarjetas gráficas, se necesitaba una nueva arquitectura sin IPC. Los clientes X deberían tener acceso directo al hardware gráfico en lugar de depender de otro proceso para hacerlo, ahorrando así toda la sobrecarga de IPC. Este enfoque se denomina "renderización directa", en contraposición a la "renderización indirecta" que proporciona la arquitectura X clásica. La infraestructura de renderización directa se desarrolló inicialmente para permitir que cualquier cliente X realizara renderización 3D utilizando este enfoque de "renderización directa".
Nada impide que se utilice DRI para implementar una renderización directa 2D acelerada dentro de un cliente X. [3] Simplemente nadie ha tenido la necesidad de hacerlo porque el rendimiento de la renderización indirecta 2D era lo suficientemente bueno.
La arquitectura básica de la infraestructura de renderizado directo implica tres componentes principales: [8]
En la arquitectura DRI original, debido al tamaño de la memoria de las tarjetas de video en ese momento, había una sola instancia del búfer frontal de la pantalla y del búfer posterior (también del búfer de profundidad auxiliar y del búfer de esténcil ), compartido por todos los clientes DRI y el servidor X. [11] [12] Todos ellos se renderizaban directamente en el búfer posterior, que se intercambiaba con el búfer frontal en el intervalo de tiempo de borrado vertical . [11] Para renderizar en el búfer posterior, un proceso DRI debe asegurarse de que la renderización se recorte al área reservada para su ventana . [11] [12]
La sincronización con el servidor X se hacía a través de señales y un buffer de memoria compartida llamado SAREA. [12] El acceso al dispositivo DRM era exclusivo, por lo que cualquier cliente DRI tenía que bloquearlo al comienzo de una operación de renderizado . Otros usuarios del dispositivo —incluido el servidor X— quedaban bloqueados mientras tanto, y tenían que esperar hasta que el bloqueo se liberara al final de la operación de renderizado actual, incluso si no hubiera ningún conflicto entre ambas operaciones. [12] Otro inconveniente era que las operaciones no conservaban las asignaciones de memoria después de que el proceso DRI actual liberara su bloqueo en el dispositivo, por lo que cualquier dato cargado en la memoria gráfica, como texturas, se perdía para las operaciones siguientes, lo que causaba un impacto significativo en el rendimiento gráfico.
Hoy en día el DRI1 se considera completamente obsoleto y no debe utilizarse.
Debido a la creciente popularidad de los administradores de ventanas de composición como Compiz , la Infraestructura de Renderizado Directo tuvo que ser rediseñada para que los clientes X también pudieran soportar la redirección a "mapas de píxeles fuera de pantalla" mientras realizaban el renderizado directo. Los clientes X regulares ya respetaban la redirección a un mapa de píxeles separado proporcionado por el Servidor X como un objetivo de renderizado —el llamado mapa de píxeles fuera de pantalla—, pero los clientes DRI continuaron haciendo el renderizado directamente en el backbuffer compartido, evitando efectivamente el administrador de ventanas de composición. [11] [13] La solución final fue cambiar la forma en que DRI manejaba los buffers de renderizado, lo que llevó a una extensión DRI completamente diferente con un nuevo conjunto de operaciones, y también cambios importantes en el Direct Rendering Manager . [3] La nueva extensión se denominó "DRI2", aunque no es una versión posterior sino una extensión diferente ni siquiera compatible con el DRI original —de hecho, ambos han coexistido dentro del Servidor X durante mucho tiempo.
En DRI2, en lugar de un único búfer (posterior) compartido, cada cliente DRI obtiene su propio búfer posterior privado [11] [12] —junto con sus búferes de profundidad y esténcil asociados— para renderizar el contenido de su ventana utilizando la aceleración de hardware . El cliente DRI luego lo intercambia con un " búfer frontal " falso , [12] que es utilizado por el administrador de ventanas de composición como una de las fuentes para componer (construir) el búfer posterior de pantalla final que se intercambiará en el intervalo VBLANK con el búfer frontal real.
Para manejar todos estos nuevos buffers, el Direct Rendering Manager tuvo que incorporar una nueva funcionalidad, específicamente un administrador de memoria gráfica . DRI2 se desarrolló inicialmente utilizando el administrador de memoria experimental TTM , [11] [13] pero luego se reescribió para utilizar GEM después de que fuera elegido como el administrador de memoria DRM definitivo. [14] El nuevo modelo de administración de buffer interno de DRI2 también resolvió dos cuellos de botella de rendimiento importantes presentes en la implementación original de DRI:
En DRI2, la asignación de los buffers privados fuera de pantalla (buffer trasero, buffer frontal falso, buffer de profundidad, buffer de esténcil, ...) para una ventana la realiza el propio servidor X. [15] [16] Los clientes DRI recuperan esos buffers para realizar la renderización en la ventana llamando a operaciones como DRI2GetBuffers y DRI2GetBuffersWithFormat disponibles en la extensión DRI2. [3] Internamente, DRI2 utiliza nombres GEM —un tipo de identificador global proporcionado por la API GEM que permite que dos procesos que acceden a un dispositivo DRM se refieran al mismo buffer— para pasar "referencias" a esos buffers a través del protocolo X11 . [16] La razón por la que el servidor X está a cargo de la asignación de buffers de los buffers de renderizado de una ventana es que la extensión GLX permite que varios clientes X realicen la renderización OpenGL de forma cooperativa en la misma ventana. [15] De esta forma, el servidor X gestiona todo el ciclo de vida de los buffers de renderizado a lo largo de todo el proceso de renderizado y sabe cuándo puede reciclarlos o descartarlos de forma segura. Cuando se realiza un cambio de tamaño de ventana, el servidor X también es responsable de asignar nuevos buffers de renderizado que coincidan con el nuevo tamaño de ventana y notificar el cambio a los clientes DRI que renderizan en la ventana mediante un evento InvalidateBuffers, para que recuperen los nombres GEM de los nuevos buffers. [15]
La extensión DRI2 proporciona otras operaciones básicas para los clientes DRI, como averiguar qué dispositivo DRM y controlador deben usar ( DRI2Connect ) o autenticarse en el servidor X para poder usar las funciones de renderizado y buffer del dispositivo DRM ( DRI2Authenticate ). [3] La presentación de los buffers renderizados en la pantalla se realiza utilizando las solicitudes DRI2CopyRegion y DRI2SwapBuffers . DRI2CopyRegion se puede utilizar para hacer una copia entre el buffer frontal falso y el buffer frontal real, pero no proporciona ninguna sincronización con el intervalo de borrado vertical, por lo que puede causar tearing . DRI2SwapBuffers , por otro lado, realiza un intercambio sincronizado con VBLANK entre el buffer frontal y posterior, si es compatible y ambos buffers tienen el mismo tamaño, o una copia ( blit ) en caso contrario. [3] [15]
Aunque DRI2 fue una mejora significativa respecto del DRI original, la nueva extensión también introdujo algunos problemas nuevos. [15] [16] En 2013, se desarrolló una tercera iteración de la Infraestructura de Representación Directa conocida como DRI3 para solucionar esos problemas. [17]
Las principales diferencias de DRI3 respecto a DRI2 son:
La asignación de buffers en el lado del cliente rompe con los supuestos de GLX en el sentido de que ya no es posible que varias aplicaciones GLX rendericen de forma cooperativa en la misma ventana. En el lado positivo, el hecho de que el cliente DRI esté a cargo de sus propios buffers durante toda su vida útil trae consigo muchas ventajas. Por ejemplo, es fácil para el cliente DRI3 asegurarse de que el tamaño de los buffers de renderización coincida siempre con el tamaño actual de la ventana y, por lo tanto, eliminar los artefactos debidos a la falta de sincronización de los tamaños de buffer entre el cliente y el servidor que plagaban el cambio de tamaño de la ventana en DRI2. [15] [16] [18] También se logra un mejor rendimiento porque ahora los clientes DRI3 se ahorran el viaje de ida y vuelta adicional esperando a que el servidor X envíe los buffers de renderización. [16] Los clientes DRI3, y especialmente los administradores de ventanas compositores, pueden aprovechar la ventaja de mantener buffers más antiguos de fotogramas anteriores y reutilizarlos como base sobre la cual renderizar solo las partes dañadas de una ventana como otra optimización del rendimiento. [15] [16] La extensión DRI3 ya no necesita ser modificada para soportar nuevos formatos de buffer particulares, ya que ahora son manejados directamente entre el controlador del cliente DRI y el controlador del kernel DRM. [15] El uso de descriptores de archivos, por otro lado, permite al kernel realizar una limpieza segura de cualquier objeto de buffer GEM no utilizado —uno que no tenga referencia a él. [15] [16]
Técnicamente, DRI3 consta de dos extensiones diferentes, la extensión "DRI3" y la extensión "Present". [17] [19] El propósito principal de la extensión DRI3 es implementar el mecanismo para compartir buffers renderizados directos entre los clientes DRI y el servidor X. [18] [19] [20] Los clientes DRI asignan y usan objetos de buffers GEM como objetivos de renderizado, mientras que el servidor X representa estos buffers de renderizado usando un tipo de objeto X11 llamado "pixmap". DRI3 proporciona dos operaciones, DRI3PixmapFromBuffer y DRI3BufferFromPixmap , una para crear un pixmap (en el "espacio del servidor X") a partir de un objeto de buffer GEM (en el "espacio del cliente DRI"), y la otra para hacer lo inverso y obtener un objeto de buffer GEM a partir de un pixmap X. [18] [19] [20] En estas operaciones DRI3, los objetos de buffer GEM se pasan como descriptores de archivo DMA-BUF en lugar de nombres GEM. DRI3 también proporciona una manera de compartir objetos de sincronización entre el cliente DRI y el servidor X, permitiendo a ambos un acceso serializado al buffer compartido. [19] A diferencia de DRI2, la operación inicial DRI3Open (la primera que cada cliente DRI debe solicitar para saber qué dispositivo DRM usar) devuelve un descriptor de archivo ya abierto al nodo del dispositivo en lugar del nombre de archivo del nodo del dispositivo, con cualquier procedimiento de autenticación requerido ya realizado de antemano por el servidor X. [18] [19]
DRI3 no proporciona ningún mecanismo para mostrar los buffers renderizados en la pantalla, sino que se basa en otra extensión, la extensión Present , para hacerlo. [20] Present se llama así porque su tarea principal es "presentar" buffers en la pantalla, lo que significa que maneja la actualización del framebuffer utilizando el contenido de los buffers renderizados entregados por las aplicaciones cliente. [19] Las actualizaciones de pantalla deben realizarse en el momento adecuado, normalmente durante el intervalo VBLANK para evitar artefactos de visualización como el tearing . Present también maneja la sincronización de las actualizaciones de pantalla con el intervalo VBLANK. [21] También mantiene al cliente X informado sobre el instante en que cada buffer se muestra realmente en la pantalla utilizando eventos, por lo que el cliente puede sincronizar su proceso de renderizado con la frecuencia de actualización de pantalla actual.
Present acepta cualquier mapa de píxeles X como fuente para una actualización de pantalla. [21] Dado que los mapas de píxeles son objetos X estándar, Present puede ser utilizado no solo por clientes DRI3 que realicen renderización directa, sino también por cualquier cliente X que renderice un mapa de píxeles por cualquier medio. [18] Por ejemplo, la mayoría de las aplicaciones GTK+ y Qt existentes no basadas en GL solían realizar renderización de mapas de píxeles con doble búfer utilizando XRender . La extensión Present también puede ser utilizada por estas aplicaciones para lograr actualizaciones de pantalla eficientes y sin cortes. Esta es la razón por la que Present se desarrolló como una extensión independiente separada en lugar de ser parte de DRI3. [18]
Además de permitir que los clientes que no son GL X se sincronicen con VBLANK, Present ofrece otras ventajas. El rendimiento gráfico de DRI3 es mejor porque Present es más eficiente que DRI2 en el intercambio de búferes. [19] Varias extensiones OpenGL que no estaban disponibles con DRI2 ahora son compatibles gracias a las nuevas características que ofrece Present. [19]
Present proporciona dos operaciones principales a los clientes X: actualizar una región de una ventana usando parte o todo el contenido de un mapa de píxeles ( PresentPixmap ) y establecer el tipo de eventos de presentación relacionados con una cierta ventana sobre los que el cliente quiere ser notificado ( PresentSelectInput ). [19] [21] Hay tres eventos de presentación sobre los que una ventana puede notificar a un cliente X: cuando una operación de presentación en curso —normalmente de una llamada a PresentPixmap — se ha completado ( PresentCompleteNotify ), cuando un mapa de píxeles usado por una operación PresentPixmap está listo para ser reutilizado ( PresentIdleNotify ) y cuando la configuración de la ventana —principalmente el tamaño de la ventana— cambia ( PresentConfigureNotify ). [19] [21] Si una operación PresentPixmap realiza una copia directa ( blit ) en el búfer frontal o un intercambio de todo el búfer posterior con el búfer frontal es un detalle interno de la implementación de la extensión Present, en lugar de una elección explícita del cliente X como era en DRI2.
Se han escrito varios controladores DRI de código abierto, incluidos los de ATI Mach64, ATI Rage128, ATI Radeon, 3dfx Voodoo3 a Voodoo5, Matrox G200 a G400, SiS serie 300, Intel i810 a i965, S3 Savage, chipsets gráficos VIA UniChrome y nouveau para Nvidia . Algunos proveedores de gráficos han escrito controladores DRI de código cerrado, incluidos ATI y PowerVR Kyro.
Las distintas versiones de DRI han sido implementadas por varios sistemas operativos, entre otros por el kernel Linux , FreeBSD , NetBSD , OpenBSD y OpenSolaris .
El proyecto fue iniciado por Jens Owen y Kevin E. Martin de Precision Insight (financiado por Silicon Graphics y Red Hat ). [1] [22] Se puso a disposición del público por primera vez como parte de XFree86 4.0 [1] [23] y ahora es parte del servidor X.Org . Actualmente lo mantiene la comunidad de software libre .
El trabajo en DRI2 comenzó en la Cumbre de Desarrolladores X de 2007 a partir de una propuesta de Kristian Høgsberg . [24] [25] El propio Høgsberg escribió la nueva extensión DRI2 y las modificaciones a Mesa y GLX . [26] En marzo de 2008, DRI2 estaba casi terminado, [27] [28] [29] pero no pudo llegar a la versión 1.5 de X.Org Server [14] y tuvo que esperar hasta la versión 1.6 de febrero de 2009. [30] La extensión DRI2 se incluyó oficialmente en la versión X11R7.5 de octubre de 2009. [31] La primera versión pública del protocolo DRI2 (2.0) se anunció en abril de 2009. [32] Desde entonces ha habido varias revisiones, la más reciente es la versión 2.8 de julio de 2012. [4]
Debido a varias limitaciones de DRI2, Keith Packard y Emma Anholt propusieron una nueva extensión llamada DRI-Next en la Conferencia de desarrolladores de X.Org de 2012. [15] La extensión se propuso nuevamente como DRI3000 en Linux.conf.au de 2013. [16] [17] Las extensiones DRI3 y Present se desarrollaron durante 2013 y se fusionaron en la versión 1.15 de X.Org Server de diciembre de 2013. [33] [34] La primera y única versión del protocolo DRI3 (1.0) se lanzó en noviembre de 2013. [5]
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}