La Infraestructura de renderizado directo ( DRI ) es el marco que comprende la pila de gráficos de Linux moderna que permite que los programas de espacio de usuario sin privilegios emitan 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 Mesa de OpenGL . DRI también se ha adaptado para proporcionar aceleración OpenGL en una consola framebuffer sin un servidor de visualización en ejecución. [7]
La implementación de DRI se encuentra dispersa en X Server y sus bibliotecas cliente asociadas, Mesa 3D y el subsistema del núcleo 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 de gráficos y, por tanto, el que realiza el renderizado real en el framebuffer . Todo lo que hacen los clientes X es comunicarse con el servidor X para enviar comandos de renderizado. Esos comandos son independientes del hardware, lo que significa que el protocolo X11 proporciona una API que abstrae el dispositivo gráfico para que los clientes X no necesiten conocer ni preocuparse por los detalles específicos del hardware subyacente. Cualquier código específico de hardware se encuentra dentro del Device Dependent X , la parte del servidor X que administra cada tipo de tarjeta de video o adaptador de gráficos y que también suele denominarse controlador de video o gráficos .
El auge del renderizado 3D ha mostrado los límites de esta arquitectura. Las aplicaciones de gráficos 3D tienden a producir grandes cantidades de comandos y datos, los cuales deben enviarse al servidor X para su renderización. A medida que aumentó la cantidad de comunicación entre procesos (IPC) entre el cliente X y el servidor X, el rendimiento de renderizado 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 Se requería una arquitectura sin IPC. Los clientes X deberían tener acceso directo al hardware de gráficos en lugar de depender de otro proceso para hacerlo, ahorrando toda la sobrecarga de IPC. Este enfoque se denomina "renderizado directo" en contraposición al "renderizado indirecto" proporcionado por la arquitectura X clásica. La infraestructura de renderizado directo se desarrolló inicialmente para permitir que cualquier cliente X realizara renderizado 3D utilizando este enfoque de "renderizado directo".
Nada impide que DRI se utilice para implementar renderizado directo 2D acelerado dentro de un cliente X. [3] Simplemente nadie ha tenido la necesidad de hacerlo porque el rendimiento del renderizado indirecto 2D era 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 memoria de las tarjetas de video en ese momento, había una única instancia del búfer frontal y posterior de la pantalla (también del búfer de profundidad auxiliar y del búfer de plantilla ), compartido por todos los clientes DRI y el servidor X. [11] [12] Todos ellos se renderizaron directamente en el búfer posterior, que se intercambió con el búfer frontal en un intervalo de tiempo de borrado vertical . [11] Para renderizar en el buffer posterior, un proceso DRI debe garantizar que la renderización se recorte en el área reservada para su ventana . [11] [12]
La sincronización con el Servidor X se realizó 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 . Mientras tanto, otros usuarios del dispositivo, incluido el servidor X, fueron bloqueados y tuvieron que esperar hasta que se liberara el bloqueo al final de la operación de renderizado actual, incluso si no hubiera ningún conflicto entre ambas operaciones. [12] Otro inconveniente fue que las operaciones no retuvieron las asignaciones de memoria después de que el proceso DRI actual liberó su bloqueo en el dispositivo, por lo que cualquier dato cargado en la memoria de gráficos, como las texturas , se perdió para las operaciones siguientes, lo que provocó un impacto significativo en el rendimiento de los gráficos. .
Hoy en día, 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 admitir la redirección a "mapas de píxeles fuera de la pantalla" mientras realizaban el renderizado directo. Los clientes X habituales ya respetaban la redirección a un mapa de píxeles separado proporcionado por el servidor X como destino 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 definitiva 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 a cambios importantes en Direct Rendering Manager . [3] La nueva extensión se llamó "DRI2", aunque no es una versión posterior sino una extensión diferente que ni siquiera es compatible con la DRI original; de hecho, ambas han coexistido dentro del X Server durante mucho tiempo.
En DRI2, en lugar de un único búfer compartido (posterior), cada cliente DRI obtiene su propio búfer posterior privado [11] [12] , junto con sus búferes de plantilla y profundidad asociados , para representar el contenido de su ventana utilizando la aceleración de hardware . Luego, el cliente DRI 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 real. búfer frontal.
Para manejar todos estos nuevos buffers, Direct Rendering Manager tuvo que incorporar nuevas funcionalidades, específicamente un administrador de memoria gráfica . DRI2 se desarrolló inicialmente utilizando el administrador de memoria TTM experimental, [11] [13] pero luego se reescribió para usar GEM después de que fue elegido como el administrador de memoria DRM definitivo. [14] El nuevo modelo de gestión de buffer interno de DRI2 también resolvió dos importantes cuellos de botella de rendimiento presentes en la implementación original de DRI:
En DRI2, la asignación de los búferes privados fuera de la pantalla (búfer posterior, búfer frontal falso, búfer de profundidad, búfer de plantilla, ...) para una ventana la realiza el propio servidor X. [15] [16] Los clientes DRI recuperan esos buffers para realizar la representació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 hagan referencia 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 del buffer de renderizado de una ventana es que la extensión GLX permite que múltiples clientes X realicen renderizado OpenGL de forma cooperativa en la misma ventana. [15] De esta manera, 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 de notificar el cambio a los clientes DRI que renderizan en la ventana mediante un evento InvalidateBuffers, para que recuperen el GEM. nombres de los nuevos buffers. [15]
La extensión DRI2 proporciona otras operaciones principales para los clientes DRI, como averiguar qué dispositivo y controlador DRM deben usar ( DRI2Connect ) o ser autenticado por el servidor X para poder usar las funciones de renderizado y búfer 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 realizar una copia entre el búfer frontal falso y el búfer frontal real, pero no proporciona ninguna sincronización con el intervalo de borrado vertical, por lo que puede provocar desgarros . DRI2SwapBuffers , por otro lado, realiza un intercambio sincronizado con VBLANK entre el búfer frontal y el posterior, si es compatible y ambos búferes tienen el mismo tamaño, o una copia ( blit ) en caso contrario. [3] [15]
Aunque DRI2 supuso una mejora significativa con respecto al DRI original, la nueva extensión también introdujo algunos problemas nuevos. [15] [16] En 2013, se desarrolló una tercera versión de la infraestructura de renderizado directo conocida como DRI3 para solucionar esos problemas. [17]
Las principales diferencias de DRI3 respecto a DRI2 son:
La asignación de búfer en el lado del cliente rompe las suposiciones de GLX en el sentido de que ya no es posible que múltiples aplicaciones GLX se representen de manera 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 aporta muchas ventajas. Por ejemplo, es fácil para el cliente DRI3 garantizar que el tamaño de los buffers de renderizado siempre coincida con el tamaño actual de la ventana y, por lo tanto, eliminar los artefactos debido 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 ahorran el viaje de ida y vuelta adicional esperando que el servidor X envíe los buffers de renderizado. [16] Los clientes DRI3, y especialmente los administradores de ventanas del compositor, pueden aprovechar la ventaja de mantener los buffers más antiguos de fotogramas anteriores y reutilizarlos como base para renderizar solo las partes dañadas de una ventana como otra optimización del rendimiento. [15] [16] Ya no es necesario modificar la extensión DRI3 para admitir nuevos formatos de búfer particulares, ya que ahora se manejan directamente entre el controlador del cliente DRI y el controlador del núcleo DRM. [15] El uso de descriptores de archivos, por otro lado, permite al kernel realizar una limpieza segura de cualquier objeto de búfer 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 "Presente". [17] [19] El objetivo 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 mapa de píxeles (en el "espacio del servidor X") a partir de un objeto de búfer GEM (en el "espacio del cliente DRI") y la otra para hacer lo contrario y obtener un objeto de búfer GEM de un mapa de píxeles X. [18] [19] [20] En estas operaciones DRI3, los objetos de búfer GEM se pasan como descriptores de archivos DMA-BUF en lugar de nombres GEM. DRI3 también proporciona una forma de compartir objetos de sincronización entre el cliente DRI y el servidor X, permitiendo a ambos un acceso serializado al búfer 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. por adelantado por el servidor X. [18] [19]
DRI3 no proporciona ningún mecanismo para mostrar los buffers renderizados en la pantalla, pero depende de otra extensión, la extensión Presente , 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 desgarro . Present también maneja la sincronización de actualizaciones de pantalla al intervalo VBLANK. [21] También mantiene al cliente X informado sobre el instante en que cada buffer se muestra realmente en la pantalla usando eventos, para que el cliente pueda sincronizar su proceso de renderizado con la frecuencia de actualización de la 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 realizan renderizado directo, sino también por cualquier cliente X que renderice en un mapa de píxeles por cualquier medio. [18] Por ejemplo, la mayoría de las aplicaciones GTK+ y Qt no basadas en GL existentes solían realizar renderizado de mapas de píxeles con doble buffer usando XRender . Estas aplicaciones también pueden utilizar la extensión Present para lograr actualizaciones de pantalla eficientes y sin interrupciones. Esta es la razón por la que Present se desarrolló como una extensión independiente 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 de los gráficos DRI3 es mejor porque Present es más eficiente que DRI2 en el intercambio de buffers. [19] Varias extensiones de OpenGL que no estaban disponibles con DRI2 ahora son compatibles según las nuevas funciones proporcionadas por Present. [19]
Present proporciona dos operaciones principales a los clientes X: actualizar una región de una ventana utilizando parte o todo el contenido de un mapa de píxeles ( PresentPixmap ) y establecer el tipo de eventos de presentación relacionados con una determinada ventana sobre la que el cliente desea recibir notificaciones ( PresentSelectInput ). [19] [21] Hay tres eventos de presentación sobre los cuales una ventana puede notificar a un cliente X: cuando una operación de presentación en curso, normalmente desde una llamada a PresentPixmap , se ha completado ( PresentCompleteNotify ), cuando un mapa de píxeles utilizado por una operación PresentPixmap es 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 X cliente como estaba en DRI2.
Se han escrito varios controladores DRI de código abierto, incluidos algunos para ATI Mach64, ATI Rage128, ATI Radeon, 3dfx Voodoo3 a Voodoo5, Matrox G200 a G400, SiS 300-series, Intel i810 a i965, S3 Savage, conjuntos de chips gráficos VIA UniChrome y Nuevo 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 de 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] Primero estuvo ampliamente disponible como parte de XFree86 4.0 [1] [23] y ahora es parte del servidor X.Org . Actualmente es mantenido por la comunidad de software libre .
El trabajo en DRI2 comenzó en la X Cumbre de Desarrolladores 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 prácticamente terminado, [27] [28] [29] pero no pudo integrarse en la versión 1.5 del servidor X.Org [14] y tuvo que esperar hasta la versión 1.6 a partir 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 siendo 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 2012. [15] La extensión se propuso nuevamente como DRI3000 en Linux.conf.au 2013. [ 16] [17] Las extensiones DRI3 y Present se desarrollaron durante 2013 y se fusionaron en la versión X.Org Server 1.15 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}