Hispanopedia Wiki
Articulo de referencia

Gerente de renderizado directo

El Direct Rendering Manager ( DRM ) es un subsistema del kernel de Linux responsable de la interfaz con las GPU de las tarjetas de video modernas . DRM expone una API que los pr...

Hispanopedia WikiContenido en espanolLectura gratuita

El Direct Rendering Manager ( DRM ) es un subsistema del kernel de Linux responsable de la interfaz con las GPU de las tarjetas de video modernas . 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 visualización. DRM se desarrolló inicialmente como el componente de espacio de kernel de la infraestructura de renderizado directo del servidor X , [ 1 ] pero desde entonces ha sido utilizado por otras alternativas de pila gráfica como Wayland y aplicaciones y bibliotecas independientes como SDL2 y Kodi .

Los programas en espacio de usuario pueden usar la API DRM para ordenar a la GPU que realice renderizado 3D acelerado por hardware y decodificación de vídeo , así como computación GPGPU .

Descripción general

El kernel de Linux ya contaba con una API llamada fbdev , utilizada para gestionar el framebuffer de un adaptador gráfico , [ 2 ] pero no podía utilizarse para satisfacer las necesidades del hardware de vídeo moderno basado en GPU acelerado por 3D . Estos dispositivos suelen requerir la configuración y gestión de una cola de comandos en su propia memoria para enviar comandos a la GPU, así como la gestión de búferes y espacio libre dentro de esa memoria. [ 3 ] Inicialmente, los programas de espacio de usuario (como el servidor X ) gestionaban directamente estos recursos, pero generalmente actuaban como si fueran los únicos con acceso a ellos. Cuando dos o más programas intentaban controlar el mismo hardware simultáneamente y configurar sus recursos cada uno a su manera, en la mayoría de los casos el resultado era catastrófico. [ 3 ]

Acceso a la tarjeta de vídeo sin DRM
Sin DRM
Acceso a tarjeta de video con DRM
Con DRM
La gestión de derechos digitales (DRM) permite que varios programas accedan simultáneamente a la tarjeta de vídeo 3D, evitando colisiones.

El Administrador de Renderizado Directo (DRM) se creó para permitir que varios programas utilicen los 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 al DRM, que actúa como árbitro y se encarga de evitar posibles conflictos.

El alcance de DRM se ha ampliado a lo largo de los años para abarcar más funcionalidades que antes gestionaban los programas del espacio de usuario, como la administración del búfer de fotogramas y la configuración del modo , los objetos de memoria compartida y la sincronización de memoria. [ 5 ] [ 6 ] Algunas de estas ampliaciones recibieron nombres específicos, como Gestor de Ejecución Gráfica (GEM) o configuración del modo del kernel (KMS), y la terminología prevalece cuando se alude específicamente a la funcionalidad que proporcionan. Pero en realidad son partes del subsistema DRM del kernel.

La tendencia a incluir dos GPU en un ordenador —una GPU dedicada 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 , se dotó a DRM de capacidades de descarga de GPU, denominadas PRIME. [ 7 ]

Arquitectura de software

Un proceso que utiliza el Administrador de renderizado directo del kernel de Linux para acceder a una tarjeta gráfica con aceleración 3D.

El Direct Rendering Manager reside en el espacio del kernel , por lo que los programas del 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, usando archivos de dispositivo bajo la /devjerarquí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 del espacio de usuario que quieran hablar con la GPU deben abrir este archivo y usar llamadas ioctl para comunicarse con DRM. Diferentes ioctl corresponden a diferentes funciones de la API de 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 una envoltura que proporciona una función escrita en C para cada ioctl de la API de 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 también presenta las ventajas habituales de reutilizar y compartir código entre programas.

Detalles de la arquitectura del Direct Rendering Manager: Núcleo DRM y controlador DRM (incluidos GEM y KMS) con interfaz a través de libdrm.

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 los diferentes controladores DRM pueden registrarse y también proporciona al espacio de usuario un conjunto mínimo de ioctls con funcionalidad común e independiente del hardware. [ 8 ] Un controlador DRM, por otro lado, implementa la parte de la API dependiente del hardware, 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 extra disponible solo en dicho hardware. [ 8 ] Cuando un controlador DRM específico proporciona una API mejorada, la biblioteca libdrm del espacio de usuario también se extiende con una biblioteca adicional libdrm- driver que puede ser utilizada por el espacio de usuario para interactuar con los ioctls adicionales.

API

El núcleo DRM exporta varias interfaces a aplicaciones de espacio de usuario, generalmente destinadas a ser utilizadas mediante libdrmfunciones de envoltura correspondientes. Además, los controladores exportan interfaces específicas del dispositivo para su uso por parte de controladores de espacio de usuario y aplicaciones que reconocen el dispositivo a través de llamadas ioctl y archivos sysfs . Las interfaces externas incluyen: asignación de memoria, gestión de contexto, operaciones DMA , gestión AGP , control de vblank , gestión de barreras, gestión de memoria y gestió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 a un único proceso de espacio de usuario por dispositivo. [ 8 ] Para implementar esta restricción, DRM limita dichas ioctls a ser invocadas únicamente por el proceso considerado el "maestro" de un dispositivo DRM, generalmente llamado DRM-Master . Solo uno de todos los procesos que tengan abierto el nodo del dispositivo tendrá su identificador de archivo marcado como maestro, específicamente el primero que llame a la ioctl SET_MASTER . Cualquier intento de usar una de estas ioctls restringidas sin ser el DRM-Master devolverá un error. Un proceso también puede renunciar a su rol de maestro —y dejar que otro proceso lo adquiera— llamando a la ioctl DROP_MASTER ./dev/dri/cardX

El servidor X —o cualquier otro servidor de visualización— suele ser el proceso que adquiere el estado de DRM-Master en cada dispositivo DRM que administra, normalmente cuando abre el nodo del dispositivo correspondiente durante su inicio, y mantiene estos privilegios durante toda la sesión gráfica hasta que finaliza o se detiene.

Para los procesos restantes del espacio de usuario, existe otra forma de obtener el privilegio de invocar algunas operaciones restringidas en el dispositivo DRM, denominada DRM-Auth . Básicamente, se trata de un método de autenticación contra el dispositivo DRM para demostrarle que el proceso cuenta con la aprobación del DRM-Master para obtener dichos privilegios. El procedimiento consiste en: [ 12 ] : 13

  • El cliente obtiene un token único —un entero de 32 bits— del dispositivo DRM mediante la llamada ioctl GET_MAGIC y lo pasa al proceso DRM-Master por cualquier medio (normalmente algún tipo de IPC ; por ejemplo, en DRI2 hay una solicitud DRI2Authenticate que cualquier cliente X puede enviar al servidor X. [ 13 ] )
  • El proceso DRM-Master, a su vez, devuelve el token al dispositivo DRM mediante la llamada al sistema ioctl AUTH_MAGIC .
  • El dispositivo otorga derechos especiales al identificador de archivo del proceso cuyo token de autenticación coincide con el token recibido del DRM-Master.

Gestor de ejecución de gráficos

Debido al tamaño cada vez mayor de la memoria de vídeo y a la creciente complejidad de las API gráficas como OpenGL , la estrategia de reinicializar el estado de la tarjeta gráfica en cada cambio de contexto resultaba demasiado costosa en términos de rendimiento. Además, los escritorios Linux modernos necesitaban una forma óptima de compartir los búferes fuera de pantalla con el gestor de composición . Estos requisitos llevaron al desarrollo de nuevos métodos para gestionar los búferes gráficos dentro del kernel. El Gestor de Ejecución Gráfica (GEM) surgió como uno de estos métodos. [ 6 ]

GEM proporciona una API con primitivas explícitas de gestión de memoria . [ 6 ] A través de GEM, un programa en el espacio de usuario puede crear, gestionar y destruir objetos de memoria que residen en la memoria de vídeo de la GPU. Estos objetos, llamados "objetos GEM", [ 14 ] son ​​persistentes desde la perspectiva del programa en el espacio de usuario y no necesitan recargarse cada vez que el programa recupera el control de la GPU. Cuando un programa en el espacio de usuario necesita un bloque de memoria de vídeo (para almacenar un framebuffer , una textura o cualquier otro dato requerido por la GPU [ 15 ] ), solicita la asignación al controlador DRM utilizando la API de GEM. El controlador DRM realiza un seguimiento de la memoria de vídeo utilizada y puede cumplir con la solicitud si hay memoria libre disponible, devolviendo un "identificador" al espacio de usuario para que pueda hacer referencia a la memoria asignada en operaciones posteriores. [ 6 ] [ 14 ] La API de GEM también proporciona operaciones para llenar el búfer y liberarlo cuando ya no se necesita. La memoria de los identificadores GEM no liberados se recupera cuando el proceso del espacio de usuario cierra el descriptor de archivo del dispositivo DRM , ya sea intencionalmente o porque finaliza. [ 16 ]

GEM también permite que dos o más procesos en el espacio de usuario que utilizan el mismo dispositivo DRM (y, por lo tanto, el mismo controlador DRM) compartan un objeto GEM. [ 16 ] Los identificadores 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 un único 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 a partir de un identificador GEM. [ 16 ] [ 12 ] : 16 El proceso puede entonces pasar este nombre GEM (entero de 32 bits) a otro proceso utilizando cualquier mecanismo IPC disponible. [ 12 ] : 15 El nombre GEM puede ser utilizado por el proceso receptor 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 malicioso de terceros que acceda al mismo dispositivo DRM podría intentar adivinar el nombre GEM de un búfer compartido por otros dos procesos, simplemente sondeando 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 los búferes en el espacio de usuario como descriptores de archivo, que se pueden compartir de forma segura .

