El nucli de Linux ja tenia una API anomenada fbdev, que s'utilitzava per gestionar el framebuffer d'un adaptador de gràfics, però no es podia utilitzar per atendre les necessitats del maquinari de vídeo modern basat en GPU accelerada en 3D. Aquests dispositius normalment requereixen configurar i gestionar una cua d'ordres a la seva pròpia memòria per enviar ordres a la GPU i també requereixen la gestió de les memòries intermèdies i l'espai lliure dins d'aquesta memòria. Inicialment, els programes d'espai d'usuari (com ara el X Server) gestionaven directament aquests recursos, però normalment actuaven com si fossin els únics amb accés a ells. Quan dos o més programes intentaven controlar el mateix maquinari alhora, i establien els seus recursos cadascun a la seva manera, la majoria de vegades acabaven catastròficament.[3]
Without DRM
With DRM
DRM allows multiple programs concurrent access to the 3D video card, avoiding collisions
El gestor de renderització directa es va crear per permetre que diversos programes utilitzin els recursos de maquinari de vídeo de manera cooperativa. El DRM té accés exclusiu a la GPU i és responsable d'inicialitzar i mantenir la cua d'ordres, la memòria i qualsevol altre recurs de maquinari. Els programes que volen utilitzar la GPU envien peticions a DRM, que actua com a àrbitre i s'encarrega d'evitar possibles conflictes.[4]
L'abast del DRM s'ha ampliat al llarg dels anys per cobrir més funcionalitats que abans gestionaven els programes d'espai d'usuari, com ara la gestió de framebuffer i la configuració del mode, objectes per compartir memòria i sincronització de memòria. Algunes d'aquestes expansions van rebre noms específics, com ara Graphics Execution Manager (GEM) o kernel mode-setting (KMS), i la terminologia preval quan s'al·ludeix específicament a la funcionalitat que proporcionen. Però realment són parts de tot el subsistema DRM del nucli.
La tendència d'incloure dues GPU en un ordinador — una GPU discreta i una d'integrada — va provocar nous problemes com el canvi de GPU que també calia resoldre a la capa DRM. Per tal de fer coincidir la tecnologia Nvidia Optimus, DRM es va proporcionar amb capacitats de descàrrega de GPU, anomenades PRIME.
Arquitectura del programari
El gestor de representació directa resideix a l'espai del nucli, de manera que els programes d'espai d'usuari han d'utilitzar les crides al sistema del nucli per sol·licitar els seus serveis. Tanmateix, DRM no defineix les seves pròpies crides de sistema personalitzades. En canvi, segueix el principi Unix de " tot és un fitxer " per exposar les GPU a través de l'espai de noms del sistema de fitxers, utilitzant fitxers de dispositiu sota la jerarquia /dev. Cada GPU detectada per DRM es coneix com a dispositiu DRM i es crea un fitxer de dispositiu /dev/dri/card X (on X és un número seqüencial) per connectar-hi. Els programes d'espai d'usuari que vulguin parlar amb la GPU han d'obrir aquest fitxer i utilitzar crides ioctl per comunicar-se amb DRM. Diferents ioctls corresponen a diferents funcions de l'API DRM.
Es va crear una biblioteca anomenada libdrm per facilitar la interfície dels programes d'espai d'usuari amb el subsistema DRM. Aquesta biblioteca és només un embolcall que proporciona una funció escrita en C per a cada ioctl de l'API DRM, així com constants, estructures i altres elements auxiliars. L'ús de libdrm no només evita exposar la interfície del nucli directament a les aplicacions, sinó que presenta els avantatges habituals de reutilitzar i compartir codi entre programes.
Suport de maquinari
El subsistema DRM de Linux inclou controladors gratuïts i de codi obert per donar suport al maquinari dels 3 principals fabricants de GPU per a ordinadors d'escriptori (AMD, NVIDIA i Intel), així com d'un nombre creixent de GPU mòbil i System on a chip (SoC) integradors. La qualitat de cada conductor varia molt, depenent del grau de cooperació del fabricant i d'altres qüestions.