La representación Direct Manager ( DRM ) es un subsistema del kernel de Linux responsable de la interfaz con las GPU de las modernas tarjetas de vídeo . DRM expone una API que los programas de espacio de usuario pueden usar para enviar comandos y datos a la GPU y realizar operaciones como configurar el modo de la pantalla. DRM se desarrolló por primera vez como el componente de espacio de kernel de la infraestructura de representación directa del servidor X , [1] pero desde entonces ha sido utilizado por otras alternativas de pila de gráficos como Wayland .
Autor (es) original (es) | kernel.org y freedesktop.org |
---|---|
Desarrollador (es) | kernel.org y freedesktop.org |
Escrito en | C |
Tipo | |
Licencia |
|
Sitio web | dri |
Los programas de espacio de usuario pueden usar la API DRM para ordenar a la GPU que realice renderizado 3D y decodificación de video acelerados por hardware , así como computación GPGPU .
Descripción general
El kernel de Linux ya tenía una API llamada fbdev , que se usaba para administrar el framebuffer de un adaptador de gráficos , [2] pero no se podía usar para manejar las necesidades del hardware de video moderno basado en GPU acelerado en 3D . Estos dispositivos generalmente requieren configurar y administrar una cola de comandos en su propia memoria para enviar comandos a la GPU y también requieren la administración de búferes y espacio libre dentro de esa memoria. [3] Inicialmente, los programas de espacio de usuario (como el servidor X ) administraban directamente estos recursos, pero generalmente actuaban como si fueran los únicos con acceso a ellos. Cuando dos o más programas intentaron controlar el mismo hardware al mismo tiempo y configurar sus recursos cada uno a su manera, la mayoría de las veces terminaron catastróficamente. [3]
Direct Rendering Manager se creó para permitir que varios programas utilicen recursos de hardware de vídeo de forma cooperativa. [4] El DRM obtiene acceso exclusivo a la GPU y es responsable de inicializar y mantener la cola de comandos, la memoria y cualquier otro recurso de hardware. Los programas que desean utilizar la GPU envían solicitudes a DRM, que actúa como árbitro y se encarga de evitar posibles conflictos.
El alcance de DRM se ha expandido a lo largo de los años para cubrir más funcionalidades previamente manejadas por programas de espacio de usuario, como la gestión de framebuffer y la configuración de modo , objetos de uso compartido de memoria y sincronización de memoria. [5] [6] Algunas de estas expansiones recibieron nombres específicos, como Graphics Execution Manager (GEM) o kernel mode-setting (KMS), y la terminología prevalece cuando se menciona específicamente la funcionalidad que proporcionan. Pero en realidad son parte de todo el subsistema DRM del kernel.
La tendencia a incluir dos GPU en una computadora, una GPU discreta y una integrada, generó nuevos problemas, como la conmutación de GPU, que también debían resolverse en la capa DRM. Para igualar la tecnología Nvidia Optimus , DRM se proporcionó con capacidades de descarga de GPU, llamadas PRIME. [7]
Arquitectura de software
Direct Rendering Manager reside en el espacio del kernel , por lo que los programas de espacio de usuario deben usar llamadas al sistema del kernel para solicitar sus servicios. Sin embargo, DRM no define sus propias llamadas al sistema personalizadas. En cambio, sigue el principio de Unix de " todo es un archivo " para exponer las GPU a través del espacio de nombres del sistema de archivos, utilizando archivos de dispositivo bajo la /dev
jerarquía. Cada GPU detectada por DRM se denomina dispositivo DRM y se crea un archivo de dispositivo (donde X es un número secuencial) para interactuar con él. [8] [9] Los programas de espacio de usuario que quieran hablar con la GPU deben abrir este archivo y usar llamadas ioctl para comunicarse con DRM. Diferentes ioctls corresponden a diferentes funciones de la API DRM ./dev/dri/cardX
Se creó una biblioteca llamada libdrm para facilitar la interfaz de los programas de espacio de usuario con el subsistema DRM. Esta biblioteca es simplemente un contenedor que proporciona una función escrita en C para cada ioctl de la API DRM, así como constantes, estructuras y otros elementos auxiliares. [10] El uso de libdrm no solo evita exponer la interfaz del kernel directamente a las aplicaciones, sino que presenta las ventajas habituales de reutilizar y compartir código entre programas.
DRM consta de dos partes: un "núcleo DRM" genérico y uno específico ("controlador DRM") para cada tipo de hardware compatible. [11] El núcleo DRM proporciona el marco básico donde se pueden registrar diferentes controladores DRM y también proporciona al espacio de usuario un conjunto mínimo de ioctls con funcionalidad común independiente del hardware. [8] Un controlador DRM, por otro lado, implementa la parte dependiente del hardware de la API, específica para el tipo de GPU que admite; debe proporcionar la implementación de los ioctls restantes no cubiertos por el núcleo DRM, pero también puede extender la API, ofreciendo ioctls adicionales con funcionalidad adicional solo disponible en dicho hardware. [8] Cuando un controlador DRM específico proporciona una API mejorada, el espacio de usuario libdrm también se amplía con un controlador libdrm de biblioteca adicional que puede ser utilizado por el espacio de usuario para interactuar con los ioctls adicionales.
API
El núcleo de DRM exporta varias interfaces a aplicaciones de espacio de usuario, generalmente destinadas a ser utilizadas a través de las libdrm
funciones de envoltura correspondientes . Además, los controladores exportan interfaces específicas del dispositivo para que las utilicen los controladores de espacio de usuario y las aplicaciones compatibles con el dispositivo a través de archivos ioctls y sysfs . Las interfaces externas incluyen: mapeo de memoria, administración de contexto, operaciones DMA , administración AGP , control vblank , administración de cercas, administración de memoria y administración de salida.
DRM-Master y DRM-Auth
Hay varias operaciones (ioctls) en la API de DRM que, ya sea por motivos de seguridad o por problemas de concurrencia, deben restringirse para ser utilizadas por un solo proceso de espacio de usuario por dispositivo. [8] Para implementar esta restricción, DRM limita tales ioctls para que solo sean invocados por el proceso considerado el "maestro" de un dispositivo DRM, generalmente llamado DRM-Master . Solo uno de todos los procesos que tienen el nodo de dispositivo abierto tendrá su identificador de archivo marcado como maestro, específicamente el primero que llame al SET_MASTER ioctl. Cualquier intento de utilizar uno de estos ioctls restringidos sin ser el DRM-Master devolverá un error. Un proceso también puede renunciar a su función de maestro, y dejar que otro proceso lo adquiera, llamando al /dev/dri/cardX
DROP_MASTER ioctl.
El servidor X, o cualquier otro servidor de visualización, es comúnmente el proceso que adquiere el estado DRM-Master en cada dispositivo DRM que administra, generalmente cuando abre el nodo de dispositivo correspondiente durante su inicio, y mantiene estos privilegios durante toda la sesión gráfica hasta termina o muere.
Para los procesos de espacio de usuario restantes, hay otra forma de obtener el privilegio de invocar algunas operaciones restringidas en el dispositivo DRM llamado DRM-Auth . Básicamente es un método de autenticación contra el dispositivo DRM, con el fin de demostrarle que el proceso tiene la aprobación del DRM-Master para obtener dichos privilegios. El procedimiento consta de: [12] : 13
- El cliente obtiene un token único (un número entero de 32 bits) del dispositivo DRM mediante el GET_MAGIC ioctl y lo pasa al proceso DRM-Master por cualquier medio (normalmente algún tipo de IPC ; por ejemplo, en DRI2 hay un DRI2 Solicitud de autenticación que cualquier cliente X puede enviar al servidor X. [13] )
- El proceso DRM-Master, a su vez, devuelve el token al dispositivo DRM invocando el AUTH_MAGIC ioctl.
- El dispositivo otorga derechos especiales al identificador del archivo de proceso cuyo token de autenticación coincide con el token recibido del DRM-Master.
Administrador de ejecución de gráficos
Debido al creciente tamaño de la memoria de video y la creciente complejidad de las API de gráficos como OpenGL , la estrategia de reinicializar el estado de la tarjeta gráfica en cada cambio de contexto era demasiado costosa en cuanto al rendimiento. Además, los escritorios Linux modernos necesitaban una forma óptima de compartir búferes fuera de la pantalla con el administrador de composición . Estos requisitos llevaron al desarrollo de nuevos métodos para administrar búferes de gráficos dentro del kernel. La ejecución Administrador de gráficos (GEM) surgió como uno de estos métodos. [6]
GEM proporciona una API con primitivas de gestión de memoria explícitas . [6] A través de GEM, un programa de espacio de usuario puede crear, manejar y destruir objetos de memoria que viven en la memoria de video de la GPU. Estos objetos, llamados "objetos GEM", [14] son persistentes desde la perspectiva del programa de espacio de usuario y no necesitan ser recargados cada vez que el programa recupera el control de la GPU. Cuando un programa de espacio de usuario necesita una porción de memoria de video (para almacenar un framebuffer , textura o cualquier otro dato requerido por la GPU [15] ), solicita la asignación al controlador DRM usando la API GEM. El controlador DRM realiza un seguimiento de la memoria de video utilizada y es capaz de cumplir con la solicitud si hay memoria libre disponible, devolviendo un "identificador" al espacio del usuario para referir aún más la memoria asignada en las próximas operaciones. [6] [14] GEM API también proporciona operaciones para llenar el búfer y liberarlo cuando ya no sea necesario. La memoria de los identificadores de GEM no publicados se recupera cuando el proceso de espacio de usuario cierra el descriptor de archivo del dispositivo DRM, intencionalmente o porque termina. [dieciséis]
GEM también permite que dos o más procesos de espacio de usuario que utilizan el mismo dispositivo DRM (por lo tanto, el mismo controlador DRM) compartan un objeto GEM. [16] Los identificadores de GEM son enteros locales de 32 bits únicos para un proceso, pero repetibles en otros procesos, por lo que no son adecuados para compartir. Lo que se necesita es un espacio de nombres global, y GEM proporciona uno mediante el uso de identificadores globales llamados nombres GEM . Un nombre GEM se refiere a uno, y solo uno, objeto GEM creado dentro del mismo dispositivo DRM por el mismo controlador DRM, utilizando un entero único de 32 bits . GEM proporciona una operación flink para obtener un nombre GEM de un identificador GEM. [16] [12] : 16 El proceso puede pasar este nombre GEM (entero de 32 bits) a otro proceso utilizando cualquier mecanismo de IPC disponible. [12] : 15 El proceso del destinatario puede utilizar el nombre GEM para obtener un identificador GEM local que apunte al objeto GEM original.
Desafortunadamente, el uso de nombres GEM para compartir búferes no es seguro. [12] : 16 [17] [18] Un proceso de terceros malintencionado que accede al mismo dispositivo DRM podría intentar adivinar el nombre GEM de un búfer compartido por otros dos procesos, simplemente probando enteros de 32 bits. [19] [18] Una vez que se encuentra un nombre GEM, se puede acceder a su contenido y modificarlo, violando la confidencialidad e integridad de la información del búfer. Este inconveniente se superó más tarde con la introducción del soporte DMA-BUF en DRM, ya que DMA-BUF representa búferes en el espacio de usuario como descriptores de archivo, que pueden compartirse de forma segura .
Otra tarea importante para cualquier sistema de administración de memoria de video, además de administrar el espacio de la memoria de video, es manejar la sincronización de la memoria entre la GPU y la CPU. Las arquitecturas de memoria actuales son muy complejas y generalmente involucran varios niveles de cachés para la memoria del sistema y, a veces, también para la memoria de video. Por lo tanto, los administradores de memoria de video también deben manejar la coherencia de la caché para garantizar que los datos compartidos entre la CPU y la GPU sean consistentes. [20] Esto significa que a menudo los componentes internos de la gestión de la memoria de vídeo dependen en gran medida de los detalles del hardware de la GPU y la arquitectura de la memoria y, por tanto, son específicos del controlador. [21]
GEM fue desarrollado inicialmente por ingenieros de Intel para proporcionar un administrador de memoria de video para su controlador i915. [20] La familia Intel GMA 9xx son GPU integradas con una arquitectura de memoria uniforme (UMA), donde la GPU y la CPU comparten la memoria física y no hay una VRAM dedicada. [22] GEM define "dominios de memoria" para la sincronización de memoria, y si bien estos dominios de memoria son independientes de la GPU, [6] están diseñados específicamente con una arquitectura de memoria UMA en mente, lo que los hace menos adecuados para otras arquitecturas de memoria como las que tienen un VRAM separada. Por esta razón, otros controladores DRM han decidido exponer a los programas de espacio de usuario la API GEM, pero internamente implementaron un administrador de memoria diferente más adecuado para su arquitectura de memoria y hardware particular. [23]
La API de GEM también proporciona ioctls para el control del flujo de ejecución (búferes de comando), pero son específicos de Intel, para usarse con Intel i915 y GPU posteriores. [6] Ningún otro controlador DRM ha intentado implementar ninguna parte de la API de GEM más allá de las ioctls específicas de administración de memoria.
Mapas de tablas de traducción
Translation Table Maps (TTM) es el nombre del administrador de memoria genérico para GPU que se desarrolló antes de GEM. [5] [14] Fue diseñado específicamente para administrar los diferentes tipos de memoria a los que puede acceder una GPU, incluida la RAM de video dedicada (comúnmente instalada en la tarjeta de video) y la memoria del sistema accesible a través de una unidad de administración de memoria de E / S llamada Gráficos Tabla de reasignación de direcciones (GART). [5] TTM también debe manejar las partes de la RAM de video que no son directamente direccionables por la CPU y hacerlo con el mejor rendimiento posible, considerando que las aplicaciones de gráficos en el espacio del usuario generalmente funcionan con grandes cantidades de datos de video. Otro asunto importante fue mantener la coherencia entre los diferentes recuerdos y cachés involucrados.
El concepto principal de TTM son los "objetos de búfer", regiones de la memoria de video que en algún momento deben ser direccionables por la GPU. [5] Cuando una aplicación de gráficos de espacio de usuario desea acceder a un determinado objeto de búfer (generalmente para llenarlo con contenido), TTM puede requerir reubicarlo en un tipo de memoria direccionable por la CPU. Pueden ocurrir más reubicaciones, u operaciones de mapeo de GART, cuando la GPU necesita acceder a un objeto de búfer pero aún no está en el espacio de direcciones de la GPU. Cada una de estas operaciones de reubicación debe manejar cualquier problema relacionado con los datos y la coherencia de la caché. [5]
Otro concepto importante de TTM son las vallas . Las vallas son esencialmente un mecanismo para administrar la concurrencia entre la CPU y la GPU. [24] Una valla rastrea cuando la GPU ya no usa un objeto de búfer, generalmente para notificar cualquier proceso de espacio de usuario con acceso a él. [5]
El hecho de que TTM intentara administrar todo tipo de arquitecturas de memoria, incluidas aquellas con y sin una VRAM dedicada, de una manera adecuada, y proporcionar todas las funciones imaginables en un administrador de memoria para su uso con cualquier tipo de hardware, llevó a un resultado demasiado complejo. solución con una API mucho más grande de lo necesario. [24] [14] Algunos desarrolladores de DRM pensaron que no encajaría bien con ningún controlador específico, especialmente la API. Cuando GEM surgió como un administrador de memoria más simple, se prefirió su API a la de TTM. Pero algunos desarrolladores de controladores consideraron que el enfoque adoptado por TTM era más adecuado para tarjetas de video discretas con memoria de video dedicada e IOMMU, por lo que decidieron usar TTM internamente, al tiempo que exponen sus objetos de búfer como objetos GEM y, por lo tanto, admiten la API de GEM. [23] Ejemplos de controladores actuales que utilizan TTM como administrador de memoria interna pero que proporcionan una API GEM son el controlador radeon para tarjetas de video AMD y el controlador nouveau para tarjetas de video NVIDIA.
Uso compartido de búfer DMA y PRIME
La API de uso compartido de búfer DMA (a menudo abreviada como DMA-BUF) es una API interna del kernel de Linux diseñada para proporcionar un mecanismo genérico para compartir búferes DMA en múltiples dispositivos, posiblemente administrados por diferentes tipos de controladores de dispositivo. [25] [26] Por ejemplo, un dispositivo Video4Linux y un dispositivo adaptador de gráficos podrían compartir búferes a través de DMA-BUF para lograr una copia cero de los datos de un flujo de video producido por el primero y consumido por el segundo. Cualquier controlador de dispositivo Linux puede implementar esta API como exportador, como usuario (consumidor) o ambos.
Esta característica se aprovechó por primera vez en DRM para implementar PRIME, una solución para la descarga de GPU que usa DMA-BUF para compartir los framebuffers resultantes entre los controladores DRM de la GPU discreta e integrada. [27] : 13 Una característica importante de DMA-BUF es que se presenta un búfer compartido en el espacio del usuario como un descriptor de archivo . [14] [12] : 17 Para el desarrollo de PRIME, se agregaron dos nuevos ioctls a la API DRM, uno para convertir un identificador GEM local en un descriptor de archivo DMA-BUF y otro para la operación exactamente opuesta.
Estos dos nuevos ioctls se reutilizaron más tarde como una forma de corregir la inseguridad inherente al intercambio de búfer GEM. [12] : 17 A diferencia de los nombres GEM, los descriptores de archivos no se pueden adivinar (no son un espacio de nombres global) y los sistemas operativos Unix proporcionan una forma segura de pasarlos a través de un socket de dominio Unix usando la semántica SCM_RIGHTS. [14] [28] : 11 Un proceso que quiere compartir un objeto GEM con otro proceso puede convertir su identificador GEM local en un descriptor de archivo DMA-BUF y pasarlo al destinatario, que a su vez puede obtener su propio identificador GEM de el descriptor de archivo recibido. [12] : 16 DRI3 utiliza este método para compartir búferes entre el cliente y el servidor X [29] y también Wayland .
Configuración del modo de kernel
Para que funcione correctamente, una tarjeta de video o un adaptador de gráficos debe establecer un modo ( una combinación de resolución de pantalla , profundidad de color y frecuencia de actualización) que esté dentro del rango de valores admitidos por ella misma y la pantalla adjunta . Esta operación se llama configuración de modo , [30] y generalmente requiere acceso sin formato al hardware de gráficos, es decir, la capacidad de escribir en ciertos registros de la tarjeta de video. [31] [32] Se debe realizar una operación de configuración de modo antes de comenzar a usar el framebuffer , y también cuando una aplicación o el usuario requiera que el modo cambie.
En los primeros días, los programas de espacio de usuario que querían usar el framebuffer gráfico también eran responsables de proporcionar las operaciones de configuración de modo, [3] y por lo tanto necesitaban ejecutarse con acceso privilegiado al hardware de video. En los sistemas operativos de tipo Unix, el servidor X fue el ejemplo más destacado, y su implementación de configuración de modo vivía en el controlador DDX para cada tipo específico de tarjeta de video. [33] Este enfoque, más adelante denominado Configuración de modo de espacio de usuario o UMS, [34] [35] plantea varios problemas. [36] [30] No solo rompe el aislamiento que los sistemas operativos deberían proporcionar entre los programas y el hardware, lo que plantea problemas de estabilidad y seguridad, sino que también podría dejar el hardware de gráficos en un estado inconsistente si dos o más programas de espacio de usuario intentan hacerlo. el ajuste de modo al mismo tiempo. Para evitar estos conflictos, el servidor X se convirtió en la práctica en el único programa de espacio de usuario que realizaba operaciones de establecimiento de modo; el resto de los programas de espacio de usuario confiaban en el servidor X para establecer el modo apropiado y para manejar cualquier otra operación relacionada con el ajuste de modo. Inicialmente, la configuración del modo se realizó exclusivamente durante el proceso de inicio del servidor X, pero luego el servidor X adquirió la capacidad de hacerlo mientras se ejecuta. [37] La extensión XFree86-VidModeExtension se introdujo en XFree86 3.1.2 para permitir que cualquier petición del cliente X modeline (resolución) cambios en el X Server. [38] [39] La extensión VidMode fue reemplazada posteriormente por la extensión XRandR más genérica .
Sin embargo, este no era el único código que realizaba la configuración de modo en un sistema Linux . Durante el proceso de arranque del sistema, el kernel de Linux debe establecer un modo de texto mínimo para la consola virtual (basado en los modos estándar definidos por las extensiones de BIOS VESA ). [40] Además, el controlador de framebuffer del kernel de Linux contenía un código de configuración de modo para configurar los dispositivos de framebuffer. [2] Para evitar conflictos de configuración de modo, el servidor XFree86, y más tarde el servidor X.Org, manejó el caso cuando el usuario cambiaba del entorno gráfico a una consola virtual de texto guardando su estado de configuración de modo y restaurándolo cuando el usuario volvió a cambiar a X. [41] Este proceso provocó un molesto parpadeo en la transición, y también puede fallar, dando lugar a una pantalla de salida dañada o inutilizable. [42]
El enfoque de configuración del modo de espacio de usuario también provocó otros problemas: [43] [42]
- El proceso de suspensión / reanudación tiene que depender de las herramientas de espacio del usuario para restaurar el modo anterior. Una sola falla o caída de uno de estos programas podría dejar el sistema sin una pantalla de trabajo debido a una mala configuración del conjunto de modos y, por lo tanto, inutilizable.
- También era imposible que el kernel mostrara mensajes de error o depuración cuando la pantalla estaba en modo gráfico, por ejemplo, cuando X se estaba ejecutando, ya que los únicos modos que conocía el kernel eran los modos de texto estándar del BIOS VESA.
- Un problema más urgente fue la proliferación de aplicaciones gráficas que omitieron el servidor X y la aparición de otras alternativas de pila de gráficos a X, lo que amplió aún más la duplicación del código de configuración de modo en todo el sistema.
Para abordar estos problemas, el código de configuración de modo se movió a un solo lugar dentro del kernel, específicamente al módulo DRM existente. [36] [37] [44] [42] [43] Entonces, todos los procesos, incluido el servidor X, deberían poder ordenar al kernel que realice operaciones de configuración de modo, y el kernel se aseguraría de que las operaciones simultáneas no lo hagan. resultar en un estado inconsistente. La nueva API del kernel y el código agregado al módulo DRM para realizar estas operaciones de configuración de modo se denominaron Kernel Mode-Setting (KMS). [30]
La configuración del modo de kernel proporciona varios beneficios. El más inmediato es, por supuesto, la eliminación del código de configuración de modo duplicado, tanto del kernel (consola Linux, fbdev) como del espacio de usuario (controladores X Server DDX). KMS también facilita la escritura de sistemas gráficos alternativos, que ahora no necesitan implementar su propio código de configuración de modo. [42] [43] Al proporcionar administración de modo centralizada, KMS resuelve los problemas de parpadeo al cambiar entre consola y X, y también entre diferentes instancias de X (cambio rápido de usuario). [41] [44] Dado que está disponible en el kernel, también se puede usar al comienzo del proceso de arranque, lo que evita el parpadeo debido a los cambios de modo en estas primeras etapas.
El hecho de que KMS sea parte del kernel le permite utilizar recursos que solo están disponibles en el espacio del kernel, como las interrupciones . [45] Por ejemplo, la recuperación de modo después de un proceso de suspensión / reanudación se simplifica mucho al ser administrada por el propio núcleo y, de paso, mejora la seguridad (no más herramientas de espacio de usuario que requieran permisos de root). El kernel también permite la conexión en caliente de nuevos dispositivos de visualización fácilmente, resolviendo un problema de larga data. [45] La configuración de modo también está estrechamente relacionada con la gestión de la memoria, ya que los framebuffers son básicamente memorias intermedias, por lo que se recomienda encarecidamente una estrecha integración con el administrador de memoria gráfica. Esa es la razón principal por la que el código de configuración del modo del kernel se incorporó a DRM y no como un subsistema separado. [44]
Para evitar romper la compatibilidad con versiones anteriores de la API de DRM, la configuración del modo de kernel se proporciona como una función de controlador adicional de ciertos controladores de DRM. [46] Cualquier controlador DRM puede optar por proporcionar DRIVER_MODESET marca cuando se registra con el núcleo de DRM para indicar que es compatible con la API de KMS. [8] Los controladores que implementan la configuración del modo de kernel a menudo se denominan controladores KMS como una forma de diferenciarlos de los controladores DRM heredados, sin KMS.
KMS se ha adoptado hasta tal punto que ciertos controladores que carecen de aceleración 3D (o para los que el proveedor de hardware no quiere exponerlo o implementarlo) implementan la API de KMS sin el resto de la API de DRM.
Modelo de dispositivo KMS
KMS modela y administra los dispositivos de salida como una serie de bloques de hardware abstractos que se encuentran comúnmente en la tubería de salida de pantalla de un controlador de pantalla . Estos bloques son: [47]
- CRTC : cada CRTC (del controlador CRT [48] [33] ) representa un motor de exploración del controlador de pantalla, que apunta a un búfer de exploración ( framebuffer ). [47] El propósito de un CRTC es leer los datos de píxeles que se encuentran actualmente en el búfer de exploración y generar a partir de ellos la señal de temporización del modo de video con la ayuda de un circuito PLL . [49] El número de CRTC disponibles determina cuántos dispositivos de salida independientes puede manejar el hardware al mismo tiempo, por lo que para utilizar configuraciones de múltiples cabezales se requiere al menos un CRTC por dispositivo de visualización. [47] Dos (o más) CRTC también pueden funcionar en modo de clonación si escanean desde el mismo framebuffer para enviar la misma imagen a varios dispositivos de salida. [49] [48]
- Conectores : un conector representa el lugar donde el controlador de pantalla envía la señal de video de una operación de escaneo para que se muestre. Habitualmente, el concepto KMS de un conector corresponde a un conector físico ( VGA , DVI , FPD-Link , HDMI , DisplayPort , S-Video , ...) en el hardware donde se encuentra un dispositivo de salida ( monitor , panel de portátil , ... ) se adjunta de forma permanente o temporal. La información relacionada con el dispositivo de salida actualmente conectado físicamente, como el estado de la conexión, los datos EDID , el estado de DPMS o los modos de video admitidos, también se almacena dentro del conector. [47]
- Codificadores : el controlador de pantalla debe codificar la señal de temporización del modo de vídeo del CRTC utilizando un formato adecuado para el conector previsto. [47] Un codificador representa el bloque de hardware capaz de realizar una de estas codificaciones. Ejemplos de codificaciones — para salidas digitales — son TMDS y LVDS ; para salidas analógicas como VGA y salida de TV , generalmente se utilizan bloques DAC específicos . Un conector solo puede recibir la señal de un codificador a la vez, [47] y cada tipo de conector solo admite algunas codificaciones. También puede haber restricciones físicas adicionales por las que no todos los CRTC están conectados a todos los codificadores disponibles, lo que limita las posibles combinaciones de conector de codificador CRTC.
- Planos : un avión no es un bloque de hardware, sino un objeto de memoria que contiene un búfer del que se alimenta un motor de exploración (un CRTC). El plano que contiene el framebuffer se llama plano primario , y cada CRTC debe tener uno asociado, [47] ya que es la fuente para que el CRTC determine el modo de video: resolución de pantalla (ancho y alto), tamaño de píxel, formato de píxel, frecuencia de actualización, etc. Un CRTC también puede tener planos de cursor asociados si el controlador de pantalla admite superposiciones de cursor de hardware, o planos secundarios si puede escanear desde superposiciones de hardware adicionales y componer o mezclar "sobre la marcha" la imagen final enviada al dispositivo de salida. [33]
Pantalla atómica
En los últimos años, ha habido un esfuerzo continuo para llevar atomicidad a algunas operaciones regulares relacionadas con la API de KMS, específicamente a la configuración del modo y las operaciones de cambio de página . [33] [50] Esta API KMS mejorada es lo que se llama Atómica Display (anteriormente conocido como modo de configuración atómica y atómica o pageflip nuclear ).
El propósito de la configuración del modo atómico es asegurar un cambio de modo correcto en configuraciones complejas con múltiples restricciones, evitando pasos intermedios que podrían conducir a un estado de video inconsistente o inválido; [50] también evita estados de video de riesgo cuando un proceso de configuración de modo fallido tiene que deshacerse ("rollback"). [51] : 9 La configuración del modo atómico permite saber de antemano si cierta configuración de modo específico es apropiada, proporcionando capacidades de prueba de modo. [50] Cuando se prueba un modo atómico y se confirma su validez, se puede aplicar con una sola operación de confirmación indivisible (atómica) . Tanto las operaciones de prueba como las de confirmación las proporciona el mismo ioctl nuevo con diferentes banderas.
El cambio de página atómico, por otro lado, permite actualizar varios planos en la misma salida (por ejemplo, el plano primario, el plano del cursor y tal vez algunas superposiciones o planos secundarios), todos sincronizados dentro del mismo intervalo VBLANK , lo que garantiza una visualización adecuada sin desgarros. [51] : 9,14 [50] Este requisito es especialmente relevante para los controladores de pantalla integrados y móviles, que tienden a utilizar varios planos / superposiciones para ahorrar energía.
La nueva API atómica se basa en la antigua API de KMS. Utiliza el mismo modelo y objetos (CRTC, codificadores, conectores, planos, ...), pero con un número creciente de propiedades de objeto modificables. [50] El procedimiento atómico se basa en cambiar las propiedades relevantes para construir el estado que queremos probar o confirmar. Las propiedades que queremos modificar dependen de si queremos hacer un ajuste de modo (principalmente CRTC, propiedades de codificadores y conectores) o cambio de página (generalmente propiedades de planos). El ioctl es el mismo para ambos casos, la diferencia es la lista de propiedades pasadas con cada uno. [52]
Renderizar nodos
En la API DRM original, el dispositivo DRM se usa para operaciones con privilegios (configuración de modo, otro control de visualización) y sin privilegios (renderizado, cómputo GPGPU ). [9] Por razones de seguridad, abrir el archivo del dispositivo DRM asociado requiere privilegios especiales "equivalentes a los privilegios de root". [53] Esto conduce a una arquitectura en la que solo algunos programas de espacio de usuario confiables (el servidor X, un compositor gráfico, ...) tienen acceso completo a la API DRM, incluidas las partes privilegiadas como la API modeset. El propietario del dispositivo DRM ("DRM Master") debe otorgar el resto de las aplicaciones de espacio de usuario que quieran renderizar o realizar cálculos GPGPU mediante el uso de una interfaz de autenticación especial. [54] Luego, las aplicaciones autenticadas pueden renderizar o realizar cálculos usando una versión restringida de la API DRM sin operaciones privilegiadas. Este diseño impone una restricción severa: siempre debe haber un servidor de gráficos en ejecución (el servidor X, un compositor de Wayland, ...) que actúe como DRM-Master de un dispositivo DRM para que otros programas de espacio de usuario puedan obtener el uso del dispositivo, incluso en casos que no involucran ninguna pantalla gráfica como cálculos GPGPU. [53] [54]/dev/dri/cardX
El concepto de "nodos de renderizado" intenta resolver estos escenarios dividiendo la API de espacio de usuario DRM en dos interfaces, una privilegiada y otra no privilegiada, y usando archivos de dispositivo separados (o "nodos") para cada una. [9] Para cada GPU encontrada, su controlador DRM correspondiente, si es compatible con la función de nodos de renderizado, crea un archivo de dispositivo , llamado nodo de renderizado , además del nodo principal . [54] [9] Los clientes que utilizan un modelo de renderizado directo y aplicaciones que desean aprovechar las instalaciones informáticas de una GPU, pueden hacerlo sin requerir privilegios adicionales simplemente abriendo cualquier nodo de renderizado existente y enviando operaciones de GPU usando el subconjunto limitado de la API de DRM admitida por esos nodos, siempre que tengan permisos del sistema de archivos para abrir el archivo del dispositivo. Los servidores de pantalla, los compositores y cualquier otro programa que requiera la API modeset o cualquier otra operación privilegiada deben abrir el nodo primario estándar que otorga acceso a la API DRM completa y usarlo como de costumbre. Los nodos de renderizado rechazan explícitamente la operación flink de GEM para evitar que se comparta el búfer utilizando nombres globales de GEM inseguros; solo se pueden usar descriptores de archivo PRIME (DMA-BUF) para compartir búferes con otro cliente, incluido el servidor de gráficos. [9] [54]/dev/dri/renderDX
/dev/dri/cardX
Soporte de hardware
El subsistema Linux DRM incluye controladores gratuitos y de código abierto para admitir hardware de los 3 principales fabricantes de GPU para computadoras de escritorio (AMD, NVIDIA e Intel), así como de un número creciente de GPU móviles y System on a chip (SoC). integradores. La calidad de cada conductor varía mucho, dependiendo del grado de cooperación del fabricante y otros asuntos.
Conductor | Desde kernel | Hardware compatible | Soporte de proveedores | Estado / Notas |
---|---|---|---|---|
radeon | 2.4.1 | Serie de GPU AMD (anteriormente ATi) Radeon con las arquitecturas TeraScale y GCN de 1.a y 2.a generación . Incluyendo modelos de R100 / 200 / 300 / 400 , Radeon X1000 , HD 2000 / 4000 / 5000 / 6000 / 7000 / 8000 , R5 / R7 / R9 200 / 300 series y Kaveri APU. | sí | Activo |
i915 | 2.6.9 | Conjuntos de chips Intel GMA 830M, 845G, 852GM, 855GM, 865G, 915G, 945G, 965G, G35, G41, G43, G45. Intel HD e Iris Graphics HD Graphics 2000/3000/2500/4000/4200/4400/4600 / P4600 / P4700 / 5000, Iris Graphics 5100, Iris Pro Graphics 5200 GPU integradas. | sí | Activo |
Nouveau | 2.6.33 [56] [57] | NVIDIA Tesla , Fermi , Kepler , GPU GeForce basadas en Maxwell , Tegra K1 , X1 SoC | Parcial | Activo |
exynos | 3.2 [58] | SoC Exynos basados en ARM de Samsung | ||
vmwgfx | 3.2 (de la puesta en escena) [59] | GPU virtual para VMware SVGA2 | controlador virtual | |
gma500 | 3.3 (de la puesta en escena) [60] [61] | GPU de gráficos basados en Intel GMA 500 y otras tecnologías de imaginación ( PowerVR ) | controlador solo de KMS 2D experimental | |
ast | 3,5 [62] | ASpeed Technologies serie 2000 | experimental | |
mgag200 | 3,5 [63] | Motores de pantalla de servidor Matrox MGA-G200 | Solo KMS | |
shmobile | 3,7 [64] | Renesas SH Mobile | ||
tegra | 3.8 [65] | SoC Nvidia Tegra 20, Tegra30 | sí | Activo |
omapdrm | 3.9 [66] | SoC OMAP 5 de Texas Instruments | ||
rcar-du | 3,11 [67] | Unidades de visualización Renesas R-Car SoC | ||
msm | 3.12 [68] [69] | Qualcomm 's Adreno A2xx / A3XX / A4xx familias GPU ( Snapdragon SOCs) [70] | ||
armada | 3.13 [71] [72] | SoC Marvell Armada 510 | ||
bochs | 3,14 [73] | Tarjetas VGA virtuales que utilizan la interfaz dispi vga de Bochs (como QEMU stdvga) | controlador virtual | |
sti | 3.17 [74] [75] | STMicroelectronics SoC serie stiH41x | ||
imx | 3.19 (de la puesta en escena) [76] [77] | SoC Freescale i.MX | ||
rockchip | 3,19 [76] [78] | GPU basadas en SoC de Rockchip | Solo KMS | |
amdgpu [55] | 4.2 [79] [80] | Serie de GPU AMD Radeon con las arquitecturas GCN de 3.a y 4.a generación . Incluyendo modelos de Radeon Rx 200 / 300 / 400 / 500 [81] serie y Carrizo y Bristol y Stoney de Ridge APUs. | sí | Activo |
virtio | 4.2 [82] | controlador de GPU virtual para administradores de máquinas virtuales basados en QEMU (como KVM o Xen ) | controlador virtual | |
vc4 | 4.4 [83] [84] [85] | Frambuesa Pi 's Broadcom BCM2835 y BCM2836 SoC ( VideoCore IV GPU) | ||
Etnaviv | 4.5 [86] [87] [88] | Núcleos de GPU Vivante que se encuentran en varios SoC como Marvell ARMADA y Freescale i.MX6 Series | ||
sun4i | 4.7 [89] [90] | SoC de Allwinner (GPU ARM Mali-400 ) | ||
Kirin | 4.7 [91] [90] | SoC HiSilicon Kirin hi6220 (GPU ARM Mali 450-MP4 ) | ||
mediatek | 4.7 [92] [90] | SoC MediaTek MT8173 ( GPU Imagination PowerVR GX6250) | ||
hibmc | 4.10 [93] | HiSilicon hi1710 Huawei iBMC SoC ( núcleo de GPU Silicon Image SM750 [94] ) | Solo KMS | |
vboxvideo | 4.13 (de la puesta en escena) [95] [96] | Controlador de GPU virtual para VirtualBox (VBoxVGA GPU) | controlador virtual | |
Lima | 5.2 [97] | GPU ARM Mali 4xx | ||
panfrost | 5.2 [98] | GPU ARM Mali Txxx (Midgard) y Gxx (Bifrost) |
También hay una serie de controladores para hardware antiguo y obsoleto que se detallan en la siguiente tabla con fines históricos. Algunos de ellos aún permanecen en el código del kernel, pero otros ya se han eliminado.
Conductor | Desde kernel | Hardware compatible | Estado / Notas |
---|---|---|---|
gama | 2.3.18 | 3Dlabs GLINT GMX 2000 | Eliminado desde 2.6.14 [99] |
ffb | 2.4 | Creator / Creator3D (utilizado por las estaciones de trabajo Sun Microsystems Ultra ) | Eliminado desde 2.6.21 [100] |
tdfx | 2.4 | 3dfx Banshee / Voodoo3 + | |
mga | 2.4 | Matrox G200 / G400 / G450 | |
r128 | 2.4 | ATI Rage 128 | |
i810 | 2.4 | Intel i810 | |
hermana | 2.4.17 | SiS 300 /630/540 | |
i830 | 2.4.20 | Intel 830M / 845G / 852GM / 855GM / 865G | Eliminado desde 2.6.39 [101] (reemplazado por el controlador i915) |
vía | 2.6.13 [102] | VIA Unichrome / Unichrome Pro | |
salvaje | 2.6.14 [103] | S3 Graphics Savage 3D / MX / IX / 4 / SuperSavage / Pro / Twister |
Desarrollo
Direct Rendering Manager se desarrolla dentro del kernel de Linux y su código fuente reside en el /drivers/gpu/drm
directorio del código fuente de Linux. El encargado del mantenimiento del subsistema es Dave Airlie, y otros encargados del mantenimiento se encargan de controladores específicos. [104] Como es habitual en el desarrollo del kernel de Linux, los submaintainers y contribuyentes de DRM envían sus parches con nuevas características y correcciones de errores al mantenedor principal de DRM, que los integra en su propio repositorio de Linux . El mantenedor de DRM, a su vez, envía todos estos parches que están listos para ser mainline a Linus Torvalds cada vez que se lanza una nueva versión de Linux. Torvalds, como principal responsable de mantenimiento de todo el núcleo, tiene la última palabra sobre si un parche es adecuado o no para su inclusión en el núcleo.
Por razones históricas, el código fuente de la biblioteca libdrm se mantiene bajo el paraguas del proyecto Mesa . [105]
Historia
En 1999, mientras desarrollaba DRI para XFree86 , Precision Insight creó la primera versión de DRM para las tarjetas de video 3dfx , como un parche del kernel de Linux incluido en el código fuente de Mesa . [106] Más tarde ese año, el código DRM se incorporó al kernel 2.3.18 de Linux en el directorio para dispositivos de caracteres . [107] Durante los años siguientes, creció el número de tarjetas de video compatibles. Cuando se lanzó Linux 2.4.0 en enero de 2001, ya existía soporte para Creative Labs GMX 2000, Intel i810, Matrox G200 / G400 y ATI Rage 128, además de las tarjetas 3dfx Voodoo3, [108] y esa lista se expandió durante la 2.4. x, con controladores para tarjetas ATI Radeon , algunas tarjetas de video SiS e Intel 830M y posteriores GPU integradas./drivers/char/drm/
La división de DRM en dos componentes, el núcleo de DRM y el controlador de DRM, denominada división de núcleo de DRM / personalidad se realizó durante la segunda mitad de 2004, [11] [109] y se fusionó en la versión 2.6.11 del kernel. [110] Esta división permitió que varios controladores DRM para varios dispositivos funcionaran simultáneamente, abriendo el camino a la compatibilidad con varias GPU.
La idea de poner todo el código de configuración del modo de video en un lugar dentro del kernel había sido reconocida durante años, [111] [112] pero los fabricantes de tarjetas gráficas habían argumentado que la única forma de hacer la configuración del modo era usar las rutinas proporcionados por ellos mismos y contenidos en el BIOS de video de cada tarjeta gráfica. Dicho código tenía que ejecutarse usando el modo real x86 , lo que impedía que un kernel que se ejecutara en modo protegido lo invocara . [44] La situación cambió cuando Luc Verhaegen y otros desarrolladores encontraron una manera de realizar el ajuste de modo de forma nativa en lugar de hacerlo basado en BIOS, [113] [44] demostrando que era posible hacerlo usando código normal del kernel y sentando las bases para lo que se convertiría en Configuración del modo Kernel . En mayo de 2007, Jesse Barnes ( Intel ) publicó la primera propuesta para una API de configuración de modo drm y una implementación nativa funcional de configuración de modo para GPU Intel dentro del controlador DRM i915. [42] En diciembre de 2007 Jerome Glisse comenzó a agregar el código de configuración de modo nativo para tarjetas ATI al controlador DRM de radeon. [114] [115] El trabajo tanto en la API como en los controladores continuó durante 2008, pero se retrasó por la necesidad de un administrador de memoria también en el espacio del kernel para manejar los framebuffers. [116]
En octubre de 2008, el kernel de Linux 2.6.27 trajo una importante reorganización del código fuente , antes de algunos cambios importantes que se avecinan. El árbol del código fuente DRM se movió a su propio directorio fuente /drivers/gpu/drm/
y los diferentes controladores se movieron a sus propios subdirectorios. Los encabezados también se movieron a un nuevo /include/drm
directorio. [117]
La creciente complejidad de la gestión de la memoria de video llevó a varios enfoques para resolver este problema. El primer intento fue el administrador de memoria Translation Table Maps (TTM), desarrollado por Thomas Hellstrom ( Tungsten Graphics ) en colaboración con Eric Anholt (Intel) y Dave Airlie ( Red Hat ). [5] Se propuso la inclusión de TTM en el núcleo principal 2.6.25 en noviembre de 2007, [5] y nuevamente en mayo de 2008, pero se abandonó en favor de un nuevo enfoque llamado Graphics Execution Manager (GEM). [24] GEM fue desarrollado por primera vez por Keith Packard y Eric Anholt de Intel como una solución más simple para la administración de memoria para su controlador i915. [6] GEM fue bien recibido y se fusionó con la versión 2.6.28 del kernel de Linux lanzada en diciembre de 2008. [118] Mientras tanto, TTM tuvo que esperar hasta septiembre de 2009 para finalmente fusionarse con Linux 2.6.31 como un requisito de la nueva Radeon Controlador KMS DRM. [119]
Con la administración de memoria en su lugar para manejar objetos de búfer, los desarrolladores de DRM finalmente podrían agregar al kernel la API ya terminada y el código para hacer la configuración del modo . Esta API ampliada es lo que se denomina configuración del modo de kernel (KMS) y los controladores que la implementan se denominan a menudo controladores KMS . En marzo de 2009, KMS se fusionó con la versión 2.6.29, [30] [120] del kernel de Linux junto con el soporte de KMS para el controlador i915. [121] La API de KMS ha estado expuesta a programas de espacio de usuario desde libdrm 2.4.3. [122] El controlador X.Org DDX del espacio de usuario para tarjetas gráficas Intel también fue el primero en utilizar las nuevas API de GEM y KMS. [123] La compatibilidad con KMS para el controlador DRM de radeon se agregó a la versión 2.6.31 de Linux de septiembre de 2009. [124] [125] [126] El nuevo controlador KMS de radeon usaba el administrador de memoria TTM pero expuso interfaces e ioctls compatibles con GEM de los TTM. [23]
Desde 2006, el proyecto nouveau ha estado desarrollando un controlador DRM de software gratuito para las GPU NVIDIA fuera del kernel oficial de Linux. En 2010, el código fuente nouveau se fusionó con Linux 2.6.33 como un controlador experimental. [56] [57] En el momento de la fusión, el controlador ya se había convertido a KMS y, detrás de la API de GEM, usaba TTM como administrador de memoria. [127]
La nueva API de KMS, incluida la API de GEM, fue un gran hito en el desarrollo de DRM, pero no impidió que la API se mejorara en los años siguientes. KMS obtuvo soporte para cambios de página junto con notificaciones VBLANK asíncronas en Linux 2.6.33 [128] [129] —sólo para el controlador i915, radeon y nouveau lo agregaron más tarde durante el lanzamiento de Linux 2.6.38. [130] La nueva interfaz de cambio de página se agregó a libdrm 2.4.17. [131] A principios de 2011, durante el ciclo de lanzamiento de Linux 2.6.39, se agregaron a la API de KMS los llamados búferes tontos, una forma no acelerada, independiente del hardware, para manejar búferes simples adecuados para su uso como búfer de marcos. [132] [133] El objetivo era reducir la complejidad de aplicaciones como Plymouth que no necesitan utilizar operaciones especiales aceleradas proporcionadas por ioctls específicos del controlador. [134] La función fue expuesta por libdrm desde la versión 2.4.25 en adelante. [135] Más tarde ese año también ganó un nuevo tipo principal de objetos, llamados aviones . Los planos se desarrollaron para representar superposiciones de hardware compatibles con el motor de exploración. [136] [137] El soporte de Plane se fusionó con Linux 3.3. [138] y libdrm 2.4.30. Otro concepto agregado a la API, durante las versiones de Linux 3.5 [139] y libdrm 2.4.36 [140] , fueron las propiedades de objetos genéricos , un método para agregar valores genéricos a cualquier objeto KMS. Las propiedades son especialmente útiles para establecer comportamientos o características especiales para objetos como CRTC y planos.
Dave Airlie desarrolló una primera prueba de concepto para proporcionar descarga de GPU entre controladores DRM en 2010. [7] [141] Dado que Airlie estaba tratando de imitar la tecnología NVIDIA Optimus , decidió llamarla "PRIME". [7] Airlie reanudó su trabajo en PRIME a finales de 2011, pero basándose en el nuevo mecanismo de intercambio de búfer DMA-BUF introducido por el kernel 3.3 de Linux. [142] La infraestructura básica DMA-BUF PRIME se terminó en marzo de 2012 [143] y se fusionó en la versión 3.4 de Linux, [144] [145] [146] así como en libdrm 2.4.34. [147] Más tarde, durante el lanzamiento de Linux 3.5, varios controladores DRM implementaron soporte PRIME, incluido i915 para tarjetas Intel, radeon para tarjetas AMD y nouveau para tarjetas NVIDIA. [148] [149]
En los últimos años, la API de DRM se ha expandido gradualmente con funciones nuevas y mejoradas. En 2013, como parte de GSoC , David Herrmann desarrolló la función de múltiples nodos de renderizado . [53] Su código fue agregado a la versión 3.12 del kernel de Linux como una característica experimental [150] [151] soportada por los controladores i915, [152] radeon [153] y nouveau [154] , y habilitada por defecto desde Linux 3.17. [75] En 2014 Matt Roper (Intel) desarrolló el concepto de planos universales (o planos unificados ) mediante el cual los framebuffers ( planos primarios ), las superposiciones ( planos secundarios ) y los cursores ( planos del cursor ) se tratan como un solo tipo de objeto con un API unificada. [155] El soporte de planos universales proporciona una API DRM más consistente con menos ioctls más genéricos . [33] Para mantener la API compatible con versiones anteriores , el núcleo DRM expone la función como una capacidad adicional que puede proporcionar un controlador DRM. El soporte de plano universal debutó en Linux 3.15 [156] y libdrm 2.4.55. [157] Varios controladores, como Intel i915, [158] ya lo han implementado.
La mejora más reciente de la API de DRM es la API de configuración de modo atómico , que aporta atomicidad a las operaciones de configuración de modo y cambio de página en un dispositivo DRM. La idea de una API atómica para la configuración de modo se propuso por primera vez a principios de 2012. [159] Ville Syrjälä (Intel) asumió la tarea de diseñar e implementar dicha API atómica. [160] Basado en su trabajo, Rob Clark ( Texas Instruments ) adoptó un enfoque similar con el objetivo de implementar cambios de página atómicos. [161] Más adelante en 2013, ambas características propuestas se reunieron en una sola usando un solo ioctl para ambas tareas. [162] Dado que era un requisito, la función tuvo que esperar a que se fusionara el soporte de aviones universales a mediados de 2014. [158] Durante la segunda mitad de 2014, el código atómico fue mejorado en gran medida por Daniel Vetter (Intel) y otros desarrolladores de DRM [163] : 18 para facilitar la transición de los controladores KMS existentes al nuevo marco atómico. [164] Todo este trabajo se fusionó finalmente en las versiones de Linux 3.19 [165] y Linux 4.0 [166] [167] [168] , y se habilitó de forma predeterminada desde Linux 4.2. [169] libdrm expuso la nueva API atómica desde la versión 2.4.62. [170] Ya se han convertido varios controladores a la nueva API atómica. [171] Para 2018, diez nuevos controladores DRM basados en este nuevo modelo atómico se habían agregado al kernel de Linux. [172]
Adopción
El subsistema del kernel Direct Rendering Manager se desarrolló inicialmente para ser utilizado con la nueva Infraestructura de Representación Directa del servidor de pantalla XFree86 4.0, heredado más tarde por su sucesor, el X.Org Server . Por lo tanto, los principales usuarios de DRM fueron los clientes de DRI que se vinculan a la implementación de OpenGL acelerada por hardware que vive en la biblioteca Mesa 3D , así como al propio X Server. Hoy en día, DRM también es utilizado por varios compositores de Wayland , incluido el compositor de referencia Weston . kmscon es una implementación de consola virtual que se ejecuta en el espacio del usuario utilizando las instalaciones de DRM KMS. [173]
En 2015, la versión 358.09 (beta) del controlador propietario de Nvidia GeForce recibió soporte para la interfaz de configuración del modo DRM implementada como un nuevo blob del kernel llamado nvidia-modeset.ko
. Este nuevo componente de controlador funciona junto con el nvidia.ko
módulo del kernel para programar el motor de visualización (es decir, el controlador de visualización) de la GPU. [174]
Ver también
- Infraestructura de renderizado directo
- Controlador de dispositivo gráfico gratuito y de código abierto
- Framebuffer de Linux
Referencias
- ^ "Kernel de Linux / drivers / gpu / drm / README.drm" . kernel.org . Archivado desde el original el 26 de febrero de 2014 . Consultado el 26 de febrero de 2014 .
- ^ a b Uytterhoeven, Geert. "El dispositivo Frame Buffer" . Kernel.org . Consultado el 28 de enero de 2015 .
- ^ a b c White, Thomas. "Cómo funcionan DRI y DRM" . Consultado el 22 de julio de 2014 .
- ^ Faith, Rickard E. (11 de mayo de 1999). "El administrador de renderizado directo: soporte de kernel para la infraestructura de renderizado directo" . Consultado el 12 de mayo de 2016 .
- ^ a b c d e f g h Corbet, Jonathan (6 de noviembre de 2007). "Gestión de memoria para procesadores gráficos" . LWN.net . Consultado el 23 de julio de 2014 .
- ^ a b c d e f g Packard, Keith; Anholt, Eric (13 de mayo de 2008). "GEM - el administrador de ejecución de gráficos" . lista de correo dri-devel . Consultado el 23 de julio de 2014 .
- ^ a b c Airlie, Dave (12 de marzo de 2010). "Descarga de GPU - PRIME - prueba de concepto" . Archivado desde el original el 10 de febrero de 2015 . Consultado el 10 de febrero de 2015 .
- ^ a b c d e Cocinando, Simon. "Módulos de kernel DRM y KMS" . Consultado el 13 de mayo de 2016 .
- ^ a b c d e Herrmann, David (1 de septiembre de 2013). "División de nodos de dispositivos DRM y KMS" . Consultado el 23 de julio de 2014 .
- ^ "README.rst - mesa / drm - módulos de kernel y encabezados de Direct Rendering Manager" . 2020-03-21. Archivado desde el original el 21 de marzo de 2020.
- ^ a b Airlie, Dave (4 de septiembre de 2004). "Nueva propuesta de diseño de interfaz DRM" . dri-devel (lista de correo).
- ^ a b c d e f g Peres, Martin; Ravier, Timothée (2 de febrero de 2013). "DRI-next / DRM2: un recorrido por la pila de gráficos de Linux y su seguridad" (PDF) . Consultado el 13 de mayo de 2016 .
- ^ Høgsberg, Kristian (4 de septiembre de 2008). "La Extensión DRI2 - Versión 2.0" . X.Org . Consultado el 23 de mayo de 2016 .
- ^ a b c d e f Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. "Guía del desarrollador del controlador de GPU de Linux - Gestión de memoria" . Consultado el 31 de agosto de 2016 .
- ^ Vetter, Daniel. "i915 / GEM Crashcourse por Daniel Vetter" . Centro de tecnología de código abierto de Intel . Consultado el 31 de enero de 2015 .
GEM esencialmente se ocupa de los objetos de búfer de gráficos (que pueden contener texturas, búferes de representación, sombreadores o todo tipo de otros objetos de estado y datos utilizados por la gpu)
- ^ a b c Vetter, Daniel (4 de mayo de 2011). "Descripción general de GEM" . Consultado el 13 de febrero de 2015 .
- ^ Packard, Keith (28 de septiembre de 2012). "Pensamientos sobre DRI.Next" . Consultado el 26 de mayo de 2016 .
GEM flink tiene muchos problemas. Los nombres de flink son globales, lo que permite que cualquier persona con acceso al dispositivo acceda al contenido de los datos de flink.
- ^ a b Herrmann, David (2 de julio de 2013). "Seguridad DRM" . Actas de la Conferencia de desarrolladores de X.Org 2013 (XDC2013) . Consultado el 13 de febrero de 2015 .
gem-flink no proporciona espacios de nombres privados para aplicaciones y servidores. En su lugar, solo se proporciona un espacio de nombres global por nodo DRM. Las aplicaciones autenticadas maliciosas pueden atacar a otros clientes mediante la "adivinación de nombres" por la fuerza bruta de los búferes de gemas.
- ^ Kerrisk, Michael (25 de septiembre de 2012). "XDC2012: seguridad de la pila de gráficos" . LWN.net . Consultado el 25 de noviembre de 2015 .
- ^ a b Packard, Keith (4 de julio de 2008). "actualización de gemas" . Consultado el 25 de abril de 2016 .
- ^ "página de manual de drm-memory" . Manuales de Ubuntu . Consultado el 29 de enero de 2015 .
Muchas GPU modernas de gama alta vienen con sus propios administradores de memoria. Incluso incluyen varios cachés diferentes que deben sincronizarse durante el acceso. [...]. Por lo tanto, la administración de la memoria en las GPU depende en gran medida del controlador y del hardware.
- ^ "Guía del desarrollador del acelerador de medios gráficos Intel" . Intel Corporation . Consultado el 24 de noviembre de 2015 .
- ^ a b c Larabel, Michael (26 de agosto de 2008). "Un administrador TTM mejorado para Radeon" . Phoronix . Consultado el 24 de abril de 2016 .
- ^ a b c Corbet, Jonathan (28 de mayo de 2008). "GEM v. TTM" . LWN.net . Consultado el 10 de febrero de 2015 .
- ^ Corbet, Jonathan (11 de enero de 2012). "Compartición de búfer DMA en 3.3" . LWN.net . Consultado el 14 de mayo de 2016 .
- ^ Clark, Rob; Semwal, Sumit. "Marco de intercambio de búfer DMA: una introducción" (PDF) . Consultado el 14 de mayo de 2016 .
- ^ Peres, Martin (26 de septiembre de 2014). "La pila de gráficos de Linux, Optimus y el controlador Nouveau" (PDF) . Consultado el 14 de mayo de 2016 .
- ^ Pinchart, Laurent (20 de febrero de 2013). "Anatomía de un controlador KMS integrado" (PDF) . Consultado el 27 de junio de 2016 .
- ^ Edge, Jake (9 de octubre de 2013). "DRI3 y Presente" . LWN.net . Consultado el 28 de mayo de 2016 .
- ^ a b c d "Linux 2.6.29 - Configuración del modo del kernel" . Principiantes del kernel de Linux . Consultado el 19 de noviembre de 2015 .
- ^ "Hardware VGA" . OSDev.org . Consultado el 23 de noviembre de 2015 .
- ^ Rathmann, B. (15 de febrero de 2008). "El estado de Nouveau, parte I" . LWN.net . Consultado el 23 de noviembre de 2015 .
Las tarjetas gráficas se programan de diversas formas, pero la mayoría de las configuraciones de inicialización y modo se realizan a través de E / S mapeadas en memoria. Este es solo un conjunto de registros accesibles a la CPU a través de su espacio de direcciones de memoria estándar. Los registros en este espacio de direcciones se dividen en rangos que se ocupan de varias características de la tarjeta gráfica, como la configuración del modo, el control de salida o la configuración del reloj.
- ^ a b c d e Paalanen, Pekka (5 de junio de 2014). "Desde la prehistoria hasta más allá de la guerra termonuclear global" . Consultado el 29 de julio de 2014 .
- ^ "página de manual de drm-kms" . Manuales de Ubuntu . Consultado el 19 de noviembre de 2015 .
- ^ Corbet, Jonathan (13 de enero de 2010). "¿El fin de la configuración del modo de espacio de usuario?" . LWN.net . Consultado el 20 de noviembre de 2015 .
- ^ a b "Discusión de diseño de configuración de modo" . Wiki de X.Org . Consultado el 19 de noviembre de 2015 .
- ^ a b Corbet, Jonathan (22 de enero de 2007). "LCA: Actualizaciones en el sistema X Window" . LWN.net . Consultado el 23 de noviembre de 2015 .
- ^ "Página de manual de XF86VIDMODE" . X.Org . Consultado el 23 de abril de 2016 .
- ^ "Notas de la versión X11R6.1" . X.Org . 14 de marzo de 1996 . Consultado el 23 de abril de 2016 .
- ^ Corbet, Jonathan (20 de julio de 2004). "Kernel Summit: controladores de video" . LWN.net . Consultado el 23 de noviembre de 2015 .
- ^ a b "Fedora - Funciones / KernelModeSetting" . Proyecto Fedora . Consultado el 20 de noviembre de 2015 .
Históricamente, el servidor X era responsable de guardar el estado de salida cuando se iniciaba y luego restaurarlo cuando volvía al modo de texto. El cambio de usuario rápido se logró con un conmutador VT, por lo que el cambio desde el servidor X del primer usuario parpadearía una vez para ir al modo de texto y luego volvería a parpadear inmediatamente para ir a la sesión del segundo usuario.
- ^ a b c d e Barnes, Jesse (17 de mayo de 2007). "[RFC] mejorando el subsistema de gráficos del kernel" . linux-kernel (lista de correo).
- ^ a b c "DrmModesetting - Mejora de los gráficos del kernel" . DRI Wiki . Consultado el 23 de noviembre de 2015 .
- ^ a b c d e Packard, Keith (16 de septiembre de 2007). "controladores en modo kernel" . Consultado el 30 de abril de 2016 .
- ^ a b Packard, Keith (24 de abril de 2000). "Afilado del enfoque del controlador Intel" . Consultado el 23 de mayo de 2016 .
Una limitación más sutil es que el controlador no podía manejar las interrupciones, por lo que no había ningún soporte de monitor de conexión en caliente.
- ^ Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. "Guía del desarrollador del controlador de GPU de Linux: inicialización del controlador" . Consultado el 31 de agosto de 2016 .
- ^ a b c d e f g Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. "Guía del desarrollador del controlador de GPU de Linux - Inicialización y limpieza de KMS" . Consultado el 31 de agosto de 2016 .
- ^ a b "Tarjetas de video" . Wiki de X.Org . Consultado el 11 de abril de 2016 .
- ^ a b Deucher, Alex (15 de abril de 2010). "Notas sobre el hardware de pantalla Radeon" . Archivado desde el original el 5 de abril de 2016 . Consultado el 8 de abril de 2016 .
- ^ a b c d e Vetter, Daniel (5 de agosto de 2015). "Descripción general del diseño de la configuración del modo atómico, parte 1" . LWN.net . Consultado el 7 de mayo de 2016 .
- ^ a b Reding, Thierry (1 de febrero de 2015). "Configuración del modo atómico" (PDF) . Archivos FOSDEM . Consultado el 7 de mayo de 2016 .
- ^ Vetter, Daniel (12 de agosto de 2015). "Descripción general del diseño de configuración del modo atómico, parte 2" . LWN.net . Consultado el 7 de mayo de 2016 .
- ^ a b c Herrmann, David (29 de mayo de 2013). "DRM Render- y Modeset-Nodos" . Consultado el 21 de julio de 2014 .
- ^ a b c d Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. "Guía del desarrollador del controlador de GPU de Linux - Renderizar nodos" . Consultado el 31 de agosto de 2016 .
- ^ a b Deucher, Alex (20 de abril de 2015). "Versión inicial del controlador amdgpu" . dri-devel (lista de correo).
- ^ a b "Linux 2.6.33 - Nouveau, un controlador para tarjetas gráficas Nvidia" . Principiantes del kernel de Linux . Consultado el 26 de abril de 2016 .
- ^ a b "drm / nouveau: agregue el controlador DRM para las GPU NVIDIA" . Kernel.org . Consultado el 27 de enero de 2015 .
- ^ "DRM: agregue el controlador DRM para Samsung SoC EXYNOS4210" . Kernel.org . Consultado el 3 de marzo de 2016 .
- ^ "vmwgfx: saca el controlador de la etapa de preparación" . Kernel.org . Consultado el 3 de marzo de 2016 .
- ^ "Linux 3.3 - DriverArch - Gráficos" . Principiantes del kernel de Linux . Consultado el 3 de marzo de 2016 .
- ^ Larabel, Michael (10 de enero de 2012). "El tirón DRM de Linux 3.3 tiene muchas mejoras" . Phoronix . Consultado el 3 de marzo de 2016 .
- ^ "drm: controlador KMS inicial para AST (ASpeed Technologies) serie 2000 (v2)" . Kernel.org . Consultado el 3 de marzo de 2016 .
- ^ Airlie, Dave (17 de mayo de 2012). "mgag200: controlador inicial g200se (v2)" . Consultado el 24 de enero de 2018 .
- ^ "drm: controlador DRM de Renesas SH Mobile" . Kernel.org . Consultado el 3 de marzo de 2016 .
- ^ "drm: agregue soporte NVIDIA Tegra20" . Kernel.org . Consultado el 3 de marzo de 2016 .
- ^ "drm / omap: salir de la puesta en escena" . Kernel.org . Consultado el 3 de marzo de 2016 .
- ^ "drm: controlador DRM Renesas R-Car Display Unit" . Kernel.org . Consultado el 3 de marzo de 2016 .
- ^ "drm / msm: controlador KMS básico para snapdragon" . Kernel.org . Consultado el 3 de marzo de 2016 .
- ^ Larabel, Michael (28 de agosto de 2013). "Controlador Snapdragon DRM / KMS combinado para Linux 3.12" . Phoronix . Consultado el 26 de enero de 2015 .
- ^ Edge, Jake (8 de abril de 2015). "Una actualización del controlador de gráficos freedreno" . LWN.net . Consultado el 23 de abril de 2015 .
- ^ King, Russell (18 de octubre de 2013). "[GIT PULL] Soporte Armada DRM" . dri-devel (lista de correo).
- ^ "DRM: Armada: Agregar controlador DRM de Armada" . Kernel.org . Consultado el 3 de marzo de 2016 .
- ^ "drm / bochs: nuevo controlador" . Kernel.org . Consultado el 3 de marzo de 2016 .
- ^ Larabel, Michael (8 de agosto de 2014). "Linux 3.17 DRM Pull trae nuevo controlador de gráficos" . Phoronix . Consultado el 3 de marzo de 2016 .
- ^ a b Corbet, Jonathan (13 de agosto de 2014). "3.17 ventana de combinación, parte 2" . LWN.net . Consultado el 7 de octubre de 2014 .
- ^ a b Corbet, Jonathan (17 de diciembre de 2014). "3.19 Fusionar parte 2 de la ventana" . LWN.net . Consultado el 9 de febrero de 2015 .
- ^ "drm: imx: Mueva el controlador imx-drm fuera de la etapa de preparación" . Kernel.org . Consultado el 9 de febrero de 2015 .
- ^ "drm: rockchip: agregar controlador drm básico" . Kernel.org . Consultado el 3 de marzo de 2016 .
- ^ Larabel, Michael (25 de junio de 2015). "Actualizaciones DRM de Linux 4.2: mucha atención de AMD, sin cambios en el controlador Nouveau" . Phoronix . Consultado el 31 de agosto de 2015 .
- ^ Corbet, Jonathan (1 de julio de 2015). "4.2 Fusionar parte de la ventana 2" . LWN.net . Consultado el 31 de agosto de 2015 .
- ^ Deucher, Alex (3 de agosto de 2015). "[PATCH 00/11] Agregar soporte de Fiji" . dri-devel (lista de correo).
- ^ "Agregar controlador virtio gpu" . Kernel.org . Consultado el 3 de marzo de 2016 .
- ^ Corbet, Jonathan (11 de noviembre de 2015). "4.4 Ventana de fusión, parte 1" . LWN.net . Consultado el 11 de enero de 2016 .
- ^ Larabel, Michael (15 de noviembre de 2015). "Una mirada a las nuevas características del kernel de Linux 4.4" . Phoronix . Consultado el 11 de enero de 2016 .
- ^ "drm / vc4: agregar soporte KMS para Raspberry Pi" . Kernel.org .
- ^ Larabel, Michael (24 de enero de 2016). "Las muchas características nuevas y mejoras del kernel de Linux 4.5" . Phoronix . Consultado el 14 de marzo de 2016 .
- ^ Corbet, Jonathan (20 de enero de 2016). "4.5 ventana de fusión parte 2" . LWN.Net . Consultado el 14 de marzo de 2016 .
- ^ "Combinar etiqueta 'sun4i-drm-for-4.7 ' " . Kernel.org .
- ^ a b c Airlie, Dave (23 de mayo de 2016). "[git pull] drm para v4.7" . dri-devel (lista de correo).
- ^ "Combinar etiqueta 'drm-hisilicon-next-2016-04-29 ' " . Kernel.org .
- ^ "Combinar etiqueta 'mediatek-drm-2016-05-09 ' " . Kernel.org .
- ^ Larabel, Michael (22 de noviembre de 2016). "Se está agregando el controlador Hisilicon Hibmc DRM para Linux 4.10" . Phoronix . Consultado el 24 de enero de 2018 .
- ^ "Informe técnico de Huawei FusionServer RH5885 V3" . 18 de noviembre de 2016. Archivado desde el original el 25 de enero de 2018.
utiliza un chip de pantalla integrado que está integrado en el chip de gestión Hi1710 y utiliza el núcleo IP del SM750
- ^ "staging: vboxvideo: agregar vboxvideo a los controladores / staging" . git.kernel.org . Consultado el 2 de marzo de 2021 .
- ^ Larabel, Michael (9 de junio de 2017). "El controlador de gráficos VirtualBox DRM / KMS se está preparando para el núcleo de la línea principal" . Phoronix . Consultado el 2 de marzo de 2021 .
- ^ "kernel / git / torvalds / linux.git - árbol de fuentes del kernel de Linux" . git.kernel.org . Consultado el 28 de noviembre de 2019 .
- ^ "kernel / git / torvalds / linux.git - árbol de fuentes del kernel de Linux" . git.kernel.org . Consultado el 28 de noviembre de 2019 .
- ^ "drm: quitar el controlador gamma" . Kernel.org . Consultado el 27 de enero de 2015 .
- ^ "[DRM]: Elimina el código del controlador sparc64 FFB que nunca se crea" . Kernel.org . Consultado el 27 de enero de 2015 .
- ^ "drm: eliminar el controlador i830" . Kernel.org . Consultado el 27 de enero de 2015 .
- ^ "drm: agregar mediante soporte unicromo" . Kernel.org . Consultado el 27 de enero de 2015 .
- ^ "drm: agregar controlador salvaje" . Kernel.org . Consultado el 27 de enero de 2015 .
- ^ "Lista de mantenedores del kernel de Linux" . Kernel.org . Consultado el 14 de julio de 2014 .
- ^ "repositorio libdrm git" . Consultado el 23 de julio de 2014 .
- ^ "Primera versión DRI del controlador 3dfx" . Mesa 3D . Consultado el 15 de julio de 2014 .
- ^ "Importar 2.3.18pre1" . La historia de Linux en formato de repositorio GIT 1992-2010 (2010) . Consultado el 15 de julio de 2014 .
- ^ Torvalds, Linus. "Código fuente de Linux 2.4.0" . Kernel.org . Consultado el 29 de julio de 2014 .
- ^ Airlie, Dave (30 de diciembre de 2004). "[bk pull] drm core / personalidad dividida" . linux-kernel (lista de correo).
- ^ Torvalds, Linus (11 de enero de 2005). "Linux 2.6.11-rc1" . linux-kernel (lista de correo).
- ^ Gettys, James; Packard, Keith (15 de junio de 2004). "La (Re) Arquitectura del Sistema X Window" . Consultado el 30 de abril de 2016 .
- ^ Smirl, Jon (30 de agosto de 2005). "El estado de los gráficos de Linux" . Consultado el 30 de abril de 2016 .
Creo que la mejor solución a este problema es que el kernel proporcione un controlador de dispositivo único y completo para cada pieza de hardware de video. Esto significa que los controladores conflictivos como fbdev y DRM deben fusionarse en un sistema cooperativo. También significa que debe evitarse extraer hardware del espacio del usuario mientras se carga un controlador de dispositivo basado en el kernel.
- ^ Verhaegen, Luc (2 de marzo de 2006). "X y Modesetting: atrofia ilustrada" (PDF) . Consultado el 30 de abril de 2016 .
- ^ Glisse, Jerome (4 de diciembre de 2007). "Configuración del modo del kernel de Radeon" . Consultado el 30 de abril de 2016 .
- ^ Larabel, Michael (1 de octubre de 2008). "El estado de la configuración del modo del kernel" . Phoronix . Consultado el 30 de abril de 2016 .
- ^ Packard, Keith (21 de julio de 2008). "X estado de salida julio de 2008" . Consultado el 1 de mayo de 2016 .
- ^ "drm: reorganizar el árbol drm para que sea más preparado para el futuro" . Kernel.org .
- ^ "Linux 2.6.28 - El administrador de memoria GEM para la memoria de la GPU" . Principiantes del kernel de Linux . Consultado el 23 de julio de 2014 .
- ^ "drm: agregue el subsistema del administrador de memoria de la GPU de TTM" . Kernel.org .
- ^ "DRM: agregar soporte de configuración de modo" . Kernel.org .
- ^ "DRM: i915: agregar soporte de configuración de modo" . Kernel.org .
- ^ Anholt, Eric (22 de diciembre de 2008). "[ANUNCIO] libdrm-2.4.3" . dri-devel (lista de correo).
- ^ Barnes, Jesse (20 de octubre de 2008). "[ANUNCIO] xf86-video-intel 2.5.0" . xorg -noun (lista de correo).
- ^ "Linux 2.6.31 - Compatibilidad con la configuración del modo de kernel de ATI Radeon" . Principiantes del kernel de Linux . Archivado desde el original el 5 de noviembre de 2015 . Consultado el 28 de abril de 2016 .
- ^ Torvalds, Linus (9 de septiembre de 2009). "Linux 2.6.31" . linux-kernel (lista de correo).
- ^ "drm / radeon: introduce la configuración del modo del kernel para hardware radeon" . Kernel.org .
- ^ "El compañero irregular de desarrollo Nouveau # 40" . Proyecto Nouveau . Consultado el 3 de mayo de 2016 .
- ^ "Linux 2.6.33 - Mejoras gráficas" . Principiantes del kernel de Linux . Consultado el 28 de abril de 2016 .
- ^ "drm / kms: agregar ioctl de volteo de página" . Kernel.org .
- ^ "Linux 2.6.38 - Gráficos" . Principiantes del kernel de Linux . Consultado el 28 de abril de 2016 .
- ^ Airlie, Dave (21 de diciembre de 2009). "[ANUNCIO] libdrm 2.4.17" . dri-devel (lista de correo).
- ^ "drm: creación de escaneo tonto / mmap para intel / radeon (v3)" . Kernel.org .
- ^ "Linux 2 6 39-DriversArch" . Principiantes del kernel de Linux . Consultado el 19 de abril de 2016 .
- ^ Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. "Guía del desarrollador del controlador de GPU de Linux - Objetos de búfer tontos" . Consultado el 31 de agosto de 2016 .
- ^ Wilson, Chris (11 de abril de 2011). "[ANUNCIO] libdrm 2.4.25" . dri-devel (lista de correo).
- ^ Barnes, Jesse (25 de abril de 2011). "[RFC] drm: agregar superposiciones como objetos KMS de primera clase" . dri-devel (lista de correo).
- ^ Barnes, Jesse (13 de mayo de 2011). "[RFC] drm: agregar superposiciones como objetos KMS de primera clase" . dri-devel (lista de correo).
- ^ "drm: agregar soporte de avión v3" . Kernel.org .
- ^ "drm: agregue ioctls genéricos para obtener / establecer propiedades en cualquier objeto" . Kernel.org .
- ^ Widawsky, Ben (27 de junio de 2012). "[ANUNCIO] libdrm 2.4.36" . xorg -noun (lista de correo).
- ^ Larabel, Michael. "Prueba de concepto: ¡Renderizado de múltiples GPU de código abierto!" . Phoronix . Consultado el 14 de abril de 2016 .
- ^ Larabel, Michael (23 de febrero de 2012). "DRM Base PRIME Support parte del trabajo de VGEM" . Phoronix . Consultado el 14 de abril de 2016 .
- ^ Airlie, Dave (27 de marzo de 2012). "[PATCH] drm: soporte base prime / dma-buf (v5)" . dri-devel (lista de correo).
- ^ Larabel, Michael (30 de marzo de 2012). "Último minuto para Linux 3.4: soporte DMA-BUF PRIME" . Phoronix . Consultado el 15 de abril de 2016 .
- ^ "drm: soporte base prime / dma-buf (v5)" . Kernel.org .
- ^ "Linux 3.4 DriverArch" . Principiantes del kernel de Linux . Consultado el 15 de abril de 2016 .
- ^ Anholt, Eric (10 de mayo de 2012). "[ANUNCIO] libdrm 2.4.34" . dri-devel (lista de correo).
- ^ Larabel, Michael (12 de mayo de 2012). "DMA-BUF PRIME se unen para Linux 3.5" . Phoronix . Consultado el 15 de abril de 2016 .
- ^ "Linux 3.5 DriverArch" . Principiantes del kernel de Linux . Consultado el 15 de abril de 2016 .
- ^ Corbet, Jonathan (11 de septiembre de 2013). "3.12 ventana de combinación, parte 2" . LWN.net . Consultado el 21 de julio de 2014 .
- ^ "drm: implementar nodos de renderización experimentales" . Kernel.org .
- ^ "drm / i915: admite nodos de renderizado" . Kernel.org .
- ^ "drm / radeon: admite nodos de renderizado" . Kernel.org .
- ^ "drm / nouveau: soporte de renderizado de nodos" . Kernel.org .
- ^ Roper, Matt (7 de marzo de 2014). "[RFCv2 00/10] Soporte de plano universal" . dri-devel (lista de correo).
- ^ Larabel, Michael (2 de abril de 2014). "Conjunto de soporte de plano universal para Linux 3.15" . Phoronix . Consultado el 14 de abril de 2016 .
- ^ Lankhorst, Maarten (25 de julio de 2014). "[ANUNCIO] libdrm 2.4.55" . dri-devel (lista de correo).
- ^ a b Vetter, Daniel (7 de agosto de 2014). "Cosas interesantes por 3,17" . Consultado el 14 de abril de 2016 .
- ^ Barnes, Jesse (15 de febrero de 2012). "[RFC] drm: API de conjunto de modo atómico" . dri-devel (lista de correo).
- ^ Syrjälä, Ville (24 de mayo de 2012). "[RFC] [PATCH 0/6] WIP: drm: idea de configuración del modo atómico" . dri-devel (lista de correo).
- ^ Clark, Rob (9 de septiembre de 2012). "[RFC 0/9] volteo de página nuclear" . dri-devel (lista de correo).
- ^ Clark, Rob (6 de octubre de 2013). "[RFCv1 00/12] Modeset atómico / nuclear / pageflip" . dri-devel (lista de correo).
- ^ Vetter, Daniel (3 de febrero de 2016). "Adopte la era de las pantallas atómicas" (PDF) . Consultado el 4 de mayo de 2016 .
- ^ Vetter, Daniel (2 de noviembre de 2014). "Soporte de Atomic Modeset para controladores KMS" . Consultado el 4 de mayo de 2016 .
- ^ Airlie, Dave (14 de diciembre de 2014). "[git pull] drm para 3.19-rc1" . dri-devel (lista de correo).
- ^ Vetter, Daniel (28 de enero de 2015). "Actualización para actualizaciones de pantalla atómica" . Consultado el 4 de mayo de 2016 .
- ^ Airlie, Dave (15 de febrero de 2015). "[git pull] drm pull para 3.20-rc1" . dri-devel (lista de correo).
- ^ "Linux 4.0 - DriverArch - Gráficos" . Principiantes del kernel de Linux . Consultado el 3 de mayo de 2016 .
- ^ "Linux 4.2 - API de configuración de modo atómico habilitada por defecto" . Principiantes del kernel de Linux . Consultado el 3 de mayo de 2016 .
- ^ Velikov, Emil (29 de junio de 2015). "[ANUNCIO] libdrm 2.4.62" . dri-devel (lista de correo).
- ^ Vetter, Daniel (6 de junio de 2016). "Impresionantes avances atómicos" . Consultado el 7 de junio de 2016 .
ahora mismo hay 17 controladores que admiten la configuración del modo atómico fusionados en el subsistema DRM
- ^ Stone, Daniel (20 de marzo de 2018). "Una nueva era para los gráficos de bajo nivel de Linux - Parte 1" . Consultado el 5 de mayo de 2018 .
- ^ Herrmann, David (10 de diciembre de 2012). "Introducción a KMSCON" . Consultado el 22 de noviembre de 2015 .
- ^ "Controlador de Linux, Solaris y FreeBSD 358.09 (beta)" . 2015-12-10.
enlaces externos
- Página de inicio de DRM
- Guía del desarrollador del controlador de GPU de Linux (anteriormente , Guía del desarrollador de DRM de Linux )
- Conferencia de Linux integrado 2013: anatomía de un controlador KMS integrado en YouTube