Otra tarea importante para cualquier sistema de gestión de memoria de vídeo, además de gestionar el espacio de memoria de vídeo, es la sincronización de memoria entre la GPU y la CPU. Las arquitecturas de memoria actuales son muy complejas y suelen incluir varios niveles de caché para la memoria del sistema y, a veces, también para la memoria de vídeo. Por lo tanto, los gestores de memoria de vídeo también deben gestionar la coherencia de la caché para garantizar la consistencia de los datos compartidos entre la CPU y la GPU. [ 20 ] Esto significa que, a menudo, los aspectos internos de la gestión de memoria de vídeo dependen en gran medida de los detalles de hardware de la GPU y la arquitectura de memoria, y por lo 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 teniendo en cuenta una arquitectura de memoria UMA, lo que los hace menos adecuados para otras arquitecturas de memoria como aquellas con una VRAM separada. Por esta razón, otros controladores DRM han decidido exponer a los programas de espacio de usuario la API de GEM, pero internamente implementaron un administrador de memoria diferente más adecuado para su hardware y arquitectura de memoria particulares. [ 23 ]

La API GEM también proporciona ioctls para el control del flujo de ejecución (búferes de comandos), pero son específicos de Intel y deben usarse con GPU Intel i915 y posteriores. [ 6 ] Ningún otro controlador DRM ha intentado implementar ninguna parte de la API GEM más allá de los ioctls específicos de la administración de memoria.

Tabla de traducción Mapas

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 una GPU podría acceder, incluyendo la RAM de vídeo dedicada (comúnmente instalada en la tarjeta de vídeo) y la memoria del sistema accesible a través de una unidad de administración de memoria de E/S llamada Graphics Address Remapping Table (GART). [ 5 ] TTM también debe manejar las porciones de la RAM de vídeo que no son directamente direccionables por la CPU y hacerlo con el mejor rendimiento posible, considerando que las aplicaciones gráficas en el espacio de usuario normalmente trabajan con grandes cantidades de datos de vídeo. Otro aspecto importante era mantener la coherencia entre las diferentes memorias y cachés involucradas.

El concepto principal de TTM son los "objetos de búfer", regiones de memoria de vídeo que en algún momento deben ser accesibles para la GPU. [ 5 ] Cuando una aplicación gráfica en espacio de usuario necesita acceder a un objeto de búfer específico (normalmente para llenarlo con contenido), TTM puede requerir su reubicación a un tipo de memoria accesible para la CPU. Podrían producirse reubicaciones adicionales —o asignaciones GART— cuando la GPU necesita acceder a un objeto de búfer, pero este aún no se encuentra en su espacio de direcciones. Cada una de estas operaciones de reubicación debe gestionar los datos relacionados y los problemas de coherencia de caché. [ 5 ]

Otro concepto importante de TTM son las vallas . Las vallas son esencialmente un mecanismo para gestionar la concurrencia entre la CPU y la GPU. [ 24 ] Una valla rastrea cuándo un objeto de búfer ya no es utilizado por la GPU, generalmente para notificar a cualquier proceso del espacio de usuario que tenga acceso a él. [ 5 ]

El hecho de que TTM intentara gestionar todo tipo de arquitecturas de memoria, incluidas aquellas con y sin VRAM dedicada, de manera adecuada, y proporcionar todas las características imaginables en un gestor de memoria para su uso con cualquier tipo de hardware, dio lugar a una solución excesivamente compleja con una API mucho mayor de lo necesario. [ 24 ] [ 14 ] Algunos desarrolladores de DRM pensaron que no se adaptaría bien a ningún controlador específico, especialmente la API. Cuando GEM surgió como un gestor de memoria más simple, su API fue preferida a la de TTM. Pero algunos desarrolladores de controladores consideraron que el enfoque adoptado por TTM era más adecuado para tarjetas de vídeo discretas con memoria de vídeo dedicada e IOMMU, por lo que decidieron usar TTM internamente, exponiendo sus objetos de búfer como objetos GEM y, por lo tanto, soportando la API de GEM. [ 23 ] Ejemplos de controladores actuales que utilizan TTM como gestor de memoria interno pero que proporcionan una API de GEM son el controlador radeon para tarjetas de vídeo AMD y el controlador nouveau para tarjetas de vídeo NVIDIA.

Compartición de búfer DMA y PRIME

La API de compartición de búferes 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 entre múltiples dispositivos, posiblemente gestionados por diferentes tipos de controladores de dispositivos. [ 25 ] [ 26 ] Por ejemplo, un dispositivo Video4Linux y un adaptador gráfico podrían compartir búferes a través de DMA-BUF para lograr una copia cero de los datos de un flujo de vídeo 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 explotó por primera vez en DRM para implementar PRIME, una solución para la descarga de GPU que utiliza DMA-BUF para compartir los framebuffers resultantes entre los controladores DRM de la GPU discreta y la integrada. [ 27 ] : 13 Una característica importante de DMA-BUF es que un buffer compartido se presenta al espacio de usuario como un descriptor de archivo . [ 14 ] [ 12 ] : 17 Para el desarrollo de PRIME se agregaron dos nuevos ioctls a la API de 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 posteriormente como una forma de corregir la inseguridad inherente del uso compartido de búferes GEM. [ 12 ] : 17 A diferencia de los nombres GEM, los descriptores de archivo 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 utilizando la semántica SCM_RIGHTS. [ 14 ] [ 28 ] : 11 Un proceso que desea compartir un objeto GEM con otro proceso puede convertir su identificador GEM local en un descriptor de archivo DMA-BUF y pasarlo al receptor, que a su vez puede obtener su propio identificador GEM del descriptor de archivo recibido. [ 12 ] : 16 Este método es utilizado por DRI3 para compartir búferes entre el cliente y el servidor X [ 29 ] y también por Wayland .

Configuración del modo kernel

Debe existir un "administrador DRM" en el espacio de usuario; este programa tiene acceso exclusivo a KMS.

Para funcionar correctamente, una tarjeta de video o adaptador gráfico 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 sí mismo y la pantalla conectada . Esta operación se llama configuración de modo , [ 30 ] y generalmente requiere acceso directo al hardware gráfico , es decir, la capacidad de escribir en ciertos registros del controlador de pantalla 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 requieran cambiar el modo.

En los primeros tiempos, 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 ] Por lo tanto, necesitaban ejecutarse con acceso privilegiado al hardware de video. En los sistemas operativos tipo Unix, el servidor X era el ejemplo más destacado. Su implementación de configuración de modo residía en el controlador DDX para cada tipo específico de tarjeta de video. [ 33 ] Este enfoque, posteriormente denominado Configuración de Modo en 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 programas y hardware, lo que plantea problemas de estabilidad y seguridad, sino que también podría dejar el hardware gráfico en un estado inconsistente si dos o más programas de espacio de usuario intentan realizar la configuración 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 configuración de modo; Los programas restantes del espacio de usuario dependían del servidor X para establecer el modo apropiado y para manejar cualquier otra operación que implicara la configuración del modo. Inicialmente, la configuración del modo se realizaba exclusivamente durante el proceso de inicio del servidor X, pero más tarde el servidor X adquirió la capacidad de hacerlo mientras se ejecutaba. [ 37 ] La extensión XFree86-VidModeExtension se introdujo en XFree86 3.1.2 para permitir que cualquier cliente X solicitara cambios de línea de modelo (resolución) al servidor X. [ 38 ] [ 39 ] La extensión VidMode fue posteriormente reemplazada 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 VESA BIOS ). [ 40 ] Además, el controlador de framebuffer del kernel de Linux contenía código de configuración de modo para configurar los dispositivos framebuffer. [ 2 ] Para evitar conflictos de configuración de modo, el servidor XFree86 —y posteriormente el servidor X.Org— manejaba el caso en que 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 volvía a X. [ 41 ] Este proceso causaba un molesto parpadeo en la transición y también podía fallar, lo que provocaba una visualización de salida corrupta o inutilizable. [ 42 ]

El enfoque de configuración del modo de espacio de usuario también causó otros problemas: [ 43 ] [ 42 ]

  • El proceso de suspensión/reanudación depende de herramientas del espacio de usuario para restaurar el modo anterior. Un solo fallo o bloqueo de alguno de estos programas podría dejar el sistema sin pantalla debido a una configuración incorrecta del conjunto de modos, y por lo tanto, inutilizable.
  • Además, al núcleo le resultaba imposible mostrar mensajes de error o de depuración cuando la pantalla estaba en modo gráfico —por ejemplo, cuando se ejecutaba X— , ya ​​que los únicos modos que conocía el núcleo eran los modos de texto estándar de la BIOS VESA.
  • Un problema más acuciante fue la proliferación de aplicaciones gráficas que eludían el servidor X y la aparición de otras alternativas de pila gráfica a X, lo que extendió aún más la duplicación del código de configuración de modos en todo el sistema.

Para abordar estos problemas, el código de configuración de modo se trasladó a un único lugar dentro del núcleo, específicamente al módulo DRM existente. [ 36 ] [ 37 ] [ 44 ] [ 42 ] [ 43 ] Entonces, cada proceso —incluido el servidor X— debería poder ordenar al núcleo que realice operaciones de configuración de modo, y el núcleo garantizaría que las operaciones concurrentes no resulten en un estado inconsistente. La nueva API del núcleo y el código añadido al módulo DRM para realizar estas operaciones de configuración de modo se denominó Configuración de Modo del Núcleo (KMS). [ 30 ]

La configuración de modo del kernel proporciona varias ventajas. La más inmediata es, por supuesto, la eliminación del código duplicado de configuración de modo, tanto del kernel (consola Linux, fbdev) como del espacio de usuario (controladores DDX del servidor X). 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 una gestió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 utilizar al inicio del proceso de arranque, evitando el parpadeo debido a los cambios de modo en estas primeras etapas.

