La Infraestructura de Representación Directa ( DRI ) es un marco para permitir el acceso directo al hardware de gráficos bajo el Sistema X Window de una manera segura y eficiente. [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]
Autor (es) original (es) | Precision Insight, gráficos de tungsteno |
---|---|
Desarrollador (es) | freedesktop.org |
Versión inicial | Agosto de 1998 [1] |
Lanzamiento estable | 2.4.x / febrero de 2009 |
Escrito en | C |
Plataforma | POSIX |
Tipo | Marco / API |
Licencia | MIT y otras licencias [2] |
Sitio web | dri |
Autor (es) original (es) | Kristian Høgsberg y col. |
---|---|
Desarrollador (es) | freedesktop.org |
Versión inicial | 4 de septiembre de 2008 [3] |
Lanzamiento estable | 2.8 / 11 de julio de 2012 [4] |
Escrito en | C |
Plataforma | POSIX |
Tipo | Marco / API |
Licencia | MIT y otras licencias [2] |
Sitio web | dri |
Autor (es) original (es) | Keith Packard y col. |
---|---|
Desarrollador (es) | freedesktop.org |
Versión inicial | 1 de noviembre de 2013 [5] |
Lanzamiento estable | 1.0 / 1 de noviembre de 2013 [5] |
Escrito en | C |
Plataforma | POSIX |
Tipo | Marco / API |
Licencia | MIT y otras licencias [2] |
Sitio web | dri |
La implementación de DRI se distribuye a través de X Server y sus bibliotecas cliente asociadas, Mesa 3D y el subsistema del kernel Direct Rendering Manager . [6] Todo su código fuente es software libre .
Descripción general
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 lo 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 saber o preocuparse por los detalles del hardware subyacente. Cualquier código específico de hardware vive dentro de Device Dependent X , la parte del X Server que administra cada tipo de tarjeta de video o adaptador de gráficos y que también se denomina a menudo 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, todos los cuales deben enviarse al servidor X para su renderizado. A medida que aumentó la cantidad de comunicación entre procesos (IPC) entre el cliente X y el servidor X, el rendimiento de la representación 3D se deterioró hasta el punto de que los desarrolladores del controlador X concluyeron que para aprovechar las capacidades de hardware 3D de las últimas tarjetas gráficas, un nuevo Se requería una arquitectura sin IPC. Los clientes X deben tener acceso directo al hardware de gráficos en lugar de depender de un proceso de terceros para hacerlo, ahorrando toda la sobrecarga de IPC. Este enfoque se denomina "representación directa" en contraposición a la "representación indirecta" proporcionada por la arquitectura X clásica. La infraestructura de renderizado directo se desarrolló inicialmente para permitir que cualquier cliente X realizara un 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.
Arquitectura de software
La arquitectura básica de la infraestructura de renderizado directo consta de tres componentes principales: [8]
- el cliente DRI —un cliente X que realiza "renderizado directo" - necesita un "controlador" específico de hardware capaz de administrar la tarjeta de video actual o el adaptador de gráficos para poder renderizar en él. Estos controladores DRI generalmente se proporcionan como bibliotecas compartidas a las que el cliente está vinculado dinámicamente . Dado que DRI se concibió para aprovechar el hardware de gráficos 3D, las bibliotecas normalmente se presentan a los clientes como implementaciones aceleradas por hardware de una API 3D como OpenGL , proporcionada por el propio proveedor de hardware 3D o por un tercero como el software gratuito Mesa 3D . proyecto.
- el servidor X proporciona una extensión de protocolo X11 —la extensión DRI— que los clientes DRI usan para coordinar tanto con el sistema de ventanas como con el controlador DDX. [9] Como parte del controlador DDX, es bastante común que el proceso del servidor X también se vincule dinámicamente al mismo controlador DRI que los clientes DRI, pero para proporcionar renderizado 3D acelerado por hardware a los clientes X utilizando la extensión GLX para renderizado indirecto ( por ejemplo, clientes X remotos que no pueden utilizar la representación directa). Para el renderizado 2D, el controlador DDX también debe tener en cuenta los clientes DRI que utilizan el mismo dispositivo gráfico.
- el acceso a la tarjeta de video o al adaptador de gráficos está regulado por un componente del kernel llamado Direct Rendering Manager (DRM). [10] Tanto el controlador DDX del servidor X como el controlador DRI de cada cliente X deben usar DRM para acceder al hardware de gráficos. DRM proporciona sincronización a los recursos compartidos del hardware de gráficos, recursos como la cola de comandos, los registros de la tarjeta, la memoria de video, los motores DMA, ... interfieren entre sí. DRM también sirve como un ejecutor de seguridad básico que no permite que ningún cliente X acceda al hardware más allá de lo que necesita para realizar la representación 3D.
DRI1
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 y del búfer 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 renderizados directamente en el búfer posterior, que se intercambió con el búfer frontal en el tiempo de intervalo de supresión vertical . [11] Para renderizar en el búfer trasero, un proceso DRI debería asegurar que la renderización se recortó en el área reservada para su ventana . [11] [12]
La sincronización con el X Server se realizó a través de señales y un búfer 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 renderización 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 los datos cargados en la memoria gráfica, como las texturas, se perdieron para las próximas operaciones, lo que causó un impacto significativo en el rendimiento gráfico. .
Hoy en día, DRI1 se considera completamente obsoleto y no debe utilizarse.
DRI2
Debido a la creciente popularidad de los administradores de ventanas de composición como Compiz , la Infraestructura de representación directa 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 la representación directa. Los clientes X normales 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 la 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 búferes de renderizado, lo que llevó a una extensión DRI completamente diferente con un nuevo conjunto de operaciones, y también 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 solo búfer compartido (trasero), cada cliente DRI obtiene su propio búfer trasero 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 . 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 la pantalla final que se intercambiará en el intervalo VBLANK con el real. amortiguador delantero.
Para manejar todos estos búferes nuevos, 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 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 búfer interno DRI2 también resolvió dos importantes cuellos de botella de rendimiento presentes en la implementación DRI original:
- Los clientes DRI2 ya no bloquean todo el dispositivo DRM mientras lo usan para renderizar, ya que ahora cada cliente obtiene un búfer de renderizado independiente de los otros procesos. [12]
- Los clientes DRI2 pueden asignar sus propios búferes (con texturas, listas de vértices, ...) en la memoria de video y mantenerlos todo el tiempo que quieran, lo que reduce significativamente el consumo de ancho de banda de la memoria de video .
En DRI2, la asignación de los búferes privados fuera de la pantalla (búfer trasero, búfer frontal falso, búfer de profundidad, búfer de plantilla, ...) para una ventana la realiza el propio X Server. [15] [16] Los clientes DRI recuperan esos búferes para realizar la representación en la ventana llamando a operaciones como DRI2GetBuffers y DRI2GetBuffersWithFormat disponible en la extensión DRI2. [3] Internamente, DRI2 usa 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 búfer— para pasar "referencias" a esos búferes a través del protocolo X11 . [16] La razón por la que el servidor X está a cargo de la asignación de búfer de los búferes de renderizado de una ventana es que la extensión GLX permite que varios clientes X hagan renderizado OpenGL de forma cooperativa en la misma ventana. [15] De esta manera, el servidor X gestiona todo el ciclo de vida de los búferes 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 búferes de renderizado que coincidan con el tamaño de la nueva ventana, y de notificar el cambio a los clientes DRI que se renderizan en la ventana mediante un evento InvalidateBuffers, para que recuperen el GEM. nombres de los nuevos búferes. [15]
La extensión DRI2 proporciona otras operaciones centrales para los clientes DRI, como averiguar qué dispositivo y controlador DRM deben usar ( DRI2Connect ) o ser autenticado por el servidor X para poder utilizar las funciones de renderizado y búfer del dispositivo DRM ( DRI2Authenticate ). [3] La presentación de los búferes renderizados en la pantalla se realiza utilizando el DRI2CopyRegion y Solicitudes DRI2SwapBuffers . DRI2CopyRegion se puede usar para hacer una copia entre el búfer frontal falso y el búfer frontal real, pero no proporciona ninguna sincronización con el intervalo de supresión vertical, por lo que puede causar roturas . DRI2SwapBuffers , por otro lado, realiza un intercambio sincronizado con VBLANK entre el búfer anterior y el posterior, si es compatible y ambos búferes tienen el mismo tamaño, o una copia ( blit ) de lo contrario. [3] [15]
DRI3
Aunque DRI2 fue 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 iteración de la infraestructura de renderizado directo conocida como DRI3 para solucionar esos problemas. [17]
Las principales diferencias de DRI3 en comparación con DRI2 son:
- Los clientes DRI3 se asignan ellos mismos sus búferes de procesamiento en lugar de depender del servidor X para realizar la asignación, ese era el método admitido por DRI2. [15] [16]
- DRI3 se deshace del viejo mecanismo inseguro de intercambio de búfer de GEM basado en nombres GEM (identificadores de GEM globales) para pasar objetos de búfer entre un cliente DRI y el servidor X en favor de uno más seguro y versátil basado en PRIME DMA-BUF , que utiliza en su lugar, descriptores de archivo . [15] [16]
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 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 búferes a lo largo de su vida trae muchas ventajas. Por ejemplo, es fácil para el cliente DRI3 asegurarse de que el tamaño de los búferes 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 búfer entre el cliente y el servidor que afectó 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 que el servidor X envíe los búferes de renderizado. [16] Los clientes DRI3, y especialmente los administradores de ventanas del compositor, pueden aprovechar el mantenimiento de búferes más antiguos de marcos anteriores y reutilizarlos como base para representar 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 admitir nuevos formatos de búfer particulares, ya que ahora se manejan 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 búfer GEM no utilizado, uno sin 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 propósito principal de la extensión DRI3 es implementar el mecanismo para compartir búferes renderizados directos entre los clientes DRI y el servidor X. [18] [19] [20] Los clientes DRI asignan y utilizan objetos de búfer de GEM como objetivos de renderizado, mientras que el servidor X representa estos búferes de renderizado utilizando un tipo de objeto X11 llamado "mapa de píxeles". DRI3 proporciona dos operaciones, DRI3PixmapFromBuffer y DRI3BufferFromPixmap , uno 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 el otro 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 de DRI3, los objetos de búfer GEM se pasan como descriptores de archivo 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, lo que permite un acceso serializado al búfer compartido. [19] A diferencia de DRI2, la inicial La operación DRI3Open , la primera que todo 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 previamente por X Server. [18] [19]
DRI3 no proporciona ningún mecanismo para mostrar los búferes renderizados en la pantalla, pero se basa en otra extensión, la extensión Present , para hacerlo. [20] Present se llama así porque su tarea principal es "presentar" búferes en la pantalla, lo que significa que maneja la actualización del framebuffer usando el contenido de los búferes renderizados entregados por las aplicaciones cliente. [19] Las actualizaciones de la 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 las actualizaciones de pantalla al intervalo VBLANK. [21] También mantiene informado al cliente X sobre el instante en que cada búfer se muestra realmente en la pantalla mediante eventos, de modo que el cliente puede 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 realicen renderizado directo, sino también por cualquier renderizado de cliente X 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 hacer renderizado de mapas de píxeles con doble búfer 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 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 de los gráficos 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 con las nuevas funciones proporcionadas por Present. [19]
Presentar 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 establezca el tipo de eventos de presentación relacionados con una determinada ventana sobre la que el cliente desea ser notificado ( 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 de una llamada a PresentPixmap - se ha completado ( PresentCompleteNotify ), cuando un mapa de píxeles utilizado por un La operación PresentPixmap está lista para ser reutilizada ( PresentIdleNotify ) y cuando cambia la configuración de la ventana, principalmente el tamaño de la ventana ( PresentConfigureNotify ). [19] [21] Si un La 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 estaba en DRI2.
Adopción
Se han escrito varios controladores DRI de código abierto, incluidos los para ATI Mach64, ATI Rage128, ATI Radeon, 3dfx Voodoo3 a Voodoo5, Matrox G200 a G400, SiS 300-series, Intel i810 a i965, S3 Savage, chipsets de 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 de Linux , FreeBSD , NetBSD , OpenBSD y OpenSolaris .
Historia
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 la propuesta de Kristian Høgsberg . [24] [25] El mismo Høgsberg escribió la nueva extensión DRI2 y las modificaciones a Mesa y GLX . [26] En marzo de 2008, DRI2 se terminó principalmente, [27] [28] [29] pero no se pudo convertir en X.Org Server versión 1.5 [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, siendo la más reciente la versión 2.8 de julio de 2012. [4]
Debido a varias limitaciones de DRI2, Keith Packard y Eric Anholt propusieron una nueva extensión llamada DRI-Next en la X.Org Developer's Conference 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 1.15 de X.Org Server desde diciembre de 2013. [33] [34] La primera y única versión del protocolo DRI3 (1.0) se publicó en noviembre de 2013 . [5]
Controladores 2D dentro del servidor X
Renderizado indirecto sobre GLX , usando Utah GLX ; separado: fbdev
DRI temprano: el servidor de pantalla X aún realiza la configuración del modo , lo que obliga a ejecutarlo como root
Finalmente, todos los accesos pasan por el Administrador de renderizado directo.
En el kernel de Linux 3.12 se introdujeron los nodos de renderizado ; DRM y el controlador KMS se dividieron. Wayland implementa el renderizado directo sobre EGL
Ver también
- Gerente de renderizado directo
- Mesa 3D
- Sistema de ventanas X
Referencias
- ^ a b c Owen, Jens. "La historia del proyecto DRI" . Wiki del proyecto DRI . Consultado el 16 de abril de 2016 .
- ^ a b c Información sobre derechos de autor / licencia DRI de Mesa - Biblioteca de gráficos 3D de Mesa
- ^ a b c d e f Høgsberg, Kristian (4 de septiembre de 2008). "La Extensión DRI2 - Versión 2.0" . X.Org . Consultado el 29 de mayo de 2016 .
- ^ a b Airlie, Dave (11 de julio de 2012). "[ANUNCIO] dri2proto 2.8" . xorg -noun (lista de correo).
- ^ a b c Packard, Keith (1 de noviembre de 2013). "[ANUNCIO] dri3proto 1.0" . xorg -noun (lista de correo).
- ^ a b "Wiki de Infraestructura de Representación Directa y Mesa 3D" . Consultado el 15 de julio de 2014 .
- ^ "DRI para consolas Framebuffer" . Consultado el 4 de enero de 2019 .
- ^ Martin, Kevin E .; Faith, Rickard E .; Owen, Jens; Akin, Allen (11 de mayo de 1999). "Infraestructura de renderizado directo, documento de diseño de bajo nivel" . Consultado el 18 de mayo de 2016 .
- ^ Owen, Jens; Martin, Kevin (11 de mayo de 1999). "Extensión DRI para admitir la representación directa - Especificación de protocolo" . Consultado el 18 de mayo de 2016 .
- ^ Faith, Rickard E. (11 de mayo de 1999). "El administrador de renderizado directo: soporte de kernel para la infraestructura de renderizado directo" . Consultado el 18 de mayo de 2016 .
- ^ a b c d e f Packard, Keith (21 de julio de 2008). "X estado de salida julio de 2008" . Consultado el 26 de mayo de 2016 .
- ^ a b c d e f g Packard, Keith (24 de abril de 2009). "Afilado del enfoque del controlador Intel" . Consultado el 26 de mayo de 2016 .
- ^ a b Høgsberg, Kristian (8 de agosto de 2007). "Representación directa redirigida" . Consultado el 25 de mayo de 2016 .
- ^ a b Høgsberg, Kristian (4 de agosto de 2008). "Retrocediendo DRI2 del servidor 1.5" . xorg (lista de correo).
- ^ a b c d e f g h yo j k l Packard, Keith (28 de septiembre de 2012). "Pensamientos sobre DRI.Next" . Consultado el 26 de mayo de 2016 .
- ^ a b c d e f g h yo j Willis, Nathan (11 de febrero de 2013). "LCA: Los X-men hablan" . LWN.net . Consultado el 26 de mayo de 2016 .
- ^ a b c Packard, Keith (19 de febrero de 2013). "DRI3000 - Procesamiento directo aún mejor" . Consultado el 26 de mayo de 2016 .
- ^ a b c d e f Packard, Keith (4 de junio de 2013). "Completando la extensión DRI3" . Consultado el 31 de mayo de 2016 .
- ^ a b c d e f g h yo j Edge, Jake (9 de octubre de 2013). "DRI3 y Presente" . LWN.net . Consultado el 26 de mayo de 2016 .
- ^ a b c Packard, Keith (4 de junio de 2013). "La extensión DRI3 - Versión 1.0" . Consultado el 30 de mayo de 2016 .
- ^ a b c d Packard, Keith (6 de junio de 2013). "La actual extensión - Versión 1.0" . Consultado el 1 de junio de 2016 .
- ^ Owen, Jens; Martin, Kevin E. (15 de septiembre de 1998). "Una arquitectura de renderizado directo multipipe para 3D" . Consultado el 16 de abril de 2016 .
- ^ "Notas de la versión para XFree86 4.0" . Proyecto XFree86 . 7 de marzo de 2000 . Consultado el 16 de abril de 2016 .
- ^ "X Developers 'Summit 2007 - Notas" . X.Org . Consultado el 7 de marzo de 2016 .
- ^ Høgsberg, Kristian (3 de octubre de 2007). "Página Wiki de DRI2 Design" . xorg (lista de correo).
- ^ Høgsberg, Kristian (4 de febrero de 2008). "Planes para fusionar el trabajo de DRI2" . xorg (lista de correo).
- ^ Høgsberg, Kristian (15 de febrero de 2008). "DRI2 comprometido" . xorg (lista de correo).
- ^ Høgsberg, Kristian (31 de marzo de 2008). "Representación directa DRI2" . xorg (lista de correo).
- ^ Høgsberg, Kristian (31 de marzo de 2008). "Representación directa DRI2" . Consultado el 20 de abril de 2016 .
- ^ "Rama del servidor 1.6" . X.org . Consultado el 7 de febrero de 2015 .
- ^ "Notas de la versión para X11R7.5" . X.Org . Consultado el 20 de abril de 2016 .
- ^ Høgsberg, Kristian (20 de abril de 2009). "[ANUNCIO] dri2proto 2.0" . xorg -noun (lista de correo).
- ^ Packard, Keith. "[ANUNCIO] xorg-server 1.14.99.901" . X.org . Consultado el 9 de febrero de 2015 .
- ^ Larabel, Michael. "La versión de X.Org Server 1.15 tiene varias características nuevas" . Phoronix . Consultado el 9 de febrero de 2015 .
enlaces externos
- Página de inicio del proyecto de infraestructura de renderizado directo
- Documentos de especificaciones actuales (siempre actualizados a la versión más reciente):
- La extensión DRI2 (Kristian Høgsberg, 2008)
- La extensión DRI3 (Keith Packard, 2013)
- La extensión actual (Keith Packard, 2013)