El hecho de que KMS forme parte del núcleo le permite utilizar recursos disponibles únicamente en el espacio del núcleo, como las interrupciones . [ 45 ] Por ejemplo, la recuperación del modo tras un proceso de suspensión/reanudación se simplifica enormemente al ser gestionada por el propio núcleo, y de paso mejora la seguridad (ya no se necesitan herramientas del espacio de usuario que requieran permisos de root). El núcleo también permite la conexión en caliente de nuevos dispositivos de visualización con facilidad, solucionando un problema de larga data. [ 45 ] La configuración del modo también está estrechamente relacionada con la gestión de la memoria —dado que los framebuffers son básicamente búferes de memoria— , por lo que se recomienda encarecidamente una estrecha integración con el gestor de memoria gráfica. Esa es la razón principal por la que el código de configuración del modo del núcleo se incorporó a DRM y no como un subsistema independiente. [ 44 ]

Para evitar romper la compatibilidad con versiones anteriores de la API DRM, se proporciona la configuración del modo del kernel como una característica adicional de ciertos controladores DRM. [ 46 ] Cualquier controlador DRM puede optar por proporcionar la bandera DRIVER_MODESET cuando se registra con el núcleo DRM para indicar que admite la API KMS. [ 8 ] Los controladores que implementan la configuración del modo del kernel a menudo se denominan controladores KMS para 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 exponerla o implementarla) implementan la API de KMS sin el resto de la API de DRM, lo que permite que los servidores de visualización (como Wayland ) se ejecuten con facilidad. [ 47 ] [ 48 ]

Modelo de dispositivo KMS

KMS modela y gestiona los dispositivos de salida como una serie de bloques de hardware abstractos que se encuentran comúnmente en la canalización de salida de pantalla de un controlador de pantalla . Estos bloques son: [ 49 ]

  • CRTC : cada CRTC (de CRT Controller [ 50 ] [ 33 ] ) representa un motor de escaneo del controlador de pantalla, que apunta a un búfer de escaneo ( framebuffer ). [ 49 ] El propósito de un CRTC es leer los datos de píxeles que se encuentran actualmente en el búfer de escaneo y generar a partir de ellos la señal de temporización del modo de vídeo con la ayuda de un circuito PLL . [ 51 ] El número de CRTC disponibles determina cuántos dispositivos de salida independientes puede manejar el hardware al mismo tiempo, por lo que para usar configuraciones de múltiples cabezales se requiere al menos un CRTC por dispositivo de pantalla. [ 49 ] Dos o más CRTC también pueden trabajar en modo clon si escanean desde el mismo framebuffer para enviar la misma imagen a varios dispositivos de salida. [ 51 ] [ 50 ]
  • Conectores : un conector representa el punto por donde el controlador de pantalla envía la señal de vídeo desde una operación de escaneo para su visualización. Generalmente, el concepto de conector KMS corresponde a un conector físico ( VGA , DVI , FPD-Link , HDMI , DisplayPort , S-Video , ...) en el hardware donde se conecta de forma permanente o temporal un dispositivo de salida ( monitor , panel de portátil, ...). La información relacionada con el dispositivo de salida conectado físicamente —como el estado de la conexión, los datos EDID , el estado DPMS o los modos de vídeo compatibles— también se almacena en el conector. [ 49 ]
  • 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. [ 49 ] 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, [ 49 ] 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 CRTC-codificador-conector.
  • Planos : un plano no es un bloque de hardware, sino un objeto de memoria que contiene un búfer desde el cual se alimenta un motor de escaneo (un CRTC). El plano que contiene el búfer de fotogramas se llama plano primario , y cada CRTC debe tener uno asociado, [ 49 ] ya que es la fuente para que el CRTC determine el modo de vídeo : 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 se ha realizado un esfuerzo continuo para lograr la atomicidad en algunas operaciones regulares relacionadas con la API de KMS, específicamente en las operaciones de configuración de modo y cambio de página . [ 33 ] [ 52 ] Esta API de KMS mejorada es lo que se denomina Visualización Atómica (anteriormente conocida como configuración de modo atómico y cambio de página atómico o nuclear ).

El propósito de la configuración de modo atómico es asegurar un cambio de modo correcto en configuraciones complejas con múltiples restricciones, evitando pasos intermedios que podrían llevar a un estado de video inconsistente o inválido; [ 52 ] también evita estados de video riesgosos cuando un proceso de configuración de modo fallido debe deshacerse ("rollback"). [ 53 ] : 9 La configuración de modo atómico permite saber de antemano si cierta configuración de modo específica es apropiada, al proporcionar capacidades de prueba de modo. [ 52 ] Cuando se prueba un modo atómico y se confirma su validez, se puede aplicar con una única operación de confirmación indivisible (atómica) . Tanto las operaciones de prueba como las de confirmación son proporcionadas por el mismo nuevo ioctl con diferentes indicadores.

Por otro lado, el cambio de página atómico permite actualizar varios planos en la misma salida (por ejemplo, el plano principal, 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 desgarro. [ 53 ] : 9,14 [ 52 ] Este requisito es especialmente relevante para los controladores de pantalla móviles e integrados, que tienden a usar varios planos/superposiciones para ahorrar energía.

La nueva API atómica se basa en la antigua API KMS. Utiliza el mismo modelo y objetos (CRTC, codificadores, conectores, planos, etc.), pero con un número creciente de propiedades de objeto que se pueden modificar. [ 52 ] 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 realizar una configuración de modo (principalmente propiedades de CRTC, codificadores y conectores) o un cambio de página (generalmente propiedades de planos). La llamada ioctl es la misma para ambos casos; la diferencia radica en la lista de propiedades que se pasan con cada una. [ 54 ]

Nodos de renderizado

En la API DRM original, el dispositivo DRM se utiliza tanto para operaciones privilegiadas (modsetting, otros controles de visualización) como no privilegiadas (renderizado, cómputo GPGPU ). [ 9 ] Por razones de seguridad, abrir el archivo del dispositivo DRM asociado requiere privilegios especiales "equivalentes a privilegios de root". [ 55 ] Esto da lugar a una arquitectura en la que solo algunos programas de espacio de usuario fiables (el servidor X, un compositor gráfico, ...) tienen acceso completo a la API DRM, incluidas las partes privilegiadas como la API modeset. Otras aplicaciones de espacio de usuario que quieran renderizar o realizar cálculos GPGPU deben obtener autorización del propietario del dispositivo DRM ("DRM Master") mediante una interfaz de autenticación especial. [ 56 ] Entonces, las aplicaciones autenticadas pueden renderizar o realizar cálculos utilizando una versión restringida de la API DRM sin operaciones privilegiadas. Este diseño impone una restricción severa: siempre debe haber un servidor gráfico en ejecución (el servidor X, un compositor Wayland, ...) que actúe como DRM-Master de un dispositivo DRM para que otros programas del espacio de usuario puedan usar el dispositivo, incluso en casos que no involucren ninguna visualización gráfica, como los cálculos GPGPU. [ 55 ] [ 56 ]/dev/dri/cardX

El concepto de "nodos de renderizado" intenta resolver estos escenarios dividiendo la API del espacio de usuario de DRM en dos interfaces (una privilegiada y otra no privilegiada) y utilizando archivos de dispositivo separados (o "nodos") para cada una. [ 9 ] Para cada GPU encontrada, su controlador DRM correspondiente ( si admite la función de nodos de renderizado ) crea un archivo de dispositivo , llamado nodo de renderizado , además del nodo principal . [ 56 ] [ 9 ] Los clientes que utilizan un modelo de renderizado directo y las aplicaciones que desean aprovechar las capacidades de cálculo de una GPU pueden hacerlo sin necesidad de privilegios adicionales simplemente abriendo cualquier nodo de renderizado existente y enviando operaciones de GPU utilizando el subconjunto limitado de la API de DRM compatible con esos nodos, siempre que tengan permisos del sistema de archivos para abrir el archivo de dispositivo. Los servidores de visualización, compositores y cualquier otro programa que requiera la API modeset o cualquier otra operación privilegiada deben abrir el nodo principal estándar que otorga acceso a la API de DRM completa y usarlo como de costumbre. Los nodos de renderizado prohíben explícitamente la operación GEM flink para evitar el uso compartido de búferes mediante nombres globales GEM inseguros; solo se pueden usar descriptores de archivo PRIME (DMA-BUF) para compartir búferes con otro cliente, incluido el servidor gráfico. [ 9 ] [ 56 ]/dev/dri/renderDX/dev/dri/cardX

Soporte de hardware

DRM debe ser utilizado por el controlador de dispositivos gráficos en modo usuario, como por ejemplo AMD Catalyst o Mesa 3D . Los programas en espacio de usuario utilizan la Interfaz de Llamadas al Sistema de Linux para acceder a DRM. DRM amplía la Interfaz de Llamadas al Sistema de Linux con sus propias llamadas al sistema. [ 57 ]

El subsistema DRM de Linux incluye controladores gratuitos y de código abierto para dar soporte al hardware de los tres principales fabricantes de GPU para ordenadores de sobremesa (AMD, NVIDIA e Intel), así como a un número creciente de integradores de GPU móviles y sistemas en chip (SoC). La calidad de cada controlador varía considerablemente, dependiendo del grado de colaboración del fabricante y otros factores.

En la siguiente tabla se detallan, con fines históricos, varios controladores para hardware antiguo y obsoleto.

Desarrollo

El Direct Rendering Manager se desarrolla dentro del kernel de Linux , y su código fuente reside en el /drivers/gpu/drmdirectorio del código fuente de Linux. El mantenedor del subsistema es Dave Airlie, con otros mantenedores que se encargan de controladores específicos. [ 132 ] Como es habitual en el desarrollo del kernel de Linux, los submantenedores y colaboradores de DRM envían sus parches con nuevas características y correcciones de errores al mantenedor principal de DRM, quien 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 incorporados al núcleo a Linus Torvalds cuando se vaya a lanzar una nueva versión de Linux. Torvalds, como mantenedor principal de todo el kernel, tiene la última palabra sobre si un parche es adecuado o no para su inclusión en el kernel.

Por razones históricas, el código fuente de la biblioteca libdrm se mantiene bajo el paraguas del proyecto Mesa . [ 133 ]

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 dentro del código fuente de Mesa . [ 134 ] Más tarde ese año, el código DRM se incorporó al kernel de Linux 2.3.18 en el directorio para dispositivos de caracteres . [ 135 ] Durante los años siguientes, el número de tarjetas de video compatibles creció. Cuando se lanzó Linux 2.4.0 en enero de 2001, ya había soporte para Creative Labs GMX 2000, Intel i810, Matrox G200/G400 y ATI Rage 128, además de las tarjetas 3dfx Voodoo3, [ 136 ] y esa lista se amplió durante la serie 2.4.x, con controladores para tarjetas ATI Radeon , algunas tarjetas de video SiS e Intel 830M y GPU integradas posteriores./drivers/char/drm/

La división de DRM en dos componentes, núcleo DRM y controlador DRM, denominada división núcleo DRM/personalidad, se realizó durante la segunda mitad de 2004, [ 11 ] [ 137 ] y se fusionó en la versión del kernel 2.6.11. [ 138 ] Esta división permitió que varios controladores DRM para varios dispositivos funcionaran simultáneamente, abriendo el camino al soporte de múltiples GPU.

La idea de colocar todo el código de configuración del modo de vídeo en un solo lugar dentro del kernel se había reconocido durante años, [ 139 ] [ 140 ] 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 proporcionadas por ellos mismos y contenidas en la BIOS de vídeo de cada tarjeta gráfica. Dicho código tenía que ejecutarse usando el modo real x86 , lo que impedía que fuera invocado por un kernel que se ejecutaba en modo protegido . [ 44 ] La situación cambió cuando Luc Verhaegen y otros desarrolladores encontraron una forma de hacer la configuración del modo de forma nativa en lugar de basada en la BIOS, [ 141 ] [ 44 ] demostrando que era posible hacerlo usando código normal del kernel y sentando las bases para lo que se convertiría en Kernel Mode Setting . En mayo de 2007, Jesse Barnes ( Intel ) publicó la primera propuesta para una API drm-modesetting y una implementación nativa funcional de la configuración del 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 radeon DRM. [ 142 ] [ 143 ] 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. [ 144 ]

En octubre de 2008, el kernel de Linux 2.6.27 introdujo una importante reorganización del código fuente , antes de algunos cambios significativos que se avecinaban. El árbol de código fuente de DRM se trasladó a su propio directorio de origen /drivers/gpu/drm/y los diferentes controladores se trasladaron a sus propios subdirectorios. Los encabezados también se trasladaron a un nuevo /include/drmdirectorio. [ 145 ]

La creciente complejidad de la gestión de la memoria de vídeo dio lugar a varios enfoques para resolver este problema. El primer intento fue el gestor de memoria Translation Table Maps (TTM), desarrollado por Thomas Hellstrom ( Tungsten Graphics ) en colaboración con Emma Anholt (Intel) y Dave Airlie ( Red Hat ). [ 5 ] Se propuso la inclusión de TTM en el kernel principal 2.6.25 en noviembre de 2007, [ 5 ] y de nuevo en mayo de 2008, pero se descartó en favor de un nuevo enfoque llamado Graphics Execution Manager (GEM). [ 24 ] GEM fue desarrollado inicialmente por Keith Packard y Emma Anholt de Intel como una solución más sencilla para la gestión de memoria de su controlador i915. [ 6 ] GEM fue bien recibido y se integró en la versión 2.6.28 del kernel de Linux, publicada en diciembre de 2008. [ 146 ] Mientras tanto, TTM tuvo que esperar hasta septiembre de 2009 para integrarse finalmente en Linux 2.6.31 como requisito del nuevo controlador DRM Radeon KMS. [ 147 ]

Con la administración de memoria implementada para manejar objetos de búfer, los desarrolladores de DRM finalmente pudieron agregar al kernel la API y el código ya terminados para realizar la configuración de modo . Esta API ampliada es lo que se llama Configuración de Modo del Kernel (KMS) y los controladores que la implementan a menudo se denominan controladores KMS . En marzo de 2009, KMS se fusionó en la versión 2.6.29 del kernel de Linux, [ 30 ] [ 148 ] junto con el soporte de KMS para el controlador i915. [ 149 ] La API KMS ha estado expuesta a programas de espacio de usuario desde libdrm 2.4.3. [ 150 ] El controlador de espacio de usuario X.Org DDX para tarjetas gráficas Intel también fue el primero en utilizar las nuevas API GEM y KMS. [ 151 ] Se agregó soporte KMS para el controlador radeon DRM a la versión Linux 2.6.31 de septiembre de 2009. [ 152 ] [ 153 ] [ 154 ] El nuevo controlador radeon KMS utilizaba el administrador de memoria TTM, pero exponía interfaces e ioctls compatibles con GEM en lugar de las de TTM. [ 23 ]

Desde 2006, el proyecto nouveau había estado desarrollando un controlador DRM de software libre para GPU NVIDIA fuera del kernel oficial de Linux. En 2010, el código fuente de nouveau se integró en Linux 2.6.33 como un controlador experimental. [ 58 ] [ 59 ] En el momento de la integración, el controlador ya se había convertido a KMS y, detrás de la API GEM, utilizaba TTM como su gestor de memoria. [ 155 ]

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 asíncronas de VBLANK en Linux 2.6.33 [ 156 ] [ 157 ] , solo para el controlador i915, radeon y nouveau lo agregaron más tarde durante el lanzamiento de Linux 2.6.38. [ 158 ] La nueva interfaz de cambio de página se agregó a libdrm 2.4.17. [ 159 ] A principios de 2011, durante el ciclo de lanzamiento de Linux 2.6.39, los llamados búferes tontos , una forma independiente del hardware y no acelerada de manejar búferes simples adecuados para su uso como framebuffers , se agregaron a la API de KMS. [ 160 ] [ 161 ] El objetivo era reducir la complejidad de aplicaciones como Plymouth que no necesitan usar operaciones aceleradas especiales proporcionadas por ioctls específicos del controlador. [ 162 ] La característica fue expuesta por libdrm a partir de la versión 2.4.25. [ 163 ] Más tarde ese año también obtuvo un nuevo tipo principal de objetos, llamados planes . Los planes se desarrollaron para representar superposiciones de hardware compatibles con el motor scanout. [ 164 ] [ 165 ] La compatibilidad con planes se fusionó en Linux 3.3. [ 166 ] y libdrm 2.4.30. Otro concepto añadido a la API —durante los lanzamientos de Linux 3.5 [ 167 ] y libdrm 2.4.36 [ 168 ] — fueron las propiedades de objetos genéricos , un método para añadir valores genéricos a cualquier objeto KMS. Las propiedades son especialmente útiles para establecer comportamientos o características especiales a objetos como CRTC y planes.

Dave Airlie desarrolló en 2010 una prueba de concepto temprana para proporcionar descarga de GPU entre controladores DRM. [ 7 ] [ 169 ] Dado que Airlie intentaba imitar la tecnología NVIDIA Optimus , decidió llamarla "PRIME". [ 7 ] Airlie reanudó su trabajo en PRIME a finales de 2011, pero basado en el nuevo mecanismo de compartición de búfer DMA-BUF introducido por el kernel de Linux 3.3. [ 170 ] La infraestructura básica DMA-BUF PRIME se terminó en marzo de 2012 [ 171 ] y se fusionó en la versión Linux 3.4, [ 172 ] [ 173 ] [ 174 ] así como en libdrm 2.4.34. [ 175 ] Más tarde, durante la versión Linux 3.5, varios controladores DRM implementaron soporte para PRIME, incluidos i915 para tarjetas Intel, radeon para tarjetas AMD y nouveau para tarjetas NVIDIA. [ 176 ] [ 177 ]

En los últimos años, la API DRM se ha expandido incrementalmente con características nuevas y mejoradas. En 2013, como parte de GSoC , David Herrmann desarrolló la característica de nodos de renderizado múltiples . [ 55 ] Su código se agregó a la versión 3.12 del kernel de Linux como una característica experimental [ 178 ] [ 179 ] compatible con los controladores i915, [ 180 ] radeon [ 181 ] y nouveau [ 182 ] , y habilitado por defecto desde Linux 3.17. [ 77 ] En 2014, Matt Roper (Intel) desarrolló el concepto de planos universales (o planos unificados ) por el cual los framebuffers ( planos primarios ), las superposiciones ( planos secundarios ) y los cursores ( planos de cursor ) se tratan como un solo tipo de objeto con una API unificada. [ 183 ] La compatibilidad con planos universales proporciona una API DRM más consistente con menos ioctls , más genéricos . [ 33 ] Para mantener la compatibilidad con versiones anteriores de la API , el núcleo DRM expone la función como una capacidad adicional que puede proporcionar un controlador DRM. El soporte para planos universales debutó en Linux 3.15 [ 184 ] y libdrm 2.4.55. [ 185 ] Varios controladores, como el Intel i915, [ 186 ] ya lo han implementado.

La mejora más reciente de la API 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. [ 187 ] Ville Syrjälä (Intel) asumió la tarea de diseñar e implementar dicha API atómica. [ 188 ] Basándose en su trabajo, Rob Clark ( Texas Instruments ) adoptó un enfoque similar con el objetivo de implementar cambios de página atómicos. [ 189 ] Más tarde, en 2013, ambas características propuestas se reunieron en una sola utilizando un único ioctl para ambas tareas. [ 190 ] Dado que era un requisito, la característica tuvo que esperar a que se fusionara el soporte de planos universales a mediados de 2014. [ 186 ] 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 [ 191 ] : 18 para facilitar la transición de los controladores KMS existentes al nuevo marco atómico. [ 192 ] Todo este trabajo finalmente se fusionó en las versiones de Linux 3.19 [ 193 ] y Linux 4.0 [ 194 ] [ 195 ] [ 196 ] y se habilitó por defecto desde Linux 4.2. [ 197 ] libdrm expuso la nueva API atómica desde la versión 2.4.62. [ 198 ] Varios controladores ya se han convertido a la nueva API atómica. [ 199 ] Para 2018, se habían agregado al kernel de Linux diez nuevos controladores DRM basados ​​en este nuevo modelo atómico. [ 200 ]

Adopción

El subsistema del kernel Direct Rendering Manager se desarrolló inicialmente para usarse con la nueva infraestructura de renderizado directo del servidor de visualización XFree86 4.0, heredada posteriormente por su sucesor, el servidor X.Org . Por lo tanto, los principales usuarios de DRM eran los clientes DRI que se conectaban a la implementación de OpenGL acelerada por hardware que reside en la biblioteca Mesa 3D , así como al propio servidor X. Actualmente, DRM también es utilizado por varios compositores Wayland , incluido el compositor de referencia Weston . kmscon es una implementación de consola virtual que se ejecuta en el espacio de usuario utilizando las funciones de DRM KMS. [ 201 ]

En 2015, la versión 358.09 (beta) del controlador propietario 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 del controlador funciona junto con el nvidia.komódulo del kernel para programar el motor de visualización (es decir, el controlador de visualización) de la GPU. [ 202 ]

Véase también

Referencias

  1. ↑ "Linux kernel/drivers/gpu/drm/README.drm" . kernel.org . Consultado el 26 de febrero de 2014 .{{cite web}}: CS1 maint: servicio de archivado obsoleto ( enlace )
  2. ^ Uytterhoeven , Geert. "El dispositivo de búfer de cuadros" . Kernel.org . Consultado el 28 de enero de 2015 .
  3. 1 2 3 White, Thomas. "Cómo funcionan DRI y DRM" . Recuperado el 22 de julio de 2014 .
  4. ↑ Faith, Rickard E. (11 de mayo de 1999). "The Direct Rendering Manager: Kernel Support for the Direct Rendering Infrastructure" . Archivado del original el 24 de mayo de 2016. Recuperado el 12 de mayo de 2016 .
  5. 1 2 3 4 5 6 7 8 Corbet, Jonathan (6 de noviembre de 2007). "Gestión de memoria para procesadores gráficos" . LWN.net . Recuperado el 23 de julio de 2014 .
  6. 1 2 3 4 5 6 7 Packard, Keith; Anholt, Eric (13 de mayo de 2008). "GEM - el gestor de ejecución gráfica" . Lista de correo dri-devel . Recuperado el 23 de julio de 2014 .
  7. 1 2 3 Airlie, Dave (12 de marzo de 2010). "Descarga de GPU - PRIME - prueba de concepto" . Archivado del original el 10 de febrero de 2015. Recuperado el 10 de febrero de 2015 .
  8. 1 2 3 4 5 Kitching, Simon. "Módulos del kernel DRM y KMS" . Recuperado el 13 de mayo de 2016 .
  9. 1 2 3 4 5 Herrmann, David (1 de septiembre de 2013). "División de nodos de dispositivos DRM y KMS" . Recuperado el 23 de julio de 2014 .
  10. ↑ "README.rst - mesa/drm - Encabezados y módulos del kernel del Direct Rendering Manager" . 21/03/2020.{{cite web}}: CS1 maint: servicio de archivado obsoleto ( enlace )
  11. 1 2 Airlie, Dave (4 de septiembre de 2004). "Nuevo diseño de interfaz DRM propuesto" . dri-devel (Lista de correo).
  12. 1 2 3 4 5 6 7 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) . Recuperado el 13 de mayo de 2016 .
  13. ^ 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 .
  14. 1 2 3 4 5 6 Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. "Guía del desarrollador de controladores de GPU de Linux: administración de memoria" . Recuperado el 31 de agosto de 2016 .
  15. ↑ Vetter, Daniel. "Curso intensivo de i915/GEM por Daniel Vetter" . Centro de Tecnología de Código Abierto de Intel . Consultado el 31 de enero de 2015. GEM se ocupa esencialmente de los objetos de búfer de gráficos (que pueden contener texturas, búferes de renderizado, sombreadores o todo tipo de otros objetos de estado y datos utilizados por la GPU) .
  16. 1 2 3 Vetter, Daniel (4 de mayo de 2011). "Descripción general de GEM" . Recuperado el 13 de febrero de 2015 .
  17. ↑ Packard, Keith (28 de septiembre de 2012). "Reflexiones sobre DRI.Next" . Recuperado el 26 de mayo de 2016. GEM flink tiene muchos problemas . Los nombres de flink son globales, lo que permite que cualquiera con acceso al dispositivo acceda al contenido de los datos de flink.
  18. 1 2 Herrmann, David (2 de julio de 2013). "Seguridad DRM" . Actas de la Conferencia de Desarrolladores de X.Org de 2013 (XDC2013) . Recuperado el 13 de febrero de 2015. gem-flink no proporciona espacios de nombres privados a las aplicaciones y servidores. En cambio, 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 fuerza bruta de los búferes de gemas.
  19. ↑ Kerrisk, Michael (25 de septiembre de 2012). "XDC2012: Seguridad de la pila gráfica" . LWN.net . Consultado el 25 de noviembre de 2015 .
  20. 1 2 Packard, Keith (4 de julio de 2008). "Actualización de gemas" . Recuperado el 25 de abril de 2016 .
  21. ↑ "página man de drm-memory" . Manuales de Ubuntu . Consultado el 29 de enero de 2015. Muchas GPU modernas de gama alta vienen con sus propios gestores de memoria. Incluso incluyen varias cachés diferentes que necesitan sincronizarse durante el acceso. [...] Por lo tanto, la gestión de memoria en las GPU depende en gran medida del controlador y del hardware.
  22. ↑ "Guía para desarrolladores de Intel Graphics Media Accelerator" . Intel Corporation . Consultado el 24 de noviembre de 2015 .
  23. 1 2 3 Larabel, Michael (26 de agosto de 2008). "Un gestor TTM con GEM para Radeon" . Phoronix . Recuperado el 24 de abril de 2016 .
  24. 1 2 3 Corbet, Jonathan (28 de mayo de 2008). "GEM v. TTM" . LWN.net . Recuperado el 10 de febrero de 2015 .
  25. ↑ Corbet, Jonathan (11 de enero de 2012). "Compartición de búfer DMA en 3.3" . LWN.net . Recuperado el 14 de mayo de 2016 .
  26. ↑ Clark, Rob; Semwal, Sumit. "Marco de compartición de búfer DMA: una introducción" (PDF) . Consultado el 14 de mayo de 2016 .
  27. ↑ Peres, Martin (26 de septiembre de 2014). "La pila gráfica de Linux, Optimus y el controlador Nouveau" (PDF) . Recuperado el 14 de mayo de 2016 .
  28. ↑ Pinchart, Laurent (20 de febrero de 2013). "Anatomía de un controlador KMS integrado" (PDF) . Recuperado el 27 de junio de 2016 .
  29. ↑ Edge, Jake (9 de octubre de 2013). "DRI3 y el presente" . LWN.net . Consultado el 28 de mayo de 2016 .
  30. 1 2 3 4 "Linux 2.6.29 - Configuración del modo del kernel" . Linux Kernel Newbies . Consultado el 19 de noviembre de 2015 .
  31. ↑ "Hardware VGA" . OSDev.org . Consultado el 23 de noviembre de 2015 .
  32. ↑ Rathmann, B. (15 de febrero de 2008). "El estado de Nouveau, parte I" . LWN.net . Recuperado el 23 de noviembre de 2015. Las tarjetas gráficas se programan de numerosas maneras, pero la mayor parte de la inicialización y la configuración del modo se realiza a través de E/S mapeadas en memoria. Esto es simplemente 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 manejan varias características de la tarjeta gráfica, como la configuración del modo, el control de salida o la configuración del reloj.
  33. 1 2 3 4 5 Paalanen, Pekka (5 de junio de 2014). "De la prehistoria a más allá de la guerra termonuclear global" . Recuperado el 29 de julio de 2014 .
  34. ↑ "página man de drm-kms" . Manuales de Ubuntu . Consultado el 19 de noviembre de 2015 .
  35. ↑ 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 .
  36. 1 2 "Discusión sobre el diseño de la configuración del modo" . Wiki de X.Org . Consultado el 19 de noviembre de 2015 .
  37. 1 2 Corbet, Jonathan (22 de enero de 2007). "LCA: Actualizaciones sobre el sistema X Window" . LWN.net . Recuperado el 23 de noviembre de 2015 .
  38. ↑ "Página del manual de XF86VIDMODE" . X.Org . Consultado el 23 de abril de 2016 .
  39. ↑ "Notas de la versión X11R6.1" . X.Org . 14 de marzo de 1996. Consultado el 23 de abril de 2016 .
  40. ↑ Corbet, Jonathan (20 de julio de 2004). "Cumbre del kernel: controladores de vídeo" . LWN.net . Consultado el 23 de noviembre de 2015 .
  41. 1 2 "Fedora - Features/KernelModeSetting" . Proyecto Fedora . Consultado el 20 de noviembre de 2015. Históricamente, el servidor X era responsable de guardar el estado de salida al iniciarse y luego restaurarlo al volver al modo texto. El cambio rápido de usuario se realizaba con un interruptor VT, de modo que al cambiar del servidor X del primer usuario, se producía un parpadeo para pasar al modo texto y, acto seguido, otro parpadeo para pasar a la sesión del segundo usuario.
  42. 1 2 3 4 5 Barnes, Jesse (17 de mayo de 2007). " [ RFC ] mejorando el subsistema gráfico del kernel" . linux-kernel (Lista de correo).
  43. 1 2 3 "DrmModesetting - Mejora de los gráficos del kernel" . DRI Wiki . Consultado el 23 de noviembre de 2015 .
  44. 1 2 3 4 5 Packard, Keith (16 de septiembre de 2007). "controladores en modo kernel" . Recuperado el 30 de abril de 2016 .
  45. 1 2 Packard, Keith (24 de abril de 2000). "Afilando el enfoque del controlador Intel" . Recuperado el 23 de mayo de 2016. Una limitación más sutil es que el controlador no podía manejar interrupciones, por lo que no había soporte para conexión en caliente de monitores.
  46. ↑ Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. "Guía del desarrollador de controladores de GPU para Linux: inicialización del controlador" . Consultado el 31 de agosto de 2016 .
  47. ↑ "q3k (@q3k@hackerspace.pl)" . Club Social Hackerspace de Varsovia . 31/01/2023 . Consultado el 13/02/2023 . El controlador DRM/KMS funciona completamente ahora, aunque todavía sin DMA. Ah, y está escrito en Rust, aunque en su mayor parte está lleno de bloques inseguros sin procesar.
  48. ↑ "q3k (@q3k@hackerspace.pl)" . Club Social Hackerspace de Varsovia . 31-01-2023 . Recuperado el 13-02-2023 . Lo bueno es que, como tenemos un controlador DRM/KMS 'normal' (y ayuda de @emersion@hackerspace.pl) podemos hacer cosas como... ¡ejecutar Wayland! Weston en un iPod Nano 5G.
  49. 1 2 3 4 5 6 7 Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. "Guía del desarrollador de controladores de GPU de Linux: inicialización y limpieza de KMS" . Recuperado el 31 de agosto de 2016 .
  50. 1 2 "Tarjetas de video" . Wiki de X.Org . Consultado el 11 de abril de 2016 .
  51. 1 2 Deucher, Alex (15 de abril de 2010). "Notas sobre el hardware de visualización de Radeon" . Archivado del original el 5 de abril de 2016. Recuperado el 8 de abril de 2016 .
  52. 1 2 3 4 5 Vetter, Daniel (5 de agosto de 2015). "Descripción general del diseño de configuración de modo atómico, parte 1" . LWN.net . Recuperado el 7 de mayo de 2016 .
  53. 1 2 Reding, Thierry (1 de febrero de 2015). "Configuración del modo atómico" (PDF) . Archivos FOSDEM . Recuperado el 7 de mayo de 2016 .
  54. ↑ Vetter, Daniel (12 de agosto de 2015). "Descripción general del diseño de configuración de modo atómico, parte 2" . LWN.net . Recuperado el 7 de mayo de 2016 .
  55. 1 2 3 Herrmann, David (29 de mayo de 2013). "DRM Render- and Modeset-Nodes" . Recuperado el 21 de julio de 2014 .
  56. 1 2 3 4 Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. "Guía del desarrollador del controlador de GPU de Linux: nodos de renderizado" . Recuperado el 31 de agosto de 2016 .
  57. 1 2 Deucher, Alex (20 de abril de 2015). "Lanzamiento inicial del controlador amdgpu" . dri-devel (Lista de correo).
  58. 1 2 "Linux 2.6.33 - Nouveau, un controlador para tarjetas gráficas Nvidia" . Linux Kernel Newbies . Consultado el 26 de abril de 2016 .
  59. 1 2 "drm/nouveau: Agregar controlador DRM para GPU NVIDIA" . Kernel.org . Consultado el 27 de enero de 2015 .
  60. ↑ "DRM: agregar controlador DRM para Samsung SoC EXYNOS4210" . Kernel.org . Consultado el 3 de marzo de 2016 .
  61. ↑ "vmwgfx: Sacar el controlador del entorno de pruebas" . Kernel.org . Consultado el 3 de marzo de 2016 .
  62. ↑ "Linux 3.3 - DriverArch - Gráficos" . Linux Kernel Newbies . Consultado el 3 de marzo de 2016 .
  63. ↑ Larabel, Michael (10 de enero de 2012). "La propuesta de DRM de Linux 3.3 se centra en las mejoras" . Phoronix . Consultado el 3 de marzo de 2016 .
  64. ↑ "drm: Controlador KMS inicial para la serie 2000 de AST (ASpeed ​​Technologies) (v2)" . Kernel.org . Consultado el 3 de marzo de 2016 .
  65. ↑ Airlie, Dave (17 de mayo de 2012). "mgag200: controlador g200se inicial (v2)" . Recuperado el 24 de enero de 2018 .
  66. ↑ "drm: Controlador DRM móvil Renesas SH" . Kernel.org . Consultado el 3 de marzo de 2016 .
  67. ↑ "drm: Agregar soporte para NVIDIA Tegra20" . Kernel.org . Consultado el 3 de marzo de 2016 .
  68. ↑ "drm/omap: mover fuera del entorno de pruebas" . Kernel.org . Consultado el 3 de marzo de 2016 .
  69. ↑ "drm: Controlador DRM de la unidad de visualización Renesas R-Car" . Kernel.org . Consultado el 3 de marzo de 2016 .
  70. ↑ "drm/msm: controlador KMS básico para snapdragon" . Kernel.org . Consultado el 3 de marzo de 2016 .
  71. ↑ Larabel, Michael (28 de agosto de 2013). "Controlador DRM/KMS de Snapdragon fusionado para Linux 3.12" . Phoronix . Recuperado el 26 de enero de 2015 .
  72. ↑ Edge, Jake (8 de abril de 2015). "Una actualización sobre el controlador gráfico freedreno" . LWN.net . Consultado el 23 de abril de 2015 .
  73. ↑ King, Russell (18 de octubre de 2013). " [ GIT PULL ] Soporte para Armada DRM" . dri-devel (Lista de correo).
  74. ↑ "DRM: Armada: Agregar controlador DRM de Armada" . Kernel.org . Consultado el 3 de marzo de 2016 .
  75. ↑ "drm/bochs: nuevo controlador" . Kernel.org . Consultado el 3 de marzo de 2016 .
  76. ↑ Larabel, Michael (8 de agosto de 2014). "Linux 3.17 DRM Pull Brings New Graphics Driver" . Phoronix . Recuperado el 3 de marzo de 2016 .
  77. 1 2 Corbet, Jonathan (13 de agosto de 2014). "3.17 merge window, part 2" . LWN.net . Recuperado el 7 de octubre de 2014 .
  78. 1 2 Corbet, Jonathan (17 de diciembre de 2014). "3.19 Ventana de fusión, parte 2" . LWN.net . Recuperado el 9 de febrero de 2015 .
  79. ↑ "drm: imx: Mover el controlador imx-drm fuera del entorno de pruebas" . Kernel.org . Consultado el 9 de febrero de 2015 .
  80. ↑ "drm: rockchip: Agregar controlador drm básico" . Kernel.org . Consultado el 3 de marzo de 2016 .
  81. ↑ Larabel, Michael (25 de junio de 2015). "Actualizaciones de DRM de Linux 4.2: mucha atención de AMD, sin cambios en los controladores Nouveau" . Phoronix . Recuperado el 31 de agosto de 2015 .
  82. ↑ Corbet, Jonathan (1 de julio de 2015). "4.2 Ventana de fusión, parte 2" . LWN.net . Consultado el 31 de agosto de 2015 .
  83. ↑ Deucher, Alex (3 de agosto de 2015). " [ PATCH 00/11 ] Agregar soporte para Fiji" . dri-devel (Lista de correo).
  84. ↑ "Agregar controlador GPU virtio" . Kernel.org . Consultado el 3 de marzo de 2016 .
  85. ↑ Corbet, Jonathan (11 de noviembre de 2015). "4.4 Ventana de fusión, parte 1" . LWN.net . Consultado el 11 de enero de 2016 .
  86. ↑ Larabel, Michael (15 de noviembre de 2015). "Un vistazo a las nuevas características del kernel de Linux 4.4" . Phoronix . Consultado el 11 de enero de 2016 .
  87. ↑ "drm/vc4: Añadir soporte KMS para Raspberry Pi" . Kernel.org .
  88. ↑ "Linux 4.5-DriversArch - Graphics" . Linux Kernel Newbies . Consultado el 14 de marzo de 2016 .
  89. ↑ Larabel, Michael (24 de enero de 2016). "Las numerosas novedades y mejoras del kernel de Linux 4.5" . Phoronix . Consultado el 14 de marzo de 2016 .
  90. ↑ Corbet, Jonathan (20 de enero de 2016). "Ventana de fusión 4.5, parte 2" . LWN.Net . Recuperado el 14 de marzo de 2016 .
  91. ↑ "Combinar etiqueta 'sun4i-drm-for-4.7'" . Kernel.org .
  92. 1 2 3 Airlie, Dave (23 de mayo de 2016). " [ git pull ] drm para v4.7" . dri-devel (Lista de correo).
  93. ↑ "Combinar etiqueta 'drm-hisilicon-next-2016-04-29'" . Kernel.org .
  94. ↑ "Combinar etiqueta 'mediatek-drm-2016-05-09'"" . Kernel.org .
  95. ↑ Larabel, Michael (22 de noviembre de 2016). "Se agregará el controlador DRM Hisilicon Hibmc para Linux 4.10" . Phoronix . Recuperado el 24 de enero de 2018 .
  96. ↑ "Documento técnico de Huawei FusionServer RH5885 V3" . 18 de noviembre de 2016. Archivado del original el 25 de enero de 2018. Utiliza un chip de visualización integrado en el chip de gestión Hi1710 y utiliza el núcleo IP del SM750.
  97. ↑ "drm/vkms: Introduce el controlador VKMS básico" . git.kernel.org . Consultado el 20 de julio de 2022 .
  98. ↑ Larabel, Michael (15 de agosto de 2018). "Se agregará un controlador para configurar el modo del kernel virtual a Linux 4.19" . Phoronix . Recuperado el 20 de julio de 2022 .
  99. ↑ "drm/lima: controlador para GPU ARM Mali4xx" . git.kernel.org . Consultado el 28 de noviembre de 2019 .
  100. 1 2 3 Larabel, Michael (9 de mayo de 2019). "Linux 5.2 DRM hace que Icelake esté listo para producción, agrega controladores Lima y Panfrost" . Phoronix . Recuperado el 20 de julio de 2022 .
  101. ↑ "drm/panfrost: Agregar controlador panfrost inicial" . git.kernel.org . Consultado el 28 de noviembre de 2019 .
  102. ↑ "drm/vboxvideo: Mover el controlador vboxvideo fuera del área de pruebas" . git.kernel.org . Consultado el 20 de julio de 2022 .
  103. ↑ "drm/hyperv: Agregar controlador DRM para dispositivo de video sintético hyperv" . git.kernel.org . Consultado el 30 de agosto de 2021 .
  104. ↑ Larabel, Michael (9 de junio de 2021). "El controlador de pantalla DRM Hyper-V de Microsoft llegará a Linux 5.14" . Phoronix . Consultado el 30 de agosto de 2021 .
  105. ↑ "drm: Agregar controlador simpledrm" . git.kernel.org . Consultado el 30 de agosto de 2021 .
  106. ↑ Larabel, Michael (13 de mayo de 2021). "Linux 5.14 traerá el controlador SimpleDRM, VC4 HDR, y marca más código AGP como heredado" . Phoronix . Recuperado el 30 de agosto de 2021 .
  107. ↑ "drm/ofdrm: Agregar ofdrm para framebuffers de Open Firmware" . git.kernel.org . Consultado el 21 de febrero de 2023 .
  108. ↑ Larabel, Michael (20 de octubre de 2022). "Controlador DRM de firmware abierto "OFDRM" Queuing para Linux 6.2" . Phoronix . Recuperado el 21 de febrero de 2023 .
  109. ↑ "drm: Agregar controlador kms para el controlador de pantalla loongson" . git.kernel.org . Consultado el 23 de febrero de 2024 .
  110. ↑ Larabel, Michael (13 de julio de 2023). "Las actualizaciones de controladores gráficos de código abierto comienzan a acumularse para Linux 6.6" . Phoronix . Consultado el 23 de febrero de 2024 .
  111. ↑ "drm/imagination: Agregar controlador PowerVR de esqueleto" . git.kernel.org . Consultado el 27 de mayo de 2024 .
  112. ↑ Larabel, Michael (23 de noviembre de 2023). "Se introducirá un controlador de GPU de código abierto Imaginetion PowerVR en Linux 6.8" . Phoronix . Consultado el 27 de mayo de 2024 .
  113. ↑ "drm/xe: Introduce un nuevo controlador DRM para GPU Intel" . git.kernel.org . Consultado el 27 de mayo de 2024 .
  114. ↑ Larabel, Michael (15 de diciembre de 2023). "El nuevo controlador gráfico del kernel "Xe" de Intel se presenta antes de Linux 6.8" . Phoronix . Consultado el 27 de mayo de 2024 .
  115. ↑ "Fusionar la etiqueta 'drm-misc-next-2024-03-28' en drm-next" . git.kernel.org . Consultado el 3 de agosto de 2025. Se añade el controlador drm/panthor y diversas correcciones.
  116. ↑ Larabel, Michael (26 de marzo de 2024). "Controlador DRM Panthor en cola para Linux 6.10 para admitir las GPU Arm Mali más recientes" . Phoronix . Recuperado el 3 de agosto de 2025 .
  117. ↑ "drm/sysfb: Agregar efidrm para pantallas EFI" . git.kernel.org . Consultado el 3 de agosto de 2025 .
  118. 1 2 Larabel, Michael (10 de abril de 2025). "Los cambios en los controladores de gráficos/pantalla comienzan a acumularse para Linux 6.16 este verano" . Phoronix . Recuperado el 3 de agosto de 2025 .
  119. ↑ "drm/sysfb: Agregar vesadrm para pantallas VESA" . git.kernel.org . Consultado el 3 de agosto de 2025 .
  120. ↑ "drm: eliminar el controlador gamma" . Kernel.org . Consultado el 27 de enero de 2015 .
  121. ↑ " [ DRM ] : Eliminar el código del controlador FFB de sparc64 que nunca se compila" . Kernel.org . Consultado el 27 de enero de 2015 .
  122. ↑ "drm: Eliminar el controlador obsoleto driver-tdfx" . Kernel.org . Consultado el 23 de febrero de 2024 .
  123. ↑ "drm: Eliminar el controlador obsoleto driver-mga" . Kernel.org . Consultado el 23 de febrero de 2024 .
  124. ↑ "drm: Eliminar el controlador obsoleto driver-r128" . Kernel.org . Consultado el 23 de febrero de 2024 .
  125. ↑ "drm: Eliminar el controlador obsoleto driver-i810" . Kernel.org . Consultado el 23 de febrero de 2024 .
  126. ↑ "drm: Eliminar el controlador obsoleto driver-sis" . Kernel.org . Consultado el 23 de febrero de 2024 .
  127. ↑ "drm: eliminar controlador i830" . Kernel.org . Consultado el 27 de enero de 2015 .
  128. ↑ "drm: Agregar soporte para unichrome" . Kernel.org . Consultado el 27 de enero de 2015 .
  129. ↑ "drm: Eliminar el controlador obsoleto driver-via" . Kernel.org . Consultado el 23 de febrero de 2024 .
  130. ↑ "drm: agregar controlador savage" . Kernel.org . Consultado el 27 de enero de 2015 .
  131. ↑ "drm: Eliminar el controlador obsoleto driver-savage" . Kernel.org . Consultado el 23 de febrero de 2024 .
  132. ↑ "Lista de mantenedores del kernel de Linux" . Kernel.org . Consultado el 14 de julio de 2014 .
  133. ↑ "repositorio git de libdrm" . Consultado el 23 de julio de 2014 .
  134. ↑ "Primera versión DRI del controlador 3dfx" . Mesa 3D . Consultado el 15 de julio de 2014 .
  135. ↑ "Importar 2.3.18pre1" . La historia de Linux en formato de repositorio GIT 1992-2010 (2010) . Consultado el 15 de julio de 2014 .
  136. ↑ Torvalds, Linus. "Código fuente de Linux 2.4.0" . Kernel.org . Consultado el 29 de julio de 2014 .
  137. ↑ Airlie, Dave (30 de diciembre de 2004). " [ bk pull ] drm core/personality split" . linux-kernel (Lista de correo).
  138. ↑ Torvalds, Linus (11 de enero de 2005). "Linux 2.6.11-rc1" . linux-kernel (Lista de correo).
  139. ↑ Gettys, James; Packard, Keith (15 de junio de 2004). "La (re)arquitectura del sistema X Window" . Recuperado el 30 de abril de 2016 .
  140. ↑ Smirl, Jon (30 de agosto de 2005). "El estado de los gráficos en Linux" . Recuperado 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 componente de hardware de vídeo. Esto significa que los controladores conflictivos como fbdev y DRM deben integrarse en un sistema cooperativo. También significa que se debe evitar el acceso al hardware desde el espacio de usuario mientras se carga un controlador de dispositivo basado en el kernel.
  141. ↑ Verhaegen, Luc (2 de marzo de 2006). "X y Modesetting: Atrofia ilustrada" (PDF) . Recuperado el 30 de abril de 2016 .
  142. ↑ Glisse, Jerome (4 de diciembre de 2007). "Configuración del modo del kernel de Radeon" . Recuperado el 30 de abril de 2016 .
  143. ↑ Larabel, Michael (1 de octubre de 2008). "El estado de la configuración del modo del kernel" . Phoronix . Recuperado el 30 de abril de 2016 .
  144. ↑ Packard, Keith (21 de julio de 2008). "Estado de salida de X julio de 2008" . Recuperado el 1 de mayo de 2016 .
  145. ↑ "drm: reorganizar el árbol drm para que sea más a prueba de futuro" . Kernel.org .
  146. ↑ "Linux 2.6.28 - El gestor de memoria GEM para la memoria de la GPU" . Linux Kernel Newbies . Consultado el 23 de julio de 2014 .
  147. ↑ "drm: Añadir el subsistema de gestión de memoria de GPU TTM" . Kernel.org .
  148. ↑ "DRM: agregar soporte para configuración de modo" . Kernel.org .
  149. ↑ "DRM: i915: agregar soporte para configuración de modo" . Kernel.org .
  150. ↑ Anholt, Eric (22 de diciembre de 2008). " [ ANUNCIO ] libdrm-2.4.3" . dri-devel (Lista de correo).
  151. ↑ Barnes, Jesse (20 de octubre de 2008). " [ ANUNCIO ] xf86-video-intel 2.5.0" . xorg-announce (Lista de correo).
  152. ↑ "Linux 2.6.31 - Compatibilidad con la configuración del modo kernel de ATI Radeon" . Linux Kernel Newbies . Archivado del original el 5 de noviembre de 2015. Consultado el 28 de abril de 2016 .
  153. ↑ Torvalds, Linus (9 de septiembre de 2009). "Linux 2.6.31" . linux-kernel (Lista de correo).
  154. ↑ "drm/radeon: introduce la configuración de modos del kernel para el hardware radeon" . Kernel.org .
  155. ↑ "The irregular Nouveau Development Companion #40" . Proyecto Nouveau . Consultado el 3 de mayo de 2016 .
  156. ↑ "Linux 2.6.33 - Mejoras gráficas" . Linux Kernel Newbies . Consultado el 28 de abril de 2016 .
  157. ↑ "drm/kms: agregar ioctl de cambio de página" . Kernel.org .
  158. ↑ "Linux 2.6.38 - Gráficos" . Linux Kernel Newbies . Consultado el 28 de abril de 2016 .
  159. ↑ Airlie, Dave (21 de diciembre de 2009). " [ ANUNCIO ] libdrm 2.4.17" . dri-devel (Lista de correo).
  160. ↑ "drm: dumb scanout create/mmap para intel/radeon (v3)" . Kernel.org .
  161. ↑ "Linux 2 6 39-DriversArch" . Linux Kernel Newbies . Consultado el 19 de abril de 2016 .
  162. ↑ Barnes, Jesse; Pinchart, Laurent; Vetter, Daniel; Wunner, Lukas. "Guía del desarrollador de controladores de GPU de Linux: objetos de búfer tontos" . Consultado el 31 de agosto de 2016 .
  163. ↑ Wilson, Chris (11 de abril de 2011). " [ ANUNCIO ] libdrm 2.4.25" . dri-devel (Lista de correo).
  164. ↑ Barnes, Jesse (25 de abril de 2011). " [ RFC ] drm: agregar superposiciones como objetos KMS de primera clase" . dri-devel (Lista de correo).
  165. ↑ Barnes, Jesse (13 de mayo de 2011). " [ RFC ] drm: agregar superposiciones como objetos KMS de primera clase" . dri-devel (Lista de correo).
  166. ↑ "drm: agregar soporte para planos v3" . Kernel.org .
  167. ↑ "drm: agregar ioctls genéricos para obtener/establecer propiedades en cualquier objeto" . Kernel.org .
  168. ↑ Widawsky, Ben (27 de junio de 2012). " [ ANUNCIO ] libdrm 2.4.36" . xorg-announce (Lista de correo).
  169. ↑ Larabel, Michael. "Prueba de concepto: ¡Renderizado multi-GPU de código abierto!" . Phoronix . Consultado el 14 de abril de 2016 .
  170. ↑ Larabel, Michael (23 de febrero de 2012). "DRM Base PRIME Support Part Of VGEM Work" . Phoronix . Recuperado el 14 de abril de 2016 .
  171. ↑ Airlie, Dave (27 de marzo de 2012). " [ PATCH ] drm: soporte base prime/dma-buf (v5)" . dri-devel (Lista de correo).
  172. ↑ Larabel, Michael (30 de marzo de 2012). "Último minuto para Linux 3.4: Soporte para DMA-BUF PRIME" . Phoronix . Recuperado el 15 de abril de 2016 .
  173. ↑ "drm: soporte base prime/dma-buf (v5)" . Kernel.org .
  174. ↑ "Linux 3.4 DriverArch" . Linux Kernel Newbies . Consultado el 15 de abril de 2016 .
  175. ↑ Anholt, Eric (10 de mayo de 2012). " [ ANUNCIO ] libdrm 2.4.34" . dri-devel (Lista de correo).
  176. ↑ Larabel, Michael (12 de mayo de 2012). "DMA-BUF PRIME se unen para Linux 3.5" . Phoronix . Recuperado el 15 de abril de 2016 .
  177. ↑ "Linux 3.5 DriverArch" . Linux Kernel Newbies . Consultado el 15 de abril de 2016 .
  178. ↑ Corbet, Jonathan (11 de septiembre de 2013). "3.12 merge window, part 2" . LWN.net . Consultado el 21 de julio de 2014 .
  179. ↑ "drm: implementar nodos de renderizado experimentales" . Kernel.org .
  180. ↑ "drm/i915: Soporte para nodos de renderizado" . Kernel.org .
  181. ↑ "drm/radeon: Compatibilidad con nodos de renderizado" . Kernel.org .
  182. ↑ "drm/nouveau: Soporte para nodos de renderizado" . Kernel.org .
  183. ↑ Roper, Matt (7 de marzo de 2014). " [ RFCv2 00/10 ] Soporte universal de planos" . dri-devel (Lista de correo).
  184. ↑ Larabel, Michael (2 de abril de 2014). "Conjunto de soporte de plano universal para Linux 3.15" . Phoronix . Recuperado el 14 de abril de 2016 .
  185. ^ Lankhorst, Maarten (25 de julio de 2014). " [ ANUNCIO ] libdrm 2.4.55" . dri-devel (lista de correo).
  186. 1 2 Vetter, Daniel (7 de agosto de 2014). "Cosas interesantes para 3.17" . Recuperado el 14 de abril de 2016 .
  187. ↑ Barnes, Jesse (15 de febrero de 2012). " [ RFC ] drm: API de configuración de modo atómico" . dri-devel (Lista de correo).
  188. ↑ Syrjälä, Ville (24 de mayo de 2012). " [ RFC ] [ PATCH 0/6 ] WIP: drm: Idea de configuración de modo atómico" . dri-devel (Lista de correo).
  189. ↑ Clark, Rob (9 de septiembre de 2012). " [ RFC 0/9 ] cambio de página nuclear" . dri-devel (Lista de correo).
  190. ↑ Clark, Rob (6 de octubre de 2013). " [ RFCv1 00/12 ] Conjunto de modos atómicos/nucleares/cambio de página" . dri-devel (Lista de correo).
  191. ↑ Vetter, Daniel (3 de febrero de 2016). "Abraza la era de las pantallas atómicas" (PDF) . Recuperado el 4 de mayo de 2016 .
  192. ↑ Vetter, Daniel (2 de noviembre de 2014). "Soporte de Atomic Modeset para controladores KMS" . Recuperado el 4 de mayo de 2016 .
  193. ↑ Airlie, Dave (14 de diciembre de 2014). " [ git pull ] drm para 3.19-rc1" . dri-devel (Lista de correo).
  194. ↑ Vetter, Daniel (28 de enero de 2015). "Actualización para las actualizaciones de la pantalla atómica" . Recuperado el 4 de mayo de 2016 .
  195. ↑ Airlie, Dave (15 de febrero de 2015). " [ git pull ] drm pull para 3.20-rc1" . dri-devel (Lista de correo).
  196. ↑ "Linux 4.0 - DriverArch - Gráficos" . Linux Kernel Newbies . Consultado el 3 de mayo de 2016 .
  197. ↑ "Linux 4.2 - API de configuración de modo atómico habilitada por defecto" . Linux Kernel Newbies . Consultado el 3 de mayo de 2016 .
  198. ↑ Velikov, Emil (29 de junio de 2015). " [ ANUNCIO ] libdrm 2.4.62" . dri-devel (Lista de correo).
  199. ↑ Vetter, Daniel (6 de junio de 2016). "Impresionantes avances atómicos" . Recuperado el 7 de junio de 2016. En este momento hay 17 controladores que admiten la configuración de modo atómico integrados en el subsistema DRM .
  200. ↑ Stone, Daniel (20 de marzo de 2018). "Una nueva era para los gráficos de bajo nivel de Linux - Parte 1" . Recuperado el 5 de mayo de 2018 .
  201. ↑ Herrmann, David (10 de diciembre de 2012). "Introducción a KMSCON" . Recuperado el 22 de noviembre de 2015 .
  202. ↑ "Controlador 358.09 (beta) para Linux, Solaris y FreeBSD" . 10/12/2015.
  • Página principal de DRM
  • Guía para desarrolladores de controladores de GPU para Linux (anteriormente Guía para desarrolladores de DRM para Linux )
  • Conferencia sobre Linux embebido 2013 - Anatomía de un controlador KMS embebido en YouTube
Lecturas relacionadas
6 articulos
Núcleo de LinuxNúcleo de LinuxEl núcleo de Linux es un núcleo libre y de código abierto , [12] : 4 similar a UNIX que se utiliza en muchos sistemas informáticos en todo el mundo...Unidad de procesamiento gráficoUnidad de procesamiento gráficoUna unidad de procesamiento gráfico ( GPU ) es un circuito electrónico especializado diseñado inicialmente para el procesamiento de imágenes digita...Tarjeta gráficaTarjeta gráficaVisualizar mediante uno de los siguientes métodos:APIAPIUna interfaz de programación de aplicaciones ( API ) es una conexión entre computadoras o entre programas de computadora . Es un tipo de interfaz d...Espacio de usuario y espacio del kernelUn sistema operativo de computadora moderno generalmente usa memoria virtual para proporcionar espacios de direcciones separados o regiones de un ú...Configuración de modoConfiguración de modoLa configuración de modo es una operación de software que activa un modo de visualización (resolución de pantalla, profundidad de color y frecuenci...